Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

DevOps, Continuous Integration and Deployment on AWS

5 695 vues

Publié le

Organizations around the globe are leveraging the cloud to accomplish world-changing missions. This session will address how AWS can help organizations put more money toward their mission and scale outreach and operations to achieve more with less. Hear some of the most advanced AWS customers on how their organizations handle DevOps, continuous integration, and deployment. Learn how these practices allow them to rapidly develop, iterate, test, and deploy highly scalable web applications and core operational systems on AWS. The discussion will focus on best practices, lessons learned, and the specific technologies and services these customers use.

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

DevOps, Continuous Integration and Deployment on AWS

  1. 1. NEW YORK ©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved
  2. 2. ©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved DevOps, Continuous Integration and Deployment on AWS Leo Zhadanovsky, Senior Solutions Architect, AWS @leozh Ed Zarecor, DevOps Lead, EdX
  3. 3. DevOps
  4. 4. What is DevOps? • « DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support » - theagileadmin.com
  5. 5. Continuous Integration
  6. 6. What is Continuous Integration? • Changes to code automatically deployed to mainline branch – After passing unit and mock tests • Makes changes to code, and deployments iterative, not monolithic • Bugs are detected quickly • Helps automate deployments • Allows rapid development and deployment
  7. 7. SOURCE CODE REPOSITORY PROJECT MANAGEMENT SERVER CONTINUOUS INTEGRATION SERVER DEVELOPER PICK TASKS SUBMIT CODE SCHEDULE BUILD RECURRENT BUILDS CODE FETCHCODE QUALITY TESTS TEST RESULTS BUILD OUTPUT DOCS BINARIES & PACKAGES DEV FACING NOTIFICATIONS CLOUDFORMATION AMIS or CONTAINERS
  8. 8. SOURCE CODE REPOSITORY DNS CONTINUOUS INTEGRATION SERVER PROJECT MANAGEMENT SERVER BUILDS
  9. 9. AWS code services AWS CodeCommit Launched Today AWS CodePipeline Launched Today AWS CodeDeploy Launched Nov 2014
  10. 10. Cloud software development lifecycle 10/13/14 11 MonitorProvisionDeployTestBuildCode AWS Elastic Beanstalk AWS OpsWorks Amazon CloudWatch AWS CloudFormation ?
  11. 11. Cloud software development lifecycle 10/13/14 12 MonitorProvisionDeployTestBuildCode AWS Elastic Beanstalk AWS OpsWorks CloudWatchCloudFormationCodeDeploy CodeCommit CodePipeline
  12. 12. CODECOMMIT DNS CODEPIPELINE PROJECT MANAGEMENT SERVER BUILDS
  13. 13. PAIN POINTS • UNIT TESTS INCOMPLETE • MOCK TESTS MAINTENANCE • EXPENSIVE TEST ENVIRONMENT • TEST ENVIRONMENT ≠ PRODUCTION • DEPLOYMENT CYCLES
  14. 14. ON-DEMAND PAY AS YOU GO ELASTIC
  15. 15. = PROGRAMMABLE PLATFORM
  16. 16. IF YOU CAN PROGRAM IT YOU CAN AUTOMATE IT
  17. 17. A lot of options… • Configuration Management Systems – Puppet – Chef – Saltstack • Deployment Frameworks – CodeDeploy – AWS Elastic Beanstalk – AWS OpsWorks – Ansible – Fabric – Capistrano • Infrastructure Management – CloudFormation • Containers – Amazon EC2 Container Service
  18. 18. APPLICATION VERSIONS + INFRASTRUCTURE VERSIONS
  19. 19. CLOUDFORMATION TEMPLATE
  20. 20. CONTINUOUS DEPLOYMENT SMALL, FREQUENT CHANGES CONSTANTLY INTEGRATING INTO PRODUCTION.
  21. 21. KEY = ITERATION
  22. 22. ITERATION = MODIFY THE SYSTEM TO BETTER MEET THE EXPECTATIONS OF YOUR USERS
  23. 23. 11.6s Mean time between deployments (weekday) 1,079 Max number of deployments in a single hour 10,000 Mean number of hosts simultaneously receiving a deployment 30,000 Max number of hosts simultaneously receiving a deployment DEPLOYMENTS AT AMAZON.COM (in 2011)
  24. 24. SOFTWARE DEPLOY ≠ PRODUCT LAUNCH
  25. 25. DATA-DRIVEN ARCHITECTURES
  26. 26. METRICS @ETSY
  27. 27. METRICS @OBAMA FOR AMERICA
  28. 28. Metrics and Monitoring Options CloudWatch … and many more
  29. 29. CONTINUOUS INTEGRATION CONTINUOUS DEPLOYMENT
  30. 30. CONTINUOUS DEPLOYMENT = CONTINUOUS EXPERIMENTATION
  31. 31. CONTINUOUS DEPLOYMENT = CONTINUOUS IMPROVEMENT
  32. 32. INNOVATE
  33. 33. SPEED AND AGILITY Experiment Often Fail quickly at a low cost More Innovation Experiment Infrequently Failure is expensive Less Innovation “ON- PREMISES”
  34. 34. DevOps@edX A report from the frontline of an evolving and, hopefully, continuously improving DevOps organization, July, 2015
  35. 35. * About edX ‣ Created in May, 2012 by Harvard and MIT ‣ More than 4 million students from every country ‣ More than 12 million course enrollments ‣ 65 prestigious member institutions from around the world
  36. 36. * Our Vision To democratize and reimagine education by increasing worldwide educational access and create a culture of continuous, lifelong learning. Anyone, anywhere with a desire to learn and an Internet connection can take quality online courses.
  37. 37. * edX, the Open Source Project
  38. 38. * edX on AWS How we use AWS ‣ Deployed on AWS since the beginning ‣ Use many AWS services, but especially ‣ EC2 ‣ RDS ‣ S3 ‣ Cloudfront ‣ EMR ‣ Everything in the VPC ‣ Tend to be early adopters ‣ AWS Marketplace image in partnership with Bitnami
  39. 39. * edX on AWS Why we value AWS ‣ Breadth of offering ‣ Pay-for-what-you-use ‣ “Elastic” everywhere; scales-up and scales-down ‣ A continuum of options from “bare metal” to Elastic Beanstalk ‣ Few tie-ins ‣ Global footprint
  40. 40. * What the hell have you built? With apologies to @codinghorror
  41. 41. ** Key DevOps Learnings ‣ Infrastructure As Code ‣ Immutable Infrastructure
  42. 42. ** Infrastructure as Code
  43. 43. ** Why ‣ We need to deploy services quickly and consistently ‣ Relationships between services are complex ‣ Each additional service adds incremental operational complexity Infrastructure as Code
  44. 44. ** Each service is complex in its own right Infrastructure as Code
  45. 45. ** How ‣ CloudFormation ‣ Terraform: https://www.terraform.io/ ‣ Home-grown solutions Infrastructure as Code
  46. 46. ** Infrastructure as Code Cloud Migrator “A simple, opinionated pattern and tools for discrete, scalable, fault-tolerant services” Ed
  47. 47. ** Infrastructure as Code How we realize the components in AWS
  48. 48. ** Cloud Migrator Design goals: ‣ Ease of adding new services ‣ Minimal additional configuration per service required ‣ Flexible per service configuration supported ‣ Idempotent ‣ D.R.Y. Infrastructure as Code
  49. 49. ** What Cloud Migrator descriptors look like: ‣ yaml ‣ Minimally specify ‣ tags ‣ ports ‣ service CIDR blocks ‣ Anything can be overridden ‣ Easy to extend Infrastructure as Code
  50. 50. ** --- cluster: "notes" play: "{{ cluster }}" services_tag: "edx_notes_api" service_port: 18120 instance_type: "m3.medium" private_subnet_1: "{{ vpc_class_b }}.110.32/28" private_subnet_2: "{{ vpc_class_b }}.120.32/28" private_elb_subnet_1: "{{ vpc_class_b }}.110.128/28" private_elb_subnet_2: "{{ vpc_class_b }}.120.128/28" Infrastructure as Code
  51. 51. ** Immutable Infrastructure
  52. 52. ** Immutable Infrastructure Why ‣ Traceability, everything in SCM ‣ Pull request workflow ‣ Strong consistency guarantees with identical, tested artifacts ‣ Dead simple auto-scaling ‣ Clear path to automation
  53. 53. ** Immutable Infrastructure How ‣ Our deployment artifacts are pre-baked AMIs ‣ Several versions of application software and config converge to produce our AMIs ‣ Another homegrown tool, Abbey, builds AMIs ‣ Abbey leverages our configuration management tool of choice, Ansible
  54. 54. ** An Aside: Why Ansible ‣ We appreciate its simplicity ‣ It’s built on tried and true tools like SSH ‣ Dynamic inventories using cloud-friendly selectors like tags ‣ It is agentless ‣ We are heavily invested in Python
  55. 55. ** Cutting an Image
  56. 56. ** Cutting an Image
  57. 57. ** Cutting an Image Need something cut, talk to @alton
  58. 58. ** Chatting with @alton
  59. 59. ** Chatting with @alton
  60. 60. ** Comparing Images
  61. 61. ** Deploying
  62. 62. ** Blue/Green Deploys
  63. 63. ** Whither edX Ops ‣ Continue down the road of decomposing our monolithic application into independent services ‣ Improve testing, especially automated integration tests ‣ Move to a more fully automated CI/CD pipeline ‣ Expand our geographic reach ‣ Continuously improve our infrastructure ‣ Support our open-source partners ‣ Leverage service discovery ‣ Containers, containers, containers
  64. 64. ** Contact Details ‣ Edward Zarecor, DevOps Lead@edX, e0d@edx.org ‣ edX on github: https://github.com/edx ‣ On github I’m e0d
  65. 65. NEW YORK

×