docker compose down looks like a tidy shutdown command. It is, but the flags around it decide whether you walk away with your data intact, with a clean image store, or with a database wiped because you typed -v out of habit. The default behavior Without any flag, down stops and removes: Every container in the project The default network Compose created for the project Anonymous volumes that the stack was using It does not remove: ...
docker compose ps shows the services inside the current project. docker compose ls zooms out: every Compose stack running anywhere on the host, regardless of which directory you happen to be standing in. The basics Run it from any directory: docker compose ls Sample output: NAME STATUS CONFIG FILES api-platform running(4) /home/dev/api-platform/compose.yaml data-pipeline running(2) /home/dev/data-pipeline/compose.yaml old-prototype exited(3) /tmp/prototype/compose.yaml Three columns: the project name, how many services are up, and the path to the Compose file that started it. No need to cd into the project to see what’s running. ...
docker compose up --wait (Tip #51) waits for services to become healthy. docker compose wait does something different: it waits for services to exit, and returns their exit code. Basic usage docker compose wait <service> The command blocks until the specified service stops, then prints the exit code. If you echo $? after, it’s the same value. This is perfect for one-shot services: migrations, batch jobs, test runners, anything that runs and exits. ...
Need to grab a log file out of a container? Push a quick config change for a one-off test? Don’t redeploy with a bind mount, just use docker compose cp. Basic usage The syntax mirrors docker cp but resolves service names instead of container IDs: # Copy from container to host docker compose cp <service>:<container-path> <host-path> # Copy from host to container docker compose cp <host-path> <service>:<container-path> The direction is determined by which side has the service: prefix. ...
Know the difference between exec and run! Each has its place in your debugging toolkit. The key difference exec: Runs commands in an existing container run: Creates a new container # Exec: enters running container docker compose exec web bash # Run: starts new container docker compose run web bash When to use exec Use exec for debugging running services: # Debug a running web server docker compose exec web bash # Check logs inside container docker compose exec web tail -f /var/log/app.log # Run database queries docker compose exec db psql -U postgres # Check process list docker compose exec web ps aux # Test connectivity from inside docker compose exec web curl http://api:3000/health Important: Container must be running! ...