docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

ENGDOCS-1874 (#18786) 

* ENGDOCS-1874

* fix build

* fix build

* add description and keywords

* remove dependency

* vendoring update
This commit is contained in:
Allie Sadler 2023-11-27 13:38:11 +00:00 committed by GitHub
parent e15406c364
commit 9949bc70f0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
17 changed files with 29 additions and 2057 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

244
_vendor/github.com/docker/compose-cli/docs/aci-compose-features.md generated
View File

@ -1,244 +0,0 @@
---
title: ACI integration Compose features
description: Reference list of compose ACI features
keywords: Docker, Azure, Integration, ACI, Compose, cli, deploy, cloud
---
> **Important**
>
> Docker Compose's integration for ECS and ACI is retiring in November 2023.
{: .important}
# Compose - Azure Container Instances mapping
This document outlines the conversion of an application defined in a Compose file to ACI objects.
At a high-level, each Compose deployment is mapped to a single ACI container group.
Each service is mapped to a container in the container group. The Docker ACI integration does not allow scaling of services.
## Compose fields mapping
The table below lists supported Compose file fields and their ACI counterparts.
__Legend:__
- __✓:__ Implemented
- __n:__ Not yet implemented
- __x:__ Not applicable / no available conversion
| Keys |Map| Notes |
|--------------------------------|---|--------------------------------------------------------------|
| __Service__ | ✓ |
| service.service.build | x | Ignored. No image build support on ACI.
| service.cap_add, cap_drop | x |
| service.command | ✓ | Override container Command. On ACI, specifying `command` will override the image command and entrypoint, if the image has an command or entrypoint defined |
| service.configs | x |
| service.cgroup_parent | x |
| service.container_name | x | Service name is used as container name on ACI.
| service.credential_spec | x |
| service.deploy | ✓ |
| service.deploy.endpoint_mode | x |
| service.deploy.mode | x |
| service.deploy.replicas | x | Only one replica is started for each service.
| service.deploy.placement | x |
| service.deploy.update_config | x |
| service.deploy.resources | ✓ | Restriction: ACI resource limits cannot be greater than the sum of resource reservations for all containers in the container group. Using container limits that are greater than container reservations will cause containers in the same container group to compete with resources.
| service.deploy.restart_policy | ✓ | One of: `any`, `none`, `on-failure`. Restriction: All services must have the same restart policy. The entire ACI container group will be restarted if needed.
| service.deploy.labels | x | ACI does not have container-level labels.
| service.devices | x |
| service.depends_on | x |
| service.dns | x |
| service.dns_search | x |
| service.domainname | ✓ | Mapped to ACI DNSLabelName. Restriction: all services must specify the same `domainname`, if specified. `domainname` must be unique globally in <region>.azurecontainer.io
| service.tmpfs | x |
| service.entrypoint | x | ACI only supports overriding the container command.
| service.env_file | ✓ |
| service.environment | ✓ |
| service.expose | x |
| service.extends | x |
| service.external_links | x |
| service.extra_hosts | x |
| service.group_add | x |
| service.healthcheck | ✓ |
| service.hostname | x |
| service.image | ✓ | Private images will be accessible if the user is logged into the corresponding registry at deploy time. Users will be automatically logged in to Azure Container Registry using their Azure login if possible.
| service.isolation | x |
| service.labels | x | ACI does not have container-level labels.
| service.links | x |
| service.logging | x |
| service.network_mode | x |
| service.networks | x | Communication between services is implemented by defining mapping for each service in the shared `/etc/hosts` file of the container group. Each service can resolve names for other services and the resulting network calls will be redirected to `localhost`.
| service.pid | x |
| service.ports | ✓ | Only symmetrical port mapping is supported in ACI. See [Exposing ports](#exposing-ports).
| service.secrets | ✓ | See [Secrets](#secrets).
| service.security_opt | x |
| service.stop_grace_period | x |
| service.stop_signal | x |
| service.sysctls | x |
| service.ulimits | x |
| service.userns_mode | x |
| service.volumes | ✓ | Mapped to AZure File Shares. See [Persistent volumes](#persistent-volumes).
| service.restart | x | Replaced by service.deployment.restart_policy
| | |
| __Volume__ | x |
| driver | ✓ | See [Persistent volumes](#persistent-volumes).
| driver_opts | ✓ |
| external | x |
| labels | x |
| | |
| __Secret__ | x |
| TBD | x |
| | |
| __Config__ | x |
| TBD | x |
| | |
## Logs
Container logs can be obtained for each container with `docker logs <CONTAINER>`.
The Docker ACI integration does not currently support aggregated logs for containers in a Compose application, see https://github.com/docker/compose-cli/issues/803.
## Exposing ports
When one or more services expose ports, the entire ACI container group will be exposed and will get a public IP allocated.
As all services are mapped to containers in the same container group, only one service cannot expose a given port number.
[ACI does not support port mapping](https://feedback.azure.com/forums/602224-azure-container-instances/suggestions/34082284-support-for-port-mapping), so the source and target ports defined in the Compose file must be the same.
When exposing ports, a service can also specify the service `domainname` field to set a DNS hostname. `domainname` will be used to specify the ACI DNS Label Name, and the ACI container group will be reachable at <domainname>.<region>.azurecontainer.io.
All services specifying a `domainname` must set the same value, as it is applied to the entire container group.
`domainname` must be unique globally in <region>.azurecontainer.io
## Persistent volumes
Docker volumes are mapped to Azure file shares. Only the long Compose volume format is supported meaning that volumes must be defined in the `volume` section.
Volumes are defined with a name, the `driver` field must be set to `azure_file`, and `driver_options` must define the storage account and file share to use for the volume.
A service can then reference the volume by its name, and specify the target path to be mounted in the container.
```yaml
services:
myservice:
image: nginx
volumes:
- mydata:/mount/testvolumes
volumes:
mydata:
driver: azure_file
driver_opts:
share_name: myfileshare
storage_account_name: mystorageaccount
```
The short volume syntax is not allowed for ACI volumes, as it was designed for local path bind mounting when running local containers.
A Compose file can define several volumes, with different Azure file shares or storage accounts.
Credentials for storage accounts will be automatically fetched at deployment time using the Azure login to retrieve the storage account key for each storage account used.
## Secrets
Secrets can be defined in compose files, and will need secret files available at deploy time next to the compose file.
The content of the secret file will be made available inside selected containers, by default under `/run/secrets/<SECRET_NAME>`.
External secrets are not supported with the ACI integration.
```yaml
services:
nginx:
image: nginx
secrets:
- mysecret1
db:
image: mysql
secrets:
- mysecret2
secrets:
mysecret1:
file: ./my_secret1.txt
mysecret2:
file: ./my_secret2.txt
```
The nginx container will have secret1 mounted as `/run/secrets/mysecret1`, the db container will have secret2 mounted as `/run/secrets/mysecret2`
A target can also be specified to set the name of the mounted file or by specifying an absolute path where to mount the secret file
```yaml
services:
nginx:
image: nginx
secrets:
- source: mysecret1
target: renamedsecret1.txt
db:
image: mysql
secrets:
- source: mysecret1
target: /mnt/dbmount/mysecretonmount1.txt
- source: mysecret2
target: /mnt/dbmount/mysecretonmount2.txt
secrets:
mysecret1:
file: ./my_secret1.txt
mysecret2:
file: ./my_secret2.txt
```
In this example the `nginx` service will have its secret mounted to `/run/secrets/renamedsecret1.txt` and `db` will have 2 files (`mysecretonmount1.txt` and `mysecretonmount2.txt`).
Both of them with be mounted in the same folder (`/mnt/dbmount/`).
**Note:** Relative file paths are not allowed in the target
**Note:** Secret files cannot be mounted in a folder next to other existing files
## Container Resources
CPU and memory reservations and limits can be set in compose.
Resource limits must be greater than reservation. In ACI, setting resource limits different from resource reservation will cause containers in the same container group to compete for resources. Resource limits cannot be greater than the total resource reservation for the container group. (Therefore single containers cannot have resource limits different from resource reservations)
```yaml
services:
db:
image: mysql
deploy:
resources:
reservations:
cpus: '2'
memory: 2G
limits:
cpus: '3'
memory: 3G
web:
image: nginx
deploy:
resources:
reservations:
cpus: '1.5'
memory: 1.5G
```
In this example, the db container will be allocated 2 CPUs and 2G of memory. It will be allowed to use up to 3 CPUs and 3G of memory, using some of the resources allocated to the web container.
The web container will have its limits set to the same values as reservations, by default.
## Healthchecks
A health check can be described in the `healthcheck` section of each service. This is translated to a `LivenessProbe` in ACI. If the health check fails then the container is considered unhealthy and terminated.
In order for the container to be restarted automatically, the service needs to have a restart policy other than `none` to be set. Note that the default restart policy if one isn't set is `any`.
```yaml
services:
web:
image: nginx
deploy:
restart_policy:
condition: on-failure
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:80"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
```
**Note:** that the `test` command can be a `string` or an array starting or not by `NONE`, `CMD`, `CMD-SHELL`. In the ACI implementation, these prefixes are ignored.

88
_vendor/github.com/docker/compose-cli/docs/aci-container-features.md generated
View File

@ -1,88 +0,0 @@
---
title: ACI integration container features
description: Reference list of container ACI features
keywords: Docker, Azure, Integration, ACI, container, cli, deploy, cloud
---
> **Important**
>
> Docker Compose's integration for ECS and ACI is retiring in November 2023.
{: .important}
# Azure Container Instances: running single containers
Single containers can be executed on ACI with the `docker run` command.
A single container is executed in its own ACI container group, which will contain a single container.
Containers can be listed with the `docker ps` command, and stopped and removed with `docker stop <CONTAINER>` and `docker rm <CONTAINER>`.
# Docker run options for ACI containers
The table below lists supported `docker run` flags and their ACI counterparts.
__Legend:__
- __✓:__ Implemented
- __n:__ Not yet implemented
- __x:__ Not applicable / no available conversion
| Flag |Map| Notes
|-----------------------|---|---------------------------------|
| --cpus | ✓ | See [Container Resources](#container-resources).
| -d, --detach | ✓ | Detach from container logs when container starts. By default, the command line stays attached and follow container logs.
| --domainname | ✓ | See [Exposing ports](#exposing-ports).
| --e, --env | ✓ | Sets environment variable.
| --env-file | ✓ | Sets environment variable from and external file.
| --health-cmd | ✓ | Specify healthcheck command. See [Healthchecks](#healthchecks).
| --health-interval | ✓ | Specify healthcheck interval
| --health-retries | ✓ | Specify healthcheck number of retries
| --health-start-period | ✓ | Specify healthcheck initial delay
| --health-timeout | ✓ | Specify healthcheck timeout
| -l, --label | x | Unsupported in Docker ACI integration, due to limitations of ACI Tags.
| -m, --memory | ✓ | See [Container Resources](#container-resources).
| --name | ✓ | Provide a name for the container. Name must be unique withing the ACI resource group. a name is generated by default.
| -p, --publish | ✓ | See [Exposing ports](#exposing-ports). Only symetrical port mapping is supported in ACI.
| --restart | ✓ | Restart policy, must be one of: `always`, `no`, `on-failure`.
| --rm | x | Not supported as [ACI does not support auto-delete containers](https://feedback.azure.com/forums/602224-azure-container-instances/suggestions/34066633-support-auto-delete-of-aci-when-container-exits-no).
| -v, --volume | ✓ | See [Persistent Volumes](#persistent-volumes).
## Exposing ports
You can expose one or more ports of a container with `docker run -p <PORT>:<PORT>`
If ports are exposed when running a container, the corresponding ACI container group will be exposed with a public IP allocated and the required port(s) accessible.
> Note: [ACI does not support port mapping](https://feedback.azure.com/forums/602224-azure-container-instances/suggestions/34082284-support-for-port-mapping), so the same port number must be specified when using `-p <PORT>:<PORT>`.
When exposing ports, a container can also specify the service `--domainname` flag to set a DNS hostname. `domainname` will be used to specify the ACI DNS Label Name, and the ACI container group will be reachable at `<DOMAINNANE>.<REGION>.azurecontainer.io`.
`domainname` must be unique globally in <REGION>.azurecontainer.io
## Persistent volumes
Docker volumes are mapped to Azure File shares, each file share is part of an Azure Storage Account.
One or more volumes can be specified with `docker run -v <STORAGE-ACCOUNT>/<FILESHARE>:<TARGET-PATH>`.
A run command can use the `--volume` or `-v` flag several times for different volumes. The volumes can use the same or different storage accounts. The target paths for different volume mounts must be different and not overlap.
There is no support for mounting a single file, or mounting a subfolder from an Azure File Share.
Credentials for storage accounts will be automatically fetched at deployment time using the Azure login to retrieve the storage account key for each storage account used.
## Container Resources
CPU and memory reservations can be set when running containers with `docker run --cpus 1.5 --memory 2G`.
It is not possible to set resource limits that differ from resource reservation on single containers.
ACI allows setting resource limits for containers in a container group but these limits must stay within the reserved resources for the entire group. In the case of a single container deployed in a container group, the resource limits must be equal to the resource reservation.
## Logs
You can view container logs with the command `docker logs <CONTAINER-ID>`.
You can follow logs with the `--follow` (`-f`) option.
When running a container with `docker run`, by default the command line stays attached to container logs when the container starts. Use `docker run --detach` to not follow logs once the container starts.
> Note: Following ACI logs may have display issues especially when resizing a terminal that is following container logs. This is due to ACI providing raw log pulling but no streaming of logs. Logs are effectively pulled every 2 seconds when following logs.
## Healthchecks
A health check can be described using the flags prefixed by `--health-`. This is translated into `LivenessProbe` for ACI. If the health check fails then the container is considered unhealthy and terminated.
In order for the container to be restarted automatically, the container needs to be run with a restart policy (set by the `--restart` flag) other than `no`. Note that the default restart policy if one isn't set is `no`.
In order to restart automatically, the container also need to have a restart policy set with `--restart` (`docker run` defaults to no restart policy)

88
_vendor/github.com/docker/compose-cli/docs/ecs-architecture.md generated
View File

@ -1,88 +0,0 @@
---
title: ECS integration architecture
description: Mapping of Docker compose entities to Amazon constructs
keywords: Docker, Amazon, Integration, ECS, Compose, architecture, mapping
---
> **Important**
>
> Docker Compose's integration for ECS and ACI is retiring in November 2023.
{: .important}
# Architecture
ECS integration relies on CloudFormation to manage AWS resources as an atomic operation.
This document describes the mapping between compose application model and AWS components
## Overview
This diagram shows compose model and on same line AWS components that get created as equivalent resources
```
+----------+ +-------------+ +-------------------+
| Project | . . . . . . . . . . . . . . | Cluster | . . . . . . . | LoadBalancer |
+-+--------+ +-------------+ +-------------------+
|
| +----------+ +-------------++-------------------+ +-------------------+
+----+ Service | . . . . . . . . . . | Service || TaskDefinition | | TargetGroup |
| +--+-------+ +-------------++-------------------+-+ +-------------------+
| | | TaskRole |
| | +-------------------+-+
| | x-aws-role, x-aws-policies . . . . . . . . | TaskExecutionRole |
| | +-------------------+
| | +---------+
| +--+ Deploy |
| | +---------+ +-------------------+
| | x-aws-autoscaling . . . . . . | ScalableTarget |
| | +-------------------+---+
| | | ScalingPolicy |
| | +-------------------+-+
| | | AutoScalingRole |
| | +-------------------+
| |
| | +---------+ +-------------+ +-------------------+
| +--+ Ports | . . . . . . . | IngressRule +-----+ | Listener |
| | +---------+ +-------------+ | +-------------------+
| | |
| | +---------+ +---------------+ +------------------+
| +--+ Secrets | . . . . . . . | InitContainer | |TaskExecutionRole |
| | +---------+ +---------------+ +------------+-----+
| | | |
| | +---------+ | |
| +--+ Volumes | | |
| | +---------+ | |
| | | |
| | +---------------+ | | +-------------------+
| +--+ DeviceRequest | . . . . . . . . . . . . . . . | . . . . | . . . | CapacityProvider |
| +---------------+ | | +-------------------+--------+
| | | | AutoscalingGroup |
| +------------+ +---------------+ | | +---------------------+
+---+ Networks | . . . . . . . . . | SecurityGroup +---+ | | LaunchConfiguration |
| +------------+ +---------------+ | +---------------------+
| |
| +------------+ +---------------+ |
+---+ Secret | . . . . . . . . . | Secret +--------------+
+------------+ +---------------+
```
Each compose application service is mapped to an ECS `Service`. A `TaskDefinition` is created according to compose definition.
Actual mapping is constrained by both Cloud platform and Fargate limitations. Such a `TaskDefinition` is set with a single container,
according to the compose model which doesn't offer a syntax to support sidecar containers.
An IAM Role is created and configured as `TaskRole` to grant service access to additional AWS resources when required. For this
purpose, user can set `x-aws-policies` or define a fine grained `x-aws-role` IAM role document.
Service's ports get mapped into security group's `IngressRule`s and load balancer `Listener`s.
Compose application with HTTP services only (using ports 80/443 or `x-aws-protocol` set to `http`) get an Application Load Balancer
created, otherwise a Network Load Balancer is used.
A `TargetGroup` is created per service to dispatch traffic by load balancer to the matching containers
Secrets bound to a service get translated into an `InitContainer` added to the service's `TaskDefinition`. This init container is
responsible to create a `/run/secrets` file for secret to match docker secret model and make application code portable.
A `TaskExecutionRole` is also created per service, and is updated to grant access to bound secrets.
Services using a GPU (`DeviceRequest`) get the `Cluster` extended with an EC2 `CapacityProvider`, using an `AutoscalingGroup` to manage
EC2 resources allocation based on a `LaunchConfiguration`. The latter uses ECS recommended AMI and machine type for GPU.
Service to declare `deploy.x-aws-autoscaling` get a `ScalingPolicy` created targeting specified the configured CPU usage metric

306
_vendor/github.com/docker/compose-cli/docs/ecs-compose-examples.md generated
View File

@ -1,306 +0,0 @@
---
title: ECS integration composefile examples
description: Examples of ECS compose files
keywords: Docker, Amazon, Integration, ECS, Compose, cli, deploy, cloud, sample
---
> **Important**
>
> Docker Compose's integration for ECS and ACI is retiring in November 2023.
{: .important}
# Compose file samples - ECS specific
## Service
A service mapping may define a Docker image and runtime constraints and container requirements.
```yaml
services:
test:
image: "image"
command: "command"
entrypoint: "entrypoint"
environment:
- "FOO=BAR"
cap_add:
- SYS_PTRACE
cap_drop:
- SYSLOG
init: true
user: "user"
working_dir: "working_dir"
```
###### Task size
Set resource limits that will get translated to Fargate task size values:
```yaml
services:
test:
image: nginx
deploy:
resources:
limits:
cpus: '0.5'
memory: 2048M
```
###### IAM roles
Assign an existing user role to a task:
```yaml
services:
test:
x-aws-policies:
- "arn:aws:iam::aws:policy/AmazonS3FullAccess"
```
###### IAM policies
Assign an in-line IAM policy to a task:
```yaml
services:
test:
x-aws-role:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: sqs:*
Resource: arn:aws:sqs:us-east-1:12345678:myqueue
```
###### Logging
Pass options to awslogs driver
```yaml
services:
foo:
image: nginx
logging:
options:
awslogs-datetime-pattern: "FOO"
x-aws-logs_retention: 10
```
###### Autoscaling
Set a CPU percent target
```yaml
services:
foo:
image: nginx
deploy:
x-aws-autoscaling:
cpu: 75
```
###### GPU
Set `generic_resources` for services that require accelerators as GPUs.
```yaml
services:
learning:
image: tensorflow/tensorflow:latest-gpus
deploy:
resources:
reservations:
memory: 32Gb
cpus: "32"
generic_resources:
- discrete_resource_spec:
kind: gpus
value: 2
```
##### Load Balancers
When a service in the compose file exposes a port, a load balancer is being created and configured to distribute the traffic between all containers.
There are 2 types of Load Balancers that can be created. For a service exposing a non-http port/protocol, a __Network Load Balancer (NLB)__ is created. Services with http/https ports/protocols get an __Application Load Balancer (ALB)__.
There is only one load balancer created/configured for a Compose stack. If there are both http/non-http ports configured for services in a compose stack, an NLB is created.
The compose file below configured only the http port,therefore, on deployment it gets an ALB created.
```yaml
services:
app:
image: nginx
ports:
- 80:80
```
NLB is created for non-http port
```yaml
services:
app:
image: nginx
ports:
- 8080:8080
```
To use the http protocol with custom ports and get an ALB, use the `x-aws-protocol` port property.
```yaml
services:
test:
image: nginx
ports:
- target: 8080
x-aws-protocol: http
```
To re-use an external load balancer and avoid creating a dedicated one, set the top-level property `x-aws-loadbalancer` as below:
```yaml
x-aws-loadbalancer: "LoadBalancerName"
services:
app:
image: nginx
ports:
- 80:80
```
Similarly, an external `VPC` and `Cluster` can be reused:
```yaml
x-aws-vpc: "vpc-25435e"
x-aws-cluster: "ClusterName"
services:
app:
image: nginx
ports:
- 80:80
```
Keep in mind, that external resources are not managed as part of the compose stack's lifecycle.
## Volumes
```yaml
services:
app:
image: nginx
volumes:
- data:/test
volumes:
data:
```
To use of an external volume that has been previously created, set its id/ARN as the name:
```yaml
services:
app:
image: nginx
volumes:
- data:/test
volumes:
data:
external: true
name: "fs-f534645"
```
Customize volume configuration via `driver_opts`
```yaml
services:
test:
image: nginx
volumes:
db-data:
driver_opts:
backup_policy: ENABLED
lifecycle_policy: AFTER_30_DAYS
performance_mode: maxIO
throughput_mode: provisioned
provisioned_throughput: 1024
```
## Networks
Networks are mapped to security groups.
```yaml
services:
test:
image: nginx
networks:
default:
```
Using an external network/security group:
```yaml
services:
test:
image: nginx
networks:
default:
external: true
name: sg-123abc
```
## Secrets
Secrets are stored in __AWS SecretsManager__ as strings and are mounted to containers under `/run/secrets/`.
```yaml
services:
app:
image: nginx
ports:
- 80:80
secrets:
- mysecret
secrets:
mysecret:
file: ./secrets/mysecret.txt
```
When using external secrets, set a valid secret `ARN` under the `name` property:
```yaml
services:
app:
image: nginx
secrets:
- foo_bar
secrets:
foo_bar:
name: "arn:aws:secretsmanager:eu-west-3:xxx:secret:foo_bar"
external: true
```
## Access private images
When a service is configured with an image from a private repository on Docker Hub, make sure you have configured pull credentials correctly before deploying the Compose stack.
To create a pull credential, create a file with the following content:
```sh
$ cat creds.json
{
"username":"DockerHubID",
"password":"GeneratedHubTokenOrPassword"
}
```
To create the pull credential and retrieve the `ARN/ID` to use in the compose file run:
```sh
$ docker secret create pullcred /path/to/creds.json
arn:aws:secretsmanager:eu-west-3:xxx:secret:pullcred
```
Use the `ARN` in the output to set the `x-aws-pull_credentials` service property as below:
```yaml
services:
app:
image: DockerHubID/privateimage
x-aws-pull_credentials: arn:aws:secretsmanager:eu-west-3:xxx:secret:pullcred
ports:
- 80:80
```

187
_vendor/github.com/docker/compose-cli/docs/ecs-compose-features.md generated
View File

@ -1,187 +0,0 @@
---
title: ECS integration Compose features
description: Reference list of compose ECS features
keywords: Docker, Amazon, Integration, ECS, Compose, cli, deploy, cloud
---
> **Important**
>
> Docker Compose's integration for ECS and ACI is retiring in November 2023.
{: .important}
# Compose - Amazon ECS mapping
This document outlines the conversion of an application defined in a Compose file to AWS resources.
Each service is mapped to an ECS service in the project's cluster.
## Compose fields mapping
The table below lists supported Compose file fields and their AWS counterparts.
__Legend:__
- __✓:__ Implemented
- __n:__ Not yet implemented
- __x:__ Not applicable / no available conversion
| Keys |Map| Notes |
|--------------------------------|---|--------------------------------------------------------------|
| __Service__ | ✓ |
| service.service.build | x | Ignored. No image build support on AWS.
| service.cap_add, cap_drop | ✓ | Supported with [Fargate limitations](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html)
| service.command | ✓ |
| service.configs | x |
| service.cgroup_parent | x |
| service.container_name | x |
| service.credential_spec | x |
| service.deploy | ✓ |
| service.deploy.endpoint_mode | x |
| service.deploy.mode | x |
| service.deploy.replicas | ✓ | Set service initial scale. Auto-scaling, when enabled, will make this dynamic
| service.deploy.placement | ✓ | Used with EC2 support to select a machine type and AMI
| service.deploy.update_config | ✓ |
| service.deploy.resources | ✓ | Fargate resource is selected with the lowest instance type for configured memory and cpu
| service.deploy.restart_policy | ✓ |
| service.deploy.labels | ✓ |
| service.devices | x |
| service.depends_on | ✓ | Implemented using CloudFormation Depends_on
| service.dns | x |
| service.dns_search | x |
| service.domainname | x |
| service.tmpfs | x | Not supported on Fargate, see https://github.com/docker/compose-cli/issues/839
| service.entrypoint | ✓ |
| service.env_file | ✓ |
| service.environment | ✓ |
| service.expose | x |
| service.extends | ✓ |
| service.external_links | x |
| service.extra_hosts | x |
| service.group_add | x |
| service.healthcheck | ✓ | This configures container level health check as reported on ECS console. Application Load Balancer will also check for HTTP service health by accessing `/` and expect a HTTP 200 status code.
| service.hostname | x |
| service.image | ✓ | Private images will be accessible by passing x-aws-pull_policy with ARN of a username+password secret
| service.isolation | x |
| service.labels | x |
| service.links | x |
| service.logging | ✓ | Can be used to customize CloudWatch Logs configuration
| service.network_mode | x |
| service.networks | x | Communication between services is implemented by SecurityGroups within the application VPC.
| service.pid | x |
| service.ports | ✓ | Only symetrical port mapping is supported in ECS. See [Exposing ports](#exposing-ports).
| service.secrets | ✓ | See [Secrets](#secrets).
| service.security_opt | x |
| service.stop_grace_period | x |
| service.stop_signal | x |
| service.sysctls | x |
| service.ulimits | ✓ | Only support `nofile` ulimit due to Fargate limitations
| service.userns_mode | x |
| service.volumes | ✓ | Mapped to EFS File Systems. See [Persistent volumes](#persistent-volumes).
| service.restart | x | Replaced by service.deployment.restart_policy
| | |
| __Volume__ | x |
| driver | ✓ | See [Persistent volumes](#persistent-volumes).
| driver_opts | ✓ |
| external | ✓ | `name` must be an EFS filesystem ID
| labels | x |
| | |
| __Secret__ | x |
| external | ✓ | `name` must be set to secret's ARN
| file | ✓ | file content will be uploaded into AWS Secret Manager
| | |
| __Config__ | x |
| | |
## Logs
Application logs can be obtained container with `docker compose logs`.
The Docker ECS integration relies on AWS CloudWatch Logs to collect logs from all containers. CloudWatch can be customized by setting service `logging.driver_opts`
by passing configuration attributes prefixed with `awslogs-`.
```yaml
test:
image: mycompany/webapp
logging:
driver-opts:
awslogs-datetime-pattern: "some-pattern"
```
## Exposing ports
When one or more services expose ports, a Load Balancer is created for the application.
As all services are exposed through the same Load Balancer, only one service can expose a given port number.
The source and target ports defined in the Compose file MUST be the same, as service-to-service communication don't go through the Load Balancer and could not
benefit from Listeners abstraction to assign a distinct published port.
If services in the Compose file only expose ports 80 or 443, an Application Load Balancer is created, otherwise ECS integration will provision a Network Load Balancer.
HTTP services using distinct ports can force use of an ALB by claiming the http protocol with `x-aws-protocol` custom extension within the port declaration:
```yaml
test:
image: mycompany/webapp
ports:
- target: 8080
x-aws-protocol: http
```
## Persistent volumes
Docker volumes are mapped to EFS file systems. Volumes can be external (`name` must then be set to filesystem ID) or will be created when the application is
first deployed. `docker compose down` will NOT delete the filesystem, and it will be re-attached to the application on future runs.
`driver_opts` can be used to tweak the EFS filsystem.
Volume mount can be customized to workaround Posix filesystem permission issues by setting user and group IDs to be used to write to filesystem, whatever user
is configured to run the container.
```yaml
services:
myservice:
image: mycompany/webapp
volumes:
- mydata:/mount/testvolumes
volumes:
mydata:
driver_opts:
performance-mode: maxIO
throughput-mode: bursting
uid: 0
gid: 0
```
## Secrets
Secrets can be defined in compose files, and will need secret files available at deploy time next to the compose file.
The content of the secret file will be made available inside selected containers, by default under `/run/secrets/<SECRET_NAME>`.
External secrets are also supported, `name` must then be set to secret's ARN
```yaml
services:
nginx:
image: mycompany/webapp
secrets:
- mysecret
secrets:
mysecret:
file: ./my_secret1.txt
```
## Container Resources
CPU and memory limits can be set in compose. Those are used to select the minimal [Fargate size](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) that will match those limits.
```yaml
services:
nginx:
image: mycompany/webapp
deploy:
resources:
limits:
cpus: '0.5'
memory: 2Gb
```

1
_vendor/modules.txt
View File

@ -3,6 +3,5 @@
# github.com/docker/buildx v0.12.0
# github.com/docker/scout-cli v1.2.0
# github.com/docker/cli v24.0.8-0.20231106123152-48ec4f339e2b+incompatible
# github.com/docker/compose-cli v1.0.35
# github.com/compose-spec/compose-spec v0.0.0-20231121152139-478928e7c9f8
# github.com/docker/compose/v2 v2.23.3

19
content/cloud/_index.md Normal file
View File

@ -0,0 +1,19 @@
---
title: Cloud integrations
description: ACI and ECS integration information
keywords: compose, ACI, ECS, amazon, cloud integration
aliases:
- /engine/context/aci-integration/
- /cloud/aci-integration/
- /cloud/ecs-integration/
- /cloud/ecs-compose-examples/
- /cloud/ecs-compose-features/
- /cloud/ecs-architecture/
- /cloud/aci-compose-features/
- /cloud/aci-container-features/
---
Docker Compose's integration for Amazon's Elastic Container Service and Azure Container Instances has retired. The integration documentation is no longer available through the Docker Docs site.
However, you can still access the relevant documentation in the [Compose CLI repository](https://github.com/docker/compose-cli/tree/main/docs).

475
content/cloud/aci-integration.md
View File

@ -1,475 +0,0 @@
---
title: Deploying Docker containers on Azure
description: Deploying Docker containers on Azure
keywords: Docker, Azure, Integration, ACI, context, Compose, cli, deploy, containers,
cloud
toc_min: 1
toc_max: 2
aliases:
- /engine/context/aci-integration/
---
{{< include "aci-ecs-eol.md" >}}
## Overview
The Docker Azure Integration enables developers to use native Docker commands to run applications in Azure Container Instances (ACI) when building cloud-native applications. The new experience provides a tight integration between Docker Desktop and Microsoft Azure allowing developers to quickly run applications using the Docker CLI or VS Code extension, to switch seamlessly from local development to cloud deployment.
In addition, the integration between Docker and Microsoft developer technologies allow developers to use the Docker CLI to:
- Sign in to Azure
- Set up an ACI context in one Docker command allowing you to switch from a local context to a cloud context and run applications quickly and easily
- Simplify single container and multi-container application development using the Compose Specification, allowing a developer to invoke fully Docker-compatible commands seamlessly for the first time natively within a cloud container service
Also see the [full list of container features supported by ACI](aci-container-features.md) and [full list of compose features supported by ACI](aci-compose-features.md).
## Prerequisites
To deploy Docker containers on Azure, you must meet the following requirements:
1. Download and install the latest version of Docker Desktop.
- [Download for Mac](../desktop/install/mac-install.md)
- [Download for Windows](../desktop/install/windows-install.md)
- [Download for Linux](../desktop/install/linux-install.md)
Alternatively, install the [Docker Compose CLI for Linux](#install-the-docker-compose-cli-on-linux).
2. Ensure you have an Azure subscription. You can get started with an [Azure free account](https://aka.ms/AA8r2pj).
## Run Docker containers on ACI
Docker not only runs containers locally, but also enables developers to seamlessly deploy Docker containers on ACI using `docker run` or deploy multi-container applications defined in a Compose file using the `docker compose up` command.
The following sections contain instructions on how to deploy your Docker containers on ACI.
Also see the [full list of container features supported by ACI](aci-container-features.md).
### Sign in to Azure
Run the following commands to sign in to Azure:
```console
$ docker login azure
```
This opens your web browser and prompts you to enter your Azure sign in credentials.
If the Docker CLI cannot open a browser, it will fall back to the [Azure device code flow](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code) and lets you connect manually.
Note that the [Azure command line](https://docs.microsoft.com/en-us/cli/azure/) sign in is separated from the Docker CLI Azure sign in.
Alternatively, you can sign in without interaction (typically in
scripts or continuous integration scenarios), using an Azure Service
Principal, with `docker login azure --client-id xx --client-secret yy --tenant-id zz`
>**Note**
>
> Signing in through the Azure Service Provider obtains an access token valid
for a short period (typically 1h), but it does not allow you to automatically
and transparently refresh this token. You must manually re-authenticate
when the access token has expired when signing in with a Service Provider.
You can also use the `--tenant-id` option alone to specify a tenant, if
you have several ones available in Azure.
### Create an ACI context
After you have signed in, you need to create a Docker context associated with ACI to deploy containers in ACI.
Creating an ACI context requires an Azure subscription, a [resource group](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal), and a region.
For example, let us create a new context called `myacicontext`:
```console
$ docker context create aci myacicontext
```
This command automatically uses your Azure sign in credentials to identify your subscription IDs and resource groups. You can then interactively select the subscription and group that you would like to use. If you prefer, you can specify these options in the CLI using the following flags: `--subscription-id`,
`--resource-group`, and `--location`.
If you don't have any existing resource groups in your Azure account, the `docker context create aci myacicontext` command creates one for you. You don’t have to specify any additional options to do this.
After you have created an ACI context, you can list your Docker contexts by running the `docker context ls` command:
```console
NAME TYPE DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
myacicontext aci myResourceGroupGTA@eastus
default * moby Current DOCKER_HOST based configuration unix:///var/run/docker.sock swarm
```
### Run a container
Now you can start using Docker commands to deploy containers on ACI.
There are two ways to use your new ACI context. You can use the `--context` flag with the Docker command to specify that you would like to run the command using your newly created ACI context.
```console
$ docker --context myacicontext run -p 80:80 nginx
```
Or, you can change context using `docker context use` to select the ACI context to be your focus for running Docker commands. For example, we can use the `docker context use` command to deploy an Nginx container:
```console
$ docker context use myacicontext
$ docker run -p 80:80 nginx
```
After you've switched to the `myacicontext` context, you can use `docker ps` to list your containers running on ACI.
In the case of the demonstration Nginx container started above, the result of the ps command will display in column "PORTS" the IP address and port on which the container is running. For example, it may show `52.154.202.35:80->80/tcp`, and you can view the Nginx welcome page by browsing `http://52.154.202.35`.
To view logs from your container, run:
```console
$ docker logs <CONTAINER_ID>
```
To execute a command in a running container, run:
```console
$ docker exec -t <CONTAINER_ID> COMMAND
```
To stop and remove a container from ACI, run:
```console
$ docker stop <CONTAINER_ID>
$ docker rm <CONTAINER_ID>
```
You can remove containers using `docker rm`. To remove a running container, you must use the `--force` flag, or stop the container using `docker stop` before removing it.
> **Note**
>
> The semantics of restarting a container on ACI are different to those when using a local Docker context for local development. On ACI, the container will be reset to its initial state and started on a new node. This includes the container's filesystem so all state that is not stored in a volume will be lost on restart.
## Running Compose applications
You can also deploy and manage multi-container applications defined in Compose files to ACI using the `docker compose` command.
All containers in the same Compose application are started in the same container group. Service discovery between the containers works using the service name specified in the Compose file.
Name resolution between containers is achieved by writing service names in the `/etc/hosts` file that is shared automatically by all containers in the container group.
Also see the [full list of Compose features supported by ACI](aci-compose-features.md).
1. Ensure you are using your ACI context. You can do this either by specifying the `--context myacicontext` flag or by setting the default context using the command `docker context use myacicontext`.
2. Run `docker compose up` and `docker compose down` to start and then stop a full Compose application.
By default, `docker compose up` uses the `docker-compose.yaml` file in the current folder. You can specify the working directory using the --workdir flag or specify the Compose file directly using `docker compose --file mycomposefile.yaml up`.
You can also specify a name for the Compose application using the `--project-name` flag during deployment. If no name is specified, a name will be derived from the working directory.
Containers started as part of Compose applications will be displayed along with single containers when using `docker ps`. Their container ID will be of the format: `<COMPOSE-PROJECT>_<SERVICE>`.
These containers cannot be stopped, started, or removed independently since they are all part of the same ACI container group.
You can view each container's logs with `docker logs`. You can list deployed Compose applications with `docker compose ls`. This will list only compose applications, not single containers started with `docker run`. You can remove a Compose application with `docker compose down`.
> **Note**
>
> The current Docker Azure integration does not allow fetching a combined log stream from all the containers that make up the Compose application.
## Updating applications
From a deployed Compose application, you can update the application by re-deploying it with the same project name: `docker compose --project-name PROJECT up`.
Updating an application means the ACI node will be reused, and the application will keep the same IP address that was previously allocated to expose ports, if any. ACI has some limitations on what can be updated in an existing application (you will not be able to change CPU/memory reservation for example), in these cases, you need to deploy a new application from scratch.
Updating is the default behavior if you invoke `docker compose up` on an already deployed Compose file, as the Compose project name is derived from the directory where the Compose file is located by default. You need to explicitly execute `docker compose down` before running `docker compose up` again in order to totally reset a Compose application.
## Releasing resources
Single containers and Compose applications can be removed from ACI with
the `docker prune` command. The `docker prune` command removes deployments
that are not currently running. To remove running depoyments, you can specify
`--force`. The `--dry-run` option lists deployments that are planned for
removal, but it doesn't actually remove them.
```console
$ ./bin/docker --context acicontext prune --dry-run --force
Resources that would be deleted:
my-application
Total CPUs reclaimed: 2.01, total memory reclaimed: 2.30 GB
```
## Exposing ports
Single containers and Compose applications can optionally expose ports.
For single containers, this is done using the `--publish` (`-p`) flag of the `docker run` command : `docker run -p 80:80 nginx`.
For Compose applications, you must specify exposed ports in the Compose file service definition:
```yaml
services:
nginx:
image: nginx
ports:
- "80:80"
```
> **Note**
>
> ACI does not allow port mapping (that is, changing port number while exposing port). Therefore, the source and target ports must be the same when deploying to ACI.
>
> All containers in the same Compose application are deployed in the same ACI container group. Different containers in the same Compose application cannot expose the same port when deployed to ACI.
By default, when exposing ports for your application, a random public IP address is associated with the container group supporting the deployed application (single container or Compose application).
This IP address can be obtained when listing containers with `docker ps` or using `docker inspect`.
### DNS label name
In addition to exposing ports on a random IP address, you can specify a DNS label name to expose your application on an FQDN of the form: `<NAME>.region.azurecontainer.io`.
You can set this name with the `--domainname` flag when performing a `docker run`, or by using the `domainname` field in the Compose file when performing a `docker compose up`:
```yaml
services:
nginx:
image: nginx
domainname: "myapp"
ports:
- "80:80"
```
> **Note**
>
> The domain of a Compose application can only be set once, if you specify the
> `domainname` for several services, the value must be identical.
>
> The FQDN `<DOMAINNAME>.region.azurecontainer.io` must be available.
## Using Azure file share as volumes in ACI containers
You can deploy containers or Compose applications that use persistent data
stored in volumes. Azure File Share can be used to support volumes for ACI
containers.
Using an existing Azure File Share with storage account name `mystorageaccount`
and file share name `myfileshare`, you can specify a volume in your deployment `run`
command as follows:
```console
$ docker run -v mystorageaccount/myfileshare:/target/path myimage
```
The runtime container will see the file share content in `/target/path`.
In a Compose application, the volume specification must use the following syntax
in the Compose file:
```yaml
myservice:
image: nginx
volumes:
- mydata:/mount/testvolumes
volumes:
mydata:
driver: azure_file
driver_opts:
share_name: myfileshare
storage_account_name: mystorageaccount
```
> **Note**
>
> The volume short syntax in Compose files cannot be used as it is aimed at volume definition for local bind mounts. Using the volume driver and driver option syntax in Compose files makes the volume definition a lot more clear.
In single or multi-container deployments, the Docker CLI will use your Azure login to fetch the key to the storage account, and provide this key with the container deployment information, so that the container can access the volume.
Volumes can be used from any file share in any storage account you have access to with your Azure login. You can specify `rw` (read/write) or `ro` (read only) when mounting the volume (`rw` is the default).
### Managing Azure volumes
To create a volume that you can use in containers or Compose applications when
using your ACI Docker context, you can use the `docker volume create` command,
and specify an Azure storage account name and the file share name:
```console
$ docker --context aci volume create test-volume --storage-account mystorageaccount
[+] Running 2/2
⠿ mystorageaccount Created 26.2s
⠿ test-volume Created 0.9s
mystorageaccount/test-volume
```
By default, if the storage account does not already exist, this command
creates a new storage account using the Standard LRS as a default SKU, and the
resource group and location associated with your Docker ACI context.
If you specify an existing storage account, the command creates a new
file share in the existing account:
```console
$ docker --context aci volume create test-volume2 --storage-account mystorageaccount
[+] Running 2/2
⠿ mystorageaccount Use existing 0.7s
⠿ test-volume2 Created 0.7s
mystorageaccount/test-volume2
```
Alternatively, you can create an Azure storage account or a file share using the Azure
portal, or the `az` [command line](https://docs.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-cli).
You can also list volumes that are available for use in containers or Compose applications:
```console
$ docker --context aci volume ls
ID DESCRIPTION
mystorageaccount/test-volume Fileshare test-volume in mystorageaccount storage account
mystorageaccount/test-volume2 Fileshare test-volume2 in mystorageaccount storage account
```
To delete a volume and the corresponding Azure file share, use the `volume rm` command:
```console
$ docker --context aci volume rm mystorageaccount/test-volume
mystorageaccount/test-volume
```
This permanently deletes the Azure file share and all its data.
When deleting a volume in Azure, the command checks whether the specified file share
is the only file share available in the storage account. If the storage account is
created with the `docker volume create` command, `docker volume rm` also
deletes the storage account when it does not have any file shares.
If you are using a storage account created without the `docker volume create` command
(through Azure portal or with the `az` command line for example), `docker volume rm`
does not delete the storage account, even when it has zero remaining file shares.
## Environment variables
When using `docker run`, you can pass the environment variables to ACI containers using the `--env` flag.
For Compose applications, you can specify the environment variables in the Compose file with the `environment` or `env-file` service field, or with the `--environment` command line flag.
## Health checks
You can specify a container health checks using either the `--healthcheck-` prefixed flags with `docker run`, or in a Compose file with the `healthcheck` section of the service.
Health checks are converted to ACI `LivenessProbe`s. ACI runs the health check command periodically, and if it fails, the container will be terminated.
Health checks must be used in addition to restart policies to ensure the container is then restarted on termination. The default restart policy for `docker run` is `no` which will not restart the container. The default restart policy for Compose is `any` which will always try restarting the service containers.
Example using `docker run`:
```console
$ docker --context acicontext run -p 80:80 --restart always --health-cmd "curl http://localhost:80" --health-interval 3s nginx
```
Example using Compose files:
```yaml
services:
web:
image: nginx
deploy:
restart_policy:
condition: on-failure
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:80"]
interval: 10s
```
## Private Docker Hub images and using the Azure Container Registry
You can deploy private images to ACI that are hosted by any container registry. You need to log into the relevant registry using `docker login` before running `docker run` or `docker compose up`. The Docker CLI will fetch your registry login for the deployed images and send the credentials along with the image deployment information to ACI.
In the case of the Azure Container Registry, the command line will try to automatically log you into ACR from your Azure login. You don't need to manually login to the ACR registry first, if your Azure login has access to the ACR.
## Using ACI resource groups as namespaces
You can create several Docker contexts associated with ACI. Each context must be associated with a unique Azure resource group. This allows you to use Docker contexts as namespaces. You can switch between namespaces using `docker context use <CONTEXT>`.
When you run the `docker ps` command, it only lists containers in your current Docker context. There won’t be any contention in container names or Compose application names between two Docker contexts.
## Install the Docker Compose CLI on Linux
The Docker Compose CLI adds support for running and managing containers on Azure Container Instances (ACI).
### Install Prerequisites
- [Docker 19.03 or later](../get-docker.md)
### Install script
You can install the new CLI using the install script:
```console
$ curl -L https://raw.githubusercontent.com/docker/compose-cli/main/scripts/install/install_linux.sh | sh
```
### Manual install
You can download the Docker ACI Integration CLI from the
[latest release](https://github.com/docker/compose-cli/releases/latest) page.
You will then need to make it executable:
```console
$ chmod +x docker-aci
```
To enable using the local Docker Engine and to use existing Docker contexts, you
must have the existing Docker CLI as `com.docker.cli` somewhere in your
`PATH`. You can do this by creating a symbolic link from the existing Docker
CLI:
```console
$ ln -s /path/to/existing/docker /directory/in/PATH/com.docker.cli
```
> **Note**
>
> The `PATH` environment variable is a colon-separated list of
> directories with priority from left to right. You can view it using
> `echo $PATH`. You can find the path to the existing Docker CLI using
> `which docker`. You may need root permissions to make this link.
On a fresh install of Ubuntu 20.04 with Docker Engine
[already installed](../engine/install/ubuntu.md):
```console
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
$ which docker
/usr/bin/docker
$ sudo ln -s /usr/bin/docker /usr/local/bin/com.docker.cli
```
You can verify that this is working by checking that the new CLI works with the
default context:
```console
$ ./docker-aci --context default ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
$ echo $?
0
```
To make this CLI with ACI integration your default Docker CLI, you must move it
to a directory in your `PATH` with higher priority than the existing Docker CLI.
Again, on a fresh Ubuntu 20.04:
```console
$ which docker
/usr/bin/docker
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
$ sudo mv docker-aci /usr/local/bin/docker
$ which docker
/usr/local/bin/docker
$ docker version
...
Azure integration 0.1.4
...
```
### Supported commands
After you have installed the Docker ACI Integration CLI, run `--help` to see the current list of commands.
### Uninstall
To remove the Docker Azure Integration CLI, you need to remove the binary you downloaded and `com.docker.cli` from your `PATH`. If you installed using the script, this can be done as follows:
```console
$ sudo rm /usr/local/bin/docker /usr/local/bin/com.docker.cli
```
## Feedback
Thank you for trying out Docker Azure Integration. Your feedback is very important to us. Let us know your feedback by creating an issue in the [compose-cli](https://github.com/docker/compose-cli) GitHub repository.

628
content/cloud/ecs-integration.md
View File

@ -1,628 +0,0 @@
---
title: Deploying Docker containers on ECS
description: Deploying Docker containers on ECS
keywords: Docker, AWS, ECS, Integration, context, Compose, cli, deploy, containers,
cloud
toc_min: 1
toc_max: 2
aliases:
- /engine/context/ecs-integration/
---
{{< include "aci-ecs-eol.md" >}}
## Overview
The Docker Compose CLI lets developers use native Docker commands to run applications in Amazon Elastic Container Service (ECS) when building cloud-native applications.
The integration between Docker and Amazon ECS allows developers to use the Docker Compose CLI to:
* Set up an AWS context in one Docker command, allowing you to switch from a local context to a cloud context and run applications quickly and easily
* Simplify multi-container application development on Amazon ECS using Compose files
Also see the [ECS integration architecture](ecs-architecture.md), [full list of compose features](ecs-compose-features.md) and [Compose examples for ECS integration](ecs-compose-examples.md).
## Prerequisites
To deploy Docker containers on ECS, you must meet the following requirements:
1. Download and install the latest version of Docker Desktop.
- [Download for Mac](../desktop/install/mac-install.md)
- [Download for Windows](../desktop/install/windows-install.md)
- [Download for Linux](../desktop/install/linux-install.md)
Alternatively, install the [Docker Compose CLI for Linux](#install-the-docker-compose-cli-on-linux).
2. Ensure you have an AWS account.
Docker not only runs multi-container applications locally, but also enables
developers to seamlessly deploy Docker containers on Amazon ECS using a
Compose file with the `docker compose up` command. The following sections
contain instructions on how to deploy your Compose application on Amazon ECS.
## Run an application on ECS
### Requirements
AWS uses a fine-grained permission model, with specific role for each resource type and operation.
To ensure that Docker ECS integration is allowed to manage resources for your Compose application, you have to ensure your AWS credentials [grant access to following AWS IAM permissions](https://aws.amazon.com/iam/features/manage-permissions/):
* application-autoscaling:*
* cloudformation:*
* ec2:AuthorizeSecurityGroupIngress
* ec2:CreateSecurityGroup
* ec2:CreateTags
* ec2:DeleteSecurityGroup
* ec2:DescribeRouteTables
* ec2:DescribeSecurityGroups
* ec2:DescribeSubnets
* ec2:DescribeVpcs
* ec2:RevokeSecurityGroupIngress
* ecs:CreateCluster
* ecs:CreateService
* ecs:DeleteCluster
* ecs:DeleteService
* ecs:DeregisterTaskDefinition
* ecs:DescribeClusters
* ecs:DescribeServices
* ecs:DescribeTasks
* ecs:ListAccountSettings
* ecs:ListTasks
* ecs:RegisterTaskDefinition
* ecs:UpdateService
* elasticloadbalancing:*
* iam:AttachRolePolicy
* iam:CreateRole
* iam:DeleteRole
* iam:DetachRolePolicy
* iam:PassRole
* logs:CreateLogGroup
* logs:DeleteLogGroup
* logs:DescribeLogGroups
* logs:FilterLogEvents
* route53:CreateHostedZone
* route53:DeleteHostedZone
* route53:GetHealthCheck
* route53:GetHostedZone
* route53:ListHostedZonesByName
* servicediscovery:*
GPU support, which relies on EC2 instances to run containers with attached GPU devices,
require a few additional permissions:
* ec2:DescribeVpcs
* autoscaling:*
* iam:CreateInstanceProfile
* iam:AddRoleToInstanceProfile
* iam:RemoveRoleFromInstanceProfile
* iam:DeleteInstanceProfile
### Create AWS context
Run the `docker context create ecs myecscontext` command to create an Amazon ECS Docker
context named `myecscontext`. If you have already installed and configured the AWS CLI,
the setup command lets you select an existing AWS profile to connect to Amazon.
Otherwise, you can create a new profile by passing an
[AWS access key ID and a secret access key](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys).
Finally, you can configure your ECS context to retrieve AWS credentials by `AWS_*` environment variables, which is a common way to integrate with
third-party tools and Single Sign-On providers.
```console
? Create a Docker context using: [Use arrows to move, type to filter]
An existing AWS profile
AWS secret and token credentials
> AWS environment variables
```
After you have created an AWS context, you can list your Docker contexts by running the `docker context ls` command:
```console
NAME TYPE DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
myecscontext ecs credentials read from environment
default * moby Current DOCKER_HOST based configuration unix:///var/run/docker.sock swarm
```
### Run a Compose application
You can deploy and manage multi-container applications defined in Compose files
to Amazon ECS using the `docker compose` command. To do this:
- Ensure you are using your ECS context. You can do this either by specifying
the `--context myecscontext` flag with your command, or by setting the
current context using the command `docker context use myecscontext`.
- Run `docker compose up` and `docker compose down` to start and then
stop a full Compose application.
By default, `docker compose up` uses the `compose.yaml` or `docker-compose.yaml` file in
the current folder. You can specify the working directory using the --workdir flag or
specify the Compose file directly using `docker compose --file mycomposefile.yaml up`.
You can also specify a name for the Compose application using the `--project-name` flag during deployment. If no name is specified, a name will be derived from the working directory.
Docker ECS integration converts the Compose application model into a set of AWS resources, described as a [CloudFormation](https://aws.amazon.com/cloudformation/) template. The actual mapping is described in [technical documentation](https://github.com/docker/compose-cli/blob/main/docs/ecs-architecture.md).
You can review the generated template using `docker compose convert` command, and follow CloudFormation applying this model within
[AWS web console](https://console.aws.amazon.com/cloudformation/home) when you run `docker compose up`, in addition to CloudFormation events being displayed
in your terminal.
- You can view services created for the Compose application on Amazon ECS and
their state using the `docker compose ps` command.
- You can view logs from containers that are part of the Compose application
using the `docker compose logs` command.
Also see the [full list of compose features](ecs-compose-features.md).
## Rolling update
To update your application without interrupting production flow you can simply
use `docker compose up` on the updated Compose project.
Your ECS services are created with rolling update configuration. As you run
`docker compose up` with a modified Compose file, the stack will be
updated to reflect changes, and if required, some services will be replaced.
This replacement process will follow the rolling-update configuration set by
your services [`deploy.update_config`](../compose/compose-file/compose-file-v3.md#update_config)
configuration.
AWS ECS uses a percent-based model to define the number of containers to be
run or shut down during a rolling update. The Docker Compose CLI computes
rolling update configuration according to the `parallelism` and `replicas`
fields. However, you might prefer to directly configure a rolling update
using the extension fields `x-aws-min_percent` and `x-aws-max_percent`.
The former sets the minimum percent of containers to run for service, and the
latter sets the maximum percent of additional containers to start before
previous versions are removed.
By default, the ECS rolling update is set to run twice the number of
containers for a service (200%), and has the ability to shut down 100%
containers during the update.
## View application logs
The Docker Compose CLI configures AWS CloudWatch Logs service for your
containers.
By default you can see logs of your compose application the same way you check logs of local deployments:
```console
# fetch logs for application in current working directory
$ docker compose logs
# specify compose project name
$ docker compose --project-name PROJECT logs
# specify compose file
$ docker compose --file /path/to/docker-compose.yaml logs
```
A log group is created for the application as `docker-compose/<application_name>`,
and log streams are created for each service and container in your application
as `<application_name>/<service_name>/<container_ID>`.
You can fine tune AWS CloudWatch Logs using extension field `x-aws-logs_retention`
in your Compose file to set the number of retention days for log events. The
default behavior is to keep logs forever.
You can also pass `awslogs`
parameters to your container as standard
Compose file `logging.driver_opts` elements. See [AWS documentation](https://docs.amazonaws.cn/en_us/AmazonECS/latest/developerguide/using_awslogs.html) for details on available log driver options.
## Private Docker images
The Docker Compose CLI automatically configures authorization so you can pull private images from the Amazon ECR registry on the same AWS account. To pull private images from another registry, including Docker Hub, you’ll have to create a Username + Password (or a Username + Token) secret on the [AWS Secrets Manager service](https://docs.aws.amazon.com/secretsmanager/).
For your convenience, the Docker Compose CLI offers the `docker secret` command, so you can manage secrets created on AWS SMS without having to install the AWS CLI.
First, create a `token.json` file to define your DockerHub username and access token.
For instructions on how to generate access tokens, see [Managing access tokens](../security/for-developers/access-tokens.md)
```json
{
"username":"DockerHubUserName",
"password":"DockerHubAccessToken"
}
```
You can then create a secret from this file using `docker secret`:
```console
$ docker secret create dockerhubAccessToken token.json
arn:aws:secretsmanager:eu-west-3:12345:secret:DockerHubAccessToken
```
Once created, you can use this ARN in your Compose file using `x-aws-pull_credentials` custom extension with the Docker image URI for your service.
```yaml
services:
worker:
image: mycompany/privateimage
x-aws-pull_credentials: "arn:aws:secretsmanager:eu-west-3:12345:secret:DockerHubAccessToken"
```
> **Note**
>
> If you set the Compose file version to 3.8 or later, you can use the same Compose file for local deployment using `docker-compose`. Custom ECS extensions will be ignored in this case.
## Service discovery
Service-to-service communication is implemented transparently by default, so you can deploy your Compose applications with multiple interconnected services without changing the compose file between local and ECS deployment. Individual services can run with distinct constraints (memory, cpu) and replication rules.
### Service names
Services are registered automatically by the Docker Compose CLI on [AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/what-is-cloud-map.html) during application deployment. They are declared as fully qualified domain names of the form: `<service>.<compose_project_name>.local`.
Services can retrieve their dependencies using Compose service names (as they do when deploying locally with docker-compose), or optionally use the fully qualified names.
> **Note**
>
> Short service names, nor the fully qualified service names, will resolve unless you enable public dns names in your VPC.
### Dependent service startup time and DNS resolution
Services get concurrently scheduled on ECS when a Compose file is deployed. AWS Cloud Map introduces an initial delay for DNS service to be able to resolve your services domain names. Your code needs to support this delay by waiting for dependent services to be ready, or by adding a wait-script as the entrypoint to your Docker image, as documented in [Control startup order](../compose/startup-order.md).
Note that this need to wait for dependent services in your Compose application also exists when deploying locally with docker-compose, but the delay is typically shorter. Issues might become more visible when deploying to ECS if services do not wait for their dependencies to be available.
Alternatively, you can use the [depends_on](https://github.com/compose-spec/compose-spec/blob/master/spec.md#depends_on) feature of the Compose file format. By doing this, dependent service will be created first, and application deployment will wait for it to be up and running before starting the creation of the dependent services.
### Service isolation
Service isolation is implemented by the [Security Groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) rules, allowing services sharing a common Compose file “network” to communicate together using their Compose service names.
## Volumes
ECS integration supports volume management based on Amazon Elastic File System (Amazon EFS).
For a Compose file to declare a `volume`, ECS integration will define creation of an EFS
file system within the CloudFormation template, with `Retain` policy so data won't
be deleted on application shut-down. If the same application (same project name) is
deployed again, the file system will be re-attached to offer the same user experience
developers are used to with docker-compose.
A basic compose service using a volume can be declared like this:
```yaml
services:
nginx:
image: nginx
volumes:
- mydata:/some/container/path
volumes:
mydata:
```
With no specific volume options, the volume still must be declared in the `volumes`section for
the compose file to be valid (in the above example the empty `mydata:` entry)
If required, the initial file system can be customized using `driver-opts`:
```yaml
volumes:
my-data:
driver_opts:
# Filesystem configuration
backup_policy: ENABLED
lifecycle_policy: AFTER_14_DAYS
performance_mode: maxIO
throughput_mode: provisioned
provisioned_throughput: 1
```
File systems created by executing `docker compose up` on AWS can be listed using
`docker volume ls` and removed with `docker volume rm <filesystemID>`.
An existing file system can also be used for users who already have data stored on EFS
or want to use a file system created by another Compose stack.
```yaml
volumes:
my-data:
external: true
name: fs-123abcd
```
Accessing a volume from a container can introduce POSIX user ID
permission issues, as Docker images can define arbitrary user ID / group ID for the
process to run inside a container. However, the same `uid:gid` will have to match
POSIX permissions on the file system. To work around the possible conflict, you can set the volume
`uid` and `gid` to be used when accessing a volume:
```yaml
volumes:
my-data:
driver_opts:
# Access point configuration
uid: 0
gid: 0
```
## Secrets
You can pass secrets to your ECS services using Docker model to bind sensitive
data as files under `/run/secrets`. If your Compose file declares a secret as
file, such a secret will be created as part of your application deployment on
ECS. If you use an existing secret as `external: true` reference in your
Compose file, use the ECS Secrets Manager full ARN as the secret name:
```yaml
services:
webapp:
image: ...
secrets:
- foo
secrets:
foo:
name: "arn:aws:secretsmanager:eu-west-3:1234:secret:foo-ABC123"
external: true
```
Secrets will be available at runtime for your service as a plain text file `/run/secrets/foo`.
The AWS Secrets Manager allows you to store sensitive data either as a plain
text (like Docker secret does), or as a hierarchical JSON document. You can
use the latter with Docker Compose CLI by using custom field `x-aws-keys` to
define which entries in the JSON document to bind as a secret in your service
container.
```yaml
services:
webapp:
image: ...
secrets:
- foo
secrets:
foo:
name: "arn:aws:secretsmanager:eu-west-3:1234:secret:foo-ABC123"
x-aws-keys:
- "bar"
```
By doing this, the secret for `bar` key will be available at runtime for your
service as a plain text file `/run/secrets/foo/bar`. You can use the special
value `*` to get all keys bound in your container.
## Auto scaling
Scaling service static information (non auto-scaling) can be specified using the normal Compose syntax:
```yaml
services:
foo:
deploy:
replicas: 3
```
The Compose file model does not define any attributes to declare auto-scaling conditions.
Therefore, we rely on `x-aws-autoscaling` custom extension to define the auto-scaling range, as
well as cpu _or_ memory to define target metric, expressed as resource usage percent.
```yaml
services:
foo:
deploy:
x-aws-autoscaling:
min: 1
max: 10 #required
cpu: 75
# memory: - mutualy exlusive with cpu
```
## IAM roles
Your ECS Tasks are executed with a dedicated IAM role, granting access
to AWS Managed policies[`AmazonECSTaskExecutionRolePolicy`](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html)
and [`AmazonEC2ContainerRegistryReadOnly`](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecr_managed_policies.html).
In addition, if your service uses secrets, IAM Role gets additional
permissions to read and decrypt secrets from the AWS Secret Manager.
You can grant additional managed policies to your service execution
by using `x-aws-policies` inside a service definition:
```yaml
services:
foo:
x-aws-policies:
- "arn:aws:iam::aws:policy/AmazonS3FullAccess"
```
You can also write your own [IAM Policy Document](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)
to fine tune the IAM role to be applied to your ECS service, and use
`x-aws-role` inside a service definition to pass the
yaml-formatted policy document.
```yaml
services:
foo:
x-aws-role:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
- "some_aws_service"
Resource:
- "*"
```
## Tuning the CloudFormation template
The Docker Compose CLI relies on [Amazon CloudFormation](https://docs.aws.amazon.com/cloudformation/) to manage the application deployment. To get more control on the created resources, you can use `docker compose convert` to generate a CloudFormation stack file from your Compose file. This allows you to inspect resources it defines, or customize the template for your needs, and then apply the template to AWS using the AWS CLI, or the AWS web console.
Once you have identified the changes required to your CloudFormation template, you can include _overlays_ in your
Compose file that will be automatically applied on `compose up`. An _overlay_ is a yaml object that uses the same CloudFormation template data structure as the one generated by ECS integration, but only contains attributes to
be updated or added. It will be merged with the generated template before being applied on the AWS infrastructure.
### Adjusting Load Balancer http HealthCheck configuration
While ECS cluster uses the `HealthCheck` command on container to get service health, Application Load Balancers define
their own URL-based HealthCheck mechanism so traffic gets routed. As the Compose model does not offer such an
abstraction (yet), the default one is applied, which queries your service under `/` expecting HTTP status code
`200`.
You can tweak this behavior using a cloudformation overlay by following the [AWS CloudFormation User Guide](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-targetgroup.html) for
configuration reference:
```yaml
services:
webapp:
image: acme/webapp
ports:
- "80:80"
x-aws-cloudformation:
Resources:
WebappTCP80TargetGroup:
Properties:
HealthCheckPath: /health
Matcher:
HttpCode: 200-499
```
### Setting SSL termination by Load Balancer
You can use Application Load Balancer to handle the SSL termination for HTTPS services, so that your code, which ran inside
a container, doesn't have to. This is currently not supported by the ECS integration due to the lack of an equivalent abstraction in the Compose specification. However, you can rely on overlays to enable this feature on generated Listeners configuration:
```yaml
services:
webapp:
image: acme/webapp
ports:
- "80:80"
x-aws-cloudformation:
Resources:
WebappTCP80Listener:
Properties:
Certificates:
- CertificateArn: "arn:aws:acm:certificate/123abc"
Protocol: HTTPS
Port: 443
```
## Using existing AWS network resources
By default, the Docker Compose CLI creates an ECS cluster for your Compose application, a Security Group per network in your Compose file on your AWS account’s default VPC, and a LoadBalancer to route traffic to your services.
With the following basic compose file, the Docker Compose CLI will automatically create these ECS constructs including the load balancer to route traffic to the exposed port 80.
```yaml
services:
nginx:
image: nginx
ports:
- "80:80"
```
If your AWS account does not have [permissions](https://github.com/docker/ecs-plugin/blob/master/docs/requirements.md#permissions) to create such resources, or if you want to manage these yourself, you can use the following custom Compose extensions:
- Use `x-aws-cluster` as a top-level element in your Compose file to set the ID
of an ECS cluster when deploying a Compose application. Otherwise, a
cluster will be created for the Compose project.
- Use `x-aws-vpc` as a top-level element in your Compose file to set the ARN
of a VPC when deploying a Compose application.
- Use `x-aws-loadbalancer` as a top-level element in your Compose file to set
the ARN of an existing LoadBalancer.
The latter can be used for those who want to customize application exposure, typically to
use an existing domain name for your application:
1. Use the AWS web console or CLI to get your VPC and Subnets IDs. You can retrieve the default VPC ID and attached subnets using this AWS CLI commands:
```console
$ aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId'
"vpc-123456"
$ aws ec2 describe-subnets --filters Name=vpc-id,Values=vpc-123456 --query 'Subnets[*].SubnetId'
[
"subnet-1234abcd",
"subnet-6789ef00",
]
```
2. Use the AWS CLI to create your load balancer. The AWS Web Console can also be used but will require adding at least one listener, which we don't need here.
```console
$ aws elbv2 create-load-balancer --name myloadbalancer --type application --subnets "subnet-1234abcd" "subnet-6789ef00"
{
"LoadBalancers": [
{
"IpAddressType": "ipv4",
"VpcId": "vpc-123456",
"LoadBalancerArn": "arn:aws:elasticloadbalancing:us-east-1:1234567890:loadbalancer/app/myloadbalancer/123abcd456",
"DNSName": "myloadbalancer-123456.us-east-1.elb.amazonaws.com",
<...>
```
3. To assign your application an existing domain name, you can configure your DNS with a
CNAME entry pointing to the just-created load balancer's `DNSName`, reported as you created the load balancer.
4. Use the load balancer ARN to set `x-aws-loadbalancer` in your compose file and deploy your application using `docker compose up` command.
Please note that Docker ECS integration won't be aware of this domain name, so `docker compose ps` command will report URLs with load balancer `DNSName`, not your own domain.
You can also use `external: true` inside a network definition in your Compose file for
Docker Compose CLI to _not_ create a Security Group, and set `name` with the
ID of an existing Security Group you want to use for network connectivity between
services:
```yaml
networks:
back_tier:
external: true
name: "sg-1234acbd"
```
## Local simulation
When you deploy your application on ECS, you may also rely on the additional AWS services.
In such cases, your code must embed the AWS SDK and retrieve API credentials at runtime.
AWS offers a credentials discovery mechanism which is fully implemented by the SDK, and relies
on accessing a metadata service on a fixed IP address.
Once you adopt this approach, running your application locally for testing or debug purposes
can be difficult. Therefore, we have introduced an option on context creation to set the
`ecs-local` context to maintain application portability between local workstation and the
AWS cloud provider.
```console
$ docker context create ecs --local-simulation ecsLocal
Successfully created ecs-local context "ecsLocal"
```
When you select a local simulation context, running the `docker compose up` command doesn't
deploy your application on ECS. Therefore, you must run it locally, automatically adjusting your Compose
application so it includes the [ECS local endpoints](https://github.com/awslabs/amazon-ecs-local-container-endpoints/).
This allows the AWS SDK used by application code to
access a local mock container as "AWS metadata API" and retrieve credentials from your own
local `.aws/credentials` config file.
## Install the Docker Compose CLI on Linux
The Docker Compose CLI adds support for running and managing containers on ECS.
### Install Prerequisites
[Docker 19.03 or later](../get-docker.md)
### Install script
You can install the new CLI using the install script:
```console
$ curl -L https://raw.githubusercontent.com/docker/compose-cli/main/scripts/install/install_linux.sh | sh
```
## FAQ
**What does the error `this tool requires the "new ARN resource ID format"` mean?**
This error message means that your account requires the new ARN resource ID format for ECS. To learn more, see [Migrating your Amazon ECS deployment to the new ARN and resource ID format](https://aws.amazon.com/blogs/compute/migrating-your-amazon-ecs-deployment-to-the-new-arn-and-resource-id-format-2/).
## Feedback
Thank you for trying out the Docker Compose CLI. Your feedback is very important to us. Let us know your feedback by creating an issue in the [Compose CLI](https://github.com/docker/compose-cli) GitHub repository.

5
content/desktop/faqs/general.md
View File

@ -54,9 +54,8 @@ This includes:
- Setting up [Dev Environments](../dev-environments/index.md)
- Docker build when using [BuildKit](../../build/buildkit/index.md#getting-started).
You can work around this by disabling BuildKit. Run `DOCKER_BUILDKIT=0 docker build .` to disable BuildKit.
- Deploying an app to the cloud through Compose
[ACI](../../cloud/aci-integration.md) and [ECS](../../cloud/ecs-integration.md)
integrations
- Deploying an app to the cloud through the Docker Compose
[ACI and ECS](https://github.com/docker/compose-cli/tree/main/docs) integrations
- [Kubernetes](../kubernetes.md) (Images are download when you enable Kubernetes for the first time)
- Check for updates
- [In-app diagnostics](../troubleshoot/overview.md#diagnose-from-the-app) (including the [Self-diagnose tool](../troubleshoot/overview.md#diagnose-from-the-app))

3
content/desktop/previous-versions/2.x-mac.md
View File

@ -108,8 +108,7 @@ Docker Desktop 2.4.0.0 contains a Kubernetes upgrade. Your local Kubernetes clus
### New
- The new Cloud integration in Docker CLI makes it easy to run containers in the cloud using either Amazon ECS or Microsoft ACI. For more information, see [Deploying Docker containers on ECS](/engine/context/ecs-integration/) and [Deploying Docker containers on Azure](/engine/context/aci-integration/).
- The new Cloud integration in Docker CLI makes it easy to run containers in the cloud using either Amazon ECS or Microsoft ACI.
### Upgrades
- [Docker Compose 1.27.2](https://github.com/docker/compose/releases/tag/1.27.2)

2
content/desktop/previous-versions/2.x-windows.md
View File

@ -126,7 +126,7 @@ Docker Desktop 2.4.0.0 contains a Kubernetes upgrade. Your local Kubernetes clus
### New
- The new Cloud integration in Docker CLI makes it easy to run containers in the cloud using either Amazon ECS or Microsoft ACI. For more information, see [Deploying Docker containers on ECS](/engine/context/ecs-integration/) and [Deploying Docker containers on Azure](/engine/context/aci-integration/).
- The new Cloud integration in Docker CLI makes it easy to run containers in the cloud using either Amazon ECS or Microsoft ACI.
### Upgrades

4
content/desktop/previous-versions/edge-releases-mac.md
View File

@ -165,7 +165,7 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
### New
- In partnership with Snyk, Docker Desktop launches vulnerability scanning for Docker local images.
- Docker ECS plugin has been replaced by [ECS cloud integration](/engine/context/ecs-integration/)
- Docker ECS plugin has been replaced by ECS cloud integration
- Docker UI:
- The Images view now has search and filter options.
- You can now push an image to Docker Hub using the Remote repositories drop-down menu.
@ -249,7 +249,7 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
### Upgrades
- Beta release of [Docker ECS integration v1.0.0-beta.1](/engine/context/ecs-integration/)
- Beta release of Docker ECS integration v1.0.0-beta.1
- [Docker ACI integration v0.1.7](https://github.com/docker/aci-integration-beta/releases/tag/v0.1.7)
- [Docker Compose 1.26.2](https://github.com/docker/compose/releases/tag/1.26.2)

4
content/desktop/previous-versions/edge-releases-windows.md
View File

@ -166,7 +166,7 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
### New
- In partnership with Snyk, Docker Desktop launches vulnerability scanning for Docker local images.
- Docker ECS plugin has been replaced by [ECS cloud integration](/engine/context/ecs-integration/)
- Docker ECS plugin has been replaced by ECS cloud integration
- Docker UI:
- The Images view now has search and filter options.
- You can now push an image to Docker Hub using the Remote repositories drop-down menu.
@ -258,7 +258,7 @@ the `--privileged` flag. See [docker/for-win#8326](https://github.com/docker/for
### Upgrades
- Beta release of [Docker ECS integration v1.0.0-beta.1.](/engine/context/ecs-integration/)
- Beta release of Docker ECS integration v1.0.0-beta.1.
- [Docker ACI integration v0.1.7](https://github.com/docker/aci-integration-beta/releases/tag/v0.1.7)
- [Docker Compose 1.26.2](https://github.com/docker/compose/releases/tag/1.26.2)

18
data/toc.yaml
View File

@ -185,22 +185,8 @@ Guides:
path: /get-started/kube-deploy/
- title: "Deploy to Swarm"
path: /get-started/swarm-deploy/
- sectiontitle: Cloud integrations
section:
- path: /cloud/aci-integration/
title: Docker and ACI
- path: /cloud/aci-container-features/
title: ACI container features
- path: /cloud/aci-compose-features/
title: ACI Compose features
- path: /cloud/ecs-integration/
title: Docker and ECS
- path: /cloud/ecs-architecture/
title: Docker ECS integration architecture
- path: /cloud/ecs-compose-features/
title: ECS Compose features
- path: /cloud/ecs-compose-examples/
title: ECS Compose examples
- title: Cloud integrations
path: /cloud/
- path: /get-started/resources/
title: "Educational resources"

1
go.mod
View File

@ -8,7 +8,6 @@ require (
github.com/compose-spec/compose-spec v0.0.0-20231121152139-478928e7c9f8 // indirect
github.com/docker/buildx v0.12.0 // indirect
github.com/docker/cli v24.0.8-0.20231106123152-48ec4f339e2b+incompatible // indirect
github.com/docker/compose-cli v1.0.35 // indirect
github.com/docker/compose/v2 v2.23.3 // indirect
github.com/docker/scout-cli v1.2.0 // indirect
github.com/moby/buildkit v0.13.0-beta1.0.20231113205014-1efcd30d9dd6 // indirect

13
hugo.yaml
View File

@ -279,19 +279,6 @@ module:
- source: docs/reference/commandline/dockerd.md
target: content/engine/reference/commandline/dockerd.md
- path: github.com/docker/compose-cli
mounts:
- source: docs/aci-compose-features.md
target: content/cloud/aci-compose-features.md
- source: docs/aci-container-features.md
target: content/cloud/aci-container-features.md
- source: docs/ecs-architecture.md
target: content/cloud/ecs-architecture.md
- source: docs/ecs-compose-examples.md
target: content/cloud/ecs-compose-examples.md
- source: docs/ecs-compose-features.md
target: content/cloud/ecs-compose-features.md
- path: github.com/compose-spec/compose-spec
mounts:
- source: 01-status.md