Nicolas De Loof
cf300b6cd8
ensureImagesExists and docker compose pull now give provider-backed services their turn: compose invokes the provider's pull command with the image identity and the state of the local daemon cache (--image/--digest/--created), plus two verdicts compose alone can compute so providers never re-implement that arbitration: - --source: the authority for this invocation — local (the daemon's image is the desired state: build-only service, pull_policy build, or an image the current run just built) or registry (resolve the reference upstream — including the CI workflow where build is only the recipe used to publish the image consumers pull); - --policy: missing on the up path (a usable version suffices) or always on compose pull (ensure freshness of the authority). digest/created describe the cache, they are not instructions: the provider persists them as the bookkeeping keys of what it ingested — digest as identity test, created as the ordering fallback for backends that cannot preserve digests. Providers without the metadata block are skipped: behavior unchanged. Providers are independent, so their pulls run without fail-fast cancellation — the first failure no longer kills its siblings mid-run and mangles their reports into context-canceled noise; every provider runs to completion and every failure is reported, prefixed by service. On the pull path the provider phase runs unconditionally — skipping it because an unrelated service failed to pull would silently leave provider runtimes stale — and its error is a per-service pull error, following their exact regime: reported with them, suppressed by IgnoreFailures. A fatal errgroup error is reported joined with the accumulated per-service context instead of dropping it. The provider runs under the root context: the errgroup context is canceled once Wait returns and would kill the provider process on the spot. Signed-off-by: Nicolas De Loof <[email protected]>
Table of Contents
Docker Compose
Docker Compose is a tool for running multi-container applications on Docker
defined using the Compose file format.
A Compose file is used to define how one or more containers that make up
your application are configured.
Once you have a Compose file, you can create and start your application with a
single command: docker compose up.
Note
: About Docker Swarm Docker Swarm used to rely on the legacy compose file format but did not adopt the compose specification so is missing some of the recent enhancements in the compose syntax. After acquisition by Mirantis swarm isn't maintained by Docker Inc, and as such some Docker Compose features aren't accessible to swarm users.
Where to get Docker Compose
Windows and macOS
Docker Compose is included in Docker Desktop for Windows and macOS.
Linux
You can download Docker Compose binaries from the release page on this repository.
Rename the relevant binary for your OS to docker-compose and copy it to $HOME/.docker/cli-plugins
Or copy it into one of these folders to install it system-wide:
/usr/local/lib/docker/cli-pluginsOR/usr/local/libexec/docker/cli-plugins/usr/lib/docker/cli-pluginsOR/usr/libexec/docker/cli-plugins
(might require making the downloaded file executable with chmod +x)
Quick Start
Using Docker Compose is a three-step process:
- Define your app's environment with a
Dockerfileso it can be reproduced anywhere. - Define the services that make up your app in
compose.yamlso they can be run together in an isolated environment. - Lastly, run
docker compose upand Compose will start and run your entire app.
A Compose file looks like this:
services:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
redis:
image: redis
Contributing
Want to help develop Docker Compose? Check out our contributing documentation.
If you find an issue, please report it on the issue tracker.
Legacy
The Python version of Compose is available under the v1 branch.