Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aws-ecs: Cannot deploy fargate services with ECR images #3646

Closed
1 of 5 tasks
realharry opened this issue Aug 14, 2019 · 23 comments
Closed
1 of 5 tasks

aws-ecs: Cannot deploy fargate services with ECR images #3646

realharry opened this issue Aug 14, 2019 · 23 comments
Assignees
Labels
@aws-cdk/aws-ecs Related to Amazon Elastic Container bug This issue is a bug. needs-reproduction This issue needs reproduction.

Comments

@realharry
Copy link

  • I'm submitting a ...

    • πŸͺ² bug report
    • πŸš€ feature request
    • πŸ“š construct library gap
    • ☎️ security issue or vulnerability => Please see policy
    • ❓ support request => Please see note at the top of this template.
  • What is the current behavior?
    If the current behavior is a πŸͺ²bugπŸͺ²: Please provide the steps to reproduce

  1. Create a VPC with one public subnet. And make sure that Internet gateway is created.
  2. Create a Fargate cluster within the VPC.
  3. Try to create a LoadBalancedFargateService.

cdk deploy creates all constructs successfully, including ELB, SG, etc., but it fails to create the service, which is practically the final step:

Do you wish to deploy these changes (y/n)? y
Rbi5PatternsStagingStack: deploying...
Rbi5PatternsStagingStack: creating CloudFormation changeset...
  0/15 | 9:14:17 PM | CREATE_IN_PROGRESS   | AWS::Logs::LogGroup                       | website/TaskDef/web/LogGroup (websiteTaskDefwebLogGroupC8A8E4C5)
  0/15 | 9:14:17 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroup                   | website/Service/SecurityGroup (websiteServiceSecurityGroup997F4E46)
  0/15 | 9:14:17 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role                            | website/TaskDef/TaskRole (websiteTaskDefTaskRoleC7AA0A74)
  0/15 | 9:14:17 PM | CREATE_IN_PROGRESS   | AWS::Logs::LogGroup                       | website/TaskDef/web/LogGroup (websiteTaskDefwebLogGroupC8A8E4C5) Resource creation Initiated
  1/15 | 9:14:17 PM | CREATE_COMPLETE      | AWS::Logs::LogGroup                       | website/TaskDef/web/LogGroup (websiteTaskDefwebLogGroupC8A8E4C5)
  1/15 | 9:14:17 PM | CREATE_IN_PROGRESS   | AWS::ElasticLoadBalancingV2::TargetGroup  | website/LB/PublicListener/ECSGroup (websiteLBPublicListenerECSGroup247DABD4)
  1/15 | 9:14:18 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role                            | website/TaskDef/TaskRole (websiteTaskDefTaskRoleC7AA0A74) Resource creation Initiated
  1/15 | 9:14:18 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroup                   | website/LB/SecurityGroup (websiteLBSecurityGroup73701CCA)
  1/15 | 9:14:18 PM | CREATE_IN_PROGRESS   | AWS::ElasticLoadBalancingV2::TargetGroup  | website/LB/PublicListener/ECSGroup (websiteLBPublicListenerECSGroup247DABD4) Resource creation Initiated
  1/15 | 9:14:18 PM | CREATE_IN_PROGRESS   | AWS::ECS::Cluster                         | staging-cluster (stagingclusterDBEBD0C8)
  2/15 | 9:14:18 PM | CREATE_COMPLETE      | AWS::ElasticLoadBalancingV2::TargetGroup  | website/LB/PublicListener/ECSGroup (websiteLBPublicListenerECSGroup247DABD4)
  2/15 | 9:14:18 PM | CREATE_IN_PROGRESS   | AWS::ECS::Cluster                         | staging-cluster (stagingclusterDBEBD0C8) Resource creation Initiated
  3/15 | 9:14:19 PM | CREATE_COMPLETE      | AWS::ECS::Cluster                         | staging-cluster (stagingclusterDBEBD0C8)
  3/15 | 9:14:19 PM | CREATE_IN_PROGRESS   | AWS::CDK::Metadata                        | CDKMetadata
  3/15 | 9:14:21 PM | CREATE_IN_PROGRESS   | AWS::CDK::Metadata                        | CDKMetadata Resource creation Initiated
  4/15 | 9:14:21 PM | CREATE_COMPLETE      | AWS::CDK::Metadata                        | CDKMetadata
  4/15 | 9:14:22 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroup                   | website/Service/SecurityGroup (websiteServiceSecurityGroup997F4E46) Resource creation Initiated
  4/15 | 9:14:22 PM | CREATE_IN_PROGRESS   | AWS::IAM::Policy                          | website-execution-role/Policy (websiteexecutionrolePolicy67F459E7)
  4/15 | 9:14:22 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroup                   | website/LB/SecurityGroup (websiteLBSecurityGroup73701CCA) Resource creation Initiated
  5/15 | 9:14:23 PM | CREATE_COMPLETE      | AWS::EC2::SecurityGroup                   | website/Service/SecurityGroup (websiteServiceSecurityGroup997F4E46)
  6/15 | 9:14:23 PM | CREATE_COMPLETE      | AWS::EC2::SecurityGroup                   | website/LB/SecurityGroup (websiteLBSecurityGroup73701CCA)
  6/15 | 9:14:23 PM | CREATE_IN_PROGRESS   | AWS::IAM::Policy                          | website-execution-role/Policy (websiteexecutionrolePolicy67F459E7) Resource creation Initiated
  6/15 | 9:14:26 PM | CREATE_IN_PROGRESS   | AWS::ElasticLoadBalancingV2::LoadBalancer | website/LB (websiteLB14D1FE30)
  6/15 | 9:14:27 PM | CREATE_IN_PROGRESS   | AWS::ElasticLoadBalancingV2::LoadBalancer | website/LB (websiteLB14D1FE30) Resource creation Initiated
  6/15 | 9:14:27 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroupEgress             | website/LB/SecurityGroup/to Rbi5PatternsStagingStackwebsiteServiceSecurityGroupE0482DA5:443 (websiteLBSecurityGrouptoRbi5PatternsStagingStackwebsiteServiceSecurityGroupE0482DA544358F061E7)
  6/15 | 9:14:27 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroupIngress            | website/Service/SecurityGroup/from Rbi5PatternsStagingStackwebsiteLBSecurityGroup1CC8D48A:443 (websiteServiceSecurityGroupfromRbi5PatternsStagingStackwebsiteLBSecurityGroup1CC8D48A443278970E2)
  6/15 | 9:14:28 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroupEgress             | website/LB/SecurityGroup/to Rbi5PatternsStagingStackwebsiteServiceSecurityGroupE0482DA5:443 (websiteLBSecurityGrouptoRbi5PatternsStagingStackwebsiteServiceSecurityGroupE0482DA544358F061E7) Resource creation Initiated
  6/15 | 9:14:28 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroupIngress            | website/Service/SecurityGroup/from Rbi5PatternsStagingStackwebsiteLBSecurityGroup1CC8D48A:443 (websiteServiceSecurityGroupfromRbi5PatternsStagingStackwebsiteLBSecurityGroup1CC8D48A443278970E2) Resource creation Initiated
  7/15 | 9:14:28 PM | CREATE_COMPLETE      | AWS::EC2::SecurityGroupIngress            | website/Service/SecurityGroup/from Rbi5PatternsStagingStackwebsiteLBSecurityGroup1CC8D48A:443 (websiteServiceSecurityGroupfromRbi5PatternsStagingStackwebsiteLBSecurityGroup1CC8D48A443278970E2)
  8/15 | 9:14:28 PM | CREATE_COMPLETE      | AWS::EC2::SecurityGroupEgress             | website/LB/SecurityGroup/to Rbi5PatternsStagingStackwebsiteServiceSecurityGroupE0482DA5:443 (websiteLBSecurityGrouptoRbi5PatternsStagingStackwebsiteServiceSecurityGroupE0482DA544358F061E7)
  9/15 | 9:14:31 PM | CREATE_COMPLETE      | AWS::IAM::Policy                          | website-execution-role/Policy (websiteexecutionrolePolicy67F459E7)
 10/15 | 9:14:36 PM | CREATE_COMPLETE      | AWS::IAM::Role                            | website/TaskDef/TaskRole (websiteTaskDefTaskRoleC7AA0A74)
 10/15 | 9:14:41 PM | CREATE_IN_PROGRESS   | AWS::ECS::TaskDefinition                  | website/TaskDef (websiteTaskDef81484BC5)
 10/15 | 9:14:41 PM | CREATE_IN_PROGRESS   | AWS::ECS::TaskDefinition                  | website/TaskDef (websiteTaskDef81484BC5) Resource creation Initiated
 11/15 | 9:14:42 PM | CREATE_COMPLETE      | AWS::ECS::TaskDefinition                  | website/TaskDef (websiteTaskDef81484BC5)
11/15 Currently in progress: websiteLB14D1FE30
 12/15 | 9:16:28 PM | CREATE_COMPLETE      | AWS::ElasticLoadBalancingV2::LoadBalancer | website/LB (websiteLB14D1FE30)
 12/15 | 9:16:32 PM | CREATE_IN_PROGRESS   | AWS::ElasticLoadBalancingV2::Listener     | website/LB/PublicListener (websiteLBPublicListenerC5A4EA76)
 12/15 | 9:16:32 PM | CREATE_IN_PROGRESS   | AWS::ElasticLoadBalancingV2::Listener     | website/LB/PublicListener (websiteLBPublicListenerC5A4EA76) Resource creation Initiated
 13/15 | 9:16:32 PM | CREATE_COMPLETE      | AWS::ElasticLoadBalancingV2::Listener     | website/LB/PublicListener (websiteLBPublicListenerC5A4EA76)
 13/15 | 9:16:37 PM | CREATE_IN_PROGRESS   | AWS::ECS::Service                         | website/Service/Service (websiteService29B32E70)
 13/15 | 9:16:38 PM | CREATE_IN_PROGRESS   | AWS::ECS::Service                         | website/Service/Service (websiteService29B32E70) Resource creation Initiated
13/15 Currently in progress: websiteService29B32E70

It hangs at this point, and the deploy eventually times out.

  • What is the expected behavior (or behavior of feature suggested)?

The stack should be created successfully.

  • What is the motivation / use case for changing the behavior or adding this feature?

I'd like to use CDK to create a fargate service.

  • Please tell us about your environment:

    • CDK CLI Version: 1.3.0 (build bba9914)
    • Module Version: 1.3.0
    • OS: OSX Mojave
    • Language: TypeScript
    • Node: v10.15.3
    • Typescript: Version 3.5.3
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. associated pull-request, stackoverflow, gitter, etc)

@realharry realharry added the needs-triage This issue or PR still needs to be triaged. label Aug 14, 2019
@realharry
Copy link
Author

The service creation appears to fail because it cannot pull the docker image from ECR. The error message on the created task in the cluster: STOPPED (CannotPullContainerError: Error response from daem)

@fitzee
Copy link

fitzee commented Aug 14, 2019

Hey, me again!

What does your TaskExecutionIamRole look like? Do you have arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly in your list of policy ARNs?

@realharry
Copy link
Author

Hi @fitzee Good morning! I'm not sure what exact role this CDK app creates, but I tried with an existing role called "ecsTaskExecutionRole" (for executionRole property for LoadBalancedFargateServiceProps), but I got the same error. This role, which I presume was created when I tried ECS fargate deployment the first time (not necessarily via CDK), has "AmazonEC2ContainerRegistryFullAccess" and "AmazonECSTaskExecutionRolePolicy" attached to it.

At first I thought it was some kind of networking issue, and I tried with publicTasks: true, but it didn't help either. (I still think it could likely be a networking issue with the VPC/subnets, ECS cluster, and security groups, etc., that were created by CDK. Unfortunately, my knowledge of AWS is not deep enough to know what is exactly going on.)

CDK is very nice. (actually, very very very very nice :)), but it feels like it's a bit of a blackbox, and when you run into issues like this it seems hard to troubleshoot.

Thanks!

@realharry
Copy link
Author

I ran into the same issue using ECS constructs directly as reported in #3644 . Hence, the issue does not appear to be specific to LoadBalancedFargateService.

@realharry realharry changed the title aws-ecs-patterns: Cannot deploy fargate services with ECR images aws-ecs: Cannot deploy fargate services with ECR images Aug 15, 2019
@SoManyHs SoManyHs added the @aws-cdk/aws-ecs Related to Amazon Elastic Container label Aug 19, 2019
@iamhopaul123
Copy link
Contributor

I ran into a similar issue when trying to update my stack, which stuck at creating the service:

 0/4 | 3:22:42 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroup               | Service/SecurityGroup (ServiceSecurityGroupC96ED6A7) 
 0/4 | 3:22:46 PM | CREATE_IN_PROGRESS   | AWS::EC2::SecurityGroup               | Service/SecurityGroup (ServiceSecurityGroupC96ED6A7) Resource creation Initiated
 1/4 | 3:22:47 PM | CREATE_COMPLETE      | AWS::EC2::SecurityGroup               | Service/SecurityGroup (ServiceSecurityGroupC96ED6A7) 
 1/4 | 3:22:52 PM | UPDATE_IN_PROGRESS   | AWS::ECS::TaskDefinition              | TaskDef (TaskDef54694570) Requested update requires the creation of a new physical resource; hence creating one.
 1/4 | 3:22:52 PM | UPDATE_IN_PROGRESS   | AWS::ECS::TaskDefinition              | TaskDef (TaskDef54694570) Resource creation Initiated
 2/4 | 3:22:53 PM | UPDATE_COMPLETE      | AWS::ECS::TaskDefinition              | TaskDef (TaskDef54694570) 
 2/4 | 3:22:59 PM | UPDATE_IN_PROGRESS   | AWS::ECS::Service                     | Service/Service (ServiceD69D759B) 
2/4 Currently in progress: ServiceD69D759B

It is a very regular service that pulls images from ECR for task definition and use aws_vpc as network mode.

@ConradMearns
Copy link

Hi @fitzee Good morning! I'm not sure what exact role this CDK app creates, but I tried with an existing role called "ecsTaskExecutionRole" (for executionRole property for LoadBalancedFargateServiceProps), but I got the same error. This role, which I presume was created when I tried ECS fargate deployment the first time (not necessarily via CDK), has "AmazonEC2ContainerRegistryFullAccess" and "AmazonECSTaskExecutionRolePolicy" attached to it.

At first I thought it was some kind of networking issue, and I tried with publicTasks: true, but it didn't help either. (I still think it could likely be a networking issue with the VPC/subnets, ECS cluster, and security groups, etc., that were created by CDK. Unfortunately, my knowledge of AWS is not deep enough to know what is exactly going on.)

CDK is very nice. (actually, very very very very nice :)), but it feels like it's a bit of a blackbox, and when you run into issues like this it seems hard to troubleshoot.

Thanks!

I'm encountering the same issue - using the same "ecsTaskExecutionRole" if that matters.

@ConradMearns
Copy link

Got my solution, I hadn't specified an image tag when I called

ecs.ContainerImage.fromEcrRepository

so it defaulted to "latest" - our repository didn't have a latest tag so this failed.

Also, @realharry , if you dig into the Service and check under details, the rest of the STOPPED (CannotPullContainerError: Error response from daem) message becomes available. Mine was
CannotPullContainerError: Error response from daemon: manifest for <URI to my image in ecr>:latest not found

@NGL321 NGL321 added bug This issue is a bug. needs-reproduction This issue needs reproduction. and removed needs-triage This issue or PR still needs to be triaged. labels Oct 9, 2019
@NGL321
Copy link
Contributor

NGL321 commented Oct 9, 2019

@realharry I'm sorry to hear that the CDK feels like a blackbox. We try to be as open and public with the source code as possible, there is a minimal amount of AWS information we cant give, but if you have any suggestions as to what would make the project feel less closed off, I am all ears!

In the interim, did @ConradMearns solution work for you? (we're working hard to get through our issue queue, and it would be wonderful if this was already resolved!)

😸

@realharry
Copy link
Author

@NGL321 Thanks for following up. I no longer work on the deployment task at this point (a colleague in the team took over the task), but my understanding was it was resolved following the direction similar to what was suggested by @ConradMearns. Thanks! I'll close this ticket.

I ended up spending a little over a week (or, more like 2 weeks) with CDK, and I think I achieved quite a bit with a help of CDK (although I failed to build the whole stack (not a big architecture by any measure) using CDK within that 1~2 week time frame). My primary problem with CDK, not necessarily specific to this particular issue, was essentially my lack of knowledge across AWS service stacks. When the deployment failed, the error happened somewhere in AWS services, and CDK (being a high level tool) wasn't entirely helpful in pinpointing what exactly when wrong. But, over time, with more experience, it got easier and easier. As a general comment, I don't know how easy it would be, but if CDK could up-propagate the error messages to the user from the low-level stack where the error occurred, I think it would be very useful. Thanks!

@peebles
Copy link

peebles commented Jan 15, 2020

I am launching a stack for the very first time, which includes a ECR and a Fargate service that refers to a repo in the ECR that does not (yet) have an image. The intent is to push images later using Ci/CD. But my stack hangs, presumably trying to deploy the docker image that does not yet exist!

    // Container image
    const zcloudRepository = new ecr.Repository( this, 'ZcloudRepository', {
      repositoryName: `zcloud-image-${props.env}`,
    });
    
    // Lifecycle
    zcloudRepository.addLifecycleRule({ maxImageAge: cdk.Duration.days(30) });  // delete older than 30 days

    // Grant push access to the deploy user
    zcloudRepository.grantPullPush(deployer);

    // The task definition
    const zcloudDefinition = new ecs.FargateTaskDefinition(this, 'ZcloudDefinition', {
      // CPU and MEMORY limits here need to be equal or greater than all container instances added up
      cpu: zCPU * 4,
      memoryLimitMiB: zMemory * 4,
    });

    const container = zcloudDefinition.addContainer('zcloud', {
      image: ecs.ContainerImage.fromEcrRepository(zcloudRepository),
      memoryMiB: zMemory,
      cpu: zCPU,
      environment: {
        NODE_ENV: props.env,   // set up NODE_ENV from the props passed in
      },
      logging: new ecs.AwsLogDriver({
        logGroup: props.global.paperwatchLogGroup,
        streamPrefix: `zcloud-${props.env}`
      })
    });
    container.addPortMappings({
      containerPort: 3000 
    });

@skinny85
Copy link
Contributor

@peebles I wonder if you're running into the same problem as in this issue: #1237

@desbo
Copy link

desbo commented Feb 9, 2020

I'm having a similar problem. Is there any way to define an ECR repository and Fargate service with taskImageOptions: { image: ecs.ContainerImage.fromEcrRepository(myRepo) } in the same stack?

@djkirby
Copy link

djkirby commented Apr 29, 2020

@peebles / @desbo any of you guys figure this out? also trying to deploy a new repository and a service in the same stack but hangs on the initial deploy due to no image being in the repo yet.

edit: think I'll make a separate stack for the repo

edit: ended up ditching the repo setup and using image: ecs.ContainerImage.fromAsset( which builds the image from a Dockerfile and pushes to ECR itself

@desbo
Copy link

desbo commented Apr 29, 2020

@djkirby I ended up working around this by manually creating the ECR repo outside of CloudFormation.

I think fromEcrRepository would be a lot more useful if it was possible to define a repository and service in the same stack, using the repository as the parameter. Maybe it'd be worth opening a new issue based on the report from @peebles. Any thoughts, @NGL321?

@djkirby
Copy link

djkirby commented Apr 29, 2020

Yea and I'm also realizing it'd be nice to keep the repository in the stack so it could be torn down as part of cdk destroy.

@andreialecu
Copy link
Contributor

I am launching a stack for the very first time, which includes a ECR and a Fargate service that refers to a repo in the ECR that does not (yet) have an image. The intent is to push images later using Ci/CD. But my stack hangs, presumably trying to deploy the docker image that does not yet exist!

Running into the same problem. Came here from google, but since this issue is closed and started off as a different problem, I think the discussion should be moved to a new, separate, issue.

I'm going to try to work around it by pushing the Docker image manually.

@drakir
Copy link

drakir commented May 5, 2020

There is a solution, it's not pretty, but what you can do is to find the low level construct CfnService and override the default behavior and set the desiredCount to 0. Then in your pipeline of your app you must remember to update the desiredCount after an image have been pushed to the repository. This can be done with the aws cli.

A little example:

const loadBalancedFargateService = new ApplicationLoadBalancedFargateService(this, 'MyFargateService', {
            cluster,
            memoryLimitMiB: 1024,
            cpu: 512,
            taskImageOptions: {
                image: ContainerImage.fromEcrRepository(repository) // no image exists here at the time of this execution
            },
            desiredCount: 1 //cannot be set to any lower count here
        });

        const node = loadBalancedFargateService.service.node;

        // fetches the underlying low level construct CfnService to override the desiredCount to 0, so the stack does not time out if no image is in place.
        const cfnService: CfnService = node.findChild('Service') as CfnService; //it just so happens to be named to Service if you check the source code.
        cfnService.desiredCount = 0;`

@Mk-Etlinger
Copy link

Mk-Etlinger commented Jan 28, 2021

Hey AWS team,

I'm also having this issue. How do you solve the failed service deploy when there's no image during the first cdk deploy?

...VPC code above...

const repository = new ecr.Repository(this, 'app-ecr', {
  repositoryName: 'app-v2',
});

const cluster = new ecs.Cluster(this, 'app-cluster', {
  vpc,
  clusterName: 'app-v2',
});

const loadBalancedFargateService = new ecsPatterns.ApplicationLoadBalancedFargateService(this, 'app-service', {
  cluster,
  serviceName: 'app-v2',
  desiredCount: 1,
  cpu: 512,
  memoryLimitMiB: 1024,
  minHealthyPercent: 100,
  maxHealthyPercent: 200,
  publicLoadBalancer: true,
  taskImageOptions:{
    enableLogging: true,
    image: ecs.ContainerImage.fromEcrRepository(repository),
    containerPort: 3000,
  }
});

The above code hangs forever during cdk deploy. There's no image in the ECR but that's to be expected when you first spin up infra.

Thanks for the help @drakir, your workaround helped me get this spun up.

Is there any official solution to this problem @skinny85?

I looked at the thread you mentioned above but it didn't seem like the same thing.

Let me know if this could use a new issue, thanks!

@Plasma
Copy link
Contributor

Plasma commented Apr 7, 2021

@Mk-Etlinger As a workaround the initial deployment you could try ContainerImage.FromRegistry("amazon/amazon-ecs-sample") (I'm only prototyping though so don't know its pitfalls).

@giuliopulina
Copy link

I'm also wondering which is the best practice to avoid the "no image" issue

@prazian
Copy link

prazian commented Dec 10, 2022

One workaround to this issue:

  1. Define the ECR repo in a separate stack
  2. Deploy the ECR stack first (cdk deploy ECRStack)
  3. Build and push the image to ECR
  4. Deploy the rest ... (including ECS)

Not perfect && a bit ugly, but works.
Hope this helps.

@giuliopulina
Copy link

One workaround to this issue:

  1. Define the ECR repo in a separate stack
  2. Deploy the ECR stack first (cdk deploy ECRStack)
  3. Build and push the image to ECR
  4. Deploy the rest ... (including ECS)

Not perfect && a bit ugly, but works. Hope this helps.

Thanks, at the end I came up with this solution πŸ™‚

@floodfx
Copy link

floodfx commented Apr 19, 2024

(Adding for other folks that might land here one day)

FWIW, Another reason that loading from ECR might appear to hang when starting a Fargate service is because the health check is failing. An ApplicationLoadBalancedFargateService construct assumes your ECR image will serve via port 80 and check that port when starting new instances. You can change the port when defining the taskImageOptions inside your ApplicationLoadBalanacedFargateService.

e.g.

taskImageOptions: {
  image: ecs.ContainerImage.fromEcrRepository(repository),
  containerPort: 8080,
},

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-ecs Related to Amazon Elastic Container bug This issue is a bug. needs-reproduction This issue needs reproduction.
Projects
None yet
Development

No branches or pull requests