Description
A running container is not necessarily a responsive service, so it needs an appropriate health criterion. Omitting healthcheck in Compose can still inherit the image’s HEALTHCHECK; check the effective configuration.
Without a healthcheck, operators or orchestration systems may notice a failure late. Configure suitable checks for web services, APIs and workers whose operational state matters.
Potential impact
- An unhealthy service may appear to be running normally.
- Responses such as restart or traffic diversion may be delayed.
- Operators may need more time to diagnose the failure.
Remediation
- Check inherited image settings and configure a
healthcheckcommand appropriate for the service. - Adjust the interval, timeout and retry count to operational needs.
- Check actual responses and connect the results to monitoring and failure handling. Ordinary Docker restart policies do not restart a container merely because it becomes unhealthy.
Examples
The image must contain curl and the application must provide the /health endpoint. Restrict the published port’s exposure separately.
Before
yaml
services:
app:
image: sample/app:latest
restart: always
ports:
- "8092:8092"
After
yaml
services:
app:
image: sample/app:latest
restart: always
ports:
- "8092:8092"
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8092/health"]
interval: 30s
timeout: 10s
retries: 3
Explanation:
- Before: No separate Compose check is defined. Check whether the image provides an inherited healthcheck.
- After: Service responses are checked periodically. Configure restart or traffic handling based on those results separately.