To test our life cycle management solution, we need to have a mechanism to force your ECS container instances to be terminated. Although you could simply adjust the desired count of your Auto Scaling group (which actually is a common scenario when your Auto Scaling groups are scaling down), another common scenario where this can happen is when you need to update your ECS container instances by introducing a newly built Amazon Machine Image (AMI), complete with the latest operating system and security patches, and up-to-date versions of Docker Engine and the ECS agent. At the very least, if you are building a custom ECS container instance AMI using an approach similar to what you learned in Chapter 6, you should be rebuilding your AMI each time Amazon releases a new version of the base ECS-optimized AMI, and it is common practice to update your AMIs on a weekly or monthly basis.
To simulate introducing a new AMI into your ECS cluster, you can simply perform the same steps you executed in Chapter 6, which will output a new AMI that you can then use as an input into your stack and force your ECS cluster to upgrade each of its ECS container instances.
The following example demonstrates running the make build command from the root of the packer-ecs repository, which will output a new AMI ID for the newly created and published image. Ensure you note down this AMI ID as you will require it later on in this chapter:
> export AWS_PROFILE=docker-in-aws
> make build
packer build packer.json
amazon-ebs output will be in this color.
==> amazon-ebs: Prevalidating AMI Name: docker-in-aws-ecs 1518934269
...
...
Build 'amazon-ebs' finished.
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-east-1: ami-77893508