Updating ECS TaskDefinition reverts other changes to running service image definition tag (eg due to CodeDeploy)

❓ General Issue

The Question

Whenever an update to the TaskDefinitions for an ECS service is required (for example, new environment variables or CPU limits), the service has the indicated instance image re-applied as to what’s in the CDK template, instead of using whatever is already in the ECS’s service task definition.

Ideally, it would just find and re-use the existing service’s running TaskDefinition container image tag, that would have been set by a separate process since the CDK last performed an update (eg via a CodePipeline deployment process).

Environment

• CDK CLI Version: 1.101.0 (build 149f0fc)
• Module Version:
• Node.js Version:
• OS: all
• Language (Version): C#

Other information

[danwiltshire]

Sure, I actually implemented a working solution in the past few hours.

I’m now using the TagParameterContainerImage solution mentioned in the CDK docs.

The main change was tightly coupling application and infrastructure within the application deployment pipeline as suggested by @skinny85.

For anyone else watching, this info might be useful:

• My CDK project holds stacks for each application As such, the CDK project has its own repo. Main driver was to centralise our own CDK constructs, data, etc.
• Our application repos now hold a Dockerfile which CDK builds and deploys to Fargate.

So yes, I’m all good, thanks all. Hopefully this helps you @Plasma? Feel free to ask further questions.

[skinny85]

In my opinion, the problem is that you’ve split the deployment between code and infrastructure, and that’s why you’re running into this issue.

Unless you’re willing to dramatically change your setup, and move the CDK deployment also to the Pipeline (which is absolutely what you should do), I don’t think you’ll ever solve this problem.