Here is my Amazon Elastic Container Service (ECS) presentation from CFCamp along with my slide notes:
Slide 4 & 5 – Amazon Elastic Container Service (ECS)
- I’m going to explain AWS’s Docker service, Amazon Elastic Container Service, and associated services that allow you to create a CI environment on AWS using Docker for your application.
Slide 14 – EC2 Instances
- Your ECS cluster will need one or more EC2 instances on which to run your containers.
- Amazon ECS container agent
Slider 15 – Amazon ECS Container Agent
- The agent needs to be running on EC2 instances that are in the cluster
- Use the Amazon EC2 ECS AMI
Slide 16 – Amazon ECS-optimized AMI
- It is pre-configured and you don’t need to worry about setting anything up
- Updating the agent can be done directly either via the AWS console or API
Slide 17 – Tasks and Task Definitions
- A task is a running instance of a container
- The task definition is the parameters used to start the container
- For example, the image to use, CPU and memory for the container, networking modes, port mappings, environment variables, etc…
Slide 18 – Services
- Services run and maintain a specified number of instances of a task definition simultaneously in an Amazon ECS cluster
- If any tasks should fail or stop for any reason, the Amazon ECS service scheduler launches another instance of your task to replace it
- Services maintain a desired count of tasks
Slide 19 – Cluster
- The basic component of ECS is a cluster.
- Within a cluster you have services, tasks and (optionally) EC2 instances
Slide 20 – Auto Scaling
- Auto-scaling for ECS is in two types EC2 instances and services
Slide 21 – EC2 Instances
- Auto-scaling of the EC2 instance in your cluster can be done automatically based on a variety of metrics and monitoring types.
Slide 22 – Services
- Auto-scaling is set up at the service level and scales the number of tasks within that service that
- You set a minimum, desired and
maximumnumber of tasks to run.
- You can use certain metrics to scale the service up and downautomatically as required.
Slide 23 – Manual Scaling
- You can also manually scale both the EC2 instances and services in the cluster manually either via the AWS Console or API.
Slide 24 – Elastic Container Registry (ECR)
- ECR is a part of ECS and is a repository for your containers that are used with the ECS service.
- For people who know Docker Hub, is it similar to
- Images are tagged and lifecycle policies can be implemented to make sure only a certain number of images are kept.
Slide 25 – AWS CodeCommit
- AWS’s Git repository storage solution, like Github or BitBucket.
- CodeCommit emits events to CloudWatch when changes, e.g. a push to a repo occurs.
- Can then be used to trigger another AWS service to do something, e.g. CodePipeline to start a build and deploy process.
Slide 26 – AWS CodeBuild
- AWS’s build solution, like Travis
- In this case, it is used to build the Docker Image from a Git repo.
- Can be used to test the resulting image as well.
- Build process can use the AWS CodeBuild managed image or a custom docker image to run the build.
- Your buildspecis a YAML file in your project
Slide 27 – AWS CodePipeline
- AWS CodePipeline manages the build and deployment process using other AWS services
- It can be run manually or triggered automatically using CloudWatch Events, monitoring another resource, in most case a CodeCommit repository.
- Stages – source, build, staging
- Source can be CodeCommit, S3 or Github
- Build can be CodeBuild, Solano CI or a Jenkins server
- Staging can be AWS Service Catalog, AWS Elastic Beanstalk, AWS CodeDeploy, AWS CloudFormation and of course AWS ECS
- For ECS, tell it the cluster and service you want to deploy this build to and it will deploy it
Slide 28 – AWS Services
- AWS has some services to help with
runtime, as your container needs to be disposable, e.g. you can’t store anything directly on the container that needs to persist, like data, object, etc…
Slide 29 – S3
- One of AWS’s most recognised services, S3 allows you store objects(files) in buckets and access them whenever you need.
- Objects can also be served directly from S3 via HTTPS.
Slide 30 – RDS and DynamoDB
- This is AWS’s fully managed database service, supporting a range of database engines, including MS SQL, Oracle, PostgreSQL, MySQL, MariaDB and AmazonAurora.
- DynamoDB is AWS’s NoSQL service.
Slide 31 – ElastiCache
- This is AWS’s fully managed caching service, either Memcached or Redis
Slide 32 – AWS Secret Manager
- Used to store secrets required by either the build process and/or for running the container.
- Can automatically rotate credentials for RDS.
Slide 33 – Application Load Balancer
- Used to connect inbound traffic to the Docker containers running in ECS.
- Terminates SSL traffic, so no need to manage SSLs on the containers.
Slide 34 – AWS Certificate Manager
- Used to manage SSL certificates used by the ALB.
- Can be either free certificates issued by Amazon or imported certificates from other providers.
Slide 35 – VPC
- A logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define.
- So, all the previously mentioned services (except Secret Manager and Certificate Manager) can be placed within a VPC, isolating it from anything else on AWS.
Slide 36 – Fargate
- ECS with Fargate is essentially the same, but you don’t have to manage the underlying EC2 instances.
- It gives you the container as a fundamental compute primitive.
- Priced based on vCPU and Memory, which can be configured independently.
- From 0.25 to 4 vCPU•From 0.5GB to 30GB Memory
Slide 39 – Summary
- ECS managers your containers on AWS
- Can be used with various other services to create a CD environment
- AWS has all the tools and services you need in one place.
The code for the example shown during the presentation that builds the image that was then deployed to ECS is available here:
I’ve also done a couple of other posts about topics in this presentation: