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

docker compose alpha generate mycontainer --name myapp Point that at a container that’s already running and it inspects it, then writes back the Compose file you’d otherwise have to write by hand. Tip #28 covered that translation manually; generate does it straight from what’s actually running. What it produces Run it against a container started with docker run -p 127.0.0.1:8080:80 nginx:alpine: services: mycontainer: scale: 1 image: nginx:alpine environment: PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin NGINX_VERSION: "1.31.5" labels: maintainer: "NGINX Docker Maintainers <docker-maint@nginx.com>" ports: - host_ip: "127.0.0.1" target: 80 published: "8080" protocol: tcp It reads networks, volumes, and healthchecks the same way, and --format json swaps the output format if you’d rather feed it into other tooling. Note the environment and labels above: they include everything baked into the image, not just what you passed on the command line. Useful for capturing what a container actually runs with, but expect to trim the output before committing it. ...

Tip #3 stopped at condition: service_healthy. The long-form depends_on syntax has three more fields, each solving a different problem: services: api: build: . depends_on: migrate: condition: service_completed_successfully cache: condition: service_started restart: true metrics: condition: service_started required: false service_completed_successfully: wait for a one-shot to finish service_healthy waits for a long-running service to become ready. service_completed_successfully waits for a service to exit, and only starts the dependent if it exited zero: ...