Around Go: containers · 3 MIN READ

Compose: run an API and Redis as one local stack

Read compose.yaml and use config, up, ps, logs, exec and down.

Compose defines a local multi-container environment in one file. This example assumes your API reads REDIS_ADDR, listens on :8080 and tolerates transient downstream failures. Use a disposable directory for the exercise and save the file below as compose.yaml.

Describe services and readiness in the file

Service names provide network discovery on the Compose network. The API connects to redis:6379, not its own localhost. A dependency health check orders initial startup; it does not guarantee Redis stays healthy, so the Go client still needs deadlines and recovery.

yaml

services:
  api:
    build: .
    ports: ["127.0.0.1:8080:8080"]
    environment:
      REDIS_ADDR: redis:6379
    depends_on:
      redis:
        condition: service_healthy
  redis:
    image: redis:8-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 5

Read the code

This intentionally disposable Redis has no persistent volume or public port. Choose a supported tested image version for your project and pin release digests when needed. The API Dockerfile must exist in the same build context.

Validate, start and inspect the project

-p gives the stack a predictable project name. config --quiet validates without printing resolved configuration. up --build -d builds and starts; ps and logs reveal readiness and startup errors. Use the same project name for each command.

bash

docker compose -p go-lab config --quiet
docker compose -p go-lab up --build -d
docker compose -p go-lab ps
docker compose -p go-lab logs --tail 50 api redis

Read the code

Configuration validation does not prove the images will build or the service will boot. A missing Dockerfile, unavailable image or failing Redis health check each needs its own fix. Avoid publishing the full resolved config if it includes secrets.

Probe a dependency and tear down deliberately

exec runs inside an existing service container; redis-cli PING checks the Redis protocol path. down stops and removes the project containers and its normal networks. It does not delete named volumes unless requested with an additional destructive option.

bash

docker compose -p go-lab exec redis redis-cli PING
curl --max-time 5 --fail-with-body http://127.0.0.1:8080/healthz
docker compose -p go-lab down

Read the code

PING should return PONG, while the HTTP check verifies your API route. Run down only when the local session is finished. This fixture uses ephemeral Redis storage, so its data goes away with the disposable container.

TAKE THIS WITH YOU

Use service DNS names inside a Compose network, validate the file and inspect each service. Initial dependency ordering complements application retry/deadline behavior; it does not replace it.

Check your understanding

Where should this Compose API connect to Redis?

Go to the source

Progress stays in this browser. No account needed.