Cli

docker network rm -f and docker context rm -f share a flag name and do different things. docker network rm --help says its -f means “Do not error if the network does not exist”: a network still attached to a running container survives it regardless. docker context rm --help says its own -f means “Force the removal of a context in use”: on a context, -f genuinely forces removal even while it’s the active one. Both commands describe their own behavior accurately. The trap is assuming -f means the same thing everywhere because it’s the same letter, and skipping the one --help you actually needed to read. docker-destructive-guardrails, the skill this closing post covers, exists for exactly this kind of inconsistency: the places where “it looked like the other command” is how damage happens. ...

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

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

Run docker compose alpha --help and Compose is upfront about what that word means: EXPERIMENTAL: docker compose alpha is an experimental feature. Experimental features provide early access to product functionality. These features may change between releases without warning, or can be removed from a future release. Not a beta, not a preview with a stable target date. A command under alpha can change its flags, its output format, or disappear entirely in the next release, with no deprecation notice. Build a script around one and a routine docker compose upgrade can break it silently. ...

docker compose run creates a fresh container for a service and attaches your terminal to it. Compared to exec (Tip #34), which jumps into a running container, run is for one-shot tasks — migrations, ad-hoc scripts, REPLs, smoke tests. The flags around it decide what gets started, what gets cleaned up, and whether ports are published. –rm — clean up after exit By default, the container created by run stays around (stopped) after the command finishes. That accumulates dead containers fast in a dev loop. --rm removes the container as soon as it exits: ...