A frontend, API, and database may each need a container, but starting them one by one means repeating port, network, and naming options. Docker Compose replaces that brittle routine with a YAML file describing the application’s desired state and a command to run it. Compose creates the required containers, networks, and volumes through the Docker API. section 7.1 section 7.2
Listing 7.1 A Docker Compose file to run the to-do app
services:
todo-web:
image: diamol/ch06-todo-list:2e
ports:
- "8020:80"
networks:
- app-net
networks:
app-net:
name: nat
external: true
This small Compose file shows the basic shape: a service names its image, published port, and network; a separate networks entry defines the connection. section 7.1
Under `services`, define each application component. An `image` selects what it runs; `ports` publishes a container port to the host. A service with no published port can still communicate with other containers on its network. Use `depends_on` to start named dependencies before a dependent service. YAML indentation matters: it identifies which properties belong to each service. section 7.1 section 7.2
Run and inspect a multi-container app
From `./ch07/exercises/image-of-the-day`, run `docker compose up --detach`. The gallery publishes host port 8010; its API and log collector are separate services. To try three API containers, run `docker compose up -d --scale iotd=3`, refresh the gallery at `http://localhost:8010`, then inspect them with `docker compose logs --tail=1 iotd`. Use `docker compose stop` and `docker compose start` to pause and resume the app. `docker compose down` removes it; another `up -d` recreates resources from the file. section 7.2
Compose groups an app’s resources into a *project*. By default, the Compose file’s directory supplies its name, so repeating `up` from that directory updates the same app rather than launching another copy. Set a distinct project name with `-p` to run another instance, and give instances nonconflicting host ports and storage paths. section 10.1 section 10.5
For development and test, keep common services in one file and add environment-specific settings with override files. Environment variables, environment files, and secrets can change application configuration; overrides can also change which services run. This keeps deliberate differences in deployment artifacts instead of relying on manual setup. section 10.3 section 10.5
Compose applies the file to a single Docker machine when you run `docker compose up`; it does not continuously restore desired state after a container fails or is removed. It can be a practical starting point for a small deployment, but it does not itself provide high availability, load balancing, or failover. It also works well for starting a local smoke-test environment in a CI/CD pipeline. section 7.5 section 16.5
