(@aws-cdk/aws-ecs): ECS CodePipeline

❓ ECS + CodePipeline stuck on ECS Service creation

The Question

I am developing CodePipeline for automatic ECS deployment. The ECS cluster, VPC and CloudMap namespace is defined in separated stack and values are imported in the current one.

My goal is to create CodeCommit and ECR repositories. The push to CodeCommit repo would then trigger the CodePipeline which would build the app image in ECR and deploy to ECS cluster by EcsDeployAction.

The app stack contains:

• Fargate service
• both ECR and CodeCommit repositories
• CodePipeline definition

The issue I have is that cdk deploy does not finish successfully as it is waiting for ECS Service to be up and running. That cannot succeed in the first run because the ECR repository will contain the image once the CodePipeline runs.

But the CodePipeline artifact is dependent on the ECS Service which created “deadlock”.

My question si whether I can somehow tell CDK not to wait for ECS service to be up and running. Or is there any workaround. I can’t think of any restructuring of the code that would help so far.

The whole repository for completness is here - https://github.com/jakubgruber/ecs-cdk-fargate-pipeline

Environment

• CDK CLI Version: 1.104.0
• Module Version: 1.104.0
• Node.js Version: v12.16.1
• OS: macOS
• Language (Version): TypeScript

[skinny85]

Nice workaround, thank you. Is there any plan to enable that without these hacks?

E.g. tell the ECS service to startup once the image exists in the ECR repo?

Yes. There’s the TagParameterContainerImage. See how it’s used here: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-codepipeline-actions-readme.html#deploying-ecs-applications-stored-in-a-separate-source-code-repository

Thanks, Adam

[barticus]

Hmm, this is a tricky one, and i’m sure theres a few different approaches to it.

What i’ve done previously is that CDK always sets up the stack with the dummy image, and from there the ECS service is never updated, and my pipeline is responsible for deploying the latest version. Due to the way cloudformation works, further deployments will not interfere unless you changed something about that task definition declaring the image. This is a type of “stack drift” though where the actual resource is out of sync with Cloudformation.

What you can now do instead is use an SSM Parameter to store the “latest image” and reference it in your CDK stack. Then, your pipeline must update the SSM parameter to the latest image after deploy. This way, updates to the task definition in CDK aren’t so problematic. If you were going “full cloudformation” you could manage this via a Parameter, but the last time i looked with CDK, you couldn’t tell it to maintain the previous value of parameters on deployment, which means it reverts back to the default image.