This document provides an overview of using Amazon EC2 Container Service (ECS) to build and scale containerized microservices. It discusses microservices concepts, introduces ECS as a container management system, outlines some ECS best practices around version control, load balancing, resource usage, and alerts. It also describes how to use the AWS CLI to automate container lifecycles on ECS including creating clusters, registering tasks, deploying services, scaling, and deleting resources.
4. What are microservices?
“Service-oriented architecture
composed of
loosely coupled elements
that have
bounded contexts”
Adrian Cockcroft (VP of Cloud
Architecture @ AWS, former Cloud
Architect at Netflix)
5. A few microservices best practices
• Rely on the public API
• Use the right tool for the job
• Secure your services
• Be a good microservices citizen
• Account for organizational changes
• Automation over everything
@abbyfuller
7. Amazon EC2 Container Service (ECS)
Highly scalable, high performance
container management system.
Eliminates the need to install,
operate, and scale your own
container management
infrastructure.
@abbyfuller
8. Amazon EC2 Container Service (ECS)
ECS provides a managed platform for:
Container
orchestration
Deep AWS
integration
Cluster
management
9. How does ECS map to traditional workloads?
Instances: standard EC2 boxes. Once
registered to a Cluster, your Tasks run here
Services: layer that manages and places
Tasks
Tasks: container wrapper and configuration
around processes running on the instance
@abbyfuller
11. Why ECS?
Bottom line: containers and
microservices can require a lot of
orchestration and moving pieces.
ECS removes a lot of this heavy
lifting.
@abbyfuller
13. Some ECS-specific best practices
• Version control your TaskDefinitions, and link back to a specific
commit
• ALB vs ELB
• Cattle, not pets
• Maximize your cluster resources
• Alert, alert, alert
Customize where you need to, and rely on ECS for a sensible baseline.
@abbyfuller
14. Version control is your friend
• Version control wherever possible
• Container images:
web_app:latest
web_app:dev
web_app:87gbTg4576fdeds6a34c
Better yet: tie those back to a build from a CI/CD system
@abbyfuller
15. ALB vs ELB
• Highly recommend ALB for ECS:
• Dynamic port mapping
• More efficient use of of resources for microservices- one ALB vs many ELBs
• Route based on anything (path and IP based routing)
• Enhanced Cloudwatch and access logs
@abbyfuller
16. Cattle not pets
• Cluster servers should be redundant and replaceable
• Don’t plan on anything sticking around
• Limit configuration to the containers themselves, where possible
(some exceptions!)
• If it’s important, or stateful, like logs or data, send it somewhere else
@abbyfuller
17. Maximize your resources
• Utilize TaskPlacement Policies
• Set sensible resource usage limits
• Set Cluster and Service scaling policies- don’t let resources sit idle!
@abbyfuller
18. Alert, alert, alert
• Alert where sensible
• Let Services and Cluster scale, but add checks
• Parse logs and alerts to minimize issues and noise
• Take advantage of built-in AWS tools
• aws-logs driver
• Cloudwatch
@abbyfuller
20. Flexibility is about choices
Orchestration platforms should have:
• Sensible defaults
• The ability to extend and customize
Pick one, or a combination of both.
@abbyfuller
21. Ok, so how can we support flexibility?
A couple of features:
• Task Placement Policies
• Amazon ECS Event Stream for Cloudwatch Events
• Autoscaling at service and cluster level
• Choices! Bring and register your own AMI to ECS
@abbyfuller
23. Spoiler alert: I like the console
Why the console?
• JSON
• Quicker to test and get started
• Visual feedback
• JSON
@abbyfuller
24. But the console is not for everyone
If you’re customizing or automating, the CLI might be a better
choice.
Enter clis:
• ecs-cli: open source, takes Docker Compose files
• aws-cli: standard, shared aws-cli with support for ECS
I <3 CLIs
You can use either CLI to
manage container lifecycle
events!
@abbyfuller
27. Then, create a task
$ aws ecs register-task-definition --cli-input-json
file://path/meetup.json
You can also use a JSON string:
$ aws ecs register-task-definition --family summit --
container-definitions
"[{"name":”meetup","image":”alpine","cpu":10,
"command":["sleep","360"],"memory":10,"essential
":true}]"
@abbyfuller
28. Next, use our task to create a service
$ aws ecs create-service --service-name meetup -task-
definition meetup --desired-count 2
You can add more parameters here, such as placement strategy. You
can also register your new service with an ELB/ALB.
@abbyfuller
29. Meetups are pretty popular. Let’s scale up.
$ aws ecs update-service --service meetup--desired-
count 4
We could use this same command to scale down (which we’ll look at
next), but also to update the task definition. Effectively, deploy a new
version!
@abbyfuller
30. We don’t want to waste resources though, so
let’s scale back down
$ aws ecs update-service --service meetup --desired-
count 2
In a production environment, this is something we might want to
handle in response to other events: autoscaling!
@abbyfuller
31. We can also query state
$ aws ecs describe-services --service meetup
This returns A TON of information about our service: most importantly,
it shows us our current deployment, and what events are happening in
our cluster:
"events": [
{
"message": "(service meetup) has
reached a steady state."
@abbyfuller
32. Bye London!
$ aws ecs delete-cluster --cluster meetup
Important to note that we have to scale our service down to 0, and
remove the service before running this: just in case!
$ aws ecs update-service --service meetup --desired-
count 0
$ aws ecs delete-service --service meetup
@abbyfuller
33. Some ECS resources
• AWS docs: https://aws.amazon.com/ecs/
• ECS first run wizard:
https://console.aws.amazon.com/ecs/home?region=us-east-1
• Nathan Peck’s ECS repo: https://github.com/nathanpeck/awesome-
ecs
• More talks of mine: https://aws.amazon.com/evangelists/abby-fuller/
• ECS ”Getting Started” workshop: https://www.github.com/abby-
fuller/ecs-demo
@abbyfuller