text
\n$ docker compose up -d
\n[+] Running 5\/5
\n \u283f Network infrastructure_default Created 0.1s
\n \u283f Container postgres-db Started 0.5s
\n \u283f Container redis-cache Started 0.4s
\n \u283f Container backend-api Error 2.1s
\n \u283f Container frontend-app Started 0.8s<\/p>\n
Error response from daemon: failed to mount local volume: mount \/home\/sre_hell\/app\/config:\/etc\/app\/config, flags: 0x1000: no such file or directory<\/p>\n
$ docker compose logs –tail=20 backend-api $ docker compose ps Let\u2019s break down why this doesn’t suck. First, the Second, the environment variables. Using Third, the Table of Contents<\/p>\n
\nbackend-api | 2024-05-22T03:14:11Z CRITICAL: Failed to load configuration from \/etc\/app\/config\/settings.yaml
\nbackend-api | 2024-05-22T03:14:11Z CRITICAL: Traceback (most recent call last):
\nbackend-api | 2024-05-22T03:14:11Z CRITICAL: File “\/app\/main.py”, line 42, in
\nbackend-api | 2024-05-22T03:14:11Z CRITICAL: config = load_config()
\nbackend-api | 2024-05-22T03:14:11Z CRITICAL: FileNotFoundError: [Errno 2] No such file or directory: ‘\/etc\/app\/config\/settings.yaml’
\nbackend-api | 2024-05-22T03:14:11Z INFO: Exiting with code 1<\/p>\n
\nNAME IMAGE COMMAND SERVICE STATUS PORTS
\nbackend-api myapp-backend “python3 main.py” backend exited (1)
\nfrontend-app myapp-frontend “nginx -g ‘daemon of\u2026” frontend running 0.0.0.0:80->80\/tcp
\npostgres-db postgres:15-alpine “docker-entrypoint.s\u2026” postgres running 5432\/tcp
\nredis-cache redis:7-alpine “docker-entrypoint.s\u2026” redis running 6379\/tcp<\/p>\nDammit. Another volume mount collision because some "full-stack" wizard decided to use absolute paths in a shared `docker-compose.yml` without checking if the directory exists on the host. It\u2019s 4:00 AM. I\u2019ve been awake for 72 hours because our staging environment\u2014which some genius decided should "just run docker compose on an EC2 instance"\u2014imploded.\n\n## The Rant: Why Your Local Environment is a House of Cards\n\nI am tired of hearing about "developer experience." You know what provides a good experience? A system that doesn't catch fire when you look at it sideways. For the last three days, I\u2019ve been cleaning up the mess left behind by a team that thinks "DevOps" is a buzzword you put on a LinkedIn profile rather than a grueling discipline of managing state and failure modes. We had a "magic" setup script. It was 4,000 lines of Bash that wrapped Docker commands in a warm blanket of false security. It used `sed` to inject environment variables. It used `awk` to parse container IDs. It was a nightmare.\n\nWhen that script inevitably failed because someone updated their macOS to a version that changed how `\/tmp` permissions work, the entire engineering team ground to a halt. That\u2019s when I stepped in. I stripped away the "magic." I deleted the Bash scripts. I forced everyone back to raw `docker compose`. \n\nWhy? Because `docker compose` is the least-worst way to define a multi-container application. It isn't perfect. YAML is a formatting trap designed by people who hate parsers. But at least it\u2019s a standard. When I look at a `docker-compose.yml` file, I don't have to wonder what a custom wrapper script is doing to my iptables. I can see the networking, the volumes, and the resource constraints\u2014or the lack thereof, which is usually why the backend service is hitting Exit 137 (OOMKilled) because someone tried to run a Java heap inside a 512MB container.\n\nThe problem isn't the tool; it's the philosophy. The "Move Fast and Break Things" crowd treats the local environment like a playground. I treat it like a laboratory. If your local setup doesn't mirror the failure modes of production, your local setup is a lie. If you aren't using `healthcheck` keys, you aren't doing local development; you're just hoping for the best. If you aren't defining `mem_limit`, you're just waiting for a memory leak to freeze your entire laptop. I rebuilt our stack using `docker compose` because I needed a declarative source of truth that didn't require a PhD in shell scripting to debug. I needed to see exactly how the Redis sidecar was talking to the main API, and I needed to ensure that the Postgres container actually waited for the migrations to finish before the backend started spamming connection requests.\n\n## The Deep Dive: Anatomy of a Stable YAML\n\nLet\u2019s look at how a professional sets up a multi-container environment. We aren't using the "version 3" syntax anymore\u2014that\u2019s deprecated. We are using the Compose Specification. If I see `version: '3.8'` at the top of your file, I already know you haven't read the documentation in two years.\n\nHere is the base layer of a functional backend service. Notice the lack of "latest" tags. If you use `image: postgres:latest`, you are a liability to this company.\n\n```yaml\nservices:\n postgres:\n image: postgres:15.6-bookworm # Specific version, Debian-based for stability\n container_name: postgres-db\n environment:\n POSTGRES_USER: ${DB_USER:-postgres}\n POSTGRES_PASSWORD: ${DB_PASSWORD?Error: DB_PASSWORD not set}\n POSTGRES_DB: application_db\n volumes:\n - postgres_data:\/var\/lib\/postgresql\/data\n healthcheck:\n test: ["CMD-SHELL", "pg_isready -U postgres"]\n interval: 5s\n timeout: 5s\n retries: 5\n networks:\n - backend-network\n deploy:\n resources:\n limits:\n memory: 1gb\n\n backend:\n build:\n context: .\/backend\n dockerfile: Dockerfile.dev\n target: development\n depends_on:\n postgres:\n condition: service_healthy\n redis:\n condition: service_started\n env_file: .env\n volumes:\n - .\/backend:\/app:delegated # 'delegated' for macOS performance\n networks:\n - backend-network\n ports:\n - "8080:8080"\n<\/code><\/pre>\nhealthcheck<\/code>. Most developers just use depends_on: - postgres<\/code>. That only tells Docker to wait until the Postgres container<\/em> is running. It doesn’t mean the database is ready to accept connections. The condition: service_healthy<\/code> flag ensures the backend doesn’t even attempt to start until pg_isready<\/code> returns a 0 exit code. <\/p>\n${VAR?error}<\/code> is a lifesaver. It forces the docker compose<\/code> command to fail immediately if a required variable is missing from the .env<\/code> file, rather than letting the container start and crash with an obscure “Connection Refused” error because the password was an empty string.<\/p>\ndelegated<\/code> flag on the volume. If you are on macOS, the virtiofs or gRPC FUSE overhead for file syncing is a performance killer. Using delegated<\/code> tells Docker that the host’s view is authoritative and it’s okay if the container’s view is slightly out of sync for a few milliseconds. It\u2019s the difference between a 2-second hot reload and a 20-second one.<\/p>\n