caad72713b
By default, `compose up` attaches to all services (i.e. shows log output from every associated container). If a service is specified, e.g. `compose up foo`, then only `foo`'s logs are tailed. The `--attach-dependencies` flag can also be used, so that if `foo` depended upon `bar`, then `bar`'s logs would also be followed. It's also possible to use `--no-attach` to filter out one or more services explicitly, e.g. `compose up --no-attach=noisy` would launch all services, including `noisy`, and would show log output from every service _except_ `noisy`. Lastly, it's possible to use `up --attach` to explicitly restrict to a subset of services (or their dependencies). How these flags interact with each other is also worth thinking through. There were a few different connected issues here, but the primary issue was that running `compose up foo` was always attaching dependencies regardless of `--attach-dependencies`. The filtering logic here has been updated so that it behaves predictably both when launching all services (`compose up`) or a subset (`compose up foo`) as well as various flag combinations on top of those. Notably, this required making some changes to how it watches containers. The logic here between attaching for logs and monitoring for lifecycle changes is tightly coupled, so some changes were needed to ensure that the full set of services being `up`'d are _watched_ and the subset that should have logs shown are _attached_. (This does mean faking the attach with an event but not actually doing it.) While handling that, I adjusted the context lifetimes here, which improves error handling that gets shown to the user and should help avoid potential leaks by getting rid of a `context.Background()`. Signed-off-by: Milas Bowman <milas.bowman@docker.com> |
||
|---|---|---|
| .github | ||
| cmd | ||
| docs | ||
| e2e | ||
| internal | ||
| packaging | ||
| pkg | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yml | ||
| BUILDING.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| NOTICE | ||
| README.md | ||
| codecov.yml | ||
| docker-bake.hcl | ||
| go.mod | ||
| go.sum | ||
| logo.png | ||
README.md
Table of Contents
- Docker Compose v2
- About update and backward compatibility
- Where to get Docker Compose
- Quick Start
- Contributing
- Legacy
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 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.
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
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.
Legacy
The Python version of Compose is available under the v1 branch