Rewrite to remove the `github.com/docker/docker/registry` dependency, which will not be included in the upcoming "api" and "client" modules, and will not be a public package in the module used for the daemon itself. 1. don't call "/info" API endpoint to get default registry The `IndexServerAddress` in the `/info` endpoint was added as part of the initial Windows implementation of the engine. For legal reasons, Microsoft Windows (and thus Docker images based on Windows) were not allowed to be distributed through non-Microsoft infrastructure. As a temporary solution, a dedicated "registry-win-tp3.docker.io" registry was created to serve Windows images. Using separate registries was not an ideal solution, and a more permanent solution was created by introducing "foreign image layers" in the distribution spec, after which the "registry-win-tp3.docker.io" ceased to exist, and removed from the engine through docker/docker PR 21100. However, the `ElectAuthServer` was left in place, quoting from that PR; > make the client check which default registry the daemon uses is still > more correct than leaving it up to the client, even if it won't technically > matter after this PR. There may be some backward compatibility scenarios > where `ElectAuthServer` [sic] is still helpful. That comment was 10 Years ago, and the CLI stopped using this information, as the default registry is not configurable, so in practice was a static value. (see https://github.com/docker/cli/commit/b4ca1c7368daeead400fcc1b8f2d61951a0d9d1e). 2. replace `ParseRepositoryInfo` and `GetAuthConfigKey` with local impl The `ParseRepositoryInfo` function was originally implemented for use by the daemon itself. It returns a `RepositoryInfo` struct that holds information about the repository and the registry the repository can be found in. As it was written for use by the daemon, it also was designed to be used in combination with the daemon's configuration (such as mirrors, and insecure registries). If no daemon configuration is present, which would be the case when used in a CLI, it uses fallback logic as used in the daemon to detect if the registry is running on a localhost / loopback address, because such addresses are allowed to be "insecure" by default; this includes resolving the IP-address of the host (if it's not an IP-address). Unfortunately, these functions (and related types) were reused in the CLI and many other places, which resulted in those types to be deeply ingrained in interfaces and (external) code. For compose; it was only used to get the "auth-config key" to use for looking up auth information from the credentials store, which still needs special handling for the "default" (docker hub) domain, which unlike other image references doesn't use the hostname included in the image reference for the actual registry (and key for storing auth). For those that want to follow along; First, note that `GetAuthConfig` only requires a `registry.IndexInfo`, so not the whole `RepositoryInfo` struct; https://github.com/moby/moby/blob/v28.3.3/registry/types.go#L8-L24 From the `registry.IndexInfo` it only uses the `IsOfficial` and `Name` fields; https://github.com/moby/moby/blob/v28.3.3/registry/config.go#L390-L395 But to get the `IndexInfo`, `ParseRepositoryInfo` is needed, which first takes the image reference's "domain name" (e.g. `docker.io`); https://github.com/moby/moby/blob/v28.3.3/registry/config.go#L421 This gets "normalized" for some cases where the `info.IndexServerAddress` was incorrectly assumed to be the canonical domain for Docker Hub registry, and which _does_ happen to also be accessible as a "v2" registry. https://github.com/moby/moby/blob/v28.3.3/registry/config.go#L334-L341 After normalizing, it checks if it's a docker hub address ("docker.io" after normalizing); Docker Hub is always required to use a secure connection, so no detection happens, and the `Official` field is set to indicate it's Docker Hub (this code path was already simplified as historically it would try to find daemon configuration (or otherwise use a default) for Mirror configuration; https://github.com/moby/moby/blob/v28.3.3/registry/config.go#L420-L443 For non-Docker Hub registries, it also sets the name, and attempts to detect if the registry is allowed to be "insecure"; https://github.com/moby/moby/blob/v28.3.3/registry/config.go#L435-L442 Which (as mentioned) involves parsing the address and, if needed, resolving the hostname https://github.com/moby/moby/blob/v28.3.3/registry/config.go#L445-L481 As `Insecure` is not used for looking up the auth-config key, all of the above can be reduced to; - Is the hostname obtained from the image reference "docker.io" (after normalizing)? - If so, use the special `https://index.docker.io/v1/` as auth-config key (another horrible remnant) - Otherwise use the hostname obtained from the image reference as-is Signed-off-by: Sebastiaan van Stijn <[email protected]>
Table of Contents
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.
Note
: About Docker Swarm Docker Swarm used to rely on the legacy compose file format but did not adopted 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.
