Docker Compose

You may be disapointed as me to find out that .env file doesn’t work with Docker Swarm as it does with Docker Compose. This limitation can be frustrating, but there are some approaches. A quick fix lazy approach and a more secure one that includes Docker secrets. the quick fix lazy approach Navigate to your directory containing both .env and docker-compose.yml, then run: export $(cat .env) > /dev/null 2>&1; docker stack deploy <your_stack_name> --compose-file=docker-compose.yml This command reads your .env file and sets all secrets as env variables before deploying the stack. The security concern is really that the env variables become available to all processes launched from that shell session, not just Docker. Any script or command you run afterward could potentially read those env variables. ...

Here’s a quick tip on how to convert docker-compose.yml file to a Docker Swarm mode ready file. the command Imma be straight to the point and share few commands to help you with converting a Docker Compose stack config to a Docker Swarm mode one: docker stack config --compose-file docker-compose.yml > swarm.yml To deploy it, run: docker stack deploy --compose-file swarm.yml my-service Notes: Replace my-service with your preferred stack name Use -c for shorthand for --compose-file .env file When your setup relies on .env file, you’ll need to export the variables before deployment since Docker Swarm doesn’t automatically load .env files: ...

If you’ve been digging into the rabbit hole of Docker Compose healthchecks and restart policies, or maybe got a bit confused by my previous posts, you’ve probably wondered: “Can I use restart policies to restart containers when they become unhealthy?” tldr: By default, nope, not out of the box. Yet, you can make it work by implementing some application logic to it. restart policies Currently there are 4 restart policies: ...

You’ve got healthchecks setup (because you read those previous posts, right?), your containers are dutifully reporting their health status, and all is good. Until 2 AM when that flaky service decides to hang, your healthcheck correctly marks it as unhealthy, and… nothing happens. The container just sits there, unhealthy and useless, waiting for you to manually restart it. That’s where autoheal comes in — the unsung hero that actually does something when your containers get unhealthy. ...

As a follow-up to Dockerfile HEALTCHECK let’s see what Docker Compose healtchecks are for. Think of it as Dockerfile healtchecks with the flexibility to say “actually, in this environment let’s do things differently.” when dockerfile healthchecks fall short Picture this: your Dockerfile has a nice healthcheck that hits http://localhost:3000/health. Works great in prod where your app runs on port 3000. But in your local dev environment, you’re mapping that to port 8080, and in staging, it’s behind a reverse proxy with a completely different health endpoint. ...