diff --git a/content/manuals/compose/how-tos/environment-variables/envvars-precedence.md b/content/manuals/compose/how-tos/environment-variables/envvars-precedence.md index de6b7a558dfd..223c11ead25a 100644 --- a/content/manuals/compose/how-tos/environment-variables/envvars-precedence.md +++ b/content/manuals/compose/how-tos/environment-variables/envvars-precedence.md @@ -21,6 +21,15 @@ The order of precedence (highest to lowest) is as follows: 5. Set in a container image in the [ENV directive](/reference/dockerfile.md#env). Having any `ARG` or `ENV` setting in a `Dockerfile` evaluates only if there is no Docker Compose entry for `environment`, `env_file` or `run --env`. +> [!NOTE] +> +> When `--env-file` is not set, Compose may load up to two `.env` files. +> It first loads one from the project directory (determined by `--project-directory` +> if set, otherwise the directory of the first `-f`/`--file` Compose file, otherwise +> `PWD`). If that file sets `COMPOSE_FILE` to a path in a different directory, Compose +> loads a second `.env` file from that directory with lower precedence. For more +> information, see [local `.env` file versus project directory `.env` file](variable-interpolation.md#local-env-file-versus-project-directory-env-file). + ## Simple example In the following example, a different value for the same environment variable in an `.env` file and with the `environment` attribute in the Compose file: diff --git a/content/manuals/compose/how-tos/multiple-compose-files/_index.md b/content/manuals/compose/how-tos/multiple-compose-files/_index.md index d7e9dc78a0da..d0520f3104b3 100644 --- a/content/manuals/compose/how-tos/multiple-compose-files/_index.md +++ b/content/manuals/compose/how-tos/multiple-compose-files/_index.md @@ -13,7 +13,10 @@ This section contains information on the ways you can work with multiple Compose Using multiple Compose files lets you customize a Compose application for different environments or workflows. This is useful for large applications that may use dozens of containers, with ownership distributed across multiple teams. For example, if your organization or team uses a monorepo, each team may have their own “local” Compose file to run a subset of the application. They then need to rely on other teams to provide a reference Compose file that defines the expected way to run their own subset. Complexity moves from the code in to the infrastructure and the configuration file. -The quickest way to work with multiple Compose files is to [merge](merge.md) Compose files using the `-f` flag in the command line to list out your desired Compose files. However, [merging rules](merge.md#merging-rules) means this can soon get quite complicated. +The simplest way to work with multiple Compose files is to [merge](merge.md) them using +the `-f` flag. This works well for straightforward overrides, but the +[merging rules](merge.md#merging-rules) can make it complex to manage as your +configuration grows. Docker Compose provides two other options to manage this complexity when working with multiple Compose files. Depending on your project's needs, you can: diff --git a/content/manuals/compose/how-tos/multiple-compose-files/merge.md b/content/manuals/compose/how-tos/multiple-compose-files/merge.md index 49f32136d2a5..ebadca7c40a7 100644 --- a/content/manuals/compose/how-tos/multiple-compose-files/merge.md +++ b/content/manuals/compose/how-tos/multiple-compose-files/merge.md @@ -356,8 +356,22 @@ For more information, see [Using Compose in production](../production.md). ## Limitations -Docker Compose supports relative paths for the many resources to be included in the application model: build context for service images, location of file defining environment variables, path to a local directory used in a bind-mounted volume. -With such a constraint, code organization in a monorepo can become hard as a natural choice would be to have dedicated folders per team or component, but then the Compose files relative paths become irrelevant. +When merging Compose files, all relative paths (for build contexts, environment files, +bind-mounted volumes, and other resources) are resolved relative to the base Compose file. The +first file specified with `-f`, or `compose.yaml` in the current directory if `-f` is +not used. Paths in override files are not resolved relative to the override file's own +location. + +This means that in a monorepo where Compose files are spread across team or component +subdirectories, relative paths in those files are resolved incorrectly when used as +override files. + +> [!TIP] +> +> If you need each Compose file's paths to resolve relative to its own location, +> use the [`include` top-level element](include.md) instead of merging with `-f`. Each +> included file is loaded with its own project directory, so relative paths resolve +> correctly. ## Reference information diff --git a/content/manuals/desktop/features/wsl/_index.md b/content/manuals/desktop/features/wsl/_index.md index 9b846303f750..080e9d1bac09 100644 --- a/content/manuals/desktop/features/wsl/_index.md +++ b/content/manuals/desktop/features/wsl/_index.md @@ -10,6 +10,7 @@ aliases: - /docker-for-windows/wsl/ - /desktop/windows/wsl/ - /desktop/wsl/ +- /docker-for-windows/wsl-tech-preview/ --- Windows Subsystem for Linux (WSL) 2 is a full Linux kernel built by Microsoft that lets Linux distributions run without managing virtual machines. With Docker Desktop running on WSL 2, users can leverage Linux workspaces and avoid maintaining both Linux and Windows build scripts. In addition, WSL 2 provides improvements to file system sharing, faster cold-start times, and dynamic resource allocation.