Skip to content

Commit

Permalink
Sync from docker/docs@fd4ec38 by PCIT
Browse files Browse the repository at this point in the history
  • Loading branch information
khs1994 committed Jul 28, 2023
1 parent 52d735b commit 2399d6a
Show file tree
Hide file tree
Showing 3 changed files with 52 additions and 45 deletions.
2 changes: 1 addition & 1 deletion build/cache/backends/inline.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ Alternatively, you can also export inline cache by setting the build argument

```console
$ docker buildx build --push -t <registry>/<image> \
--arg BUILDKIT_INLINE_CACHE=1 .
--build-arg BUILDKIT_INLINE_CACHE=1 .
```

To import the resulting cache on a future build, pass `type=registry` to
Expand Down
92 changes: 49 additions & 43 deletions compose/migrate.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,25 +7,36 @@ redirect_from:
- /compose/cli-command-compatibility/
---

{% include compose-eol.md %}
From July 2023 Compose V1 stopped receiving updates. It’s also no longer available in new releases of Docker Desktop.

## What are the functional differences between Compose V1 and Compose V2?
Compose V2, which was first released in 2020, is included with all currently supported versions of Docker Desktop. It offers an improved CLI experience, improved build performance with BuildKit, and continued new-feature development.

Compose V2 introduces a new internal architecture integrated with the rest of the Docker platform.
It offers an improved CLI experience, improved build performance with BuildKit, and continued new-feature development.
## How do I switch to Compose V2?

For most projects, switching to Compose V2 requires no changes to the Compose YAML or your development workflow.
The easiest and recommended way is to make sure you have the latest version of [Docker Desktop](../desktop/release-notes.md), which bundles the Docker Engine and Docker CLI platform including Compose V2.

With Docker Desktop, Compose V2 is always accessible as `docker compose`.
Additionally, the **Use Compose V2** setting is turned on by default, which provides an alias from `docker-compose`.

For manual installs on Linux, you can get Compose V2 by either:
- [Using Docker's repository](install/linux.md#install-using-the-repository) (recommended)
- [Downloading and installing manually](install/linux.md#install-the-plugin-manually)

## What are the differences between Compose V1 and Compose V2?

### `docker-compose` vs `docker compose`

Unlike Compose V1, Compose V2 integrates into the Docker CLI platform and the recommended command-line syntax is `docker compose`.

The Docker CLI platform provides a consistent and predictable set of options and flags, such as the `DOCKER_HOST` environment variable or the `--context` command-line flag.

This change enables using all of the shared flags on the root `docker` command.
For example, `docker --log-level=debug --tls compose up` enables debug logging from the Docker Engine as well as ensures that TLS is used for the connection.
This change lets you use all of the shared flags on the root `docker` command.
For example, `docker --log-level=debug --tls compose up` enables debug logging from the Docker Engine as well as ensuring that TLS is used for the connection.

Update scripts to use Compose V2 by replacing the hyphen (`-`) with a space, using `docker compose` instead of `docker-compose`.
> **Tip**
>
> Update scripts to use Compose V2 by replacing the hyphen (`-`) with a space, using `docker compose` instead of `docker-compose`.
{: .tip}

### Service container names

Expand All @@ -34,22 +45,25 @@ Compose generates container names based on the project name, service name, and s
In Compose V1, an underscore (`_`) was used as the word separator.
In Compose V2, a hyphen (`-`) is used as the word separator.

Underscores are not valid characters in DNS hostnames.
Underscores aren't valid characters in DNS hostnames.
By using a hyphen instead, Compose V2 ensures service containers can be accessed over the network via consistent, predictable hostnames.

For example, running the Compose command `-p myproject up --scale=1 svc` results in a container named `myproject_svc_1` with Compose V1 and a container named `myproject-svc-1` with Compose V2.

In Compose V2, the global `--compatibility` flag or `COMPOSE_COMPATIBILITY` environment variable preserves the Compose V1 behavior to use underscores (`_`) as the word separator.
As this option must be specified for _every_ Compose V2 command run, we recommend only using this as a temporary measure while transitioning to Compose V2.
> **Tip**
>
>In Compose V2, the global `--compatibility` flag or `COMPOSE_COMPATIBILITY` environment variable preserves the Compose V1 behavior to use underscores (`_`) as the word separator.
As this option must be specified for every Compose V2 command run, it's recommended that you only use this as a temporary measure while transitioning to Compose V2.
{: .tip}

### Command-line flags and subcommands

Compose V2 still supports almost all Compose V1 flags and subcommands, so in most cases, it can be used as a drop-in replacement in scripts.
Compose V2 supports almost all Compose V1 flags and subcommands, so in most cases, it can be used as a drop-in replacement in scripts.

#### Unsupported in V2

The following were deprecated in Compose V1 and are not supported in Compose V2:
* `docker-compose scale` (use `docker compose up --scale` instead)
The following were deprecated in Compose V1 and aren't supported in Compose V2:
* `docker-compose scale`. Use `docker compose up --scale` instead.
* `docker-compose rm --all`

#### Different in V2
Expand All @@ -63,51 +77,43 @@ The following behave differently between Compose V1 and V2:

### Environment variables

Environment variable behavior in Compose V1 was not formally documented and behaved inconsistently in some edge cases.
Environment variable behavior in Compose V1 wasn't formally documented and behaved inconsistently in some edge cases.

For Compose V2, the [Environment variables](/compose/environment-variables/) section covers both [precedence](/compose/environment-variables/envvars-precedence) as well as [`.env` file interpolation](/compose/environment-variables/env-file) and includes numerous examples covering tricky situations such as escaping nested quotes.
For Compose V2, the [Environment variables](/compose/environment-variables/) section covers both [precedence](/compose/environment-variables/envvars-precedence) as well as [`.env` file interpolation](/compose/environment-variables/env-file) and includes many examples covering tricky situations such as escaping nested quotes.

Ask yourself...
- Is my project using multiple levels of environment variable overrides (e.g. `.env` file and `--env` CLI flags)?
- Do any `.env` file values have escape sequences or nested quotes?
- Do any `.env` file values contain literal `$` signs in them? (This is common with PHP projects!)
- Do any variable values use advanced expansion syntax? (e.g. `${VAR:?error}`)
Check if:
- Your project uses multiple levels of environment variable overrides, for example `.env` file and `--env` CLI flags.
- Any `.env` file values have escape sequences or nested quotes.
- Any `.env` file values contain literal `$` signs in them. This is common with PHP projects.
- Any variable values use advanced expansion syntax, for example `${VAR:?error}`.

Run `docker compose config` on the project to preview the configuration after Compose V2 has performed interpolation to
> **Tip**
>
> Run `docker compose config` on the project to preview the configuration after Compose V2 has performed interpolation to
verify that values appear as expected.

Maintaining backwards compatibility with Compose V1 is typically achievable by ensuring that literal values (no
>
> Maintaining backwards compatibility with Compose V1 is typically achievable by ensuring that literal values (no
interpolation) are single-quoted and values that should have interpolation applied are double-quoted.
{: .tip}

## What does this mean for my projects that use Compose V1?

For most projects, switching to Compose V2 requires no changes to the Compose YAML or your development workflow.

We recommend that you adapt to the new preferred way of running Compose V2, which is to use `docker compose` instead of `docker-compose`.
It's recommended that you adapt to the new preferred way of running Compose V2, which is to use `docker compose` instead of `docker-compose`.
This provides additional flexibility and removes the requirement for a `docker-compose` compatibility alias.

However, Docker Desktop will continue to support a `docker-compose` alias to redirect commands to `docker compose` for convenience and improved compatibility with third-party tools and scripts.

## How do I upgrade?

The easiest and recommended way to switch to Compose V2 is to make sure you have the latest version of [Docker Desktop](../desktop/release-notes.md), which bundles the Docker Engine and Docker CLI platform including Compose V2.

With Docker Desktop, Compose V2 is always accessible as `docker compose`.
Additionally, the **Use Compose V2** option is enabled by default, which provides an alias from `docker-compose`.

For manual installs on Linux, you can get Compose V2 by either:
- [Using Docker's repository](install/linux.md#install-using-the-repository) (recommended)
- [Downloading and installing manually](install/linux.md#install-the-plugin-manually)
However, Docker Desktop continues to support a `docker-compose` alias to redirect commands to `docker compose` for convenience and improved compatibility with third-party tools and scripts.

## Is there anything else I need to know before I upgrade?
## Is there anything else I need to know before I switch?

### Migrating running projects

In both V1 and V2, running `up` on a Compose project recreates service containers as necessary to reach the desired state based on comparing the actual state in the Docker Engine to the resolved project configuration including Compose YAML, environment variables, and command-line flags.

Because Compose V1 and V2 [name service containers differently](#service-container-names), running `up` using V2 the first time on a project with running services originally launched by V1 will result in service containers being recreated with updated names.
Because Compose V1 and V2 [name service containers differently](#service-container-names), running `up` using V2 the first time on a project with running services originally launched by V1, results in service containers being recreated with updated names.

Note that even if `--compatibility` flag is used to preserve the V1 naming style, Compose still needs to recreate service containers originally launched by V1 the first time `up` is run by V2 to migrate internal state.
Note that even if `--compatibility` flag is used to preserve the V1 naming style, Compose still needs to recreate service containers originally launched by V1 the first time `up` is run by V2 to migrate the internal state.

### Using Compose V2 with Docker-in-Docker

Expand All @@ -117,16 +123,16 @@ target="_blank" rel="noopener" class="_"}.
Additionally, a new [docker/compose-bin image on Docker Hub](https://hub.docker.com/r/docker/compose-bin){:
target="_blank" rel="noopener" class="_"} packages the latest version of Compose V2 for use in multi-stage builds.

## Will I still be able to use Compose V1 if I really want to?
## Can I still use Compose V1 if I want to?

Yes. You can still download and install Compose V1 packages, but you won't get support from Docker if anything breaks.

>**Warning**
>
> The final Compose v1 release (v1.29.2) was May 10, 2021. These packages haven't received any security updates since then. Use at your own risk.
> The final Compose V1 release, version 1.29.2, was May 10, 2021. These packages haven't received any security updates since then. Use at your own risk.
{: .warning}

### Additional Resources
## Additional Resources
- [docker-compose V1 on PyPI](https://pypi.org/project/docker-compose/1.29.2/){:
target="_blank" rel="noopener" class="_"}
- [docker/compose V1 on Docker Hub](https://hub.docker.com/r/docker/compose){:
Expand Down
3 changes: 2 additions & 1 deletion desktop/install/linux-install.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,7 @@ To install Docker Desktop successfully, your Linux host must meet the following
- For many Linux distros, the Gnome environment does not support tray icons. To add support for tray icons, you need to install a Gnome extension. For example, [AppIndicator](https://extensions.gnome.org/extension/615/appindicator-support/){:target="_blank" rel="noopener" class="_"}.
- At least 4 GB of RAM.
- Enable configuring ID mapping in user namespaces, see [File sharing](../faqs/linuxfaqs.md#how-do-i-enable-file-sharing).
- Recommended: [Initialize `pass`](../get-started.md#credentials-management-for-linux-users) for credentials management.

Docker Desktop for Linux runs a Virtual Machine (VM). For more information on why, see [Why Docker Desktop for Linux runs a VM](../faqs/linuxfaqs.md#why-does-docker-desktop-for-linux-run-a-vm).

Expand Down Expand Up @@ -145,5 +146,5 @@ Make sure you meet the system requirements outlined earlier and follow the distr
- [FAQs](../faqs/general.md) provide answers to frequently asked questions.
- [Release notes](../release-notes.md) lists component updates, new features, and improvements associated with Docker Desktop releases.
- [Get started with Docker](../../get-started/index.md) provides a general Docker tutorial.
* [Back up and restore data](../backup-and-restore.md) provides instructions
- [Back up and restore data](../backup-and-restore.md) provides instructions
on backing up and restoring data related to Docker.

0 comments on commit 2399d6a

Please sign in to comment.