Docker in Production: How RightScale Delivers Cloud Applications

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

ME

M

PG

M

regs

pro

c

ME

M

regs

pro

c

/etc

/lib

/bin

ME

M

regs

pro

c

/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 image Git commit Image build

Continuous Integration

GitHub

Repo Unit & Functional Tests

Fetch dependencies

Pass?

Integration Tests Pass?

Deploy Cloud Infrastructure

with RightScale

Continuous Integration

Success email

Continuous Integration: Dockerized

26

GitHub

Repo Unit & Functional Tests

Fetch dependencies

Pass?

docker build docker push Integration Tests Pass?

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