I'm redesigning my CDK setup and need to manage both an Amazon ECR repository and an ECS Fargate service. Right now, a CI pipeline builds and pushes the container image to ECR before deploying the ECS resources, but I'd like to move that process to a different CI workflow.
I've seen the suggestion to use `ecs.ContainerImage.fromAsset('./path/to/dockerfile')`, which allows CDK to build and publish the image during deployment. Is that considered a good practice, or is it better to keep the ECR and ECS deployments separate? Ideally, changes to the Dockerfile should trigger a new image deployment to the ECS service.
3 Answers
Keep the ECR repository and ECS service in separate stacks or deployment stages. The workflow can deploy the repository first, build and push the image, and then deploy or update ECS using the new image tag or digest. This keeps image publishing explicit and makes repeated image updates easier to manage.
`ContainerImage.fromAsset()` also works and creates the necessary dependency automatically, but it couples the image build to the CDK deployment. That can be convenient for small projects, though a dedicated image-build step is usually clearer for ongoing deployments.
Separate ECR and ECS stacks are a common approach. Build the container and push it to ECR first, then have ECS pull a specific image tag or, preferably, an immutable digest. It may not feel like one completely unified stack, but it gives you better control over image promotion and service rollouts.
Creating the repository manually and pushing images with the container tooling is also viable, although defining the repository in CDK keeps the infrastructure reproducible.
Another option is to synthesize the CDK application, publish its assets as a separate CI step, and then deploy the synthesized CloudFormation output. For a more conventional setup, use one stack for ECR and another for ECS, passing the image tag or digest into the ECS deployment as a parameter. This lets the container build and infrastructure deployment remain separate while still being fully automated.
That makes sense for Dockerfile changes: deploy the repository infrastructure, build and push the updated image from the CI workflow, then deploy the ECS stack with the new image reference. Using `fromAsset()` would be possible, but managing later image changes can become less straightforward.