Tech connect aws
•Download as PPTX, PDF•
0 likes•254 views
This document provides an overview of Amazon EC2 Container Service (ECS), which allows users to easily run and manage Docker containers on a cluster of Amazon EC2 instances. It discusses key concepts like clusters, tasks, services, container definitions and scheduling. It also provides examples of common usage patterns like running batch jobs or microservices, and how to update services deployed on ECS.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (10)
Similar to Tech connect aws
Similar to Tech connect aws (20)
Recently uploaded
Recently uploaded (20)
Tech connect aws
- 1. ©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved Amazon EC2 Container Service Brandon Chavis Solutions Architect, AWS
- 2. Agenda • Introduction to Containers • Amazon EC2 Container Service • Extending ECS • Conclusion
- 3. About me • Solutions Architect • With AWS since October 2012 • Sysadmin heritage
- 4. About Amazon Web Services • Agility • Cost savings • Elasticity • Breadth of functionality • Global reach
- 5. What are containers? • OS virtualization • Process isolation • Images • AutomationServer Guest OS Bins/Libs Bins/Libs App2App1
- 6. Container advantages Portable Server Guest OS Bins/Libs Bins/Libs App2App1
- 7. Container advantages Flexible Server Guest OS Bins/Libs Bins/Libs App2App1
- 8. Container advantages Fast Server Guest OS Bins/Libs Bins/Libs App2App1
- 9. Container advantages Efficient Server Guest OS Bins/Libs Bins/Libs App2App1
- 10. A container pipeline Base image Patches IT Operations Utilities
- 11. A container pipeline Base image Patches IT Operations Ruby Redis Logger Utilities
- 12. A container pipeline Base image Patches IT Operations Developer Ruby Redis Logger Utilities App
- 13. A container pipeline Base image Patches IT Operations Developer Ruby Redis Logger Utilities App
- 16. Amazon EC2 Container Service
- 17. Easily Manage Clusters for Any Scale • Nothing to run • Complete state • Control and monitoring • Scale
- 18. Flexible Container Placement • Applications • Batch jobs • Multiple schedulers
- 19. Designed for use with other AWS services • Elastic Load Balancing • Elastic Block Store • Virtual Private Cloud • Identity and Access Management • CloudTrail
- 20. Extensible • Comprehensive APIs • Open source agent • Custom schedulers
- 21. Common Patterns / Customer feedback
- 22. Pattern 1: Services and applications • Simple to model • Micro services • Blue / green deployments Phong Nguyen, Founder at Gilt Groupe, said, "As we Dockerize all our services, it is very important for us to have a platform that can help us speed up deployments, automate our services, and gain greater efficiencies. The new service scheduler and ELB integration make Amazon ECS an excellent platform for our services.”
- 23. Pattern 2: Batch jobs • Share resource pools • Ideal for “bursty” jobs • Spot instances “We required a solution on which we could securely and efficiently deploy Docker containers to encapsulate learner programming assignment submissions,” said Brennan Saeta, Architect at Coursera. “We are using Amazon EC2 Container Service to power our new programming assignments infrastructure for next-generation On-Demand course platform.”
- 24. EC2 Container Service Terminology
- 25. Amazon EC2 instances Docker daemon Amazon ECS agent Key Components: Container Instances
- 26. Regional Resource pool Grouping of Container Instances Start empty, dynamically scalable Key Components: Clusters
- 27. Key Components: Task Definitions Volume definitions Container definitions
- 28. Key Components: Task Definitions 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": "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 }, 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 execute
- 32. Key Components: Tasks Container Instance Schedule Shared data volume PHP App Time of day App
- 33. Unit of work Grouping of related Containers Run on Container Instances Key Components: Tasks
- 34. Key Components: Run a task Good for short-lived containers, e.g. batch jobs
- 35. Key Components: Create a Service Good for long- running applications and services
- 36. Key Components: Create Service • Load Balance traffic across containers • Automatically recover unhealthy containers • Discover services Elastic Load Balancing
- 37. Key Components: Update Service • Scale out • Scale in Elastic Load Balancing
- 38. Key Components: Update Service • Deploy new version • Drain connections Elastic Load Balancing
- 39. Key Components: Update Service • Deploy new version • Drain connections Elastic Load Balancing
- 40. Key Components: Update Service • Deploy new version • Drain connections Elastic Load Balancing
- 41. Next steps • Learn more about AWS – Speak to a Solutions Architect – Visit aws.amazon.com • Learn more about ECS – Read the documentation – Find even cooler ECS demos and blog posts • Set up a build pipeline with Jenkins and Amazon ECS • Automatically scale your service using CloudWatch and Lambda • Explore our training options
Editor's Notes
- a lot of content, only ½ hour and respectful to the next speaker so I can take your questions off-stage after the presentations
- My goal is to remove technology hurdles that customers might have in adopting AWS solutions as well as guide them along the way Not here to sell you AWS. Giving you the context to one of our services
- On-demand delivery of Information Technology resources via the internet with a pay-as-you-go pricing Thousands of servers in minutes, experiment and innovate, fail? deprovision Capital expense variable No need to over provision for peak activity, scale up or down with need More than 40 services (Compute, storage, networking, database, analytics, application services, deployment management and mobile), constantly innovating and making it available to all instantly 11 regions, 30 Availability Zones, 53 edge locations
- Containers are similar to hardware virtualization (like EC2), however instead of partitioning a machine, containers isolate the processes running on a single operating system This is a useful concept that lets you use the OS kernel to create multiple isolated user space processes that can have constraints on them like cpu & memory. The Docker CLI (over libcontainer) makes using containers easy, with intuitive commands like docker run, to start a container, or docker ps, to look at running containers Docker images make it easy to define what runs in a container and versions the entire app These concepts enable container automation – you can define your app, build & share the image, and deploy that image.
- You may be thinking – this sounds interesting but why would I want to use containers? There are 4 key benefits to using containers. The first is that containers are portable. the image is consistent and immutable -- no matter where I run it, or when I start it, it’s the same. This makes the dev lifecycle simpler –an image works the same on the developer’s desktop & prod, whether I start it today or scale my environment tomorrow, so there’s no surprises. The entire Application is self-contained -- The image is the version, which makes deployments and scaling easier because the image includes the dependencies. * Small, usually 10s MB for the image, very sharable
- Containers are flexible. You can create clean, reproducible, and modular environments. Whereas in the past multiple processes would be on the same OS (e.g. Ruby, caching, log pushing), now containers enable the concept of microservices Microservices encourage the decomposition of an app into smaller chunks, reducing complexity & letting teams move faster while still running the processes on the same host, This streamlines code deployment and infrastructure management- e.g. no library conflicts between multiple components of an application Process isolation – can decompose apps into whatever form makes the most sense git-like tools
- simply stating that Docker images start fast sells the technology short as speed is apparent in both performance characteristics and in application lifecycle and deployment benefits So yes, containers start quickly because the operating system is already running, but Every container can be a single threaded dev stream; less interdependencies Also ops benefits - Example: if your ops team updates the base image, you can simply build on top of this new image by editing your docker file to point at the new image for your next docker build– I can just focus on my app, meaning it’s faster for me to build & release. Developer productivity Environment fidelity == easier to test in different environments Isolate components == updates are easier, no library conflicts e.g. Container becomes unit of work Operational efficiency Version control & blue/green deployments == reduce rollout risk Known good images w/ patches, etc. == improve security Ops authored containers for common patterns such as logging == less work
- Finally, containers are efficient. You can allocate exactly the resources you want – specific cpu, ram, interfaces; there’s generally very little performance overhead as well Since it shares the same OS kernel & libs, containers use less resources than running the same processes on different virtual machines (different way to get isolation)
- How would you use containers in a deployment pipeline? Ops can create certified base images with all the necessary patches and utilities
- These base images can then be used to create utility containers, e.g. logging, Ruby, MySql, etc.
- Then Devs use these containers on laptops to build in their source code They do this by creating a container image using a manifest (called a dockerfile) that can be versioned and shared
- You can then customize that image at runtime using environment variables, or interactively if you wish e.g. dev/test enviroments
- When we talked to customers they told us they were very excited about Docker
- What we heard was that they wanted a solution for running containers at scale Now you’re suddenly managing a cluster & cluster management is hard. You need a way to intelligently place your containers on the hosts that have the resources and that means you need to know the state of everything in your system. For example… what instances have available resources like memory and ports? How do I know if a container dies? How do I hook into other resources like ELB? Can I extend whatever system that I use, e.g. CD pipeline, third party schedulers, etc. Do I need to operate another piece of software? These are the questions we wanted to answer with Amazon ECS
- Definition: Amazon EC2 Container Service (ECS) is a highly scalable, high performance container management service that supports Docker containers and allows you to easily run applications on a managed cluster of Amazon EC2 instances. 4 key advantages
- Running modern distributed applications on a cluster requires two key components - reliable state management and flexible scheduling. These are challenging problems. Amazon ECS handles the complexity of cluster and container management so you don’t have to install and operate your own cluster management infrastructure. At Amazon, we have built a number of core distributed systems primitives to support our needs. Amazon ECS is built on top of one of these primitives. We then expose this state management behind a simple set of APIs that give the details about all the instances in your cluster, and all the containers running on those instances. Amazon ECS APIs respond quickly whether you have a cluster with one instance and a few containers, or a dynamic cluster with 100s of instances and 1000s of containers. Eliminates cluster management software Manages cluster state Manages containers Control and monitoring Scale from one to tens of thousands of containers Make good placement decisions Availability of resources New resources can be added to the cluster with EC2 auto scaling
- Shared state, optimistic concurrency system So what is a scheduler? A scheduler understands the needs of the system – that is, the work that needs to be done such as starting a container that needs 200 MB RAM and port 80, and looks to efficiently satisfy them. It then submits a request to the cluster state manager requesting a resource. Since ECS provides optimistic concurrency control, other schedulers could be operating at the same time, so the cluster management will confirm that the resource is available and commit it to the scheduler. The scheduler can listen for events from the cluster manager and take action, such as maintaining the availability of your applications… It can also interact with other resources, like ELBs. Amazon ECS has two schedulers to help find the optimal instance placement based on your resource needs, isolation policies, and availability requirements: create service, run task. And ECS provides you complete cluster state information allowing you to integrate your own custom scheduler as well as open source schedulers. Shared state, optimistic concurrency system
- Amazon ECS is built to work with the AWS services you value. You can set up each cluster in its own Virtual Private Cloud and use security groups to control network access to your ec2 instances. You can store persistent information using EBS and you can route traffic to containers using ELB. CloudTrail integration captures every API access for security analysis, resource change tracking, and compliance auditing
- Complete visibility and control into your AWS resources --- Amazon ECS can easily be integrated or extended through a simple set of APIs. ECS provides complete visibility and control into your AWS resources, so you can easily integrate and use your own container scheduler or connect ECS into your existing software delivery process (e.g., continuous integration and delivery systems) – today we launched a blog that describes how to create a CD process using Jenkins to create Docker images and deploy those images to ECS, Our container agent is open source and available on GitHub. We look forward to hearing your input and pull requests.
- I gave you good reasons to use ECS but you do not have to. You can easily build you own Docker cluster on Amazon ECS
- One pattern is using ECS for long running applications and services. Docker is natural for this pattern. It supports Any app, any language You define everything that is contained in the Image using a Dockerfile -- a complete manifest of the image – no more “oops, I made a tweak that I forgot to document” Image then becomes a versioned artifact that can be stored in a repository just like your source code. Store & ship Docker images Test & deploy the same artifacts Decompose to microservices to Decouple deployments & Reduce conflicts Containers also simplify deployment -- Stateless servers are natural with Docker and each deployment is a new set of containers This Decreases risk of change – rollback is simple Describe blue/green deployment process
- With Spot Instances, you can save up to 90% by bidding on spare Amazon EC2 instances Coursera, Brennan Saeta, security, efficiency The next pattern is batch jobs. Instead of a dedicated pool of resources for each job, now can use a shared pool for multiple jobs to increase efficiency, especially for short-lived and bursty processes. For example, Coursera is using ECS to handle automatic grading of programming assignments. Those assignments come in and are placed onto the cluster. They run in a container which can then be disposed of and the instance immediately reused by another container. The compute resources – your ec2 instances – can use auto scaling, spot, and reserved instances to give you the resource mix you prefer.
- Let’s go through the core components of ECS.
- Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. --- They’re EC2 instances that have been checked into a cluster. You own them, SSH in, poke around, see how it works under the hood. We use Docker, through the remote API on the local socket. It’s the Docker you’re used to, just in the cloud. Finally, our agent processes ECS commands and turns them into Docker commands. It’s all open source on Github, and we’d love to see you involved – pull requests. We develop in the open now that we’ve launched.
- A cluster is a collection of resources – primarily instances and containers. Multiple Azs in your cluster, it’s just a big bucket of resources. Cpu, memory, etc. Dynamically scalable. Possible to have a 1 instance cluster, and then a 100 or even 1000 instance cluster. Segment for particular purposes, e.g. dev/test
- You can model your app using Task Definitions that define the containers you want to run together. A task definition also lets you specify Docker concepts like links to establish network channels between the containers and the volumes your containers need. Task definitions are tracked by name and revision, just like source code
- Our demo uses 2 containers. In addition to the PHP app I demoed earlier, I have a time of day app that will interface with my PHP app over a shared volume. The time of day app writes the time every second, and the PHP app reads & displays the file.
- JSON: Not yml but similar to fig or Docker Compose Here’s what a task definition looks like. -Family to group versions together as container definitions change, versioned, easy to see how your application evolves. -Keeping with previous example
- You can specify resources like CPU and memory, ports and volumes for each container. You can specify what command to run when the container starts. And the essential flag specifies whether the task should fail if the container stops running.
- You can also specify the Docker image to use for the container
- Then schedule the Task Definition onto an instance with available resources
- Maybe nginx in front of rails, or redis behind rails. --- A task is an instantiation of a task definition. You can have a task with just 1 container…or up to 10 that work together on a single machine. Run tasks on container instances, as many as will fit. Often people wonder about cross host links, those don’t go in your task, put them behind an ELB, or a discovery system and make multiple tasks.
- ECS has two APIs for scheduling. Run task looks at the first 100 instances in a cluster, and randomly places tasks in a spot that’ll fit. It is good for short-lived containers like batch jobs.
- The second scheduler is the service scheduler. This is good for long-running applications. You reference a task definition and count and optionally an ELB
- ECS takes care of the cluster management for you It is flexible, designed to work with AWS and extensible