Docker

Lesson 09

Healthchecks and runtime config

Describe runtime health and configuration explicitly so operators can tell whether the container is ready and healthy.

Good Code

Dockerfile
FROM node:22-alpine

WORKDIR /app
ENV NODE_ENV=production
ENV PORT=3000

COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY server.js ./server.js

# Declare the port the app is expected to listen on.
EXPOSE 3000
# Check the app endpoint, not just whether the process exists.
HEALTHCHECK --interval=30s --timeout=3s --retries=3   CMD wget -qO- http://127.0.0.1:3000/health || exit 1

CMD ["node", "server.js"]

Bad Code

Dockerfile
FROM node:22-alpine

WORKDIR /app
COPY . .
RUN npm install

# EXPOSE only documents the intended port; it does not prove the app is healthy.
EXPOSE 3000
CMD ["node", "server.js"]

Review Notes

What to review

Good Code

The good version declares runtime defaults, exposes the expected port, and provides a healthcheck tied to the app's health endpoint.

Bad Code

The bad version can be running while the application is unable to serve requests. Operators get less signal when the HTTP server or a required dependency fails.

Takeaways

  • A running container is not always a healthy application; expose a meaningful health signal.