Container Orchestration with Amazon ECS
•
0 gostou•634 visualizações
by Jeremy Cowan, Solutions Architect, AWS
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Container Orchestration with Amazon ECS
Semelhante a Container Orchestration with Amazon ECS (20)
Mais de Amazon Web Services
Mais de Amazon Web Services (20)
Último
Último (20)
Container Orchestration with Amazon ECS
- 1. Jeremy Cowan AWS Solutions Architecture Container Orchestration with Amazon ECS & Blox March 7 2017
- 2. Server Guest OS Bins/Libs Bins/Libs App2App1 Getting Started Running Containers
- 3. Running Containers at Scale Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS
- 5. Cluster Management Engine Docker Task Container Instance Container Task Container Docker Task Container Instance Container Task Container Docker Task Container Instance Container Task Container AZ 1 AZ 2 Cluster Management Engine
- 6. Agent Communication Docker Task Container Instance Container ECS Agent Task Container Docker Task Container Instance Container ECS Agent Task Container Docker Task Container Instance Container ECS Agent Task Container AZ 1 AZ 2 Cluster Management Engine Agent Communication Service
- 7. Key/Value Store Docker Task Container Instance Container ECS Agent ELB Internet ELB Task Container Docker Task Container Instance Container ECS Agent Task Container Docker Task Container Instance Container ECS Agent Task Container AZ 1 AZ 2 Key/Value Store Cluster Management Engine Agent Communication Service
- 8. APIs Docker Task Container Instance Container ECS Agent ELB Internet ELB User / Scheduler API Cluster Management Engine Task Container Docker Task Container Instance Container ECS Agent Task Container Docker Task Container Instance Container ECS Agent Task Container AZ 1 AZ 2 Key/Value Store Agent Communication Service
- 9. Scheduling Docker Task Container Instance Container ECS Agent ELB Internet ELB User / Scheduler API Cluster Management Engine Task Container Docker Task Container Instance Container ECS Agent Task Container Docker Task Container Instance Container ECS Agent Task Container AZ 1 AZ 2 Key/Value Store Agent Communication Service
- 11. Amazon ECS: Under the Hood ALB ALB AZ 1 AZ 2 user / scheduler Scheduler Cluster State Service Placement Engine Event Stream
- 13. New Placement Constraints & Attributes Name Example AMI ID attribute:ecs.ami-id == ami-eca289fb Availability Zone attribute:ecs.availability-zone == us-east-1a Instance Type attribute:ecs.instance-type == t2.small Distinct Instances type=“distinctInstance” Custom attribute:stack == prod
- 14. Anatomy of Task Placement Cluster Constraints Custom Constraints Placement Strategies Apply Filter Satisfy CPU, memory, and port requirements Filter for location, instance-type, AMI, or custom attribute constraints Identify instances that meet spread or binpack placement strategy Select final container instances for placement
- 15. Supported Placement Strategies Binpacking Spread Affinity Distinct Instance
- 16. Placement Strategy Chaining Spread tasks across Zones and Binpack within each Zone
- 17. New Cluster Query Language
- 18. Filtering: Match on Instance Family or Type
- 19. Filtering: Match on Availability Zone
- 20. Filtering: Match on Multiple Expressions
- 21. Filtering: Match on Custom Attributes
- 23. g2.2xlarge t2.small g2.2xlarge g2.2xlarge Placement: Targeting Instance Type
- 24. g2.2xlarge t2.small t2.micro t2.medium t2.medium t2.small g2.2xlarge t2.small t2.small t2.medium us-east-1aus-east-1d Placement: Targeting Instance Type & Zone
- 25. g2.2xlarge t2.small t2.micro t2.medium t2.medium t2.small g2.2xlarge t2.small us-east-1aus-east-1d g2.2xlarge t2.medium t2.micro t2.small us-east-1c Placement: Availability Zone Spread
- 26. g2.2xlarge t2.small t2.micro t2.medium t2.medium t2.small g2.2xlarge t2.small us-east-1aus-east-1d g2.2xlarge t2.medium t2.micro t2.small us-east-1c Placement: Spread across Zone and Binpack
- 27. g2.2xlarge t2.small t2.micro t2.medium t2.medium t2.small g2.2xlarge t2.small us-east-1aus-east-1d g2.2xlarge t2.medium t2.micro t2.small us-east-1c Placement: Affinity and Anti-Affinity
- 29. t2.medium t2.small t2.small us-east-1aus-east-1d t2.medium t2.micro t2.small us-east-1c Placement: Multiple Services on a Cluster
- 30. t2.medium g2.2xlarge t2.micro t2.small t2.small t2.small g2.2xlarge t2.small t2.small t2.small g2.2xlarge t2.small Placement: Services – Distinct Instances
- 31. Console: Getting Started with Placement
- 32. Console: Placement Templates to Get Started
- 33. Console: Customizing Placement Strategies
- 34. Live Demo
- 35. Event Stream
- 37. Three Steps to Getting Started with Events Step 1: Create CWE Rule Step 2: Create SNS Topic Step 3: Put Events to SNS
- 38. Consuming Events for Service Discovery app1-tst 10.1.0.11 db1-tst 10.1.0.14 app2 10.1.0.16 db2 10.1.0.18 my-app 10.1.0.20 websrv1 10.1.0.1 websrv2 10.1.0.2 websrv3 10.1.0.4 app-dev1 10.1.0.9 app-dev2 10.1.0.5 app-dev3 10.1.0.8 db-dev 10.1.0.19
- 39. Introducing Blox
- 40. What is Blox? Choice Control Developer Experience
- 41. Building with Blox scheduler cluster state service
- 42. Set Up Blox Locally Step 1: git clone https://github.com/blox/blox.git Step 3: docker-compose up -d Step 4: start using Blox locally Step 2: deploy CloudFormation template to configure ECS event stream and SQS queue
- 43. Swagger Spec: Cluster State Service
- 44. Swagger Spec: Daemon Scheduler
- 45. Daemon Scheduler
- 46. t2.small t2.small t2.small Blox: Daemon Scheduler t2.small t2.small t2.small scheduler cluster state service t2.small t2.small t2.small
- 47. Step 1: Create an Environment
- 48. Step 2: Create a Deployment
- 49. Step 3: Add Container Instances
- 50. Step 4: Monitoring and Scaling a Cluster
- 51. The Blox Vision
- 52. Contributing to Blox • Blox is licensed under Apache 2.0 • Open an issue or pull request • Watch our roadmap on GitHub • Check out our Gitter channel
- 53. Thank you!
Notas do Editor
- This may look familiar, we have shared this architecture diagram publicly before. It shows the core components of Amazon ECS. Today I want to talk about two new core capabilities: Placement Engine and the ECS Event Stream. Followed by sharing with you some more details, our vision, and a demo of Blox. Let’s get started This illustrates how we’ve built ECS Agent defines how you interact with the scheduler During this session we’ll look at the new enhancements to the ECS placement engine and the event stream, And talk talk about further the extensibility you have with Blox
- Since its inception we’ve let you run a group containers based on constraints, based on CPU, memory, and ports Now we offer additional constraints including those based on custom attributes that you create
- Let’s look at a scenario where you had 10 container instances. To start you’ll make a request to run some tasks or create a service. As part of that request you’ll specify CPU, memory, or port requirements. In addition now, you’ll also provide other constraints, such as specific Availability Zone, AMI or insance-type. And then last you’ll tell us the strategy you prefer for us to use when starting the tasks, which could range from spread for availability, binpack to optimize for utilization, place together (affinity) or place apart (anti-affinity), etc. At the end of that process we have identified a set of instances that satisfies the requirements for the task you want to run and we place (or run) those tasks across your cluster based on the requirements specified.
- We’ll dive into each of these: There are 4 new strategies Binpacking where you try to run as many containers on an instance to optimize utilization Spread, which was previously was random, now gives you the ability to target specific availability zones for an application We also have support affinity and anti-affinity, where you can use tasks placement strategies to run them together or on separate instances
- Strategy training, you can chain placement strategies together, e.g. spread and binpacking.
- Here you can filter on an instance family or specific instance type. Useful for making placement decisions optimized for a specific set of resources. Matching on instance type, get as granular as you need to, e.g. anything in the t2 family or all on t2 smalls.
- Matches t2 and specific availability zone Matches t2.small, t2.medium specific instance types or g2* family and not in us-east-1d
- Also support for new custom attributes. Here is how to set a custom attribute and make placement decisions based on these. Show an example of setting a custom attribute, querying via list-container-instances, then running a task.
- Go through examples Targeting a g2 instance, use a custom attribute or you can do this by instance family When you run the task we’ll find the instance that meets the criteria and deploy that for you.
- Spread for availability and binpacking to optimize for cost
- Run them against the same cluster simultaneously Start placement constraint on task group to place on same server Backend not on the same instance as the web server
- aws ecs describ-service --cluster ecs-demo --name my-service Also part of the service definition
- Follow the same strategy as you scale in and scale out. Demo the core part of the scheduler
- Using distinct instances, when a g2 gets created we’ll place the task on that instance for you.
- All of this is available in the ECS console Create a placement template (custom) Also binpack, deploy across Azs or create your own
- No running tasks Start with place 6 tasks on g2 instances Refresh show that all are running on the g2s Second example Bin packing, start 5 tasks and running on a single instance Third example Spread across Azs and binpack in a zone Available in all regions where ECS is available Great extensibility on how you run containers on ECS
- Built it because customers wanted real-time notifications, could use list and describe APIs to create materialized views but it was challenging
- As a new start we send events to CWE, same goes for task stop. Then you can choose how to consume those events.
- Easy to get started, e.g. SNS, say all events from all clusters, to SNS or filter to be very specific Put your events to SNS topic
- Listen for event changes and update rt53 for service discovery, to update DNS resource record Add remove and update records
- Project we’re excited about collab with the community
- Blox is a collection of open source projects for container management and orchestration. Blox gives customers control and choice over how your containerized applications run on Amazon ECS. With Blox, you can build custom schedulers or easily integrate existing scheduler logic to manage production applications – while still leveraging the ECS cluster manager and integrating with AWS platform features for load balancing, auth, and auto-scaling. 1. Choice = can now choose to use built-in schedulers of Amazon ECS, to run applications using existing ECS APIs and placement engine, or to integrate existing 3rd party. 2. Control = all of the code is open sourced and we have provided reference architectures so that customers can see a model on how leverage the ECS cluster state. This is a customer run open source project. We have had great discussions around the future of this project with customer partners like Netflix and Yelp and we invite the entire community to help decide the roadmap and what we should build. 3. Developer Experience = we will continue to invest in end to end tooling that makes it easy for customers to build, test, and run applications on Amazon ECS. One example is the ecs-cli and our vision is to continue to build tooling that our customers tell us useful and necessary to test locally and deploy predictably on Amazon ECS.
- Start with a high-level overview where Blox fits with Amazon ECS and other features we’ve discussed today. Setup CW events to send task and container instance state changes from ECS to CWE. With Blox we configure an SQS queue to store state transition messages. The Blox cluster state service reads events from the queue and stores them in a local db. Why did we build the cluster state service? Consume Event Stream Persist State Locally Handle State Reconciliation Rather than polling, now can respond in real-time to task / instance state changes across your ECS clusters
- The CloudFormation template sets up the ECS event stream and SQS queue. Simple to get started, go to github page and clone the repo CFN template that will setup the SNS queue, it will set up the containers
- Get instance and task information and filter based off clusters.
- Create an environment and deployment Will taget cluster, ensure 1 tasks is running on there, guarantee that task will be started on instances that join the cluster
- If you had a cluster of 3 instances, create env and deployment, see events in the event stream and start the containers on the cluster
- Here’s what it looks like, create an env (includes demo cli) as you look at the swagger spec, do calls against the REST API Create env, Specify the task def you want to run on your instances, as you scale up place a task on each new node.
- See it running in the console
- Provide an open and transparent roadmap to the tools that we are building to enable customers to run applications on Amazon ECS. Focus on tooling that enable extensibility and end to end testing of applications. Continue to add features that enable customers to use their scheduling frameworks of choice (ex Mesos) – while also leveraging the managed schedulers, task placement capabilities, and cluster management of Amazon ECS. Hear from the customer what’s important to help us make decisions around features, roadmap, and prioritization.