Hands-on Lab

How to Build a Multi-Container App with Docker Compose

July 17, 2026 3 min

0 / 6

Cheat sheet

Found it useful? Don't miss the next lab

0:00 / 0:00

We write compose.yaml with a heredoc so we don't depend on any editor. It defines two services (web running nginx:alpine and publishing port 8080, and cache running redis:alpine with no published port since only other containers use it), a project-owned bridge network called labnet that connects them, and a named volume web-content that holds the content nginx serves instead of storing it in the container's own layer.

mkdir -p /root/compose-lab && cat > /root/compose-lab/compose.yaml <<'EOF'
name: compose-lab
services:
  web:
    image: nginx:1.27-alpine
    ports:
      - "8080:80"
    volumes:
      - web-content:/usr/share/nginx/html
    networks:
      - labnet
    depends_on:
      - cache
  cache:
    image: redis:7-alpine
    networks:
      - labnet
networks:
  labnet:
    driver: bridge
volumes:
  web-content:
EOF
cat /root/compose-lab/compose.yaml

I did it

Before touching Docker, we check the file is valid: docker compose config reads compose.yaml, resolves the defaults (ports, and network/volume names prefixed with the compose-lab_ project name) and prints the final configuration. An indentation mistake or a reference to a nonexistent service would fail right here, not once the containers try to start.

cd /root/compose-lab && docker compose config

A single command brings up the entire stack. -d runs it detached so it doesn't block the terminal. Compose first creates the labnet network and the web-content volume, then starts the containers honoring depends_on: cache before web, though that only guarantees start order, not that the service is already ready to take traffic.

cd /root/compose-lab && docker compose up -d

I did it

docker compose ps lists only this project's containers (grouped under the compose-lab name we set in the file) and confirms both web and cache are Up, along with web's published port 8080->80. It's the first real proof the stack actually came up.

cd /root/compose-lab && docker compose ps

docker compose logs cache shows Redis's real process output from inside the container, each line prefixed with the service name. We look for the 'Ready to accept connections' line: it confirms Redis finished booting, not just that the container exists, which is all ps proves.

cd /root/compose-lab && docker compose logs cache --tail 20

docker compose exec web runs a command inside the already-running web container, no interactive session needed. We overwrite index.html at /usr/share/nginx/html, the path where we mounted the web-content volume: the change lands in that volume, not in the image, so it would survive a docker compose restart.

cd /root/compose-lab && docker compose exec web sh -c "echo '<h1>Docker Compose lab: nginx + redis</h1>' > /usr/share/nginx/html/index.html"

I did it

From outside the containers, curl against the host's port 8080 —the one we published in compose.yaml— returns the HTML we just wrote. That's the definitive proof the web service works end to end: published port, healthy container, and a volume holding the right content.

curl -s http://localhost:8080/

From inside web we resolve the name cache with getent hosts, the same name-resolution call any program would use. Compose answers with the internal IP of the cache container on the labnet network: services discover each other by name, never by a fixed IP that would change on every recreation.

cd /root/compose-lab && docker compose exec web sh -c "getent hosts cache"

I did it

We confirm that, beyond resolving the name, Redis's port 6379 is actually open and accepting connections from web over the shared labnet network. nc -zv only tests the TCP connection, without sending any Redis command yet.

cd /root/compose-lab && docker compose exec web sh -c "nc -zv cache 6379"

This time we go into the cache container itself and use its native client, redis-cli, bundled in the redis:7-alpine image. A PING that answers PONG confirms the Redis service doesn't just have its port open, it's genuinely processing commands.

cd /root/compose-lab && docker compose exec cache redis-cli ping

I did it

docker compose down -v tears down everything up created: it stops and removes the web and cache containers, deletes the labnet network, and, thanks to -v, the named web-content volume too. Without -v the volume would survive so a future up could reuse it; here we delete it on purpose to leave the lab clean.

cd /root/compose-lab && docker compose down -v

I did it

We check the cleanup on three fronts: docker compose ps -a no longer lists any container from the project, and the name filters confirm neither the compose-lab_labnet network nor the compose-lab_web-content volume still exist. Nothing is left orphaned on the system.

cd /root/compose-lab && docker compose ps -a; echo 'redes:'; docker network ls --filter name=compose-lab --format '{{.Name}}'; echo 'volumenes:'; docker volume ls --filter name=compose-lab --format '{{.Name}}'

The final proof: we repeat the same curl from earlier and now it fails with connection refused instead of returning the HTML. It's the last confirmation, from outside Docker, that docker compose down genuinely shut the service down and freed port 8080.

curl -s -o /dev/null -w '%{http_code}\n' --max-time 2 http://localhost:8080/ || echo 'sin conexion: el servicio ya no existe'

Was this lab useful? Rate it:

Click to rate this post!

[Total: 0 Average: 0]

What Docker Compose solves

Docker Compose v2 describes a docker compose multi-container app in a single declarative file: which images to run, how they talk to each other over the network, and which data survives a restart. Instead of chaining several loose docker run calls, you define the whole stack once and bring it up, inspect it, and tear it down with a handful of subcommands on Docker’s own CLI (docker compose, no hyphen: the v2 plugin that replaced the old Python docker-compose).

The shape of a compose.yaml file

A typical compose.yaml has three blocks: services (one container per service, with its image, ports and variables), networks (the networks those services share) and volumes (named storage Docker manages for you). Our lab defines a web service running Nginx and a cache service running Redis, both on the same labnet network, with Nginx’s content stored in a named volume instead of a bind mount tied to a host path.

How services find each other

Alongside the services, Compose creates a custom bridge network with an embedded DNS resolver: every container can reach the others by service name (cache, web) without knowing its internal IP, something Docker’s default bridge network doesn’t give you. It’s the same principle behind our Redis on Docker and Portainer on Docker Compose guides whenever several containers need to talk to each other.

From docker compose up to docker compose down

The whole lifecycle fits in four commands: docker compose up -d creates the network, the volume, and starts the containers in the order depends_on sets; docker compose ps and docker compose logs confirm they’re healthy; docker compose exec drops you inside a specific service; and docker compose down -v tears it all down, volume included. For production, add healthchecks and restart policies to each service. The full compose file reference lives in the official Docker Compose documentation, the v2 plugin’s code is public at github.com/docker/compose, and the Redis commands used in the lab are documented at redis.io.

FAQ

What is Docker Compose v2?

It is the official Docker CLI plugin invoked as docker compose (no hyphen), replacing the old Python-based docker-compose. It reads a compose.yaml file and orchestrates several containers, their network and their storage as a single unit.

How do services talk to each other in Docker Compose?

Compose creates its own bridge network for the project with an embedded DNS resolver: any container can reach another using its service name (for example cache) as if it were a hostname, with no need to know or hardcode its internal IP.

Why use a named volume instead of a bind mount?

A named volume is managed by Docker: it doesn't depend on a specific host path, it survives a plain docker compose down (without -v), and it's portable across machines. A bind mount ties the container to an exact host folder, handy for development but less portable.

What's the difference between docker compose stop and docker compose down?

docker compose stop halts the containers but leaves them created, along with the network and volumes, ready to resume with start. docker compose down goes further: it removes the containers and the network, and with the -v flag it also deletes the project's named volumes.

Cheat sheet

mkdir -p /root/compose-lab && cat > /root/compose-lab/compose.yaml <<'EOF'
name: compose-lab
services:
  web:
    image: nginx:1.27-alpine
    ports:
      - "8080:80"
    volumes:
      - web-content:/usr/share/nginx/html
    networks:
      - labnet
    depends_on:
      - cache
  cache:
    image: redis:7-alpine
    networks:
      - labnet
networks:
  labnet:
    driver: bridge
volumes:
  web-content:
EOF
cat /root/compose-lab/compose.yaml

cd /root/compose-lab && docker compose up -d

cd /root/compose-lab && docker compose exec web sh -c "echo '<h1>Docker Compose lab: nginx + redis</h1>' > /usr/share/nginx/html/index.html"

cd /root/compose-lab && docker compose exec web sh -c "getent hosts cache"

cd /root/compose-lab && docker compose exec cache redis-cli ping

cd /root/compose-lab && docker compose down -v

Found it useful? Don't miss the next lab

Subscribe to the newsletter

What Docker Compose solves

The shape of a compose.yaml file

How services find each other

From docker compose up to docker compose down

FAQ

What is Docker Compose v2?

How do services talk to each other in Docker Compose?

Why use a named volume instead of a bind mount?

What's the difference between docker compose stop and docker compose down?

Cheat sheet