Best Practices

A Guide to using git pull --rebase effectively Using git pull --rebase as your default merge strategy offers several benefits, particularly in maintaining a clean and linear commit history, which can simplify collaboration and code review. However, users may occasionally encounter the error “Cannot rebase onto multiple branches”. This article explains why this happens and provides a solution to make git pull --rebase work seamlessly. Benefits of git pull --rebase Linear History: Rebasing applies your local commits on top of the upstream changes, creating a straight line of commits without unnecessary merge commits. This makes the project history easier to read and understand. ...

When it comes to building Docker images, adhering to the “Filesystem Hierarchy Standard”12 can greatly enhance the organization and maintainability of your containers. Unfortunately, it’s not uncommon to encounter Docker images where files are haphazardly scattered across directories, leading to confusion and unnecessary complications. Let’s delve into some best practices to ensure your Dockerfiles follow the FHS guidelines, thus avoiding common pitfalls and streamlining your container development process. Below you can find the most important directories, from the perspective of Docker images. /dev or /root rarely are useful here. ...

I’ve been writing recently about best practices for patching and deprecating Docker images , but today I want to show how to automate a huge part of this process. You might already hear about Dependabot1, it’s a Github’s way to notify developers about security vulnerabilities in their projects. Renovate2 is similar tool3, but doesn’t require Github. For my professional work I use Bitbucket, so Renovate feels more universal as can be used anywhere. ...

Intro One of the biggest benefits of Docker images is their immutability. Once they’re built, they don’t change. Built once, would work forever… That’s how nightmares of security guys starts 🤣 We have then two contradictory concepts: flowchart LR id1(Keep it stable) <---> id2(Keep is up to date and secure) For day to day work, usually first concept wins. You want your builds stable and try to avoid tempting distractions of upgrading log4j to latest version… Who knows what might break. That’s fine, makes sense. ...

TL;DR While reasoning is important, readers may not be interested in all the frustrations I experienced while figuring out how to get things done. If you’re looking for a quick solution, skip to the “What eventually worked?” section. However, if you’re interested in the thought process behind the solution, keep reading. Why? Some might bother why the hell I’d like to make my life so hard? 🤣 We used to use nodeenv  external link for that purpose. It provides a simple script that allows to fetch any version of Node. You have to configure PATH variable and you’re done. It’s very simple from the perspective of Docker images operator. There’s one problem with nodeenv comparing it to the nvm - popularity. ...

IMO people don’t understand how VOLUME1 works so they don’t use it. It’s generally used far too rarely! In short VOLUME means two things: Whatever is left in directory marked as VOLUME, stays there and can’t be changed in later layers (actually it can be changed but changes won’t be persistent). Volumes are not part of layered image FS. They’re mounted as anonymous volumes located on standard file system. This means they’re working much faster. Let me explain it a bit. ...

People often complain, that building Docker image takes a long time. “I just added a single jar package” they say… Really? They often don’t remember that whole “build context”1 is uploaded to Docker daemon during build, which often means they’re not only adding “single jar”, but also all sources, test results and whatever they have in working directory. Solution is simple - to use .dockerignore file2. Syntax is similar to .gitignore. It excludes what shouldn’t be uploaded to Docker daemon. ...

I’ve been thinking for a long time about writing set of articles on the topic of: “Dockerfile writing best practices”. As it’s often my daily job to prepare best in class containers, that are later used by thousands of company’s applications, I have quite good insights on the topic. Some experience and knowledge gathered is often against intuition and building it took me a while. I want to share it, with a hope that feedback I get will allow me to excel on the topic even further. ...