IMAGE CREATED CREATED BY SIZE COMMENT\n<missing> 3 hours ago COPY . . # buildkit 1.8GB \n<missing> 3 hours ago RUN \/bin\/sh -c apt-get update && apt-get install -y python3-pip git vim curl wget build-essential cmake cuda-toolkit-12-1 # buildkit 2.1GB \n<missing> 3 hours ago RUN \/bin\/sh -c pip install -r requirements.txt # buildkit 300MB \n<missing> 4 weeks ago \/bin\/sh -c #(nop) CMD ["\/bin\/bash"] 0B \n<missing> 4 weeks ago \/bin\/sh -c #(nop) ADD file:702967679848520898520984520984520984520984520984520984520984520 in \/ 77.8MB \n<\/code><\/pre>\nThe COPY . .<\/code> command pulled in the entire .git<\/code> directory (800MB), the local venv<\/code> (600MB), and a bunch of raw .csv<\/code> test data (400MB) because the developer didn’t know what a .dockerignore<\/code> file was. The apt-get<\/code> layer is a crime against humanity. They didn’t use --no-install-recommends<\/code>, and they didn’t clean up \/var\/lib\/apt\/lists\/<\/code>. <\/p>\nThis is why we can’t have nice things.<\/p>\n
\n<\/span>3. THE COMMANDMENTS OF SANITY<\/span><\/h3>\n<\/span>H2: STOP USING ‘LATEST’ BEFORE YOU KILL US ALL<\/span><\/h4>\nIf you use FROM python:latest<\/code> or FROM node:latest<\/code>, you are playing Russian Roulette with the production environment. “Latest” is a moving target. When the Python maintainers decide to switch the base image from Debian Bullseye to Bookworm, or change the default OpenSSL version, your build is going to break. Or worse, it\u2019s going to build successfully but fail at runtime with a GLIBC_2.34 not found<\/code> error.<\/p>\nYou must use specific, immutable tags. Not just python:3.11<\/code>. Use python:3.11.9-slim-bookworm<\/code>. This tells me exactly what the runtime environment is, what the underlying OS is, and it ensures that when I rebuild this image in six months, I get the same result. This is the first rule of docker best<\/strong> practices: reproducibility is not optional.<\/p>\n<\/span>H2: YOUR LAYERS ARE FAT AND YOU SHOULD FEEL BAD<\/span><\/h4>\nDocker images are a stack of read-only layers. Every RUN<\/code>, COPY<\/code>, and ADD<\/code> instruction creates a new layer. If you do this:<\/p>\nRUN apt-get update\nRUN apt-get install -y heavy-package\nRUN rm -rf \/var\/lib\/apt\/lists\/*\n<\/code><\/pre>\nYou have failed. The heavy-package<\/code> is still there in the second layer. Deleting it in the third layer doesn’t remove it from the image; it just hides it in the top layer’s view. The bits are still being pushed to the registry.<\/p>\nYou must chain your commands:<\/p>\n
RUN apt-get update && apt-get install -y \\\n --no-install-recommends \\\n heavy-package \\\n && rm -rf \/var\/lib\/apt\/lists\/*\n<\/code><\/pre>\nAnd for the love of everything holy, use multi-stage builds<\/strong>. Your runtime image doesn’t need gcc<\/code>, make<\/code>, git<\/code>, or the headers for every library you compiled. Build your wheels in a builder<\/code> stage, then copy only the artifacts to a slim<\/code> or distroless<\/code> final stage.<\/p>\n<\/span>H2: ROOT IS FOR GOD AND IDIOTS, AND YOU AREN’T GOD<\/span><\/h4>\nRunning your application as root<\/code> inside a container is a firing offense in my book. If there is a container escape vulnerability (and there will be), you\u2019ve just handed the attacker a golden ticket to the host kernel. <\/p>\nModern namespaces and cgroups v2 provide isolation, but they aren’t magic. If your process is UID 0, and it manages to break out via a shocker<\/code> style exploit or a misconfigured volume mount to \/var\/run\/docker.sock<\/code>, the game is over. <\/p>\nAlways create a system user and switch to it:<\/p>\n
RUN groupadd -g 10001 appuser && \\\n useradd -u 10000 -g appuser appuser\nUSER 10000\n<\/code><\/pre>\nNotice I used explicit UIDs. This prevents collisions with the host system and makes it easier to manage file permissions on persistent volumes.<\/p>\n
<\/span>H2: SIGNAL PROPAGATION OR: WHY YOUR APP TAKES 30 SECONDS TO DIE<\/span><\/h4>\nWhen Kubernetes sends a SIGTERM<\/code> to your pod, it\u2019s politely asking your app to finish its current request, close database connections, and exit. If your app is running as a sub-process of a shell script, it will never see that signal.<\/p>\nIf you use CMD my-app.sh<\/code>, Docker runs it as \/bin\/sh -c my-app.sh<\/code>. The shell (PID 1) does not forward signals to its children. When the 30-second terminationGracePeriodSeconds<\/code> expires, the kernel sends a SIGKILL<\/code>, which is like pulling the power plug. This leads to corrupted state and broken transactions.<\/p>\nUse the “exec form”: ENTRYPOINT [\"\/usr\/bin\/my-app\"]<\/code>. This runs your app as PID 1. If your app can’t handle being PID 1 (e.g., it doesn’t reap zombie processes), use tini<\/code> as your entrypoint. It\u2019s a tiny init binary designed exactly for this.<\/p>\n