{"id":4729,"date":"2026-03-07T21:02:30","date_gmt":"2026-03-07T15:32:30","guid":{"rendered":"https:\/\/itsupportwale.com\/blog\/master-docker-compose-simplify-multi-container-workflows\/"},"modified":"2026-03-07T21:02:30","modified_gmt":"2026-03-07T15:32:30","slug":"master-docker-compose-simplify-multi-container-workflows","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/master-docker-compose-simplify-multi-container-workflows\/","title":{"rendered":"Master Docker Compose: Simplify Multi-Container Workflows"},"content":{"rendered":"

text
\n[2024-05-24T03:14:22.891Z] ERROR: worker-node-04 kernel: [192834.12] Out of memory: Killed process 28491 (python3) total-vm:4.2GB, anon-rss:3.8GB, file-rss:0B, shmem-rss:0B, uid:1000 pgtables:8420kB oom_score_adj:0
\n[2024-05-24T03:14:23.002Z] CRITICAL: container_id=f3a2b1c0d9e8 exited with code 137.
\n[2024-05-24T03:14:23.450Z] DEBUG: Attempting manual restart of service ‘api-gateway’…
\n[2024-05-24T03:14:23.501Z] ERROR: docker: Error response from daemon: driver failed programming external connectivity on endpoint api-gateway (hash): Bind for 0.0.0.0:8080 failed: port is already allocated.
\n[2024-05-24T03:14:24.110Z] FATAL: Network collision detected on bridge br-f92a11c82. Context propagation failed. Race condition in manual container deployment.<\/p>\n

It is 04:30 AM on a Sunday. I have been staring at a flickering terminal for forty-eight hours because one of you "cowboy" developers decided that writing a declarative configuration was too much work for a "quick fix" on Friday afternoon. You thought running a raw `docker run` command directly on the staging host was a shortcut. Instead, you created a cascading failure that triggered an OOMKill, wiped out the ephemeral storage of three sidecars, and left me untangling a web of orphaned network namespaces that looked like a bowl of digital spaghetti.\n\nI am done. My patience has evaporated along with my weekend. This isn't a suggestion. This isn't a "best practice" shared over a latte. This is a mandatory shift in how we operate. As of Docker Engine 26.1.4, we are officially banning the use of raw `docker` commands for anything other than `ps` or `logs`. If I catch another person manually mapping ports or injecting environment variables via the CLI, I will revoke your SSH access faster than the kernel can reclaim leaked memory.\n\nWe are moving to `docker compose` v2.27.0. Exclusively. Here is why your manual workflow is a liability and why this manifesto is the only thing standing between you and a formal performance review.\n\n## The Myth of the "One-Liner" and the Death of Reproducibility\n\nYou think you\u2019re being fast. You type `docker run -d -p 8080:80 --name my-app my-image:latest` and walk away. But you\u2019ve just committed a crime against reproducibility. Where is the record of that command? It\u2019s buried in your shell history, which will be purged. It\u2019s not in version control. It\u2019s not peer-reviewed.\n\nWhen that container crashed at 3 AM, I had no idea what environment variables you passed to it. I didn't know if you set memory limits (you didn't, which is why the OOMKiller nuked the entire node). I didn't know which network you attached it to. Using `docker compose` forces you to define the state of the world in a YAML file that lives in Git. It turns your "tribal knowledge" into a documented, executable reality.\n\nWithout a `docker-compose.yml`, we are guessing. And in SRE, guessing is just a slow way of failing.\n\n## Why Your Manual Port Mapping is a Security Nightmare\n\nLast night, the "Friday Night Massacre" happened because two of you tried to run different versions of the same microservice on the same host using manual `docker run` commands. One of you mapped `8080:80`. The other tried `8080:80` and failed, so you "cleverly" changed it to `8081:80`. \n\nYou didn't realize that the application logic was hardcoded to look for a specific port on the bridge gateway. By bypassing `docker compose`, you bypassed the internal DNS resolution that `docker compose` provides by default. In a `docker compose` environment, services talk to each other by service name over an isolated virtual bridge. You don't need to expose ports to the host interface at all unless it's the actual ingress point.\n\nWhen you use raw commands, you end up exposing internal databases to `0.0.0.0` just so your worker container can find them. You\u2019re opening the front door to the entire internet because you\u2019re too lazy to define a network namespace.\n\n## The YAML Indentation Hell We Deserve (And Why It\u2019s Better)\n\nLook at this mess. This is what I found on the staging server\u2014a shell script trying to mimic what `docker compose` does natively. It\u2019s fragile, it\u2019s ugly, and it failed the moment a container didn't exit cleanly.\n\n### Code Block 1: The "Cowboy" Failure (What NOT to do)\n```bash\n# This is garbage. Do not do this.\ndocker run -d --name redis-prod redis:7.0\ndocker run -d --name python-worker \\\n  -e REDIS_HOST=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' redis-prod) \\\n  --memory="2g" \\\n  my-python-app:v1.2\n# Result: If redis-prod restarts and gets a new IP, python-worker breaks. \n# There is no healthcheck. There is no retry logic.\n<\/code><\/pre>\n
The above is why I was paged. The Redis container restarted, the IP changed, and the Python worker spent four hours screaming into the void because it had a hardcoded IP address injected at runtime. <\/p>\n
Now, look at how we are doing it moving forward. We are using docker compose<\/code> to handle the service discovery. The internal DNS server built into the Docker daemon handles the mapping of the service name redis<\/code> to whatever ephemeral IP the container currently holds.<\/p>\n
\n
Table of Contents<\/p>\n