Merge pull request #22135 from scop/docs/manuals-compose-yaml

docs(manuals): use canonical compose.yaml filename

content/manuals/build/bake/compose-file.md

@@ -10,7 +10,7 @@ Bake supports the [Compose file format](/reference/compose-file/_index.md)
 to parse a Compose file and translate each service to a [target](reference.md#target).
 
 ```yaml
-# docker-compose.yml
+# compose.yaml
 services:
   webapp-dev:
     build: &build-dev
@@ -106,7 +106,7 @@ where the command is executed and applied to compose definitions passed
 with `-f`.
 
 ```yaml
-# docker-compose.yml
+# compose.yaml
 services:
   webapp:
     image: docker.io/username/webapp:${TAG:-v1.0.0}
@@ -152,7 +152,7 @@ the [special extension](/reference/compose-file/extension.md) field
 `x-bake` in your compose file to evaluate extra fields:
 
 ```yaml
-# docker-compose.yml
+# compose.yaml
 services:
   addon:
     image: ct-addon:bar

content/manuals/compose/how-tos/environment-variables/envvars-precedence.md

@@ -30,7 +30,7 @@ In the following example, a different value for the same environment variable in
 $ cat ./webapp.env
 NODE_ENV=test
 
-$ cat compose.yml
+$ cat compose.yaml
 services:
   webapp:
     image: 'webapp'

content/manuals/compose/how-tos/environment-variables/envvars.md

@@ -74,7 +74,7 @@ Specifies the path to a Compose file. Specifying multiple Compose files is suppo
    For example:
 
       ```console
-      COMPOSE_FILE=docker-compose.yml:docker-compose.prod.yml
+      COMPOSE_FILE=compose.yaml:compose.prod.yaml
       ```  
    The path separator can also be customized using [`COMPOSE_PATH_SEPARATOR`](#compose_path_separator).  
 

content/manuals/compose/how-tos/environment-variables/set-environment-variables.md

@@ -20,7 +20,7 @@ A container's environment is not set until there's an explicit entry in the serv
 ## Use the `environment` attribute
 
 You can set environment variables directly in your container's environment with the
-[`environment` attribute](/reference/compose-file/services.md#environment) in your `compose.yml`. 
+[`environment` attribute](/reference/compose-file/services.md#environment) in your `compose.yaml`.
 
 It supports both list and mapping syntax:
 
@@ -74,7 +74,7 @@ It can also help you keep your environment variables separate from your main con
 
 The [`env_file` attribute](/reference/compose-file/services.md#env_file) also lets you use multiple `.env` files in your Compose application.  
 
-The paths to your `.env` file, specified in the `env_file` attribute, are relative to the location of your `compose.yml` file. 
+The paths to your `.env` file, specified in the `env_file` attribute, are relative to the location of your `compose.yaml` file.
 
 > [!IMPORTANT]
 >

content/manuals/compose/how-tos/environment-variables/variable-interpolation.md

@@ -21,7 +21,7 @@ Below is a simple example:
 ```console
 $ cat .env
 TAG=v1.5
-$ cat compose.yml
+$ cat compose.yaml
 services:
   web:
     image: "webapp:${TAG}"
@@ -98,7 +98,7 @@ services:
 
 #### Additional information 
 
-- If you define a variable in your `.env` file, you can reference it directly in your `compose.yml` with the [`environment` attribute](/reference/compose-file/services.md#environment). For example, if your `.env` file contains the environment variable `DEBUG=1` and your `compose.yml` file looks like this:
+- If you define a variable in your `.env` file, you can reference it directly in your `compose.yaml` with the [`environment` attribute](/reference/compose-file/services.md#environment). For example, if your `.env` file contains the environment variable `DEBUG=1` and your `compose.yaml` file looks like this:
    ```yaml
     services:
       webapp:
@@ -163,14 +163,14 @@ $ docker compose --env-file ./config/.env.dev up
 
 #### Additional information 
 
-- This method is useful if you want to temporarily override an `.env` file that is already referenced in your `compose.yml` file. For example you may have different `.env` files for production ( `.env.prod`) and testing (`.env.test`).
+- This method is useful if you want to temporarily override an `.env` file that is already referenced in your `compose.yaml` file. For example you may have different `.env` files for production ( `.env.prod`) and testing (`.env.test`).
   In the following example, there are two environment files, `.env` and `.env.dev`. Both have different values set for `TAG`. 
   ```console
   $ cat .env
   TAG=v1.5
   $ cat ./config/.env.dev
   TAG=v1.6
-  $ cat compose.yml
+  $ cat compose.yaml
   services:
     web:
       image: "webapp:${TAG}"

content/manuals/compose/how-tos/gpu-support.md

@@ -15,7 +15,7 @@ You can use either `docker-compose` or `docker compose` commands. For more infor
 
 ## Enabling GPU access to service containers
 
-GPUs are referenced in a `compose.yml` file using the [device](/reference/compose-file/deploy.md#devices) attribute from the Compose Deploy specification, within your services that need them. 
+GPUs are referenced in a `compose.yaml` file using the [device](/reference/compose-file/deploy.md#devices) attribute from the Compose Deploy specification, within your services that need them.
 
 This provides more granular control over a GPU reservation as custom values can be set for the following device properties: 
 

content/manuals/compose/how-tos/multiple-compose-files/extends.md

@@ -59,7 +59,7 @@ services:
       - "/data"
 ```
 You get exactly the same result as if you wrote
-`docker-compose.yml` with the same `build`, `ports`, and `volumes` configuration
+`compose.yaml` with the same `build`, `ports`, and `volumes` configuration
 values defined directly under `web`.
 
 To include the service `webapp` in the final project when extending services from another file, you need to explicitly include both services in your current Compose file. For example (note this is a non-normative example):
@@ -133,7 +133,7 @@ services:
     cpu_shares: 5
 ```
 
-The `docker-compose.yaml` defines the concrete services which use the common
+The `compose.yaml` defines the concrete services which use the common
 configuration:
 
 ```yaml

content/manuals/compose/how-tos/networking.md

@@ -22,7 +22,7 @@ other containers on that network, and discoverable by the service's name.
 > project name with either the [`--project-name` flag](/reference/cli/docker/compose.md)
 > or the [`COMPOSE_PROJECT_NAME` environment variable](environment-variables/envvars.md#compose_project_name).
 
-For example, suppose your app is in a directory called `myapp`, and your `compose.yml` looks like this:
+For example, suppose your app is in a directory called `myapp`, and your `compose.yaml` looks like this:
 
 ```yaml
 services:

content/manuals/compose/how-tos/production.md

@@ -29,15 +29,15 @@ production. These changes might include:
 - Adding extra services such as a log aggregator
 
 For this reason, consider defining an additional Compose file, for example
-`production.yml`, which specifies production-appropriate
+`compose.production.yaml`, which specifies production-appropriate
 configuration. This configuration file only needs to include the changes you want to make from the original Compose file. The additional Compose file
-is then applied over the original `compose.yml` to create a new configuration.
+is then applied over the original `compose.yaml` to create a new configuration.
 
 Once you have a second configuration file, you can use it with the
 `-f` option:
 
 ```console
-$ docker compose -f compose.yml -f production.yml up -d
+$ docker compose -f compose.yaml -f compose.production.yaml up -d
 ```
 
 See [Using multiple compose files](multiple-compose-files/_index.md) for a more complete example, and other options.

content/manuals/compose/how-tos/profiles.md

@@ -61,7 +61,7 @@ $ COMPOSE_PROFILES=debug docker compose up
 ```
 
 Both commands start the services with the `debug` profile enabled.
-In the previous `compose.yml` file, this starts the services
+In the previous `compose.yaml` file, this starts the services
 `db`, `backend` and `phpmyadmin`.
 
 ### Start multiple profiles
@@ -187,7 +187,7 @@ $ docker compose --profile debug down
 $ COMPOSE_PROFILES=debug docker compose down
 ```
 
-Both commands stop and remove services with the `debug` profile. In the following `compose.yml` file, this stops the services `db` and `phpmyadmin`.
+Both commands stop and remove services with the `debug` profile. In the following `compose.yaml` file, this stops the services `db` and `phpmyadmin`.
 
 ```yaml
 services:

content/manuals/compose/intro/history.md

@@ -24,10 +24,10 @@ It also provides a quick snapshot of the differences in file formats, command-li
 ### Docker Compose CLI versioning
 
 Version one of the Docker Compose command-line binary was first released in 2014. It was written in Python, and is invoked with `docker-compose`.
-Typically, Compose V1 projects include a top-level `version` element in the `compose.yml` file, with values ranging from `2.0` to `3.8`, which refer to the specific [file formats](#compose-file-format-versioning).
+Typically, Compose V1 projects include a top-level `version` element in the `compose.yaml` file, with values ranging from `2.0` to `3.8`, which refer to the specific [file formats](#compose-file-format-versioning).
 
 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. 
+Compose V2 ignores the `version` top-level element in the `compose.yaml` file.
 
 ### Compose file format versioning
 

content/manuals/compose/support-and-feedback/faq.md

@@ -11,16 +11,16 @@ aliases:
 
 ### What is the difference between `docker compose` and `docker-compose`
 
-Version one of the Docker Compose command-line binary was first released in 2014. It was written in Python, and is invoked with `docker-compose`. Typically, Compose V1 projects include a top-level version element in the compose.yml file, with values ranging from 2.0 to 3.8, which refer to the specific file formats.
+Version one of the Docker Compose command-line binary was first released in 2014. It was written in Python, and is invoked with `docker-compose`. Typically, Compose V1 projects include a top-level version element in the compose.yaml file, with values ranging from 2.0 to 3.8, which refer to the specific file formats.
 
-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.
+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.yaml file.
 
 For further information, see [History and development of Compose](/manuals/compose/intro/history.md).
 
 ### What's the difference between `up`, `run`, and `start`?
 
 Typically, you want `docker compose up`. Use `up` to start or restart all the
-services defined in a `compose.yml`. In the default "attached"
+services defined in a `compose.yaml`. In the default "attached"
 mode, you see all the logs from all the containers. In "detached" mode (`-d`),
 Compose exits after starting the containers, but the containers continue to run
 in the background.

content/manuals/compose/support-and-feedback/samples-for-compose.md

@@ -17,9 +17,9 @@ if you have not already done so.
 The samples should help you to:
 
 - Define services based on Docker images using
-  [Compose files](/reference/compose-file/_index.md): `compose.yml` and
+  [Compose files](/reference/compose-file/_index.md): `compose.yaml` and
   `docker-stack.yml`
-- Understand the relationship between `compose.yml` and
+- Understand the relationship between `compose.yaml` and
   [Dockerfiles](/reference/dockerfile/)
 - Learn how to make calls to your application services from Compose files
 - Learn how to deploy applications and services to a [swarm](/manuals/engine/swarm/_index.md)

content/manuals/engine/cli/otel.md

@@ -63,7 +63,7 @@ The following Docker Compose file bootstraps a set of services to get started wi
 It includes an OpenTelemetry collector that the CLI can send metrics to,
 and a Prometheus backend that scrapes the metrics off the collector.
 
-```yaml {collapse=true,title=compose.yml}
+```yaml {collapse=true,title=compose.yaml}
 name: cli-otel
 services:
   prometheus:
@@ -95,7 +95,7 @@ volumes:
 ```
 
 This service assumes that the following two configuration files exist alongside
-`compose.yml`:
+`compose.yaml`:
 
 - ```yaml {collapse=true,title=otelcol.yml}
   # Receive signals over gRPC and HTTP

content/manuals/engine/security/trust/trust_sandbox.md

@@ -67,10 +67,10 @@ the `trustsandbox` container, the Notary server, and the Registry server.
         $ mkdir trustsandbox
         $ cd trustsandbox
 
-2. Create a file called `compose.yml` with your favorite editor.  For example, using vim:
+2. Create a file called `compose.yaml` with your favorite editor.  For example, using vim:
 
-        $ touch compose.yml
-        $ vim compose.yml
+        $ touch compose.yaml
+        $ vim compose.yaml
 
 3. Add the following to the new file.
 

content/manuals/engine/swarm/services.md

@@ -712,7 +712,7 @@ $ docker service create \
   nginx
 ```
 
-You can also use the `constraint` service-level key in a `compose.yml`
+You can also use the `constraint` service-level key in a `compose.yaml`
 file.
 
 If you specify multiple placement constraints, the service only deploys onto

content/manuals/engine/swarm/stack-deploy.md

@@ -111,7 +111,7 @@ counter whenever you visit it.
     CMD ["python", "app.py"]
     ```
 
-5.  Create a file called `compose.yml` and paste this in:
+5.  Create a file called `compose.yaml` and paste this in:
 
     ```yaml
       services:
@@ -220,7 +220,7 @@ The stack is now ready to be deployed.
 1.  Create the stack with `docker stack deploy`:
 
     ```console
-    $ docker stack deploy --compose-file compose.yml stackdemo
+    $ docker stack deploy --compose-file compose.yaml stackdemo
 
     Ignoring unsupported options: build
 

content/manuals/extensions/extensions-sdk/architecture/_index.md

@@ -64,9 +64,9 @@ Usually, the backend is made of one container that runs within the Docker Deskto
 a Docker Compose project, creates the container from the `image` option of the `vm` section of the `metadata.json`, and
 attaches it to the Compose project. See the [ui metadata section](metadata.md#vm-section) for more details.
 
-In some cases, a `compose.yml` file can be used instead of an `image`. This is useful when the backend container
+In some cases, a `compose.yaml` file can be used instead of an `image`. This is useful when the backend container
 needs more specific options, such as mounting volumes or requesting [capabilities](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
-that can't be expressed just with a Docker image. The `compose.yml` file can also be used to add multiple containers
+that can't be expressed just with a Docker image. The `compose.yaml` file can also be used to add multiple containers
 needed by the extension, like a database or a message broker. 
 Note that, if the Compose file defines many services, the SDK can only contact the first of them.
 

content/manuals/extensions/extensions-sdk/architecture/metadata.md

@@ -50,7 +50,7 @@ Other UI extension points will be available in the future.
 ### VM section
 
 The `vm` section defines a backend service that runs inside the Desktop VM. It must define either an `image` or a
-`docker-compose.yaml` file that specifies what service to run in the Desktop VM.
+`compose.yaml` file that specifies what service to run in the Desktop VM.
 
 ```json
 "vm": {
@@ -66,7 +66,7 @@ When you use `image`, a default compose file is generated for the extension.
 
 ```json
 "vm": {
-    "composefile": "docker-compose.yaml"
+    "composefile": "compose.yaml"
 },
 ```