Nicolas De Loof
0a64ff09a8
A GitHub Copilot PR review (docker/compose#14221#pullrequestreview-5300897216) found three real issues in the reconciliation-plan-based hook runners, all confirmed by direct reproduction against a live daemon before being fixed: - **Hook runners excluded from discovery, stale runners persist.** collectObservedState's single getContainers call requires ConfigHashLabel (getDefaultFilters), which hook runners deliberately never carry -- so they never reached the classification loop that populates HookContainers, and planPreStartHookRunners never saw a stale runner to purge. Reproduced: a failed hook run followed by a second `up` failed with "container name ... already in use" instead of recovering. Fixed by listing hook containers separately, by project+hook label alone (new getHookContainers), and merging them in before classification. Locked in by a new e2e scenario, TestPreStartHookRetryAfterFailureSucceeds, that reproduces the exact failure-then-retry sequence. - **Prepared hook runners misclassified as service replicas.** start's containers.filter(isService(name), isNotOneOff) has no reason to exclude a hook runner: it carries the same project/service labels as a real replica and no one-off label either. Added isNotHookContainer to the filter chain in startService, so a hook runner is never counted as (or started as) a surviving replica. - **Per-replica hooks create runners before unsupported configuration is rejected.** per_replica is not yet supported (#14259): runPreStart validates every hook up front and rejects the whole service before executing any of them, but planPreStartHookRunners had no equivalent check, so create/up would plan (and leave behind) runners for a service whose hooks could never run. Mirrored the same up-front, all-or-nothing validation in planPreStartHookRunners. 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.