Amazon EC2 Container Service is a new AWS service that makes it easy to run and manage Docker-enabled applications across a cluster of Amazon EC2 instances. Amazon EC2 Container Service lets you define, schedule, and stop sets of containers. You have access to the state of your resources, making it easy to confirm that tasks are running or view the utilization of Amazon EC2 instances in your cluster. This session will describe the benefits of containers, introduce the Amazon EC2 Container Service, and demonstrate how to use Amazon EC2 Container Service for your applications. Speakers: Ian Massingham, AWS Technical Evangelist and Boyan Dimitrov, Platform Automation Lead, Hailo Cabs

1. ©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

2. Agenda
Containers
EC2 Container Service
Common patterns
Demo
Q&A

3. Containers

4. What are containers?
OS virtualization
Process isolation
Automation
ImagesServer
Guest OS
Bins/Libs Bins/Libs
App2App1

5. Container advantages
Portable
Server
Guest OS
Bins/Libs Bins/Libs
App2App1

6. Container advantages
Flexible
Server
Guest OS
Bins/Libs Bins/Libs
App2App1

7. Container advantages
Fast
Server
Guest OS
Bins/Libs Bins/Libs
App2App1

8. Container advantages
Efficient
Server
Guest OS
Bins/Libs Bins/Libs
App2App1

9. A container pipeline
IT Operations
Base
Image
PatchesUtilities

10. A container pipeline
IT Operations
Base
Image
PatchesUtilities
Ruby
Redis
Logger

11. A container pipeline
IT Operations Developer
Base
Image
PatchesUtilities
Ruby
Redis
Logger
App

12. A container pipeline
Base
Image
PatchesUtilities
Ruby
Redis
Logger
App
IT Operations Developer

13. Server
Guest OS
Bins/Libs Bins/Libs
App2App1

15. EC2 Container Service Benefits

16. Easily manage clusters for any scale
Nothing to run
Complete state
Control and monitoring
Scale

17. Flexible container placement
Applications
Batch jobs
Multiple schedulers

18. 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

19. Extensible
Comprehensive APIs
Open source agent
Custom schedulers

20. Common Patterns

21. Pattern 1: services and applications
Simple to model
Decompose to smaller (micro) services
Blue / green deployments

22. Pattern 2: batch jobs
Share pools of resources
APIs provide cluster state
Auto Scaling, Spot, Reserved Instances

23. EC2 Container Service terminology

24. Amazon EC2 instances
Docker daemon
Amazon ECS agent
Key components: container instances
https://github.com/aws/amazon-ecs-agent

25. Regional
Resource pool
Grouping of container instances
Start empty, dynamically scalable
Key components: clusters

26. Key components: task definitions
Volume Definitions
Container Definitions

27. Key components: task definitions
Shared Data Volume
PHP App Time of day App

28. 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

29. 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
}

30. {
"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

31. {
"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

32. Unit of work
Grouping of related containers
Run on container instances
Key components: tasks

33. Key components: run a task
Good for short-lived
containers, for
example batch jobs

34. Key components: create a service
Good for long-
running applications
and services

35. Microservices and elastic resource pools with
ECS
Boyan Dimitrov,
Platform Automation Lead @ Hailo
@nathariel

37. 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

38. 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

39. Service interactions – not as scary as it looks!
AWS Summits 2015

40. Service deployment at present
Main goals: Reliability, Ease of Use, Resource EfficiencyAWS 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

41. 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 GroupAuto Scaling Group

42. How hard is to deploy a service?
service name version
auto scaling group
AWS Summits 2015

43. 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

44. What about resource efficiency?
35%
Utilization
85%
Utilization
Auto Scaling Group A
Auto Scaling Group B
AZ eu-west-1a AZ eu-west-1cAZ eu-west-1b
instance instance instance instance instance instance
instance instance instance
Main goals: Reliability, Ease of Use, Resource EfficiencyAWS Summits 2015

45. 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!

46. 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

47. 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

48. 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

49. 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:

50. {
“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

51. t0
t1
X
Star6ng
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

52. Thanks!
@nathariel
boyan@hailocab.com
@HailoTech
facebook.com/HailoUK
Use Promo Code AWS10
for £10 off your ride home

53. LONDON