publish updates from main (#22137)

Automated pull request for publishing docs updates.

---------

Co-authored-by: Ville Skyttä <ville.skytta@iki.fi>
Co-authored-by: Veck Hsiao <fbukevin@gmail.com>
Co-authored-by: Etienne Guerlain <32822018+eguerlain@users.noreply.github.com>
Co-authored-by: Manuel de la Peña <social.mdelapenya@gmail.com>
Co-authored-by: aevesdocker <allie.sadler@docker.com>
Co-authored-by: Veesh Goldman <rabbiveesh@gmail.com>

Author: 6 people

_vale/config/vocabularies/Docker/accept.txt

@@ -55,6 +55,7 @@ Intune
 JFrog
 Jamf
 JetBrains
+JUnit
 Kerberos
 Kitematic
 Kubeadm
@@ -80,6 +81,7 @@ Paketo
 Postgres
 PowerShell
 Python
+Ryuk
 S3
 SQLite
 Slack

content/guides/genai-leveraging-rag/index.md

@@ -38,7 +38,7 @@ The system operates as follows:
 3. The found information gets added to the original question before passed to LLM 
 4. The LLM generates responses that blend the model's inherent knowledge with the this extra information.  
 
-To hold this vector information in a efficient manner, we need a special type of database.
+To hold this vector information in an efficient manner, we need a special type of database.
 
 ## Introduction to Graph databases 
 

content/guides/python/deploy.md

@@ -161,7 +161,7 @@ In these Kubernetes YAML file, there are various objects, separated by the `---`
   your Python application](configure-ci-cd.md).
 - A Service, which will define how the ports are mapped in the containers.
 - A PersistentVolumeClaim, to define a storage that will be persistent through restarts for the database.
-- A Secret, Keeping the database password as a example using secret kubernetes resource.
+- A Secret, Keeping the database password as an example using secret kubernetes resource.
 - A NodePort service, which will route traffic from port 30001 on your host to
   port 8001 inside the pods it routes to, allowing you to reach your app
   from the network.

content/guides/ruby/develop.md

@@ -176,7 +176,7 @@ $ docker compose watch
 
 Any changes to the application's source files on your local machine will now be immediately reflected in the running container.
 
-Open `docker-ruby-on-rails/app/views/whales/index.html.erb` in an IDE or text editor and update the `Whales` string by adding a exclamation marks.
+Open `docker-ruby-on-rails/app/views/whales/index.html.erb` in an IDE or text editor and update the `Whales` string by adding an exclamation mark.
 
 ```diff
 -    <h1>Whales</h1>

content/manuals/_index.md

@@ -26,6 +26,10 @@ params:
     description: Define and run multi-container applications.
     icon: /assets/icons/Compose.svg
     link: /compose/
+  - title: Testcontainers OSS
+    description: Run containers programmatically in your preferred programming language.
+    icon: /assets/icons/Testcontainers.svg
+    link: /testcontainers/
   products:
   - title: Docker Desktop
     description: Your command center for container development.

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/releases/release-notes.md

@@ -289,7 +289,7 @@ For more detailed information, see the [release notes in the Compose repo](https
 
 - Fixed the docs on `docker compose kill` usage.
 - Fixed redundant condition from `toAPIBuildOptions` in build.go.
-- Fixed initial Watch `sync` after Compose restarts with introduction of `x-initSync`.
+- Fixed initial Watch `sync` after Compose restarts with introduction of `x-initialSync`.
 - Fixed an issue which stopped the Compose process for a single container on `sync-restart` Watch action.
 
 ## 2.29.1

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/desktop/features/dev-environments/set-up.md

@@ -18,7 +18,7 @@ aliases:
 
 To set up a dev environment, there are additional configuration steps to tell Docker Desktop how to build, start, and use the right image for your services.
 
-Dev Environments use an `compose-dev.yaml` file located at the root of your project. This file allows you to define the image required for a dedicated service, the ports you'd like to expose, along with additional configuration options.
+Dev Environments use a `compose-dev.yaml` file located at the root of your project. This file allows you to define the image required for a dedicated service, the ports you'd like to expose, along with additional configuration options.
 
 The following is an example `compose-dev.yaml` file.
 

content/manuals/desktop/use-desktop/volumes.md

@@ -119,7 +119,7 @@ To empty a volume:
 
 ## Export a volume
 
-You can export the content of a volume to a local file, a local image, an to an
+You can export the content of a volume to a local file, a local image, and to an
 image in Docker Hub, or to a supported cloud provider. When exporting content
 from a volume used by one or more running containers, the containers are
 temporarily stopped while Docker exports the content, and then restarted when

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/logging/drivers/gelf.md

@@ -66,7 +66,7 @@ The `gelf` logging driver supports the following options:
 | `gelf-address`             | required | The address of the GELF server. `tcp` and `udp` are the only supported URI specifier and you must specify the port.                                                                                                                                                                 | `--log-opt gelf-address=udp://192.168.0.42:12201`  |
 | `gelf-compression-type`    | optional | `UDP Only` The type of compression the GELF driver uses to compress each log message. Allowed values are `gzip`, `zlib` and `none`. The default is `gzip`. Note that enabled compression leads to excessive CPU usage, so it's highly recommended to set this to `none`.            | `--log-opt gelf-compression-type=gzip`             |
 | `gelf-compression-level`   | optional | `UDP Only` The level of compression when `gzip` or `zlib` is the `gelf-compression-type`. An integer in the range of `-1` to `9` (BestCompression). Default value is 1 (BestSpeed). Higher levels provide more compression at lower speed. Either `-1` or `0` disables compression. | `--log-opt gelf-compression-level=2`               |
-| `gelf-tcp-max-reconnect`   | optional | `TCP Only` The maximum number of reconnection attempts when the connection drop. An positive integer. Default value is 3.                                                                                                                                                           | `--log-opt gelf-tcp-max-reconnect=3`               |
+| `gelf-tcp-max-reconnect`   | optional | `TCP Only` The maximum number of reconnection attempts when the connection drop. A positive integer. Default value is 3.                                                                                                                                                            | `--log-opt gelf-tcp-max-reconnect=3`               |
 | `gelf-tcp-reconnect-delay` | optional | `TCP Only` The number of seconds to wait between reconnection attempts. A positive integer. Default value is 1.                                                                                                                                                                     | `--log-opt gelf-tcp-reconnect-delay=1`             |
 | `tag`                      | optional | A string that's appended to the `APP-NAME` in the `gelf` message. By default, Docker uses the first 12 characters of the container ID to tag log messages. Refer to the [log tag option documentation](log_tags.md) for customizing the log tag format.                             | `--log-opt tag=mailer`                             |
 | `labels`                   | optional | Applies when starting the Docker daemon. A comma-separated list of logging-related labels this daemon accepts. Adds additional key on the `extra` fields, prefixed by an underscore (`_`). Used for advanced [log tag options](log_tags.md).                                        | `--log-opt labels=production_status,geo`           |

content/manuals/engine/release-notes/28.md

@@ -317,6 +317,6 @@ For a full list of pull requests and changes in this release, refer to the relev
 - `api/types/system/Commit.Expected` field is deprecated and should no longer be used. [moby/moby#48478](https://github.com/moby/moby/pull/48478)
 - `daemon/graphdriver`: Deprecate `GetDriver()` [moby/moby#48079](https://github.com/moby/moby/pull/48079)
 - `libnetwork/iptables`: Deprecate `Passthrough`. This function was only used internally, and will be removed in the next release. [moby/moby#49115](https://github.com/moby/moby/pull/49115)
-- `pkg/directory.Size()` function is deprecated, an will be removed in the next release. [moby/moby#48057](https://github.com/moby/moby/pull/48057)
+- `pkg/directory.Size()` function is deprecated, and will be removed in the next release. [moby/moby#48057](https://github.com/moby/moby/pull/48057)
 - `registry`: Deprecate `APIEndpoint.TrimHostName`; hostname is now trimmed unconditionally for remote names. This field will be removed in the next release. [moby/moby#49005](https://github.com/moby/moby/pull/49005)
 - `allow-nondistributable-artifacts` field in `daemon.json`. Setting either option will no longer take effect, but a deprecation warning log is added to raise awareness about the deprecation. This warning is planned to become an error in the next release. [moby/moby#49065](https://github.com/moby/moby/pull/49065)