Docker right now provides great value in the enterprise but the value proposition is more about developer productivity than scale-out. Docker benefits include resource management, environment management, continuous delivery, developer and operations collaboration, and hybrid workloads. Take care in its introduction. Consider Docker as just part of an overall toolkit and you don't need to go "full stack" to gain value.

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

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

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

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

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

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

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

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

10. 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/continuo
us-delivery/

11. Inside:
• Packages
• JVM
• Custom Code
• Applications
• Whatever….
Apps are ideally written to
be configured within a
container…12 factor-ish

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

13. Standard Monitoring:
• Ports
• Health endpoints
• Agents (baked in)
e.g. JMXtrans

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

15. Service Endpoints:
• Ports
• Naming
e.g. Service Parameters in env.sh

16. Service Discovery
• “Cheap and Cheerful”
• Nginx or Haproxy
• Easy, low risk static
o Discovery
o Load-balancing
o Failover
e.g. nginx config

18. Docker
Registry
Host
AZ1
Proxy
ServiceA
ServiceB
ServiceC
Build Server
BitBucket
Nexus
Go
sshd dockerd
Docker
Index
Host
AZ2
Proxy
ServiceA
ServiceB
ServiceC
sshd dockerd

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

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

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

24. • 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…

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

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

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

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

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

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