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. 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

4. POLLING QUESTIONS
3

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

7. Containers vs. Processes
6
MEMPGMregs
proc
MEMregs
proc
/etc
/lib
/bin
MEMregs
proc
/etc
/lib
/bin
limit
textbook process real process container

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

16. RIGHTSCALE
PLAN OF ATTACK

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

20. DEVELOPMENT TO
PRODUCTION

21. About Server Templates

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

24. Branching Workflow
production

25. Branching Workflow: Dockerized
24
master
staging
production
rightscale/my_app:latest
rightscale/my_app:staging
rightscale/my_app:production
Docker imageGit commit Image build

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

35. THANK YOU.

36. NEXT STEPS
35

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