publish updates from main

content/manuals/compose/bridge/_index.md

@@ -1,14 +1,14 @@
 ---
-description: Understand what Compose Bridge is and how it can be useful
-keywords: compose, orchestration, kubernetes, bridge
+description: Learn how Compose Bridge transforms Docker Compose files into Kubernetes manifests for seamless platform transitions
+keywords: docker compose bridge, compose to kubernetes, docker compose kubernetes integration, docker compose kustomize, compose bridge docker desktop
 title: Overview of Compose Bridge
 linkTitle: Compose Bridge
 weight: 50
 ---
 
 {{< summary-bar feature_name="Compose bridge" >}}
 
-Compose Bridge lets you transform your Compose configuration file into configuration files for different platforms, primarily focusing on Kubernetes. The default transformation generates Kubernetes manifests and a Kustomize overlay which are designed for deployment on Docker Desktop with Kubernetes enabled.  
+Compose Bridge converts your Docker Compose configuration into platform-specific formats—primarily Kubernetes manifests. The default transformation generates Kubernetes manifests and a Kustomize overlay which are designed for deployment on Docker Desktop with Kubernetes enabled.  
 
 It's a flexible tool that lets you either take advantage of the [default transformation](usage.md) or [create a custom transformation](customize.md) to suit specific project needs and requirements.  
 

content/manuals/compose/bridge/customize.md

@@ -2,25 +2,26 @@
 title: Customize Compose Bridge 
 linkTitle: Customize
 weight: 20
-description: Learn about the Compose Bridge templates syntax
-keywords: compose, bridge, templates
+description: Learn how to customize Compose Bridge transformations using Go templates and Compose extensions
+keywords: docker compose bridge, customize compose bridge, compose bridge templates, compose to kubernetes, compose bridge transformation, go templates docker
+
 ---
 
 {{< summary-bar feature_name="Compose bridge" >}}
 
-This page explains how Compose Bridge utilizes templating to efficiently translate Docker Compose files into Kubernetes manifests. It also explain how you can customize these templates for your specific requirements and needs, or how you can build your own transformation. 
+This page explains how Compose Bridge utilizes templating to efficiently translate Docker Compose files into Kubernetes manifests. It also explains how you can customize these templates for your specific requirements and needs, or how you can build your own transformation. 
 
 ## How it works 
 
 Compose bridge uses transformations to let you convert a Compose model into another form. 
 
 A transformation is packaged as a Docker image that receives the fully-resolved Compose model as `/in/compose.yaml` and can produce any target format file under `/out`.
 
-Compose Bridge provides its transformation for Kubernetes using Go templates, so that it is easy to extend for customization by just replacing or appending your own templates.
+Compose Bridge includes a default Kubernetes transformation using Go templates, which you can customize by replacing or extending templates.
 
 ### Syntax
 
-Compose Bridge make use of templates to transform a Compose configuration file into Kubernetes manifests. Templates are plain text files that use the [Go templating syntax](https://pkg.go.dev/text/template). This enables the insertion of logic and data, making the templates dynamic and adaptable according to the Compose model.
+Compose Bridge makes use of templates to transform a Compose configuration file into Kubernetes manifests. Templates are plain text files that use the [Go templating syntax](https://pkg.go.dev/text/template). This enables the insertion of logic and data, making the templates dynamic and adaptable according to the Compose model.
 
 When a template is executed, it must produce a YAML file which is the standard format for Kubernetes manifests. Multiple files can be generated as long as they are separated by `---`
 
@@ -44,7 +45,7 @@ key: value
 
 ### Input
 
-The input Compose model is the canonical YAML model you can get by running  `docker compose config`. Within the templates, data from the `compose.yaml` is accessed using dot notation, allowing you to navigate through nested data structures. For example, to access the deployment mode of a service, you would use `service.deploy.mode`:
+You can generate the input model by running `docker compose config`. This canonical YAML output serves as the input for Compose Bridge transformations. Within the templates, data from the `compose.yaml` is accessed using dot notation, allowing you to navigate through nested data structures. For example, to access the deployment mode of a service, you would use `service.deploy.mode`:
 
  ```yaml
 # iterate over a yaml sequence
@@ -86,7 +87,7 @@ In the following example, the template checks if a healthcheck interval is speci
 As Kubernetes is a versatile platform, there are many ways
 to map Compose concepts into Kubernetes resource definitions. Compose
 Bridge lets you customize the transformation to match your own infrastructure
-decisions and preferences, with various level of flexibility and effort.
+decisions and preferences, with varying level of flexibility and effort.
 
 ### Modify the default templates
 

content/manuals/compose/bridge/usage.md

@@ -2,13 +2,13 @@
 title: Use the default Compose Bridge transformation
 linkTitle: Usage
 weight: 10
-description: Learn about and use the Compose Bridge default transformation
-keywords: compose, bridge, kubernetes
+description: Learn how to use the default Compose Bridge transformation to convert Compose files into Kubernetes manifests
+keywords: docker compose bridge, compose kubernetes transform, kubernetes from compose, compose bridge convert, compose.yaml to kubernetes
 ---
 
 {{< summary-bar feature_name="Compose bridge" >}}
 
-Compose Bridge supplies an out-of-the box transformation for your Compose configuration file. Based on an arbitrary `compose.yaml` file, Compose Bridge produces:
+Compose Bridge supplies an out-of-the-box transformation for your Compose configuration file. Based on an arbitrary `compose.yaml` file, Compose Bridge produces:
 
 - A [Namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) so all your resources are isolated and don't conflict with resources from other deployments.
 - A [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) with an entry for each and every [config](/reference/compose-file/configs.md) resource in your Compose application.
@@ -34,7 +34,8 @@ $ docker compose bridge convert
 
 Compose looks for a `compose.yaml` file inside the current directory and then converts it.
 
-The following output is displayed 
+When successful, Compose Bridge generates Kubernetes manifests and logs output similar to the following:
+
 ```console
 $ docker compose bridge convert -f compose.yaml 
 Kubernetes resource api-deployment.yaml created
@@ -62,7 +63,7 @@ These files are then stored within your project in the `/out` folder.
 The Kubernetes manifests can then be used to run the application on Kubernetes using
 the standard deployment command `kubectl apply -k out/overlays/desktop/`.
 
-> [!NOTE]
+> [!IMPORTANT]
 >
 > Make sure you have enabled Kubernetes in Docker Desktop before you deploy your Compose Bridge transformations.
 
@@ -80,7 +81,7 @@ $ docker compose bridge convert --help
 
 > [!TIP]
 >
-> You can now convert and deploy your Compose project to a Kubernetes cluster from the Compose file viewer.
+> You can convert and deploy your Compose project to a Kubernetes cluster from the Compose file viewer.
 > 
 > Make sure you are signed in to your Docker account, navigate to your container in the **Containers** view, and in the top-right corner select **View configurations** and then **Convert and Deploy to Kubernetes**. 
 

content/manuals/compose/how-tos/dependent-images.md

@@ -8,7 +8,7 @@ weight: 50
 {{< summary-bar feature_name="Compose dependent images" >}}
 
 To reduce push/pull time and image weight, a common practice for Compose applications is to have services
-share base layers as much as possible. You will typically select the same operating system base image for
+share base layers as much as possible. You typically select the same operating system base image for
 all services. But you can also get one step further by sharing image layers when your images share the same
 system packages. The challenge to address is then to avoid repeating the exact same Dockerfile instruction 
 in all services.
@@ -162,3 +162,8 @@ Bake can also be selected as the default builder by editing your `$HOME/.docker/
   ...
 }
 ```
+
+## Additional resources
+
+- [Docker Compose build reference](/reference/cli/docker/compose/build.md)
+- [Learn about multi-stage Dockerfiles](/manuals/build/building/multi-stage.md)

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

@@ -2,14 +2,13 @@
 title: Environment variables in Compose
 linkTitle: Use environment variables
 weight: 40
-description: Explainer on the ways to set, use and manage environment variables in
-  Compose
+description: Explains how to set, use, and manage environment variables in Docker Compose.
 keywords: compose, orchestration, environment, env file
 aliases:
 - /compose/environment-variables/
 ---
 
-By leveraging environment variables and interpolation in Docker Compose, you can create versatile and reusable configurations, making your Dockerized applications easier to manage and deploy across different environments. 
+Environment variables and interpolation in Docker Compose help you create reusable, flexible configurations. This makes Dockerized applications easier to manage and deploy across environments.
 
 > [!TIP]
 >

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

@@ -12,7 +12,7 @@ aliases:
 
 When the same environment variable is set in multiple sources, Docker Compose follows a precedence rule to determine the value for that variable in your container's environment.
 
-This page contains information on the level of precedence each method of setting environmental variables takes.
+This page explains how Docker Compose determines the final value of an environment variable when it's defined in multiple locations.
 
 The order of precedence (highest to lowest) is as follows:
 1. Set using [`docker compose run -e` in the CLI](set-environment-variables.md#set-environment-variables-with-docker-compose-run---env).
@@ -59,25 +59,25 @@ The columns `Host OS environment` and `.env` file is listed only for illustratio
 
 Each row represents a combination of contexts where `VALUE` is set, substituted, or both. The **Result** column indicates the final value for `VALUE` in each scenario.
 
-|  # |  `docker compose run`  |  `environment` attribute  |  `env_file` attribute  |  Image `ENV` |  `Host OS` environment  |  `.env` file      | |  Result  |
-|:--:|:----------------:|:-------------------------------:|:----------------------:|:------------:|:-----------------------:|:-----------------:|:---:|:----------:|
-|  1 |   -              |   -                             |   -                    |   -          |  `VALUE=1.4`            |  `VALUE=1.3`      || -               |
-|  2 |   -              |   -                             |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |   -               ||**`VALUE=1.6`**  |
-|  3 |   -              |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |   -               ||**`VALUE=1.7`**  |
-|  4 |   -              |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.5`**  |
-|  5 |`--env VALUE=1.8` |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.8`**  |
-|  6 |`--env VALUE`     |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.4`**  |
-|  7 |`--env VALUE`     |   -                             |   -                    |  `VALUE=1.5` |   -                     |  `VALUE=1.3`      ||**`VALUE=1.3`**  |
-|  8 |   -              |   -                             |   `VALUE`              |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.4`**  |
-|  9 |   -              |   -                             |   `VALUE`              |  `VALUE=1.5` |   -                     |  `VALUE=1.3`      ||**`VALUE=1.3`**  |
-| 10 |   -              |  `VALUE`                        |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.4`**  |
-| 11 |   -              |  `VALUE`                        |   -                    |  `VALUE=1.5` |  -                      |  `VALUE=1.3`      ||**`VALUE=1.3`**  |
-| 12 |`--env VALUE`     |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.4`**  |
-| 13 |`--env VALUE=1.8` |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.8`**  |
-| 14 |`--env VALUE=1.8` |   -                             |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.8`**  |
-| 15 |`--env VALUE=1.8` |  `VALUE=1.7`                    |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      ||**`VALUE=1.8`**  |
-
-### Result explanation
+|  # |  `docker compose run`  |  `environment` attribute  |  `env_file` attribute  |  Image `ENV` |  `Host OS` environment  |  `.env` file      |   Result  |
+|:--:|:----------------:|:-------------------------------:|:----------------------:|:------------:|:-----------------------:|:-----------------:|:----------:|
+|  1 |   -              |   -                             |   -                    |   -          |  `VALUE=1.4`            |  `VALUE=1.3`      | -               |
+|  2 |   -              |   -                             |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |   -               |**`VALUE=1.6`**  |
+|  3 |   -              |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |   -               |**`VALUE=1.7`**  |
+|  4 |   -              |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.5`**  |
+|  5 |`--env VALUE=1.8` |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.8`**  |
+|  6 |`--env VALUE`     |   -                             |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.4`**  |
+|  7 |`--env VALUE`     |   -                             |   -                    |  `VALUE=1.5` |   -                     |  `VALUE=1.3`      |**`VALUE=1.3`**  |
+|  8 |   -              |   -                             |   `VALUE`              |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.4`**  |
+|  9 |   -              |   -                             |   `VALUE`              |  `VALUE=1.5` |   -                     |  `VALUE=1.3`      |**`VALUE=1.3`**  |
+| 10 |   -              |  `VALUE`                        |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.4`**  |
+| 11 |   -              |  `VALUE`                        |   -                    |  `VALUE=1.5` |  -                      |  `VALUE=1.3`      |**`VALUE=1.3`**  |
+| 12 |`--env VALUE`     |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.4`**  |
+| 13 |`--env VALUE=1.8` |  `VALUE=1.7`                    |   -                    |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.8`**  |
+| 14 |`--env VALUE=1.8` |   -                             |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.8`**  |
+| 15 |`--env VALUE=1.8` |  `VALUE=1.7`                    |  `VALUE=1.6`           |  `VALUE=1.5` |  `VALUE=1.4`            |  `VALUE=1.3`      |**`VALUE=1.8`**  |
+
+### Understanding precedence results
 
 Result 1: The local environment takes precedence, but the Compose file is not set to replicate this inside the container, so no such variable is set.
 
@@ -87,7 +87,7 @@ Result 3: The `environment` attribute in the Compose file defines an explicit va
 
 Result 4: The image's `ENV` directive declares the variable `VALUE`, and since the Compose file is not set to override this value, this variable is defined by image
 
-Result 5: The `docker compose run` command has the `--env` flag set which an explicit value, and overrides the value set by the image. 
+Result 5: The `docker compose run` command has the `--env` flag set with an explicit value, and overrides the value set by the image. 
 
 Result 6: The `docker compose run` command has the `--env` flag set to replicate the value from the environment. Host OS value takes precedence and is replicated into the container's environment.
 
@@ -104,3 +104,8 @@ Result 11: The `environment` attribute in the Compose file is set to replicate `
 Result 12: The `--env` flag has higher precedence than the `environment` and `env_file` attributes and is to set to replicate `VALUE` from the local environment. Host OS value takes precedence and is replicated into the container's environment.
 
 Results 13 to 15: The `--env` flag has higher precedence than the `environment` and `env_file` attributes and so sets the value. 
+
+## Next steps
+
+- [Set environment variables in Compose](set-environment-variables.md)
+- [Use variable interpolation in Compose files](variable-interpolation.md)