Posts

depends_on only guarantees a container has started. It says nothing about whether the process inside is actually ready to take traffic, and a database container that’s up but still replaying its init scripts will happily accept a connection from a service that then fails on its first query. docker-compose-patterns, the skill that fires when the task is service wiring rather than image builds, spends a good part of its rules closing that exact gap. ...

A registry token passed through ARG never shows up in docker run, never gets printed by the app, looks completely invisible. It’s still sitting in the image’s layer history, one docker history away from anyone who pulls it. That’s the exact mistake docker-build-strategies is written to intercept, and it’s one of several the Dockerfile & Build family of Docker Skills, covered here alongside docker-project-foundations, catches before the image ships. Part 1 introduced Docker Skills and the eleven skills it ships. The two skills in this post are deliberately scoped apart: docker-project-foundations handles the case where there’s no Docker setup at all yet, and steps aside once a project has a mature one that only needs minor edits; docker-build-strategies optimizes and hardens an existing Dockerfile, and steps aside when the actual need is that first-pass scaffold, or when the task is really about Compose wiring rather than image internals. Part 3 covers that Compose wiring skill next. ...

AI coding agents write a lot of Dockerfiles and Compose files these days, and most of them are mediocre: latest tags, missing health checks, credentials baked into layers, root users left in place. Not because the models don’t know better in the abstract, but because “Docker best practice” is scattered across docs, blog posts, and tribal knowledge, and a generic coding agent has no reliable way to pull the right piece of it into a given prompt. This week Docker open-sourced docker/skills, a small collection of files meant to fix exactly that. This is the first post in a series that walks through what’s in it; today is the overview, later posts go deep on each product family. ...

depends_on reads fine when a Compose file has two or three services. Past that, tracing who starts after whom means scrolling between blocks and holding the chain in your head. docker compose alpha viz reads the same file and prints the graph instead. docker compose alpha viz What it prints Against a two-service file (web depending on db), the default output is a minimal Graphviz digraph: digraph "myapp" { layout=dot; "db" [style="filled" label=<<font point-size="15">db</font>>]; "web" [style="filled" label=<<font point-size="15">web</font>>]; "web" -> "db"; } Add --image, --ports, and --networks and each node’s label grows to match: ...

Run this from a container whose process is uid 0: services: hardened: image: alpine cap_drop: - ALL command: sh -c "touch /tmp/f && chown 2000:2000 /tmp/f && echo OK" docker compose run --rm hardened chown: /tmp/f: Operation not permitted Tip #29 listed which cap_add values pair with which workload. This is the part worth sitting with: cap_drop: ALL just took a privilege away from uid 0, not from some non-root user it was supposedly protecting against. ...