Long `docker run` commands are hard to repeat: each application may need different ports, environment variables, and volumes. A Docker Compose file puts those choices in YAML so one command can build and run the configured services. The examples use `compose.yaml` or `docker-compose.yaml`; both filenames are supported. section 6.2 section 6.2.1
Listing 6.3 Docker Compose for our Python app
services:
web:
build:
context: .
dockerfile: Dockerfile
ports:
- "8080:8080"
environment:
- PORT=8080
Start with the Python web service. `services` names the containers Compose manages; `build.context` selects the build directory, and `build.dockerfile` selects its Dockerfile. `ports` and `environment` replace arguments formerly passed to `docker run`. section 6.2.2
From the project directory, use the same short commands each time:
- `docker compose build` builds the container. section 6.2.2
- `docker compose up` runs it; `docker compose up --build` rebuilds before running when needed. section 6.2.1 section 6.4.2
- `docker compose down` stops the Compose-managed containers. For mounted volumes, ordinary `down` preserves data, while `down -v` can delete it. section 6.2.2 section 6.4.2
Reuse the pattern for Node.js
A Node.js web service keeps the same `services` and `build` structure but uses its own port mapping and `PORT` value. The application-specific arguments live in its Compose file rather than in a command you must remember. section 6.2.3
Listing 6.11 Redis service in Docker Compose
services:
my-nginx-service:
image: nginx
web:
build:
context: .
dockerfile: Dockerfile
ports:
- "8080:8080"
environment:
- PORT=8080
volumes:
- mywebdata:/app/data
my-redis-service:
image: redis
volumes:
- myredisdata:/data
volumes:
mywebdata:
myredisdata:
A service can grow into a small application stack. This configuration places the Python web service alongside NGINX and Redis, and declares named volumes for application and Redis data. Other services can reach Redis by its service name. section 6.4.2
Different environments can use different files: `docker compose -f compose.prod.yaml up` selects a production configuration. An `image` name can include `${TAG:-latest}`, using `TAG` when set and `latest` otherwise. A production file can instead point at a hosted image, read an `.env` file, and publish the application on port 80; a deployment workflow copies that file to a virtual machine, pulls images, then runs `docker compose up -d`. section 7.2.2 section 7.3.3
For Docker Swarm, a related Compose file adds `deploy.replicas` to request service instances. That setting is ignored if the file is run with `docker compose up`, so a Swarm-specific file is not a drop-in way to scale ordinary Compose runs. section 9.1.2
