Amazon Elastic Container Service (ECS) – Establishing a Deployment Strategy – SAP-C02 Study Guide

Note

To run this code, it is a prerequisite to have the CDK CLI installed on your terminal.

First, as illustrated in the preceding example, creating resources with the CDK is usually concise and much less verbose than with CloudFormation and its templates in YAML or JSON. This is due to the fact that the CDK assumes many of the default parameters that you normally have to specify when using CloudFormation. This is something that you can easily verify by letting the CDK generate the supporting CloudFormation template—that’s the synthesization step (cdk synth in the CLI). The CDK will generate a CloudFormation JSON template that will be used to deploy your resources. As you will see in this case, it is not unusual for the resulting CloudFormation template to be 10 times as big as the piece of code that you actually wrote.

Second, and most important for them, developers can now create AWS resources using a programming language they’re familiar with. This makes their life so much easier compared to writing CloudFormation templates using either YAML or JSON.

Additionally, for those familiar with or already using HashiCorp Terraform, there also exists a Cloud Development Kit for Terraform (CDKTF). The CDKTF lets you access the Terraform ecosystem without having to learn HashiCorp Configuration Language (HCL).

Amazon Elastic Container Service (ECS)

Amazon ECS is AWS’s native and fully managed container orchestration service. ECS integrates with core AWS services such as CloudWatch, Auto Scaling, and IAM to provide a seamless experience for monitoring, scaling, and load balancing your containerized applications. It lets you deploy Docker containers without having to worry about installing, operating, or scaling the container management infrastructure, that is, the control plane. It supports three types of compute engines, or launch types, for deploying containers: EC2 instances, AWS Fargate, and external.

EC2 allows you to run and manage Docker containers on a cluster of Amazon EC2 instances that you manage. With this option, you have control over the underlying infrastructure, giving you the flexibility to choose the instance types, manage the cluster’s scaling policies, and configure the networking.

Fargate offers a serverless experience to container developers by managing the underlying AWS infrastructure on their behalf. The external launch type lets you deploy containerized applications on ECS on infrastructure that you run on an on-premises server or Virtual Machine (VM).

ECS groups containers in tasks. A task is simply a unit of deployment for containers and can consist of multiple different containers (up to 10 at the time of writing). You would typically combine containers that are closely related into a single task. However, it is good practice to split an application into multiple tasks, each representing a component of your application.

In terms of infrastructure, when working with ECS, you start by creating a cluster, that is, a logical grouping of your application components. You then deploy your application components onto the cluster using tasks. ECS also has two important additional concepts:

  • Service: ECS services ensure that tasks run as expected and are scheduled, stopped, and restarted when needed.
  • Capacity provider: ECS capacity providers manage the infrastructure supporting the tasks and, in particular, handle scaling and manage placement constraints, if any.

When you want to actually deploy your application components onto ECS, you have several options, called deployment types, to roll out new releases of your ECS services. ECS currently offers three deployment types—rolling update, blue/green, and external.

In the case of the rolling update deployment type, the ECS service scheduler replaces the currently running tasks with new tasks. You control how many tasks ECS adds or removes through the deployment configuration. What happens behind the scenes is that the ECS service scheduler launches enough new tasks to reach the desired count that you specified in your deployment configuration (or when the service was defined). It is worth noting that the rolling update deployment type also allows you to optionally use circuit breaker logic on the service deployment; this causes the deployment to transition to a failed state if it can’t reach a steady state. This functionality can be used to trigger ECS to roll back to the last completed deployment upon a deployment failure.

In the case of the blue/green deployment type, ECS leverages the blue/green deployment model controlled by CodeDeploy. Traffic essentially shifts to the new release of the service in one of three ways:

  • Canary: Traffic is shifted in two increments. The first portion of traffic shifts in the first increment while the rest of the traffic is sent over, after the specified amount of time, in the second increment.
  • Linear: Traffic is shifted in equal increments with an equal time between each increment.
  • All-at-once: All traffic is shifted from the original tasks to the updated tasks all at once.

We have already covered blue/green deployment to ECS using CodeDeploy in the section of this chapter dedicated to CodeDeploy; please refer to that section for more details.

Finally, in the case of the external deployment type, you can hand over the control of the deployment to a third-party solution. The external deployment solution then makes use of the ECS APIs for managing services and tasks to pilot the deployment.