Healthcheck

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. ...

Writing a Dockerfile is straightforward — slap a FROM, add some RUN commands, maybe throw in a CMD, and boom, you’re a Docker expert. But writing good Dockerfiles that follow best practices? That’s another level. To keep things short and precise, one thing that’s kinda underrated and if often mentioned is the HEALTHCHECK instruction. At the time I was mostly aware of it however it didn’t caught my attention until Trivy started complaining about AVD-DS-0026: No HEALTHCHECK defined as a LOW severity finding in our GitHub Actions pipeline. ...