Deep Dive with Amazon EC2 Container Service Hands-on Workshop
•
5 gefällt mir•1,436 views
This is an advanced workshop for Amazon ECS. In this workshop you will learn: How to provision your Amazon ECS with CloudFormation Amazon ECS with Windows Container Amazon ECS CI/CD Amazon ECS service autoscaling and host autoscaling design pattern and best practices Amazon ECS log consolidation design patterns Secure credential management with IAM and EC2 Parameter Store Amazon ECS Events and design patterns Service Discovery with fully-managed etcd3 cluster on Amazon ECS
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Deep Dive with Amazon EC2 Container Service Hands-on Workshop
Ähnlich wie Deep Dive with Amazon EC2 Container Service Hands-on Workshop (20)
Mehr von Amazon Web Services
Mehr von Amazon Web Services (20)
Deep Dive with Amazon EC2 Container Service Hands-on Workshop
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Pahud Hsieh(謝洪恩), Solutions Architect Aug 01, 2017 Hong Kong Amazon ECS Advanced Workshop
- 2. What to Expect from the Workshop • Introduction to ECS • Lab1 Getting Started with ECS and CloudFormation • Lab2 ECS Windows Container • Lab3 ECS CI/CD • Lab4 ECS service autoscaling and host autoscaling • Lab5 Log consolidation
- 3. What to Expect from the Workshop • Lab6 ECS Events • Lab7 Spot Fleet support • Lab8 host scale in with container draining • Lab9 credentials management • Lab10 ECS Service with external and internal ALB • Lab11 service discovery with etcd3 • Q & A
- 4. Prerequisite • AWS Account (personal preferred) • IAM User with AdministratorAccess policy
- 5. Amazon ECS: Under the Hood
- 6. Amazon ECS: Under the Hood ALB ALB AZ 1 AZ 2 user / scheduler Scheduler Cluster State Service Placement Engine Event Stream
- 8. Lab1 – ECS with CloudFormation
- 9. Lab2 – ECS with Windows Container
- 10. Lab3 – ECS CI/CD
- 14. Amazon EC2 Container Service (ECS) EC2 INSTANCES ECS AGENT ECS AGENT Amazon ECS ECS AGENT DEPLOYMENT AUTOMATION
- 15. Deployment – In Place – Doubling Availability Zone Availability Zone Scenario Service’s task definition is updated to a new revision with parameters: Desired Count = 2 Minimum Healthy Percent = 100% Maximum Percent = 200% These settings permit the service to grow to double its desired size during deployment EXISTING EXISTING
- 16. Deployment – In Place – Doubling Availability Zone Availability Zone Two new tasks are started growing the number of tasks to 200% of its desired count which is the maximum permitted EXISTING EXISTINGNEW NEW Desired Count = 2 Minimum Healthy Percent = 100% Maximum Percent = 200%
- 17. Deployment – In Place – Doubling Availability Zone Availability Zone After the new tasks are verified to be healthy by the Elastic Load Balancer health check, the two previous tasks with the older task definition are drained and stopped NEW NEW Desired Count = 2 Minimum Healthy Percent = 100% Maximum Percent = 200%
- 18. Deployment – In Place – Rolling Availability Zone Availability Zone Scenario Service’s task definition is updated to a new revision with parameters: Desired Count = 2 Minimum Healthy Percent = 50% Maximum Percent = 100% These settings constrain the service to not exceed its desired size but allows it to halve the number of tasks during deployment EXISTING EXISTING
- 19. Deployment – In Place – Rolling Availability Zone Availability Zone First, an existing task is stopped which brings the healthy percentage of the service to 50% and makes room on the cluster for new tasks EXISTING Desired Count = 2 Minimum Healthy Percent = 50% Maximum Percent = 100%
- 20. Deployment – In Place – Rolling Availability Zone Availability Zone A task using the new task definition is started bringing the service back to 100% EXISTING Desired Count = 2 Minimum Healthy Percent = 50% Maximum Percent = 100% NEW
- 21. Deployment – In Place – Rolling Availability Zone Availability Zone After the new task is verified to be healthy by the Elastic Load Balancer health check, the next existing task with the older task definition is drained and stopped Desired Count = 2 Minimum Healthy Percent = 50% Maximum Percent = 100% NEW
- 22. Deployment – In Place – Rolling Availability Zone Availability Zone The second new task is started on the cluster bringing the service back to 100% NEW NEW Desired Count = 2 Minimum Healthy Percent = 50% Maximum Percent = 100%
- 23. Deployment – Canary Availability Zone Availability Zone Scenario The new revision runs as a small subset of production by deploying a canary service in the same target group Deployment is completed by updating the primary service’s task definition and scaling down the canary service. EXISTING EXISTINGEXISTING
- 24. Deployment – Canary Availability Zone Availability Zone A standalone service with the new task definition is deployed using the same Application Load Balancer target group of the existing service EXISTING EXISTINGEXISTING CANARY
- 25. Deployment – Canary Availability Zone Availability Zone After some period of monitoring the metrics from the canary instance, the existing service’s task definition is updated to the new revision NEW NEWNEW CANARY
- 26. Deployment – Canary Availability Zone Availability Zone After the deployment, all tasks are running the same task definition with the new revision of the application and the canary can be destroyed NEW NEWNEW
- 27. Deployment – Blue/Green – DNS Swap Availability Zone EXISTING EXISTING www.myproduct.com Scenario Two services are defined each with their own Application Load Balancer Deployment is completed by swapping the Route 53 alias record between the two Application Load Balancers Availability Zone
- 28. Deployment – Blue/Green – DNS Swap Availability Zone EXISTING EXISTING www.myproduct.com An identical Application Load Balancer and a service with a task definition using the new revision is deployed Availability Zone NEW NEW next.myproduct.com
- 29. Deployment – Blue/Green – DNS Swap Availability Zone EXISTING EXISTING next.myproduct.com After automated or manual testing, the deployment is completed by swapping the Route 53 alias record between the two Application Load Balancers Availability Zone NEW NEW www.myproduct.com
- 30. Deployment – Blue/Green – DNS Swap Availability Zone The previous service and its Application Load Balancer can then be destroyed Availability Zone NEW NEW www.myproduct.com
- 31. Deployment – Blue/Green – Target Group Swap Availability Zone EXISTING EXISTING Scenario Two services are defined each with their own target group registered in the same Application Load Balancer using Host-based routing Deployment is completed by swapping the listener rules between the two target groups Availability Zone
- 32. Deployment – Blue/Green – Target Group Swap Availability Zone EXISTING EXISTING The second service is deployed with a new target group and registered to the same Application Load Balancer Using Host-based routing, requests to www.myproduct.com are directed to our blue service while requests to next.myproduct.com are directed to our green service NEW NEW Availability Zone
- 33. Deployment – Blue/Green – Target Group Swap Availability Zone After automated or manual testing, the deployment can be completed by swapping the listener rules on the Application Load Balancer and sending traffic to the green service NEW NEW Availability Zone EXISTING EXISTING
- 34. Deployment – Blue/Green – Target Group Swap Availability Zone The previous service and its target group can then be destroyed NEW NEW Availability Zone
- 35. Best Practices • In-place Doubling – beware the CPU and Memory reservation with host autoscaling ahead • Monitor the health of ecs-agent • Monitor your CloudWatch metrics and Logs • Canary deployment – test your pilot workload with the same backend capacity • Prepare your rollback plan
- 36. Lab4 – ECS Service and Host Autoscaling
- 37. Lab5 – Log Consolidation
- 38. Best Practices • CloudWatch Logs Agent 1. In the same Docker image 2. In the same Task Definition 3. Standalone task with distinct placement • Alternative – Fluentd
- 39. Lab6 – ECS Events
- 40. Takeaways • Monitor state changes for containers and tasks • On state changes, trigger SNS and Lambda for advanced coordination or scheduling • Monitor cloudtrail logs(API usage) as well
- 41. Lab7 – Spot Fleet Support
- 42. Takeaways • Use lowestPrice allocation strategy for dev/testing • Use diversified allocation strategy for pilot, staging or pre-prod • Beware of the host termination – you have no enough time for container draining • Be careful to deploy in Production
- 43. Lab8 – ASG Scale In and Container Draining
- 44. Takeaways • Container Draining may take up to 5-10 min • Beware of the draining of batch tasks • Stay patient and test
- 45. Lab9 – Credentials Management
- 46. Takeaways • Restrict the access of parameter and KMS key in the ECS Task Role • Use Parameter Hierarchy, Tagging and Notification $ aws ssm get-parameter-by-path –path /Dev/Web/Nginx $ aws ssm get-parameter-by-path –path /Testing/Web/Nginx $ aws ssm get-parameter-by-path –path /Prod/Web/Nginx –with-encryption
- 47. Lab10 – External and Internal ALB
- 48. Takeaways • Use ALB host-based and path-based routing • Fanout your task events for multiple operations – e.g. Route53 update • We have a PFR for this
- 49. feedback and get $25 credits
- 50. Q & A
- 51. Thank You