Specifying x-aws-loadbalancer should apply the LB subnets to the generated ECS service definitions

[knoxilla]

Description

When running docker compose upagainst a docker-compose.yaml file that refers to an existing VPC and existing ALB, the Cloud Formation template that is generated assigns every subnet in the VPC to the ECS service definition. Too many subnets will cause the deploy to fail:

Invalid request provided: CreateService error: subnets can have at most 16 items. (Service: Ecs, Status Code: 400, Request ID: , Extended Request ID: null)

Steps to reproduce the issue:

1. Create a docker-compose.yaml file a service and top-level keys for existing resouces x-aws-vpc and x-aws-loadbalancer
2. Run docker compose up
3. Get error above
4. Run docker compose convert > file.cf and confirm all the subnets listed!

Describe the results you received:

Deployment failed even though convert could generate teh CF template.

Describe the results you expected:

Successful deployment. If you specify an existing LB it already has a list of subnets attached to it.

The ECS service definitions should use the list of subnets from the LB, not every subnet in the VPC.

Additional information you deem important (e.g. issue happens only occasionally):

In this case, I'm using an application load balancer. If I

• use convert to genreate the CF template
• edit it to skinny down the list of subnets for each service
• and aws cloudformation create-stack using the corrected file
• the deployment gets much farther, but still does not complete...

Output of docker version:

Client: Docker Engine - Community
 Cloud integration: 1.0.3
 Version:           20.10.0-rc1
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        5cc2396
 Built:             Tue Nov 17 22:49:30 2020
 OS/Arch:           darwin/amd64
 Context:           equivtest
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.0-rc1
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       131bf7e
  Built:            Tue Nov 17 22:52:57 2020
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.4.1
  GitCommit:        c623d1b36f09f8ef6536a057bd658b3aa8632828
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker context show:
You can also run docker context inspect context-name to give us more details but don't forget to remove sensitive content.

[
    {
        "Name": "equivtest",
        "Metadata": {
            "Type": "ecs"
        },
        "Endpoints": {
            "docker": {
                "SkipTLSVerify": false
            },
            "ecs": {
                "Profile": "dev"
            }
        },
        "TLSMaterial": {},
        "Storage": {
            "MetadataPath": "/SNIP/.docker/contexts/meta/562bc151869d11fa1fcfe82ea962bafd7399facaf89441bfd780cd803aef3a4e",
            "TLSPath": "/SNIP/.docker/contexts/tls/562bc151869d11fa1fcfe82ea962bafd7399facaf89441bfd780cd803aef3a4e"
        }
    }
]

Output of docker info:

unknown command "info" for "docker"

Additional environment details (AWS ECS, Azure ACI, local, etc.):

[ndeloof]

also see #921 on a comparable topic

[coffeedome]

Hi there - I'm having the same issue as this ticket and https://github.com/docker/compose-cli/issues/921 although I don't understand why it has been closed; It's very common to have multiple public subnets in a VPC. At a minimum it should just pick the first subnet from the list just to bypass this issue - it's a real roadblock!!!

I also just tried deploying to a separate aws account where I have only one subnet and vpc:
"VPC vpc-************ should have at least 2 associated subnets in different availability zones"

Note this is a fair warning but it should not be mandatory.