docker composeRun a multi-container app from one YAML file
docker compose starts a whole application (API, database, cache, workers) from a compose.yaml: one network, its volumes, the right start order and health checks. up is declarative: run it again after a change and only what changed is recreated. It's the standard for local development, CI test stacks and small single-host deployments.
docker compose [-f FILE] [-p PROJECT] up|down|ps|logs|exec|build|pull|config [SERVICE...]You've cloned the shop repo and want the API, Postgres and Redis running locally with one command.
docker composeCompose v2, a docker CLI plugin. The old Python docker-compose (v1) is end-of-life.
Compose reads compose.yaml, merges any override files, and fills ${VARS} from the shell and a .env file next to it. It then talks to dockerd through the normal API. For project shop it creates the network shop_default and named volumes like shop_pgdata, then one container per service named shop-<service>-1, labelled with the project, the service and a hash of that service's configuration. Services start in depends_on order; with condition: service_healthy Compose waits for the dependency's HEALTHCHECK to pass. On the next up it compares each container's config-hash label with the file and recreates only the services that changed. Containers reach each other by service name through Docker's DNS on the project network. down removes the containers and the network; volumes survive unless you add -v.
Compose turns the YAML into API calls: a network, volumes, then containers in dependency order, waiting on health checks.
Compose loads compose.yaml plus any override file, substitutes ${VARIABLES} from the shell and .env, and validates the result (what docker compose config prints).
up -dCreate/update and start everything in the backgroundup --build / --force-recreateRebuild images first / recreate even unchanged containersdown [-v] [--rmi local]Remove containers and network; -v also deletes volumes (data!)ps [-a]The project's containers with service, status and portslogs -f [SERVICE]Follow logs, prefixed with the service nameexec SERVICE CMDRun a command in a service's running container (TTY by default)run --rm SERVICE CMDOne-off container for a service, e.g. migrationsconfigValidate and print the fully merged, interpolated filepull / buildFetch or build all service imagesrestart / stop / start SERVICELifecycle of individual services-p NAME, -f FILE, --profile PProject name, file(s), optional service profilesdocker compose down -v to 'restart cleanly'-v deletes the named volumes, so the database and any uploads are gone.
docker compose down (keeps volumes), or docker compose restart <service>depends_on: [db] and expecting the database to be readyPlain depends_on only orders container starts; the API may connect before Postgres accepts connections.
A healthcheck on db and depends_on: { db: { condition: service_healthy } }, plus retries in the appDB_HOST=localhost in a Compose serviceEach service is its own container; localhost is the service itself.
Use the service name: DB_HOST=dbCommitting passwords directly in compose.yamlThey end up in git history and in docker inspect output.
env_file with a git-ignored .env, or Compose secrets mounted as filesTry these on a Linux machine of your own. Each task has a hint and a solution.
Create ~/app/compose.yaml with two services: api built from . publishing 127.0.0.1:8085:8080, and cache using redis:7-alpine. Check it with docker compose config, then bring it up in the background.
~/app/.env has REDIS_URL pointing at cache.internal. In a Compose project with a service named cache, what should it be? Fix it with sed.
Write the commands to: follow only the api service's logs, then open a shell in the db service.
Write the command that stops the project and also deletes its volumes, and say when you would use it.
docker composeRun a multi-container app from one YAML file
docker compose starts a whole application (API, database, cache, workers) from a compose.yaml: one network, its volumes, the right start order and health checks. up is declarative: run it again after a change and only what changed is recreated. It's the standard for local development, CI test stacks and small single-host deployments.
docker compose [-f FILE] [-p PROJECT] up|down|ps|logs|exec|build|pull|config [SERVICE...]You've cloned the shop repo and want the API, Postgres and Redis running locally with one command.
docker composeCompose v2, a docker CLI plugin. The old Python docker-compose (v1) is end-of-life.
Compose reads compose.yaml, merges any override files, and fills ${VARS} from the shell and a .env file next to it. It then talks to dockerd through the normal API. For project shop it creates the network shop_default and named volumes like shop_pgdata, then one container per service named shop-<service>-1, labelled with the project, the service and a hash of that service's configuration. Services start in depends_on order; with condition: service_healthy Compose waits for the dependency's HEALTHCHECK to pass. On the next up it compares each container's config-hash label with the file and recreates only the services that changed. Containers reach each other by service name through Docker's DNS on the project network. down removes the containers and the network; volumes survive unless you add -v.
Compose turns the YAML into API calls: a network, volumes, then containers in dependency order, waiting on health checks.
Compose loads compose.yaml plus any override file, substitutes ${VARIABLES} from the shell and .env, and validates the result (what docker compose config prints).
up -dCreate/update and start everything in the backgroundup --build / --force-recreateRebuild images first / recreate even unchanged containersdown [-v] [--rmi local]Remove containers and network; -v also deletes volumes (data!)ps [-a]The project's containers with service, status and portslogs -f [SERVICE]Follow logs, prefixed with the service nameexec SERVICE CMDRun a command in a service's running container (TTY by default)run --rm SERVICE CMDOne-off container for a service, e.g. migrationsconfigValidate and print the fully merged, interpolated filepull / buildFetch or build all service imagesrestart / stop / start SERVICELifecycle of individual services-p NAME, -f FILE, --profile PProject name, file(s), optional service profilesdocker compose down -v to 'restart cleanly'-v deletes the named volumes, so the database and any uploads are gone.
docker compose down (keeps volumes), or docker compose restart <service>depends_on: [db] and expecting the database to be readyPlain depends_on only orders container starts; the API may connect before Postgres accepts connections.
A healthcheck on db and depends_on: { db: { condition: service_healthy } }, plus retries in the appDB_HOST=localhost in a Compose serviceEach service is its own container; localhost is the service itself.
Use the service name: DB_HOST=dbCommitting passwords directly in compose.yamlThey end up in git history and in docker inspect output.
env_file with a git-ignored .env, or Compose secrets mounted as filesTry these on a Linux machine of your own. Each task has a hint and a solution.
Create ~/app/compose.yaml with two services: api built from . publishing 127.0.0.1:8085:8080, and cache using redis:7-alpine. Check it with docker compose config, then bring it up in the background.
~/app/.env has REDIS_URL pointing at cache.internal. In a Compose project with a service named cache, what should it be? Fix it with sed.
Write the commands to: follow only the api service's logs, then open a shell in the db service.
Write the command that stops the project and also deletes its volumes, and say when you would use it.