Docker

Around 3 years ago I’ve checked the age of various base images available on Docker Hub. Curiosity recently got the better of me, prompting another investigation into the current state of affairs. Since then, there have been significant changes: CentOS 8 has reached its end of life  external link , prompting a shift to CentOS 8 Stream  external link , which is also nearing its demise 🤣 OpenJDK images have been deprecated  external link and no longer receiving updates. They recommend to switch to alternatives such as: Amazon’s Corretto or Eclipse Temurin (formely AdoptOpenJDK). Let’s delve into the findings: ...

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. ...

Working with Docker environments amid diverse architectures, like Apple’s arm64 and x86-64/AMD64, presents challenges. I’ve encountered the clash between my Mac’s M1 arm64 architecture and my x86-centric server workloads. The solution? Just use DOCKER_DEFAULT_PLATFORM 1 2. Just run in the terminal: Enforce platform for all commands export DOCKER_DEFAULT_PLATFORM=linux/amd64 With this command, Docker enforces x86 architecture by default on commands supporting --platform parameter, streamlining workflows and sparing the need for repetitive --platform specifications. ...

One day, I was looking for some gains to improve the startup time for Jenkins agents. We run them as containers and because images are quite big, I was thinking about cutting the size, by cutting less frequently used features. I was looking for the metrics I could use to decide which changes are most valuable. I could think about two: download time and startup time. Together they combine to the gap between the request to start agent and the moment you can start to use it. Sadly it wasn’t that easy to measure that and collect statistics. It’s also not that practical, when you’re developing improvement as you can’t see the difference. ...

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. ...

I switched recently from Docker Desktop  external link on my MacBook to Rancher Desktop  external link . The most important reason for me to do it, was possibility to gently switch between docker and containerd runtimes. There’s still one feature that I miss on Rancher Desktop - possibility to change Docker daemon configuration. I used to enable experimental features1 and BuildKit2. Sadly, there’s no easy way to do it on Rancher… But there’s a magical way3. ...

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. ...