bc806da712
When running `compose down`, the `--rmi` flag can be passed,
which currently supports two values:
* `local`: remove any _implicitly-named_ images that Compose
built
* `all` : remove any named images (locally-built or fetched
from a remote repo)
Removing images in the `local` case can be problematic, as it's
historically been done via a fair amount of inference over the
Compose model. Additionally, when using the "project-model"
(by passing `--project-name` instead of using a Compose file),
we're even more limited: if no containers for the project are
running, there's nothing to derive state from to perform the
inference on.
As a first pass, we started labeling _containers_ with the name
of the locally-built image associated with it (if any) in #9715.
Unfortunately, this still suffers from the aforementioned problems
around using actual state (i.e. the containers might no longer
exist) and meant that when operating in file mode (the default),
things did not behave as expected: the label is not available
in the project since it only exists at runtime.
Now, with these changes, Compose will label any images it builds
with project metadata. Upon cleanup during `down`, the engine
image API is queried for related images and matched up with the
services for the project. As a fallback for images built with
prior versions of Compose, the previous approach is still taken.
See also:
* https://github.com/docker/compose/issues/9655
* https://github.com/docker/compose/pull/9715
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
|
||
|---|---|---|
| .github | ||
| cmd | ||
| docs | ||
| internal | ||
| packaging | ||
| pkg | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yml | ||
| BUILDING.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| NOTICE | ||
| README.md | ||
| docker-bake.hcl | ||
| go.mod | ||
| go.sum | ||
| logo.png | ||
README.md
Docker Compose v2
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 the 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.
About update and backward compatibility
Docker Compose V2 is a major version bump release of Docker Compose. It has been completely rewritten from scratch in Golang (V1 was in Python). The installation instructions for Compose V2 differ from V1. V2 is not a standalone binary anymore, and installation scripts will have to be adjusted. Some commands are different.
For a smooth transition from legacy docker-compose 1.xx, please consider installing compose-switch to translate docker-compose ... commands into Compose V2's docker compose .... . Also check V2's --compatibility flag.
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 for installing 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 to make the downloaded file executable with chmod +x)
Quick Start
Using Docker Compose is basically 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
docker-compose.ymlso 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.