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. ...
Linux isolates containers using kernel namespaces. Sometimes you need the opposite: two containers that can see each other’s processes or share memory. The pid and ipc directives give you that escape hatch. Sharing a PID namespace pid: service:<name> lets a container see and act on processes inside another service: services: app: image: myapp debugger: image: alpine pid: service:app cap_add: - SYS_PTRACE command: sleep infinity The debugger container’s ps, strace, and /proc all reflect app’s processes. Combined with cap_add: SYS_PTRACE, you can attach strace or gdb to a running production-style container without baking debug tools into its image. ...
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. ...
A container is running but your app feels sluggish. Is it CPU-bound? Leaking memory? Stuck on a runaway process? Compose gives you two essential commands to find out: docker compose top and docker compose stats. docker compose top Show running processes inside each service’s container: docker compose top myapp-web-1 UID PID PPID C STIME TTY TIME CMD root 12345 12320 0 09:15 ? 00:00:02 nginx: master process nobody 12400 12345 0 09:15 ? 00:00:00 nginx: worker process myapp-api-1 UID PID PPID C STIME TTY TIME CMD node 12500 12480 2 09:15 ? 00:01:45 node server.js node 12600 12500 0 09:15 ? 00:00:12 node worker.js You see every process running inside each container with their CPU usage (C column) and CPU time. Perfect for spotting runaway workers or unexpected child processes. ...