Amazon EC2 Container Service: Manage Docker-Enabled Apps in EC2

Agenda Containers EC2 Container Service Common patterns Demo Q&A

Containers

What are containers? App1 App2 Bins/Libs Bins/Libs Guest OS Server OS virtualization Process isolation Automation Images

Container advantages App1 App2 Bins/Libs Guest OS Bins/Libs Portable Server

Container advantages App1 App2 Bins/Libs Guest OS Bins/Libs Flexible Server

Container advantages App1 App2 Bins/Libs Guest OS Bins/Libs Fast Server

Container advantages App1 App2 Bins/Libs Guest OS Bins/Libs Efficient Server

A container pipeline IT Operations Utilities Patches Base Image

A container pipeline IT Operations Ruby Utilities Patches Base Image Redis Logger

A container pipeline IT Operations Developer Ruby App Utilities Patches Base Image Redis Logger

App1 Bins/Libs App2 Bins/Libs Guest OS Server

EC2 Container Service Benefits

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

Flexible container placement Applications Batch jobs Multiple schedulers

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

Extensible Comprehensive APIs Open source agent Custom schedulers

Common Patterns

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

EC2 Container Service terminology

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

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

Key components: task definitions Volume Definitions Container Definitions

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

Key components: task definitions Shared Data Volume PHP App Time of day App Shared Data Volume Schedule PHP App Time of day App Container Instance

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/myvol" }, } ], "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 }

Key components: task definitions { "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/myvol" }, } ], "entrypoint": [ "/usr/sbin/apache2", "-D", "FOREGROUND" ], "essential": true [ ] { } "image": "mysql", "name": "db", "cpu": 500 megabytes 10, of memory "memory": 500, "essential": true, Expose port 80 in container "entrypoint": [ to "/entrypoint.sh" port 80 on host ], "environment": [ { Create "name": and "MYSQL_ROOT_PASSWORD", mount volumes "value": "pass" } ], "portmappings": [] 10 CPU units (1024 is full CPU), Essential to our task

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 { "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: tasks Unit of work Grouping of related containers Run on container instances

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

Key components: create a service Good for longrunning applications and services

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

Microservices intro Monolith App 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 Service A Service C Service B Service D Service E Each service (at Hailo) gets for free: Discovery Configuration A/B testing capabilities Monitoring & Instrumentation and much more AWS Summits 2015

What do we have 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 AWS Summits 2015

Service interactions not as scary as it looks! AWS Summits 2015

Service deployment at present 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 AWS Summits 2015 Main goals: Reliability, Ease of Use, Resource Efficiency

Deployment overview and our journey towards containers CI Pipeline Amazon S3 Process Container Docker Registry Auto Scaling Group Provisioning Service Provisioning Service Auto Scaling Group Instance Instance Provisioning Manager

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

Is this good enough? service name version As a developer: How do I figure this one out? Would my service live there forever? What if my team owns 20+ services? auto scaling group AWS Summits 2015 Main goals: Reliability, Ease of Use, Resource Efficiency

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

Challenges 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! AWS Summits 2015

So what do we want? 75-80% Utilization instance instance instance instance instance instance Elastic resource pool eu-west-1a eu-west-1b eu-west-1c One word such difference! Main goals: Reliability, Ease of Use, Resource Efficiency

Our solution cluster management on top of an elastic resource pool QoS Scheduler Cloud Provider AWS Cluster Manager ECS ECS Agent ECS Agent ECS Agent ECS Agent ECS Agent ECS Agent instance instance instance instance instance instance Elastic Resource Pool eu-west-1a eu-west-1b eu-west-1c

Why ECS? 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 AWS Summits 2015

Why building our own scheduler? We want a cloud-native scheduler that is aware of the cloud specifics and our microservices ecosystem: 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 AWS Summits 2015

Take Service Priority as an example { service : Foo mincpu": 10, minmemory": 500, mininstances : 3, Priority : Default } { service : Baz mincpu": 50, minmemory": 1500, mininstances : 3, Priority : Critical } AWS Summits 2015

Service criticality matters when resources are constrained t0 t1 instance instance instance X instance instance instance t2 instance instance Star6ng instance t3 AWS Summits 2015 instance instance instance

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

LONDON