I'm redesigning my CDK setup and need to manage both an Amazon ECR repository and an ECS Fargate service. My current pipeline builds and pushes an image to ECR, then deploys the ECS resources, but I'm considering moving that process to a CI workflow instead.
I've seen the suggestion to use `ecs.ContainerImage.fromAsset('./path/to/dockerfile')`, which lets CDK build and publish the container image during deployment. Is that generally considered a good practice, or is it better to keep the ECR and ECS deployments separate and have the CI workflow build and push new images before updating the service?
3 Answers
I generally use separate ECR and ECS stacks. The image is built and pushed to ECR first, and the ECS service is configured to deploy a specific image tag or digest afterward. It is a little less self-contained than one stack, but the release flow is easier to understand and gives you more control over when a new image is rolled out.
Another option is to synthesize the CDK application, publish the generated assets with the CDK asset tooling, and then deploy the synthesized CloudFormation template. You can also pass the image tag or digest into the ECS stack as a parameter. This keeps infrastructure deployment and image publishing separate while still allowing the workflow to automate both steps.
Keeping the ECR repository and ECS service in separate stacks is a common approach. Your CI workflow can deploy the repository stack first, build and push the image, and then deploy the ECS stack using the resulting image reference. `ContainerImage.fromAsset()` also works and handles the asset dependency for you, but it couples image publishing to CDK deployment.
That makes sense. My main goal is for Dockerfile changes pushed to the source repository to result in a new ECS deployment, so separating the image build from the infrastructure update may be cleaner.