{"id":4723,"date":"2026-02-25T21:43:33","date_gmt":"2026-02-25T16:13:33","guid":{"rendered":"https:\/\/itsupportwale.com\/blog\/master-docker-compose-a-guide-to-multi-container-apps\/"},"modified":"2026-02-25T21:43:33","modified_gmt":"2026-02-25T16:13:33","slug":"master-docker-compose-a-guide-to-multi-container-apps","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/master-docker-compose-a-guide-to-multi-container-apps\/","title":{"rendered":"Master Docker Compose: A Guide to Multi-Container Apps"},"content":{"rendered":"

[2023-10-14 03:14:22] ERROR: Could not bind to port 8080. Address already in use.
\n[2023-10-14 03:14:22] DEBUG: Attempting to kill existing container ‘api_v2_final_FINAL’…
\n[2023-10-14 03:14:23] Error response from daemon: No such container: api_v2_final_FINAL
\n[2023-10-14 03:14:23] CRITICAL: Bash script ‘deploy_magic.sh’ exited with code 127.
\n[2023-10-14 03:14:23] CRITICAL: Database connection string ‘localhost:5432’ failed.
\n[2023-10-14 03:14:23] FATAL: Production is down. 404 errors spiking.
\n[2023-10-14 03:14:24] SMS ALERT: [SRE_TEAM] – Wake up. The world is ending. Kevin pushed a script.<\/p>\n

It\u2019s 4:00 AM. I\u2019ve consumed enough caffeine to kill a small horse, and I\u2019m staring at a terminal screen that looks like a digital crime scene. The culprit? A 400-line bash script written by a junior developer who thought he could "simplify" our deployment process by manually wrapping `docker run` commands. \n\nHe didn't use a manifest. He didn't use an orchestrator. He used "hope" and a series of nested `if` statements that checked for the existence of PID files that hadn't been relevant since 2012. \n\nThe result? A cascading failure where the API tried to start before the database, the database couldn't find its volume because the path was hardcoded to a directory on Kevin's laptop, and the frontend was trying to talk to a Redis instance that existed only in the ethereal plane of a misconfigured bridge network.\n\nIf you are still using manual bash scripts to manage your containers, you are a liability. If you aren't using **docker compose**, you are essentially playing Jenga with a live grenade. This isn't about "streamlining" your workflow. This is about survival. This is about having a single source of truth that doesn't rely on the fragile memory of a human who hasn't slept.\n\n## The Manual Script That Tried To Kill Me\n\nLet\u2019s look at what I found when I logged into the production jump box. Kevin\u2019s script was a masterpiece of incompetence. It tried to manage container lifecycles using `grep` and `awk` to find container IDs. \n\n```bash\n# DO NOT DO THIS. EVER.\ndocker stop $(docker ps -a -q --filter name=web)\ndocker rm $(docker ps -a -q --filter name=web)\ndocker run -d --name web_app_v3 -p 80:8080 --link db_prod:db myapp:latest\n<\/code><\/pre>\n
The --link<\/code> flag? That\u2019s been deprecated for years. It\u2019s a ghost. A relic. And yet, there it was, failing because the db_prod<\/code> container had crashed five minutes earlier due to an unhandled OOM (Out Of Memory) event that the script didn’t bother to monitor.<\/p>\n
When you use docker compose<\/strong>, you aren’t just running containers; you are defining a state. You are telling the Docker Engine: “This is what the world should look like. Make it so.” With docker compose version v2.20.2<\/strong>, we have the power to define dependencies, healthchecks, and resource constraints in a way that a bash script never could.<\/p>\n
The manual approach fails because it is imperative. “Do this, then do that.” If “this” fails, “that” happens anyway, or the whole thing hangs. docker compose<\/strong> is declarative. It doesn’t care about the “how” as much as the “what.”<\/p>\n
\n
Table of Contents<\/p>\n