Compose and service health

Save the runtime choices with the project

A long docker run command can be difficult to repeat consistently. Compose describes services, networks, mounts, ports, and related settings in a YAML file. A service describes how to run a component; a project groups the resulting local resources. Compose is useful for a local application but does not by itself provide a multi-host production platform.

Return to docker-status with Dockerfile and restored status.json. Check docker compose version; use the modern docker compose command. Save compose.yaml:

services:
  status:
    build: .
    image: learnwithsk-status:dev
    ports:
      - '127.0.0.1:8765:8000'
    healthcheck:
      test: ['CMD', 'python', '-c', "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/status.json', timeout=2)"]
      interval: 5s
      timeout: 3s
      retries: 3

build points to the context. image names the built result. ports repeats the host-to-container mapping from the last lesson. The health command runs inside the container, so it uses port 8000 on that container's loopback. It uses Python because Python is known to exist in this image; assuming every minimal image contains curl would be a mistake.

Render before starting

From the same directory:

docker compose -p sk-study config --services
docker compose -p sk-study config --quiet

Expect one service named status and successful validation. These commands do not start the service. A full config rendering can reveal interpolated values, so inspect it privately if a project contains secrets. Environment substitution in Compose and environment variables inside the eventual container are related but distinct steps.

The next lab runs this file. Its health check considers a successful HTTP request healthy. It does not parse JSON or prove the body contains status=ok. A process can be running but not ready, and a healthy static endpoint can coexist with a broken business operation.

Reason about dependent services

Suppose an API needs a database. Basic depends_on controls startup ordering, but the database process may still be initializing. The longer form can wait for its configured health check:

depends_on:
  database:
    condition: service_healthy

This is a fragment for a future API service, not a complete file to paste over the status fixture. A one-off initializer can instead use service_completed_successfully. Startup checks do not replace the application's retry and reconnection behavior if a dependency fails later. Nor does a health failure alone mean Docker will automatically restart the unhealthy process.

Separate three questions: has the process started, is it ready for its intended work, and can a representative user operation complete? A useful health check answers a deliberately chosen question. Restarting an otherwise functioning API every time a dependency briefly slows may amplify a problem.

Read the actual application

At the pinned MicroBank revision, upstream Compose has frontend, Accounts, Ledger, three database services, and LocalStack. There is a notifications database but no notifications application service. Accounts uses healthy-dependency conditions; Ledger uses basic startup dependencies. Accounts' health handler returns a static response. Vite frontend variables are compiled into browser assets at build time; a new runtime environment value cannot automatically rewrite those files.

Practice: list two failures the status fixture's health check would miss. Example answers are a semantically wrong JSON body and a broken downstream operation that this file server never calls. Why is successful Compose validation insufficient? It checked configuration, not processes or network responses.

Next, learn how to identify the image Compose selects, then run the complete fixture lab with startup, response, and cleanup checks.

References: Compose startup order↗, Compose services↗, Vite environment handling↗, and MicroBank source↗.