mirror of https://github.com/docker/docs.git
ENGDOCS-1944 (#19104)
* ENGDOCS-1944 * edits * edits * change wording * change wording * review edits
This commit is contained in:
parent
cfa324aab7
commit
547d161248
|
@ -6,6 +6,14 @@ keywords: docker compose, docker-compose, docker compose command, docker compose
|
|||
service
|
||||
title: Docker Compose overview
|
||||
grid:
|
||||
- title: Why use Compose?
|
||||
description: Understand Docker Compose's key benefits
|
||||
icon: feature_search
|
||||
link: /compose/intro/features-uses/
|
||||
- title: How Compose works
|
||||
description: Understand how Compose works
|
||||
icon: category
|
||||
link: /compose/compose-application-model/
|
||||
- title: Install Compose
|
||||
description: Follow the instructions on how to install Docker Compose.
|
||||
icon: download
|
||||
|
@ -19,19 +27,19 @@ grid:
|
|||
description: Find out about the latest enhancements and bug fixes.
|
||||
icon: note_add
|
||||
link: /compose/release-notes
|
||||
- title: Understand key features of Compose
|
||||
description: Understand its key features and explore common use cases.
|
||||
icon: category
|
||||
link: /compose/features-uses/
|
||||
- title: Explore the Compose file reference
|
||||
description: Find information on defining services, networks, and volumes for a
|
||||
Docker application.
|
||||
icon: feature_search
|
||||
icon: polyline
|
||||
link: /compose/compose-file
|
||||
- title: Browse common FAQs
|
||||
description: Explore general FAQs and find out how to give feedback.
|
||||
icon: help
|
||||
link: /compose/faq
|
||||
- title: Migrate to Compose V2
|
||||
description: Learn how to migrate from Compose V1 to V2
|
||||
icon: folder_delete
|
||||
link: /compose/migrate/
|
||||
aliases:
|
||||
- /compose/cli-command/
|
||||
- /compose/networking/swarm/
|
||||
|
@ -42,10 +50,11 @@ aliases:
|
|||
|
||||
{{< include "compose-eol.md" >}}
|
||||
|
||||
Compose is a tool for defining and running multi-container Docker applications.
|
||||
With Compose, you use a YAML file to configure your application's services.
|
||||
Then, with a single command, you create and start all the services
|
||||
from your configuration.
|
||||
Docker Compose is a tool for defining and running multi-container applications.
|
||||
It is the key to unlocking a streamlined and efficient development and deployment experience.
|
||||
|
||||
Compose simplifies the control of your entire application stack, making it easy to manage services, networks, and volumes in a single, comprehensible YAML configuration file. Then, with a single command, you create and start all the services
|
||||
from your configuration file.
|
||||
|
||||
Compose works in all environments; production, staging, development, testing, as
|
||||
well as CI workflows. It also has commands for managing the whole lifecycle of your application:
|
||||
|
@ -55,11 +64,4 @@ well as CI workflows. It also has commands for managing the whole lifecycle of y
|
|||
* Stream the log output of running services
|
||||
* Run a one-off command on a service
|
||||
|
||||
The key features of Compose that make it effective are:
|
||||
|
||||
* [Have multiple isolated environments on a single host](features-uses.md#have-multiple-isolated-environments-on-a-single-host)
|
||||
* [Preserve volume data when containers are created](features-uses.md#preserves-volume-data-when-containers-are-created)
|
||||
* [Only recreate containers that have changed](features-uses.md#only-recreate-containers-that-have-changed)
|
||||
* [Support variables and moving a composition between environments](features-uses.md#supports-variables-and-moving-a-composition-between-environments)
|
||||
|
||||
{{< grid >}}
|
|
@ -1,18 +1,23 @@
|
|||
---
|
||||
title: Understand the Compose application model
|
||||
description: Understand the Compose application model with an illustrative example
|
||||
title: How Compose works
|
||||
description: Understand how Compose works and the Compose application model with an illustrative example
|
||||
keywords: compose, docker compose, compose specification, compose model
|
||||
aliases:
|
||||
- /compose/compose-file/02-model/
|
||||
- /compose/compose-yaml-file/
|
||||
---
|
||||
|
||||
The Compose Specification lets you define a platform-agnostic container based application. Such an application is designed as a set of containers which have to both run together with adequate shared resources and communication channels.
|
||||
Docker Compose relies on a YAML configuration file, usually named `compose.yaml`.
|
||||
|
||||
The `compose.yaml` file follows the rules provided by the [Compose Specification](compose-file/_index.md) in how to define multi-container applications. This is the Docker Compose implementation of the formal [Compose Specification](https://github.com/compose-spec/compose-spec).
|
||||
|
||||
{{< accordion title="The Compose application model" >}}
|
||||
|
||||
Computing components of an application are defined as [services](compose-file/05-services.md). A service is an abstract concept implemented on platforms by running the same container image, and configuration, one or more times.
|
||||
|
||||
Services communicate with each other through [networks](compose-file/06-networks.md). In the Compose Specification, a network is a platform capability abstraction to establish an IP route between containers within services connected together. Low-level, platform-specific networking options are grouped into the Network definition and may be partially implemented on some platforms.
|
||||
Services communicate with each other through [networks](compose-file/06-networks.md). In the Compose Specification, a network is a platform capability abstraction to establish an IP route between containers within services connected together.
|
||||
|
||||
Services store and share persistent data into [volumes](compose-file/07-volumes.md). The Specification describes such a persistent data as a high-level filesystem mount with global options. Actual platform-specific implementation details are grouped into the volumes definition and may be partially implemented on some platforms.
|
||||
Services store and share persistent data into [volumes](compose-file/07-volumes.md). The Specification describes such a persistent data as a high-level filesystem mount with global options.
|
||||
|
||||
Some services require configuration data that is dependent on the runtime or platform. For this, the Specification defines a dedicated [configs](compose-file/08-configs.md) concept. From a service container point of view, configs are comparable to volumes, in that they are files mounted into the container. But the actual definition involves distinct platform resources and services, which are abstracted by this type.
|
||||
|
||||
|
@ -23,16 +28,34 @@ A [secret](compose-file/09-secrets.md) is a specific flavor of configuration dat
|
|||
> With volumes, configs and secrets you can have a simple declaration at the top-level and then add more platform-specific information at the service level.
|
||||
|
||||
A project is an individual deployment of an application specification on a platform. A project's name, set with the top-level [`name`](compose-file/04-version-and-name.md) attribute, is used to group
|
||||
resources together and isolate them from other applications or other installation of the same Compose specified application with distinct parameters. If you are creating resources on a platform, you must prefix resource names by project and
|
||||
resources together and isolate them from other applications or other installation of the same Compose-specified application with distinct parameters. If you are creating resources on a platform, you must prefix resource names by project and
|
||||
set the label `com.docker.compose.project`.
|
||||
|
||||
Compose offers a way for users to set a custom project name and override this name, so that the same `compose.yaml` file can be deployed twice on the same infrastructure, without changes, by just passing a distinct name.
|
||||
Compose offers a way for you to set a custom project name and override this name, so that the same `compose.yaml` file can be deployed twice on the same infrastructure, without changes, by just passing a distinct name.
|
||||
|
||||
Project names must contain only lowercase letters, decimal digits, dashes, and underscores, and must begin with a lowercase letter or decimal digit.
|
||||
{{< /accordion >}}
|
||||
|
||||
You then interact with your Compose application through the [Compose CLI](reference/_index.md). Commands such as `docker compose up` are used to start the application, while `docker compose down` stops and removes the containers.
|
||||
|
||||
## The Compose file
|
||||
|
||||
The default path for a Compose file is `compose.yaml` (preferred) or `compose.yml` that is placed in the working directory.
|
||||
Compose also supports `docker-compose.yaml` and `docker-compose.yml` for backwards compatibility of earlier versions.
|
||||
If both files exist, Compose prefers the canonical `compose.yaml`.
|
||||
|
||||
You can use [fragments](compose-file/10-fragments.md) and [extensions](compose-file/11-extension.md) to keep your Compose file efficient and easy to maintain.
|
||||
|
||||
Multiple Compose files can be [merged](13-merge.md) together to define the application model. The combination of YAML files is implemented by appending or overriding YAML elements based on the Compose file order you set.
|
||||
Simple attributes and maps get overridden by the highest order Compose file, lists get merged by appending. Relative
|
||||
paths are resolved based on the first Compose file's parent folder, whenever complimentary files being
|
||||
merged are hosted in other folders. As some Compose file elements can both be expressed as single strings or complex objects, merges apply to
|
||||
the expanded form. For more information, see [Working with multiple Compose files](multiple-compose-files/_index.md)
|
||||
|
||||
If you want to reuse other Compose files, or factor out parts of your application model into separate Compose files, you can also use [`include`](compose-file/14-include.md). This is useful if your Compose application is dependent on another application which is managed by a different team, or needs to be shared with others.
|
||||
|
||||
## Illustrative example
|
||||
|
||||
The following example illustrates the Compose Specification concepts outlined above. The example is non-normative.
|
||||
The following example illustrates the Compose concepts outlined above. The example is non-normative.
|
||||
|
||||
Consider an application split into a frontend web application and a backend service.
|
||||
|
||||
|
@ -42,40 +65,7 @@ The backend stores data in a persistent volume.
|
|||
|
||||
Both services communicate with each other on an isolated back-tier network, while the frontend is also connected to a front-tier network and exposes port 443 for external usage.
|
||||
|
||||
```mermaid
|
||||
%%{ init: { 'flowchart': { 'curve': 'linear' } } }%%
|
||||
flowchart LR
|
||||
subgraph A[INFRASTRUCTURE]
|
||||
direction TB
|
||||
subgraph TOP[" "]
|
||||
subgraph B1[Frontend Service]
|
||||
fs["`**webapp**`"]
|
||||
end
|
||||
style B1 fill:#ccd6e8, stroke-width:0px
|
||||
subgraph B2[Backend Service]
|
||||
bs["`**database**`"]
|
||||
end
|
||||
style B2 fill:#ccd6e8, stroke-width:0px
|
||||
|
||||
end
|
||||
style TOP fill:transparent, stroke-width:2px, stroke:#62affb, stroke-dasharray: 5 5
|
||||
key[ro= read only\nr+w = read write]
|
||||
style key fill:transparent, stroke-width:0px,text-align: left, size: 94px
|
||||
|
||||
direction TB
|
||||
id2(Server\nCertificate)
|
||||
id1(HTTP\nConfiguration)
|
||||
id1 & id2 -.-|ro| B1
|
||||
style id1 stroke:#000,stroke-width:1px,stroke-dasharray: 10
|
||||
style id2 stroke:#000,stroke-width:1px,stroke-dasharray: 10
|
||||
B2 ==r+w==> id3[(Persistent\nVolume)]
|
||||
end
|
||||
style A fill:#eeeeee, stroke-width:0px
|
||||
direction LR
|
||||
id4[External\nUser] ---id5(((443)))--->|Frontend\nNetwork| B1
|
||||
style id4 stroke:#000,stroke-width:2px
|
||||
B1 --Backend\nNetwork--> B2
|
||||
```
|
||||

|
||||
|
||||
The example application is composed of the following parts:
|
||||
|
||||
|
@ -126,8 +116,8 @@ networks:
|
|||
back-tier: {}
|
||||
```
|
||||
|
||||
This example illustrates the distinction between volumes, configs and secrets. While all of them are all exposed
|
||||
to service containers as mounted files or directories, only a volume can be configured for read+write access.
|
||||
Secrets and configs are read-only. The volume configuration allows you to select a volume driver and pass driver options
|
||||
to tweak volume management according to the actual infrastructure. Configs and secrets rely on platform services,
|
||||
and are declared `external` as they are not managed as part of the application lifecycle. Compose uses a platform-specific lookup mechanism to retrieve runtime values.
|
||||
## What's next
|
||||
|
||||
- [Try Compose](gettingstarted.md)
|
||||
- [Explore some sample applications](samples-for-compose.md)
|
||||
- [Familiarize yourself with the Compose Specification](compose-file/_index.md)
|
|
@ -39,10 +39,10 @@ aliases:
|
|||
|
||||
>**New to Compose?**
|
||||
>
|
||||
> Find more information about the [key features and use cases of Docker Compose](../features-uses.md) or [try the get started guide](../gettingstarted.md).
|
||||
> Find more information about the [key features and use cases of Docker Compose](../intro/features-uses.md) or [try the get started guide](../gettingstarted.md).
|
||||
{ .tip }
|
||||
|
||||
The Compose Specification is the latest and recommended version of the Compose file format. It helps you define a [Compose file](../compose-yaml-file.md) which is used to configure your Docker application’s services, networks, volumes, and more.
|
||||
The Compose Specification is the latest and recommended version of the Compose file format. It helps you define a [Compose file](../compose-application-model.md) which is used to configure your Docker application’s services, networks, volumes, and more.
|
||||
|
||||
Legacy versions 2.x and 3.x of the Compose file format were merged into the Compose Specification. It is implemented in versions 1.27.0 and above (also known as Compose V2) of the Docker Compose CLI.
|
||||
|
||||
|
|
|
@ -1,29 +0,0 @@
|
|||
---
|
||||
title: Understand the Compose file
|
||||
description: Understand the Compose application model with an illustrative example
|
||||
keywords: compose, docker compose, compose specification, compose model
|
||||
aliases:
|
||||
- /compose/compose-file/03-compose-file/
|
||||
---
|
||||
|
||||
The Compose file is a [YAML](http://yaml.org/) file defining:
|
||||
- [Version](compose-file/04-version-and-name.md) (Optional)
|
||||
- [Services](compose-file/05-services.md) (Required)
|
||||
- [Networks](compose-file/06-networks.md)
|
||||
- [Volumes](compose-file/07-volumes.md)
|
||||
- [Configs](compose-file/08-configs.md)
|
||||
- [Secrets](compose-file/09-secrets.md)
|
||||
|
||||
The default path for a Compose file is `compose.yaml` (preferred) or `compose.yml` that is placed in the working directory.
|
||||
Compose also supports `docker-compose.yaml` and `docker-compose.yml` for backwards compatibility of earlier versions.
|
||||
If both files exist, Compose prefers the canonical `compose.yaml`.
|
||||
|
||||
You can use [fragments](compose-file/10-fragments.md) and [extensions](compose-file/11-extension.md) to keep your Compose file efficient and easy to maintain.
|
||||
|
||||
Multiple Compose files can be [merged](13-merge.md) together to define the application model. The combination of YAML files are implemented by appending or overriding YAML elements based on the Compose file order you set.
|
||||
Simple attributes and maps get overridden by the highest order Compose file, lists get merged by appending. Relative
|
||||
paths are resolved based on the first Compose file's parent folder, whenever complimentary files being
|
||||
merged are hosted in other folders. As some Compose file elements can both be expressed as single strings or complex objects, merges apply to
|
||||
the expanded form.
|
||||
|
||||
If you want to reuse other Compose files, or factor out parts of you application model into separate Compose files, you can also use [`include`](compose-file/14-include.md). This is useful if your Compose application is dependent on another application which is managed by a different team, or needs to be shared with others.
|
|
@ -29,7 +29,7 @@ Version one of the Docker Compose command-line binary was first released in 2014
|
|||
|
||||
Version two of the Docker Compose command-line binary was announced in 2020, is written in Go, and is invoked with `docker compose`. Compose V2 ignores the version top-level element in the compose.yml file.
|
||||
|
||||
For further information, see [History and development of Compose](history.md).
|
||||
For further information, see [History and development of Compose](intro/history.md).
|
||||
|
||||
### What's the difference between `up`, `run`, and `start`?
|
||||
|
||||
|
|
|
@ -1,126 +0,0 @@
|
|||
---
|
||||
description: Key features and use cases of Docker Compose
|
||||
keywords: documentation, docs, docker, compose, orchestration, containers, uses, features
|
||||
title: Key features and use cases of Docker Compose
|
||||
---
|
||||
|
||||
Using Compose is essentially a three-step process:
|
||||
|
||||
1. Define your app's environment with a `Dockerfile` so it can be reproduced
|
||||
anywhere.
|
||||
|
||||
2. Define the services that make up your app in a `compose.yaml` file
|
||||
so they can be run together in an isolated environment.
|
||||
|
||||
3. Run `docker compose up` and the Docker compose command starts and runs your entire app.
|
||||
|
||||
A `compose.yaml` looks like this:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
web:
|
||||
build: .
|
||||
ports:
|
||||
- "8000:5000"
|
||||
volumes:
|
||||
- .:/code
|
||||
- logvolume01:/var/log
|
||||
depends_on:
|
||||
- redis
|
||||
redis:
|
||||
image: redis
|
||||
volumes:
|
||||
logvolume01: {}
|
||||
```
|
||||
|
||||
For more information about the Compose file, see the
|
||||
[Compose file reference](compose-file/index.md).
|
||||
|
||||
## Key features of Docker Compose
|
||||
|
||||
### Have multiple isolated environments on a single host
|
||||
|
||||
Compose uses a project name to isolate environments from each other. You can make use of this project name in several different contexts:
|
||||
|
||||
* On a dev host, to create multiple copies of a single environment, such as when you want to run a stable copy for each feature branch of a project
|
||||
* On a CI server, to keep builds from interfering with each other, you can set
|
||||
the project name to a unique build number
|
||||
* On a shared host or dev host, to prevent different projects, which may use the
|
||||
same service names, from interfering with each other
|
||||
|
||||
The default project name is the base name of the project directory. You can set
|
||||
a custom project name by using the
|
||||
[`-p` command line option](reference/index.md) or the
|
||||
[`COMPOSE_PROJECT_NAME` environment variable](environment-variables/envvars.md#compose_project_name).
|
||||
|
||||
The default project directory is the base directory of the Compose file. A custom value
|
||||
for it can be defined with the `--project-directory` command line option.
|
||||
|
||||
### Preserves volume data when containers are created
|
||||
|
||||
Compose preserves all volumes used by your services. When `docker compose up`
|
||||
runs, if it finds any containers from previous runs, it copies the volumes from
|
||||
the old container to the new container. This process ensures that any data
|
||||
you've created in volumes isn't lost.
|
||||
|
||||
If you use `docker compose` on a Windows machine, see
|
||||
[Environment variables](environment-variables/envvars.md) and adjust the necessary environment
|
||||
variables for your specific needs.
|
||||
|
||||
### Only recreate containers that have changed
|
||||
|
||||
Compose caches the configuration used to create a container. When you
|
||||
restart a service that has not changed, Compose re-uses the existing
|
||||
containers. Re-using containers means that you can make changes to your
|
||||
environment very quickly.
|
||||
|
||||
|
||||
### Supports variables and moving a composition between environments
|
||||
|
||||
Compose supports variables in the Compose file. You can use these variables
|
||||
to customize your composition for different environments, or different users.
|
||||
|
||||
You can extend a Compose file using the `extends` field or by creating multiple
|
||||
Compose files. For more details, see [Working with multiple Compose files](multiple-compose-files/index.md).
|
||||
|
||||
## Common use cases of Docker Compose
|
||||
|
||||
Compose can be used in many different ways. Some common use cases are outlined
|
||||
below.
|
||||
|
||||
### Development environments
|
||||
|
||||
When you're developing software, the ability to run an application in an
|
||||
isolated environment and interact with it is crucial. The Compose command
|
||||
line tool can be used to create the environment and interact with it.
|
||||
|
||||
The [Compose file](compose-file/index.md) provides a way to document and configure
|
||||
all of the application's service dependencies (databases, queues, caches,
|
||||
web service APIs, etc). Using the Compose command line tool you can create
|
||||
and start one or more containers for each dependency with a single command
|
||||
(`docker compose up`).
|
||||
|
||||
Together, these features provide a convenient way for developers to get
|
||||
started on a project. Compose can reduce a multi-page "developer getting
|
||||
started guide" to a single machine readable Compose file and a few commands.
|
||||
|
||||
### Automated testing environments
|
||||
|
||||
An important part of any Continuous Deployment or Continuous Integration process
|
||||
is the automated test suite. Automated end-to-end testing requires an
|
||||
environment in which to run tests. Compose provides a convenient way to create
|
||||
and destroy isolated testing environments for your test suite. By defining the full environment in a [Compose file](compose-file/index.md), you can create and destroy these environments in just a few commands:
|
||||
|
||||
```console
|
||||
$ docker compose up -d
|
||||
$ ./run_tests
|
||||
$ docker compose down
|
||||
```
|
||||
|
||||
### Single host deployments
|
||||
|
||||
Compose has traditionally been focused on development and testing workflows,
|
||||
but with each release we're making progress on more production-oriented features.
|
||||
|
||||
For details on using production-oriented features, see
|
||||
[Compose in production](production.md).
|
Binary file not shown.
After Width: | Height: | Size: 47 KiB |
|
@ -0,0 +1,68 @@
|
|||
---
|
||||
description: Key benefits and use cases of Docker Compose
|
||||
keywords: documentation, docs, docker, compose, orchestration, containers, uses, benefits
|
||||
title: Why use Compose?
|
||||
aliases:
|
||||
- /compose/features-uses/
|
||||
---
|
||||
|
||||
## Key benefits of Docker Compose
|
||||
|
||||
Using Docker Compose offers several benefits that streamline the development, deployment, and management of containerized applications:
|
||||
|
||||
- Simplified control: Docker Compose allows you to define and manage multi-container applications in a single YAML file. This simplifies the complex task of orchestrating and coordinating various services, making it easier to manage and replicate your application environment.
|
||||
|
||||
- Efficient collaboration: Docker Compose configuration files are easy to share, facilitating collaboration among developers, operations teams, and other stakeholders. This collaborative approach leads to smoother workflows, faster issue resolution, and increased overall efficiency.
|
||||
|
||||
- Rapid application development: Compose caches the configuration used to create a container. When you restart a service that has not changed, Compose re-uses the existing containers. Re-using containers means that you can make changes to your environment very quickly.
|
||||
|
||||
- Portability across environments: Compose supports variables in the Compose file. You can use these variables to customize your composition for different environments, or different users.
|
||||
|
||||
- Extensive community and support: Docker Compose benefits from a vibrant and active community, which means abundant resources, tutorials, and support. This community-driven ecosystem contributes to the continuous improvement of Docker Compose and helps users troubleshoot issues effectively.
|
||||
|
||||
## Common use cases of Docker Compose
|
||||
|
||||
Compose can be used in many different ways. Some common use cases are outlined
|
||||
below.
|
||||
|
||||
### Development environments
|
||||
|
||||
When you're developing software, the ability to run an application in an
|
||||
isolated environment and interact with it is crucial. The Compose command
|
||||
line tool can be used to create the environment and interact with it.
|
||||
|
||||
The [Compose file](../compose-file/_index.md) provides a way to document and configure
|
||||
all of the application's service dependencies (databases, queues, caches,
|
||||
web service APIs, etc). Using the Compose command line tool you can create
|
||||
and start one or more containers for each dependency with a single command
|
||||
(`docker compose up`).
|
||||
|
||||
Together, these features provide a convenient way for you to get
|
||||
started on a project. Compose can reduce a multi-page "developer getting
|
||||
started guide" to a single machine-readable Compose file and a few commands.
|
||||
|
||||
### Automated testing environments
|
||||
|
||||
An important part of any Continuous Deployment or Continuous Integration process
|
||||
is the automated test suite. Automated end-to-end testing requires an
|
||||
environment in which to run tests. Compose provides a convenient way to create
|
||||
and destroy isolated testing environments for your test suite. By defining the full environment in a [Compose file](../compose-file/_index.md), you can create and destroy these environments in just a few commands:
|
||||
|
||||
```console
|
||||
$ docker compose up -d
|
||||
$ ./run_tests
|
||||
$ docker compose down
|
||||
```
|
||||
|
||||
### Single host deployments
|
||||
|
||||
Compose has traditionally been focused on development and testing workflows,
|
||||
but with each release we're making progress on more production-oriented features.
|
||||
|
||||
For details on using production-oriented features, see
|
||||
[Compose in production](../production.md).
|
||||
|
||||
## What's next?
|
||||
- [Learn about the history of Compose](history.md)
|
||||
- [Understand how Compose works](../compose-application-model.md)
|
||||
- [Try Compose](../gettingstarted.md)
|
|
@ -2,6 +2,8 @@
|
|||
title: History and development of Docker Compose
|
||||
description: History of Compose V1 and Compose YAML schema versioning
|
||||
keywords: compose, compose yaml, swarm, migration, compatibility, docker compose vs docker-compose
|
||||
aliases:
|
||||
- /compose/history/
|
||||
---
|
||||
|
||||
{{< include "compose-eol.md" >}}
|
||||
|
@ -13,9 +15,9 @@ This page provides:
|
|||
|
||||
## Introduction
|
||||
|
||||

|
||||

|
||||
|
||||
The image above shows that the currently supported version of the Docker Compose CLI is Compose V2 which is defined by the [Compose Specification](https://github.com/compose-spec/compose-spec).
|
||||
The image above shows that the currently supported version of the Docker Compose CLI is Compose V2 which is defined by the [Compose Specification](../compose-file/_index.md).
|
||||
|
||||
It also provides a quick snapshot of the differences in file formats, command-line syntax, and top-level elements. This is covered in more detail in the following sections.
|
||||
|
||||
|
@ -32,17 +34,17 @@ Compose V2 ignores the `version` top-level element in the `compose.yml` file.
|
|||
The Docker Compose CLIs are defined by specific file formats.
|
||||
|
||||
Three major versions of the Compose file format for Compose V1 were released:
|
||||
- [Compose file format 1](./compose-file/compose-versioning.md##version-1-to-2x) with Compose 1.0.0 in 2014
|
||||
- [Compose file format 2.x](./compose-file/compose-file-v2.md) with Compose 1.6.0 in 2016
|
||||
- [Compose file format 3.x](./compose-file/compose-file-v3.md) with Compose 1.10.0 in 2017
|
||||
- [Compose file format 1](../compose-file/compose-versioning.md##version-1-to-2x) with Compose 1.0.0 in 2014
|
||||
- [Compose file format 2.x](../compose-file/compose-file-v2.md) with Compose 1.6.0 in 2016
|
||||
- [Compose file format 3.x](../compose-file/compose-file-v3.md) with Compose 1.10.0 in 2017
|
||||
|
||||
Compose file format 1 is substantially different to all the following formats as it lacks a top-level `services` key.
|
||||
Its usage is historical and files written in this format don't run with Compose V2.
|
||||
|
||||
Compose file format 2.x and 3.x are very similar to each other, but the latter introduced many new options targeted at Swarm deployments.
|
||||
|
||||
To address confusion around Compose CLI versioning, Compose file format versioning, and feature parity depending on whether Swarm mode was in use, file format 2.x and 3.x were merged into the [Compose Specification](compose-file/_index.md).
|
||||
To address confusion around Compose CLI versioning, Compose file format versioning, and feature parity depending on whether Swarm mode was in use, file format 2.x and 3.x were merged into the [Compose Specification](../compose-file/_index.md).
|
||||
|
||||
Compose V2 uses the Compose Specification for project definition. Unlike the prior file formats, the Compose Specification is rolling and makes the `version` top-level element optional. Compose V2 also makes use of optional specifications - [Deploy](compose-file/deploy.md), [Develop](compose-file/develop.md) and [Build](compose-file/build.md).
|
||||
Compose V2 uses the Compose Specification for project definition. Unlike the prior file formats, the Compose Specification is rolling and makes the `version` top-level element optional. Compose V2 also makes use of optional specifications - [Deploy](../compose-file/deploy.md), [Develop](../compose-file/develop.md) and [Build](../compose-file/build.md).
|
||||
|
||||
To make [migration](migrate.md) easier, Compose V2 has backwards compatibility for certain elements that have been deprecated or changed between Compose file format 2.x/3.x and the Compose Specification.
|
||||
To make [migration](../migrate.md) easier, Compose V2 has backwards compatibility for certain elements that have been deprecated or changed between Compose file format 2.x/3.x and the Compose Specification.
|
|
@ -176,6 +176,25 @@ underscores, and must begin with a lowercase letter or decimal digit. If the
|
|||
`basename` of the project directory or current directory violates this
|
||||
constraint, you must use one of the other mechanisms.
|
||||
|
||||
### Have multiple isolated environments on a single host
|
||||
|
||||
Compose uses a project name to isolate environments from each other. You can make use of this project name in several different contexts:
|
||||
|
||||
* On a dev host, to create multiple copies of a single environment, such as when you want to run a stable copy for each feature branch of a project
|
||||
* On a CI server, to keep builds from interfering with each other, you can set
|
||||
the project name to a unique build number
|
||||
* On a shared host or dev host, to prevent different projects, which may use the
|
||||
same service names, from interfering with each other
|
||||
|
||||
The default project name is the base name of the project directory. You can set
|
||||
a custom project name by using the
|
||||
[`-p` command line option](reference/index.md) or the
|
||||
[`COMPOSE_PROJECT_NAME` environment variable](../environment-variables/envvars.md#compose_project_name).
|
||||
|
||||
The default project directory is the base directory of the Compose file. A custom value
|
||||
for it can be defined with the `--project-directory` command line option.
|
||||
|
||||
|
||||
## Use `--profile` to specify one or more active profiles
|
||||
|
||||
Calling `docker compose --profile frontend up` will start the services with the
|
||||
|
|
|
@ -32,7 +32,7 @@ long: |-
|
|||
|
||||
* [.dockerignore](../../../engine/reference/builder.md#dockerignore-file)
|
||||
* [Dockerfile](../../../engine/reference/builder.md)
|
||||
* [compose.yaml](../../../compose/compose-yaml-file.md)
|
||||
* [compose.yaml](../../../compose/compose-application-model.md)
|
||||
|
||||
usage: docker init [OPTIONS]
|
||||
pname: docker
|
||||
|
|
|
@ -1937,14 +1937,12 @@ Manuals:
|
|||
section:
|
||||
- path: /compose/
|
||||
title: Overview
|
||||
- path: /compose/features-uses/
|
||||
title: Key features and use cases
|
||||
- path: /compose/compose-application-model/
|
||||
title: Understand the Compose application model
|
||||
- path: /compose/compose-yaml-file/
|
||||
title: Understand the Compose file
|
||||
- path: /compose/history/
|
||||
title: History and development of Compose
|
||||
- sectiontitle: Introduction to Compose
|
||||
section:
|
||||
- path: /compose/intro/features-uses/
|
||||
title: Why use Compose?
|
||||
- path: /compose/intro/history/
|
||||
title: History and development of Compose
|
||||
- sectiontitle: Install Docker Compose
|
||||
section:
|
||||
- path: /compose/install/
|
||||
|
@ -1955,11 +1953,10 @@ Manuals:
|
|||
title: Install Compose standalone
|
||||
- path: /compose/install/uninstall/
|
||||
title: Uninstall Compose
|
||||
- path: /compose/migrate/
|
||||
title: Migrate to Compose V2
|
||||
- path: /compose/compose-application-model/
|
||||
title: How Compose works
|
||||
- path: /compose/gettingstarted/
|
||||
title: Try Docker Compose
|
||||
|
||||
title: Try Compose
|
||||
- sectiontitle: Environment variables
|
||||
section:
|
||||
- path: /compose/environment-variables/
|
||||
|
@ -2000,6 +1997,8 @@ Manuals:
|
|||
title: Control startup order
|
||||
- path: /compose/samples-for-compose/
|
||||
title: Sample apps with Compose
|
||||
- path: /compose/migrate/
|
||||
title: Migrate to Compose V2
|
||||
- path: /compose/release-notes/
|
||||
title: Release notes
|
||||
|
||||
|
|
Loading…
Reference in New Issue