Add HEALTHCHECK to Dockerfiles for Reliable Services

A running container is not the same thing as a ready service. Docker considers a container "running" the instant its main process starts, but that process may still be parsing config, warming caches, or waiting on a downstream port long after the container shows up in docker ps. When another service depends on it, that gap is where multi-container stacks break: the web tier connects before the database accepts queries, the worker dequeues before the broker is initialized, and the whole stack fails on first request.

The HEALTHCHECK Dockerfile directive closes that gap by attaching a probe to the container itself. Docker runs the probe on an interval, tracks consecutive failures, and exposes one of three states (starting, healthy, unhealthy) on the container. Compose then uses those states to sequence startup with depends_on: condition: service_healthy, so downstream services wait for actual readiness instead of mere process launch. In this lab, you will author a Dockerfile with a tuned HEALTHCHECK probe, watch the container transition between health states in real time, break the service intentionally to trigger an unhealthy verdict, and wire the same healthcheck into a Compose file that starts a Redis sidecar only after the web tier is genuinely serving traffic.

Objectives

Upon completion of this beginner level lab, you will be able to:

• Author a Dockerfile that adds a HEALTHCHECK directive with tuned --interval, --timeout, --start-period, and --retries flags.
• Build and run the image, then observe the container transition from starting to healthy in docker ps.
• Inspect probe history via docker inspect to read the raw health log and exit codes.
• Break the service inside a running container and watch the health state flip to unhealthy once the retry budget is exhausted.
• Translate the healthcheck into a Compose file and gate a downstream Redis service with depends_on: condition: service_healthy.

Who is this lab for?

This lab is designed for:

• Beginner Docker users who can build and run a basic image but have not yet worked with container health probes.
• Developers and SREs adopting Compose for local multi-service stacks.
• Anyone tired of debugging "container is up, service is not" startup races.