6

I am deploying an ECS Fargate task with two containers: 1 reverse proxy nginx and 1 python server. For each I have an ECR repository, and I have a CI/CD CodePipeline set up with

CodeCommit -> CodeBuild -> CodeDeploy

This flow works fine for simple code changes. But what if I want to add another container? I can certainly update my buildspec.yml to add the building of the container, but I also need to 1) update my task definition, and 2) assign this task definition to my service.

Questions:

1) If I use the CLI in my CodeBuild stage to create a new task definition and associate it with my service, won't this trigger a deploy? And then my CodeDeploy will try to deploy again, so I'll end up deploying twice?

2) This approach ends up creating a new task definition and updating the service on every single deploy. Is this bad? Should I have some logic to pull down the LATEST task revision and diff the JSON from CodeCommit version and only update if there is a difference?

Thanks!

lollercoaster
  • 15,969
  • 35
  • 115
  • 173

1 Answers1

5

The CodePipeline's ECS Job Worker copies the Task Definition and updates the Image and ImageTag for the container specified in the 'imagedefinitions.json' file, then updates the ECS Service with this new TaskDef. The job worker cannot add a new container in the task definition.

If I use the CLI in my CodeBuild stage to create a new task definition and associate it with my service, won't this trigger a deploy? And then my CodeDeploy will try to deploy again, so I'll end up deploying twice?

I don't think so. Is there a CloudWatch event rule that triggers CodeDeploy in such fashion?

This approach ends up creating a new task definition and updating the service on every single deploy. Is this bad? Should I have some logic to pull down the LATEST task revision and diff the JSON from CodeCommit version and only update if there is a difference?

The ECS Deploy Job worker creates a new task definition revision every time a deployment occurs so if this is official behaviour, I wouldn't consider it bad as such.

I will question why you need to add new containers to your Task definition in runtime during deploys. Your task definition in general should be modified less often, and only the image:tag in it should be modified regularly - something the ECS Deploy action helps you achieve.

shariqmaws
  • 8,152
  • 1
  • 16
  • 35
  • 1
    If you update an ECS service, yes I believe it triggers a deployment. Maybe I can specify not to with `--no-force-new-deployment` in the [update service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) command, however. – lollercoaster Oct 20 '19 at 07:07
  • 1
    Yes, I understand adding containers is a little rarer. But since managing with Terraform, even if `modified less often`, I didn't want to mess up my infra as code paradigm to change container settings often (which can be ulimits, etc, not just wholly new containers). – lollercoaster Oct 20 '19 at 07:08
  • 2
    Hi, how about environment variables? It's quite common to update/add/remove an env. I've been updating them manually by creating a new task def and updating the service before/after deploy and it's a quite cumbersome process. Does anyone have any good solution? Thanks! – Chih Dec 05 '20 at 23:03