Download - Amazon ECS
©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved
Amazon EC2 Container Service: Manage Docker-Enabled Apps in EC2
Ian Massingham AWS Technical Evangelist
@IanMmmm
What are containers?
OS virtualization
Process isolation
Automation
Images Server
Guest OS
Bins/Libs Bins/Libs
App2 App1
Designed for use with other AWS services
Elastic Load Balancing Amazon Elastic Block Store
Amazon Virtual Private Cloud AWS Identity and Access Management
AWS CloudTrail
Pattern 1: services and applications
Simple to model
Decompose to smaller (micro) services
Blue / green deployments
Pattern 2: batch jobs
Share pools of resources
APIs provide cluster state
Auto Scaling, Spot, Reserved Instances
Amazon EC2 instances
Docker daemon
Amazon ECS agent
Key components: container instances
https://github.com/aws/amazon-ecs-agent
Regional
Resource pool
Grouping of container instances
Start empty, dynamically scalable
Key components: clusters
Key components: task definitions
Container Instance
Schedule
Shared Data Volume
PHP App Time of day App
Shared Data Volume
PHP App
Time of day App
Key components: task definitions { "environment": [], "name": "simple-demo", "image": "my-demo", "cpu": 10, "memory": 500, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "mountPoints": [ { "sourceVolume": "my-vol", "containerPath": "/var/www/my-vol" } ], "entryPoint": [ "/usr/sbin/apache2", "-D", "FOREGROUND" ], "essential": true },
{ "name": "busybox", "image": "busybox", "cpu": 10, "memory": 500, "volumesFrom": [ { "sourceContainer": "simple-demo" } ], "entryPoint": [ "sh", "-c" ], "command": [ "/bin/sh -c \"while true; do /bin/date > /var/www/my-vol/date; sleep 1; done\"" ], "essential": false }
{ "environment": [], "name": "simple-demo", "image": "amazon/amazon-ecs-sample", "cpu": 10, "memory": 500, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "mountPoints": [ { "sourceVolume": "my-vol", "containerPath": "/var/www/my-vol" } ], "entryPoint": [ "/usr/sbin/apache2", "-D", "FOREGROUND" ], "essential": true },
Key components: task definitions [ { "image": "mysql", "name": "db", "cpu": 10, "memory": 500, "essential": true, "entryPoint": [ "/entrypoint.sh" ], "environment": [ { "name": "MYSQL_ROOT_PASSWORD", "value": "pass" } ], "portMappings": [] }]
Essential to our task
Create and mount volumes
Expose port 80 in container to port 80 on host
10 CPU units (1024 is full CPU), 500 megabytes of memory
{ "name": "busybox", "image": "busybox", "cpu": 10, "memory": 500, "volumesFrom": [ { "sourceContainer": "simple-demo" } ], "entryPoint": [ "sh", "-c" ], "command": [ "/bin/sh -c \"while true; do /bin/date > /var/www/my-vol/date; sleep 1; done\"" ], "essential": false }
Key components: task definitions [ { "image": "tutum/wordpress-stackable", "name": "wordpress", "cpu": 10, "memory": 500, "essential": true, "links": [ "db" ], "entryPoint": [ "/bin/sh", "-c" ], "environment": [ … ], "portMappings": [ { "containerPort": 80, "hostPort": 80 } ] }, ]
From Docker Hub
Mount volume from other container
Command to exec
Microservices and elastic resource pools with ECS
Boyan Dimitrov, Platform Automation Lead @ Hailo @nathariel
Microservices intro
• Discovery • Configuration • A/B testing capabilities • Monitoring & Instrumentation • … and much more
Each service (at Hailo) gets for free:
Service B
Service A
Service C
Service E
Service D
Small, self-contained units of execution with well defined API Built around business capabilities or domain objects Responsible for one thing and one thing only Fully automated lifecycle
AWS Summits 2015
Monolith App
What do we have
AWS Summits 2015
• Microservices ecosystem based on Go
• Designed specifically for the cloud – different building blocks and components will constantly be in flux, broken or unavailable
• 1000+ AWS instances spanning multiple regions
• 200+ services in production
Service deployment at present
Main goals: Reliability, Ease of Use, Resource Efficiency
AWS Summits 2015
• Each service is decoupled from the rest and deployed individually
• We run multiple services on the same instance
• We rely on auto scaling groups for organizing and scaling our workload
• We use static partitioning to match a service to an auto scaling group
• An automated deployment system takes care of all service lifecycle details
Provisioning Service
Provisioning Service
CI Pipeline
Amazon S3
Provisioning Manager
Provisioning Service
Docker Registry
Deployment overview and our journey towards containers
Instance Instance
Process Container
Auto Scaling Group Auto Scaling Group
Is this good enough?
Main goals: Reliability, Ease of Use, Resource Efficiency
service name version
auto scaling group How do I figure this one out? Would my service live there forever? What if my team owns 20+ services ?
As a developer:
AWS Summits 2015
Provisioning Service
What about resource efficiency?
35% Utilization
85% Utilization
Auto Scaling Group A
Auto Scaling Group B
AZ eu-west-1a AZ eu-west-1c AZ eu-west-1b
instance instance instance instance instance instance
instance instance instance
Main goals: Reliability, Ease of Use, Resource Efficiency
AWS Summits 2015
Challenges
AWS Summits 2015
• Our overall utilization across the services auto scaling groups is between 25% and 50%
• Performance of individual services is way more complex than simple CPU and memory calculations. Accumulated interference on the instance needs to be accounted for
• Static partitioning of services is hard and non scalable
• Our developers should not care about service placement or infrastructure specifics!
So what do we want?
Elastic resource pool
75-80% Utilization
eu-west-1a eu-west-1b eu-west-1c
One word – such difference! Main goals: Reliability, Ease of Use, Resource Efficiency
instance instance instance instance instance instance
Our solution – cluster management on top of an elastic resource pool
Elastic Resource Pool
ECS Agent ECS Agent ECS Agent ECS Agent ECS Agent ECS Agent
QoS Scheduler
eu-west-1a eu-west-1b eu-west-1c
AWS Cloud Provider
ECS Cluster Manager
instance instance instance instance instance instance
Why ECS?
AWS Summits 2015
• It is a managed service!
• It is great for storing and enforcing task state
• Designed with custom schedulers in mind
• The agent code is available on a public GitHub repo and … it is in GO!
• Easy to integrate with other AWS services
Why building our own scheduler?
AWS Summits 2015
• Service Priority
• Service specific runtime metrics
• Interference
• Cloud awareness ( availability zones, pool elasticity…)
Running services in a pay as you go fashion will soon be a reality as much as todays on demand compute
We want a cloud-native scheduler that is aware of the cloud specifics and our microservices ecosystem:
{ “service”: “Foo” ”minCPU": 10, ”minMemory": 500, “minInstances”: 3, “Priority”: “Default”}
{ “service”: “Baz” ”minCPU": 50, ”minMemory": 1500, “minInstances”: 3, “Priority”: “Critical”}
Take Service Priority as an example
AWS Summits 2015
t0
t1 XStar6ng t2
Service criticality ma#ers when resources are constrained
AWS Summits 2015
instance instance instance
instance instance instance
instance instance instance
instance instance instance
t3
Thanks!
@nathariel [email protected]
@HailoTech facebook.com/HailoUK
Use Promo Code AWS10 for £10 off your ride home