Guillaume Lours
8bd79da4bc
Several e2e tests used fixed host ports (8070, 8080, 8090, etc.), global buildx builders registered with --use, and a hardcoded IPC container name. Under parallel execution these shared daemon-level resources caused port conflicts, buildkitd container-name collisions, and intermittent failures. Separately, the standalone make target hardcoded -parallel=1, forcing the entire standalone suite to run serially even though the same tests run in parallel in plugin mode. Changes: - Convert fixed host ports in four fixtures (network-test, sentences, build-test, volume-test) to ephemeral bindings; add ServicePublishedPort helper to framework.go to resolve the actual mapped port at runtime. - Give each buildx-builder test a unique daemon-scoped name via BuilderName helper, preventing container-name collisions between parallel goroutines. Applies to TestBuildPlatformsWithCorrectBuildxConfig, TestBuildPrivileged, TestBuildBuilder, TestBuildEntitlements, TestBuildTLS. - Rename the fixed ipc_mode_container to a project-scoped name (ipc_e2e-src) and update the ipc-test fixture accordingly. - Replace the hardcoded -parallel=1 in make e2e-compose-standalone with E2E_PARALLEL_PLUGIN?=4 and E2E_STANDALONE_PARALLEL?=4, aligning both modes with the effective GOMAXPROCS on 4-core GitHub Actions runners. Both variables are overridable (E2E_STANDALONE_PARALLEL=1 restores serial local debugging). - Raise the poll delay in watch_test.go long-running polls (90s/120s timeout) from the default 100ms to 1s; bump cascade_test.go and publish_test.go from 100ms to 500ms. Reduces CPU pressure without affecting effective test duration. The logging-driver fixture retains its fixed port 24224: the Docker fluentd log driver encodes fluentd-address at service-start time, making ephemeral resolution non-trivial. TestLoggingDriver is serial so there is no collision risk in practice. Signed-off-by: Guillaume Lours <[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.