SlideShare a Scribd company logo

Docker in Production: How RightScale Delivers Cloud Applications

•
•
RightScale
RightScale

This document discusses how RightScale delivers cloud applications using Docker. It begins with an introduction to Docker and outlines three approaches to using Docker: containerizing code, composing applications, and deploying a sea of containers. It then details RightScale's plan of attack for using Docker which takes a gradual, phased approach. The document also covers RightScale's development to production workflow when using Docker and compares operations before and after adopting Docker. It concludes with discussing next steps such as improving monitoring, composition, and orchestration when using Docker.

1 of 39
Download to read offline
DOCKER IN PRODUCTION: HOW RIGHTSCALE DELIVERS CLOUD APPLICATIONS
Panelists ��� Tim Miller: Moderator • VP Engineering • Tony Spataro • Senior Systems Architect • Mark Dotson • Principal System Administrator
Agenda • Docker Level-Set • Three Approaches to Using Docker • RightScale Plan of Attack • Development to Production • Before and After • Next Steps • Q&A
POLLING QUESTIONS 3
2015 DevOps Tools – All Respondents 3% 6% 10% 13% 24% 28% 11% 10% 10% 35% 19% 18% 0% 20% 40% 60% 80% 100% Rocket Salt Ansible Docker Puppet Chef Respondents Using DevOps Tools Use today Plan to use Source: RightScale 2015 State of the Cloud Report
• User-friendly wrapper for cgroups • Nice CLI • Novel isolation features • Overlay filesystem • Virtual network interface • Packaging, distribution, reusability • Image registries (e.g. DockerHub) • Image metadata What is Docker? 5 ubuntu ubuntu ubuntu security security security ruby ruby apache app1 app2 rw rw rw
Containers vs. Processes 6 MEMPGMregs proc MEMregs proc /etc /lib /bin MEMregs proc /etc /lib /bin limit textbook process real process container
Docker Image Metadata Explained 7  Complain to this guy  You can tune this setting  I offer a network service  I need persistent storage  I specialize my base image like this  Invoke me like this  I’m derived from this base image
3 DOCKER USE CASES
• Architectural role of VMs doesn’t change • Deploy 1 app container onto each VM • Additional services can live outside container Containerize Code 9 syslog smtp my-awesome-app Application Server 1..n Container No container nginx
• Simplifies config management • Package messy apps • Speed up deployment (installs at container build time) • Enhance app reliability (through better isolation) • Hot-swappable apps (zero-downtime) Benefits Drawbacks • Poor resource utilization (maybe) • Services shared with host machine • Config management required on host machine Containerize Code 10
• Deploy N containers onto a VM • Host-local network • Declarative dependencies • Great for microservices architecture Compose Applications 11 Application Server 1..n nginx my-awesome-app smtp syslog
• Everything is a service • Reusable app components • Simple orchestration for free Benefits Drawbacks • Moderate up-front investment • Complicates hot-swapping • Complicates config management • Complicates fault tolerance • Brittle (all-or-nothing fail/replace) Compose Applications 12
Deploy a Sea of Containers 13 VM VM VM A A A A A A C C B B B B VM VM VM A A A C C A A A C C B B B B B Container Management B • N(×M) containers • 0..N VMs • Elastic mesh network • Declarative everything • Resource scheduling A A
• Cost efficiency • Elasticity Benefits Drawbacks • Large up-front investment • Hard to manage & monitor • Beta-quality (rough edges) Deploy a Sea of Containers 14
RIGHTSCALE PLAN OF ATTACK
1. Research spike • Play with tech • Find limitations • Identify workarounds 1. Development & Test • Suite of microservices • Continuous integration 1. Production for a small, new-ish app Docker Plan of Attack: Baby Steps 16
• Maintain High Availability and SLAs • No negative impact on developer productivity • Integrate with existing production tools (monitoring, alerting, orchestration) • Integrate with existing non-docker apps as seamlessly as possible Constraints 17
Conclusion: Containerize our Code 1. Dead simple for DevOps and Dev to understand 2. Low investment; immediate return 3. 100% compatible with existing production tools Choosing an Approach 18
DEVELOPMENT TO PRODUCTION
About Server Templates
• Curated base images • Wanted to have known images provided by Ops • We modify ubuntu-provided images with common app needs • Git, maketools, etc. • Patching schedule • Even Docker images must fulfill security-patching SLA • Base images rebuilt daily w/latest upstream patches • Respond to disclosures by rebuilding application images Preparation 21
• Application manifest (“all the files?!”) for dockerfile • Watch for hidden OS dependencies (e.g. system calls to “mail”) • Service Dependencies • Inputs (e.g. how many workers) • Secrets Development: What it Means to Dockerize 22 Interface Contract between Ops and Devs
Branching Workflow production
Branching Workflow: Dockerized 24 master staging production rightscale/my_app:latest rightscale/my_app:staging rightscale/my_app:production Docker imageGit commit Image build
Continuous Integration GitHub Repo Unit & Functional Tests Fetch dependencies Pass? Integration TestsPass? Deploy Cloud Infrastructure with RightScale Continuous Integration Success email
Continuous Integration: Dockerized 26 GitHub Repo Unit & Functional Tests Fetch dependencies Pass? docker builddocker push Integration TestsPass? Deploy Cloud Infrastructure with RightScale DockerHub Continuous Integration docker daemon Docker Build Farm in the Cloud docker daemon Local Image Store Deploy Cloud Infrastructure with RightScale
• Significant departure from non-Docker workflow • Only CI can build images • No image unless unit/functional tests pass • Must use team integration branch (no image per feature branch) • Benefits of always building Docker images in CI: • Less burden on developers (no Docker running on laptop) • Uniform, reproducible build procedure • Quality Assurance: not much change • Acceptance/regression tests simulate end-user gestures • Docker changes nothing from the end-user perspective Continuous Integration: Key Differences 27
• Large undertaking • Same procedure • Unexpected benefits! Weekly Release 28
• System monitoring: more of the same • Throw some more more metrics onto the stack • Alert when containers look funny • Application monitoring: novel challenges • More containment = less transparency • docker exec to the rescue? • Single collection, analysis & alerting infrastructure • Avoid “split-brain” syndrome After Release: Sustaining Operations 29
B.D. AND A.D. BEFORE DOCKER AND AFTER DOCKER 30
Before After Dozens of ServerTemplates Two ServerTemplates overall Apps that share ServerTemplates, share runtime dependencies Each app precisely controls its runtime dependencies Dozens of inputs in RS dashboard Two places for inputs RS: fine adjustments + secrets Git: coarse adjustments 10-20 minute provisioning Install management boilerplate Install lang. runtime, libraries, etc 6-10 minute provisioning Install boilerplate; Docker; done! New bottleneck: DockerHub Rolling-restart dance Fire-and-forget deploy gun Benefits to DevOps 31
Before After “Ask Ops” mentality “I built this” mentality Can’t touch staging Free to tinker in staging Can’t debug Debug any time, anywhere (not strictly thanks to Docker) Benefits to Developers 32
• eBook: Continuous Integration and Delivery: How RightScale Does It • http://www.rightscale.com/ci-cd-ebook • Free Trial for RightScale • https://www.rightscale.com/free-trial • Sample RightScale ServerTemplate • http://goo.gl/CjxELA Q&A 33
THANK YOU.
NEXT STEPS 35
• Intelligent containers • Self-defined monitoring metrics • Self-defined alerts • Intelligent alerts • Tune boundary conditions on the fly • Squelch/enable alerts as operational state changes • Whole-service monitoring • Aggregate datapoints of all nodes running an app • Alert on overall QoS & availability Monitoring 36
• Enable it (but don’t force-fit) • ServerTemplate: 1 page • Cloud Application Template: 1 book • How to do it in production? • …and still save money? • “Microservices on a stick” • Strong potential • Limited use cases: brittle, monolithic Composition 37 syslog smtp my-awesome-app nginx application server (1..n)
• Service discovery • Self-healing applications • Enabled by whole-system monitoring • Like elastic scaling, but for other concerns Orchestration 38

More Related Content

Docker in Production: How RightScale Delivers Cloud Applications

  • 1. DOCKER IN PRODUCTION: HOW RIGHTSCALE DELIVERS CLOUD APPLICATIONS
  • 2. Panelists • Tim Miller: Moderator • VP Engineering • Tony Spataro • Senior Systems Architect • Mark Dotson • Principal System Administrator
  • 3. Agenda • Docker Level-Set • Three Approaches to Using Docker • RightScale Plan of Attack • Development to Production • Before and After • Next Steps • Q&A
  • 5. 2015 DevOps Tools – All Respondents 3% 6% 10% 13% 24% 28% 11% 10% 10% 35% 19% 18% 0% 20% 40% 60% 80% 100% Rocket Salt Ansible Docker Puppet Chef Respondents Using DevOps Tools Use today Plan to use Source: RightScale 2015 State of the Cloud Report
  • 6. • User-friendly wrapper for cgroups • Nice CLI • Novel isolation features • Overlay filesystem • Virtual network interface • Packaging, distribution, reusability • Image registries (e.g. DockerHub) • Image metadata What is Docker? 5 ubuntu ubuntu ubuntu security security security ruby ruby apache app1 app2 rw rw rw
  • 8. Docker Image Metadata Explained 7  Complain to this guy  You can tune this setting  I offer a network service  I need persistent storage  I specialize my base image like this  Invoke me like this  I’m derived from this base image
  • 9. 3 DOCKER USE CASES
  • 10. • Architectural role of VMs doesn’t change • Deploy 1 app container onto each VM • Additional services can live outside container Containerize Code 9 syslog smtp my-awesome-app Application Server 1..n Container No container nginx
  • 11. • Simplifies config management • Package messy apps • Speed up deployment (installs at container build time) • Enhance app reliability (through better isolation) • Hot-swappable apps (zero-downtime) Benefits Drawbacks • Poor resource utilization (maybe) • Services shared with host machine • Config management required on host machine Containerize Code 10
  • 12. • Deploy N containers onto a VM • Host-local network • Declarative dependencies • Great for microservices architecture Compose Applications 11 Application Server 1..n nginx my-awesome-app smtp syslog
  • 13. • Everything is a service • Reusable app components • Simple orchestration for free Benefits Drawbacks • Moderate up-front investment • Complicates hot-swapping • Complicates config management • Complicates fault tolerance • Brittle (all-or-nothing fail/replace) Compose Applications 12
  • 14. Deploy a Sea of Containers 13 VM VM VM A A A A A A C C B B B B VM VM VM A A A C C A A A C C B B B B B Container Management B • N(×M) containers • 0..N VMs • Elastic mesh network • Declarative everything • Resource scheduling A A
  • 15. • Cost efficiency • Elasticity Benefits Drawbacks • Large up-front investment • Hard to manage & monitor • Beta-quality (rough edges) Deploy a Sea of Containers 14
  • 17. 1. Research spike • Play with tech • Find limitations • Identify workarounds 1. Development & Test • Suite of microservices • Continuous integration 1. Production for a small, new-ish app Docker Plan of Attack: Baby Steps 16
  • 18. • Maintain High Availability and SLAs • No negative impact on developer productivity • Integrate with existing production tools (monitoring, alerting, orchestration) • Integrate with existing non-docker apps as seamlessly as possible Constraints 17
  • 19. Conclusion: Containerize our Code 1. Dead simple for DevOps and Dev to understand 2. Low investment; immediate return 3. 100% compatible with existing production tools Choosing an Approach 18
  • 22. • Curated base images • Wanted to have known images provided by Ops • We modify ubuntu-provided images with common app needs • Git, maketools, etc. • Patching schedule • Even Docker images must fulfill security-patching SLA • Base images rebuilt daily w/latest upstream patches • Respond to disclosures by rebuilding application images Preparation 21
  • 23. • Application manifest (“all the files?!”) for dockerfile • Watch for hidden OS dependencies (e.g. system calls to “mail”) • Service Dependencies • Inputs (e.g. how many workers) • Secrets Development: What it Means to Dockerize 22 Interface Contract between Ops and Devs
  • 26. Continuous Integration GitHub Repo Unit & Functional Tests Fetch dependencies Pass? Integration TestsPass? Deploy Cloud Infrastructure with RightScale Continuous Integration Success email
  • 27. Continuous Integration: Dockerized 26 GitHub Repo Unit & Functional Tests Fetch dependencies Pass? docker builddocker push Integration TestsPass? Deploy Cloud Infrastructure with RightScale DockerHub Continuous Integration docker daemon Docker Build Farm in the Cloud docker daemon Local Image Store Deploy Cloud Infrastructure with RightScale
  • 28. • Significant departure from non-Docker workflow • Only CI can build images • No image unless unit/functional tests pass • Must use team integration branch (no image per feature branch) • Benefits of always building Docker images in CI: • Less burden on developers (no Docker running on laptop) • Uniform, reproducible build procedure • Quality Assurance: not much change • Acceptance/regression tests simulate end-user gestures • Docker changes nothing from the end-user perspective Continuous Integration: Key Differences 27
  • 29. • Large undertaking • Same procedure • Unexpected benefits! Weekly Release 28
  • 30. • System monitoring: more of the same • Throw some more more metrics onto the stack • Alert when containers look funny • Application monitoring: novel challenges • More containment = less transparency • docker exec to the rescue? • Single collection, analysis & alerting infrastructure • Avoid “split-brain” syndrome After Release: Sustaining Operations 29
  • 31. B.D. AND A.D. BEFORE DOCKER AND AFTER DOCKER 30
  • 32. Before After Dozens of ServerTemplates Two ServerTemplates overall Apps that share ServerTemplates, share runtime dependencies Each app precisely controls its runtime dependencies Dozens of inputs in RS dashboard Two places for inputs RS: fine adjustments + secrets Git: coarse adjustments 10-20 minute provisioning Install management boilerplate Install lang. runtime, libraries, etc 6-10 minute provisioning Install boilerplate; Docker; done! New bottleneck: DockerHub Rolling-restart dance Fire-and-forget deploy gun Benefits to DevOps 31
  • 33. Before After “Ask Ops” mentality “I built this” mentality Can’t touch staging Free to tinker in staging Can’t debug Debug any time, anywhere (not strictly thanks to Docker) Benefits to Developers 32
  • 34. • eBook: Continuous Integration and Delivery: How RightScale Does It • http://www.rightscale.com/ci-cd-ebook • Free Trial for RightScale • https://www.rightscale.com/free-trial • Sample RightScale ServerTemplate • http://goo.gl/CjxELA Q&A 33
  • 37. • Intelligent containers • Self-defined monitoring metrics • Self-defined alerts • Intelligent alerts • Tune boundary conditions on the fly • Squelch/enable alerts as operational state changes • Whole-service monitoring • Aggregate datapoints of all nodes running an app • Alert on overall QoS & availability Monitoring 36
  • 38. • Enable it (but don’t force-fit) • ServerTemplate: 1 page • Cloud Application Template: 1 book • How to do it in production? • …and still save money? • “Microservices on a stick” • Strong potential • Limited use cases: brittle, monolithic Composition 37 syslog smtp my-awesome-app nginx application server (1..n)
  • 39. • Service discovery • Self-healing applications • Enabled by whole-system monitoring • Like elastic scaling, but for other concerns Orchestration 38