Saul Caganoff, CTO Sixtree saul@sixtree.com.au

@scaganoff

• Organizational Siloes – Hand-offs, communication problems

• Technical Legacy – Complex environments

– Technical debt

– IT can’t keep up with business requirements

• But huge imperatives to change – Digital products and services

– Cloud challenges to traditional IT management

• Docker is a patented method for boiling oceans

a proven solution to world hunger

• How is Docker useful for addressing some of these pain points?

• The value proposition for Docker is different in the enterprise – More about control

– Less about scale

• Containers are well established in the enterprise - just not terribly visible

• Solaris, AIX, HP-UX and Linux

– Resource management on very big boxes

– Scale-out is not so important

• Docker makes containers more visible & useful in contexts other than resource virtualization

• Developer friendly – Docker makes containers easy to use

• Dockerfile – Simple way to describe and build an image

• Docker Daemon – Uniform runtime monitoring

• Layered FS – Can inherit and extend images

• Repository – Storage and re-use of images

• Docker is part of an overall ecosystem

• Becoming available on other OS’s – Oracle and IBM recently jumping on the bandwagon

• Who fills out the rest of the map? – Orchestration

– Logging

– Discovery

– Monitoring

• Docker is being leveraged/absorbed by PaaS

• Integration for the 21st Century – Lightweight SOA – On-premise, Cloud and Hybrid – Rapid time to value – OSS, Lean, Continuous Delivery – Leverage the cloud – cloud citizen (if not native)

• We’ve heavily incorporated Docker into our delivery model

• Docker authorized partner – Consulting – Training

• Maintain control of our environment

• Support continuous delivery processes

• Lower risk environment promotion

• Introduce new & better practices to our clients

• Being used at a number of clients – Government

– Education

– Procurement

Principles 1. The process of releasing/deploying software MUST be

repeatable and reliable. 2. Automate everything. 3. If something is difficult or painful, do it more often. 4. Keep everything in source control. 5. Done means “released”. 6. Build quality in. 7. Everybody has responsibility for the release process. 8. Improve Continuously.

Practices 1. Build binaries only once. 2. Use precisely the same mechanism to deploy to every

environment. 3. Smoke test your deployment. 4. If anything fails, stop the line.

http://devopsnet.com/2011/08/04/continuous-delivery/

Inside: • Packages • JVM • Custom Code • Applications • Whatever….

Apps are ideally written to be configured within a container…12 factor-ish

Environment Variables: • Runtime parameters • Ports • Connections – URLs, JDBC Connections • Templates for config files – e.g. erb

e.g. ActiveMQ Configuration

Standard Monitoring: • Ports • Health endpoints • Agents (baked in)

e.g. JMXtrans

Standard Logging Infrastructure: • Standard Log Format • Logshipping • Central aggregation, correlation, reporting e.g. Loggly sidecar

Service Endpoints: • Ports • Naming

e.g. Service Parameters in env.sh

Service Discovery • “Cheap and Cheerful” • Nginx or Haproxy • Easy, low risk static

o Discovery o Load-balancing o Failover

e.g. nginx config

DockerRegistry

HostAZ1

Proxy

Se

rvic

e A

Se

rvic

e B

Se

rvic

e C

Build Server

Bit

Bu

cke

t

Ne

xus

Go

sshd dockerd

Do

cke

r In

de

x

HostAZ2

Proxy

Se

rvic

e A

Se

rvic

e B

Se

rvic

e C

sshd dockerd

• Developer checks an app into BitBucket. • CI Server

– Builds the app into a deployable unit. – Generates a Dockerfile using a base image.

• Describes steps to place the deployable unit and service configuration into the image and what ports and volumes need to be exposed.

– Builds a Docker Image. – Pushes the Docker Image to our private Docker Registry.

• Someone triggers a deployment to an environment. • CI Server

– SSH’es to the target server. – Pulls the Docker Image and run a Docker Container off it.

• Chef and Puppet are still useful

• But Docker does a lot of the heavy lifting

– Docker build files

– Image inheritance

• Docker dramatically shrinks the surface area that must be automated

• Docker provides a common well-defined interface

– Inside the box: Devs have more control over their environment

– Outside the box: Ops have less variation to deal with

• Disaster Recover is really hard – Dependency management between complicated

systems

– Restoring the correct system state

– Inevitable drift between production and DR environments

• Production Images can be easily instantiated out of the Docker Repository – That takes care of environment drift

– But the rest is still up to you…

• Docker has security in its architecture

• Namespaced resources are fully isolated

• Each container runs its own network stack

– Have to be explicit about public ports

• CGroups prevent DOS attacks from containers

• Containers start with limited capabilities

• Not every resource is namespaced: – /sys, /sys/fs, /proc/sys, /dev/mem etc

– But they are mounted as ro volumes

• Docker daemon must run as root – Best practice to lock it down – no REST access

• Containers interact with kernels, so all concerns with kernel exploits apply. – Use a secure & hardened kernel

– RHEL SELinux works well with Docker

• Never run Docker Daemon with Privileged flag • Treat root inside the container as if it is outside

– Drop privileges as quickly as possible – Run as non-root whenever possible

• Run only trusted containers – Have a private Docker Registry

• Have system updates as part of Dockerfile – Runtime patching becomes just building a new image and

running it

• Ensure you are running the latest version of Docker • Mount only the minimum required of file system

• The “Full Stack Developer”

• Not all devs want to take on ops activities – You need to handle this carefully

• Don’t try to “hide” ops concerns

• Better to make them apparent, but easy to deal with – Standards

– Base images

– Use sidecars (auxiliary Docker containers) to help - e.g. Registrator, Loggly logger.

• Automation & higher-level orchestration tools provide a great deal of value – Kubernetes, Mesos, etcd…

• But you can get real value out of Docker without these tools

• Premature automation brings some risks. – The landscape is shifting quickly – Incremental change helps manage risks – whether

they are real or perceived – Learn Docker with your existing automation tools

(Chef, Puppet) first

• Docker brings real value to the enterprise now.

• More about developer agility than scale-out – Resource Management

– Environment Management

– Continuous Delivery

– Dev + Ops harmony

– Hybrid cloud + on-premise workloads

• Care is needed in bringing everyone along

• Docker is part of your CD toolbox, not the whole thing.

• You don’t need to go “full stack” to gain value