Minimal or distroless container images provide only the components required to run an application. By design, they exclude shells and common troubleshooting utilities. While this keeps images small and secure, reality kicks in when you need to debug something. You could find yourself needing a shell for runtime initialization scripts, health checks, or troubleshooting. ...
I previously described how I think container base images should be built. This post turns that idea into a working example. Usually a container image starts with something like FROM: python:3.x or FROM debian:bookworm-slim. What gets pulled in is more than just a runtime. It’s an entire filesystem assembled by an upstream distribution. The filesystem often includes tools and binaries that aren’t required for the application. They’re not necessarily harmful, but they are unexplained. When a container image includes a Perl interpreter, USB utilities, or terminal tooling that the application never uses, it raises a simple question. Why is that there? ...
Many container images start with FROM python:3.x. What gets imported is not only Python, its a preassembled filesystem of decisions you didn’t make. Understanding what’s inherited from the base image is key to building container images. Instead of implicitly trusting what’s included with the base image, think of the image as a collection of artifacts that are intentionally assembled. Large Container Images The official Python container image hosted on Docker Hub is a great demonstration of inheriting unknown layers. For Linux environments, the Python image comes with either a Debian or Alpine base image. Both base images come with additional applications not required by Python. ...
There’s a popular myth in the Docker community. The myth is that it’s possible to mount /var/run/docker.sock with read only options. Even large container projects like Traefik get this wrong. Bind mounting the Docker socket with read only options doesn’t work the way one thinks it would. This post will explain how using the ":ro" option when mounting the Docker socket is little more than security theater and to discuss alternatives. Please read this post if you’re adding /var/run/docker.sock:/var/run/docker.sock:ro to Docker compose files. ...
Who Should Not Read This Post This post does not discuss: data support for multiple writers having zero downtime cloud-scale best practices Instead I discuss embracing single points of failure (SPOF) in exchange for simplicity within environments that can tolerate downtime. Permission to Not Over-Engineer In environments that tolerate downtime, having a SPOF is great because they are simple to deploy and it’s obvious what failed. Lets examine the typical home router. In addition to routing packets between the LAN and the Internet, the home router also provides DHCP and DNS services. Then someone learns of PiHole and runs it on a separate device like a Raspberry PI. Now the router queries PiHole for adblock entries during DNS resolution. Ad-free browsing works works great; until HTTP requests stop working. With this scenario, it’s not obvious if it’s an issue on the router or an issue with PiHole. ...
With Docker, it’s not always obvious what storage options exist beyond the built-in local volume driver or a traditional bind mount. Exploring Docker volume drivers often turns up archived GitHub repositories or commercially backed plugins tied to specific cloud storage products. The volume ecosystem is especially limited for on-premise storage, and many plugins require more privileges than you’d expect. In this post, I’ll cover how Docker handles volume storage under the hood. I’ll also walkthrough how to create a volume plugin that interacts with remote storage without needing CAP_SYS_ADMIN privileges. ...