How do I update a Fargate service when I update the image using the same tag?

[yorinasub17]

We have a Fargate service that uses a docker image. We pushed a new image with the same tag and would like to restart the service to make it use the new image. Running terragrunt apply doesn't see any changes to the infrastructure, as there are none.

[yorinasub17]

If you wish to rotate the containers in this scenario, the only option you have is to spin up a new set of replicas by doubling your replica count, and then tearing down the old replicas by spinning down the count.

Alternatively, you can do a manual rolling deploy by stopping each container, one at a time. When you stop a container, ECS or EKS will both spin up a new container to compensate.

There is no automated way to do this with terragrunt, or other declarative IaC tools (like kubectl) as they all depend on diffs in the configuration file itself to induce actions, and when you are updating the tag directly with new images, nothing will change in the IaC, and thus by design the IaC tools will not take any actions.

This is primarily why we recommend using specific tags for each image version, rather than relying on updating the same tag with new versions to induce rollout. Almost all of the container orchestration systems do not support automatically rotating images with the same tag to pull in the latest image, as they follow the pattern of immutable tags. In this scenario, rolling out new images is straightforward as you would update the IaC config with the new image tag, inducing a configuration change that will then get rolled out.

[nmilev-scribe]

Does stopping a container result in downtime (meaning the old one will be destroyed before the new one gets spun up)?

[yorinasub17]

For ECS, no as stopping a container causes AWS to deregister the targets from the load balancers prior to setting the signals to stop the container (see https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/).

With EKS, it may cause some downtime when you delete a Pod due to delays in deregistering the Pod from the Service. Refer to this blog post for more information on why this happens, and some tactics to avoid it.

[nmilev-scribe]

Thanks!