This document discusses Docker and Puppet and how they can be used together. It describes how Puppet can be used to install and configure Docker on a system and then how Dockerfiles can be used to build container images. However, it notes that using Puppet to build container images directly is not recommended and describes alternatives like using Puppet during the build process to configure "golden images" and then deploying them. It suggests approaches like running services externally to containers and using data containers to optimize container usage.

1. Docker
and
Puppet
1+1=3

2. @jpetazzo
● Wrote dotCloud PAAS deployment tools
– EC2, LXC, Puppet, Python, Shell, ØMQ...
● Docker contributor
– Docker-in-Docker, VPN-in-Docker,
router-in-Docker...
CONTAINERIZE ALL THE THINGS!
● Runs Docker in production,
and helps others to do the same

3. What is
Docker?
The quick elevator pitch

4. Docker Engine
+ Docker Hub
= Docker Platform

5. Docker
Engine

6. The Docker Engine
● Open Source
● Written in Go
● Runs containers
● On any modern Linux machine
(Intel 64 bits for now)

7. Containers ?

8. Containers
● Software delivery mechanism
(a bit like a package!)
● Put your application in a container,
run it anywhere
● A bit like a VM, but ...

9. I have four words for you
● CONTAINERS boot faster
(than VMs)
● CONTAINERS have less overhead
(more consolidation)
● CONTAINERS bring native performance
(on bare metal)
● CONTAINERS are cloud-compatible
(can run in VMs)

10. Docker Engine recap
● Approximation:
it's an hypervisor to run containers
● Approximation:
containers are like VMs, but lighter
● Docker makes containers available to everybody
(not just veterans from the last emacs/vim war)

12. Docker
Hub

13. Docker Hub
● Services operated by Docker Inc.
● Library of ready-to-use container images
● Registry for your container images
(public or private)
● Automated builds
(triggered by pushes to GitHub/Bitbucket)
● Free for public/open source code, $$ otherwise

14. Building
containers

15. Dockerfile
FROM ubuntu:14.04
MAINTAINER Docker Team <education@docker.com>
RUN apt-get update
RUN apt-get install -y nginx
RUN echo 'Hi, I am in your container'
>/usr/share/nginx/html/index.html
CMD [ "nginx", "-g", "daemon off;" ]
EXPOSE 80

17. FROM ubuntu
RUN apt-get -y update
RUN apt-get install -y g++
RUN apt-get install -y erlang-dev erlang-manpages erlang-base-hipe
...
RUN apt-get install -y libmozjs185-dev libicu-dev libtool ...
RUN apt-get install -y make wget
RUN wget http://.../apache-couchdb-1.3.1.tar.gz | tar -C /tmp -zxf-
RUN cd /tmp/apache-couchdb-* && ./configure && make install
RUN printf "[httpd]nport = 8101nbind_address = 0.0.0.0" >
/usr/local/etc/couchdb/local.d/docker.ini
EXPOSE 8101
CMD ["/usr/local/bin/couchdb"]
docker build -t jpetazzo/couchdb .

18. Dockerfile
vs.
Shell scripts

19. Shell scripts
● OK-ish for simple stacks
● Tricky to handle all possible situations
(that's why we have proper config management)
● Though choice when rebuilding:
– from scratch (but it takes forever!)
– iteratively (but might behave differently!)

20. Dockerfile
vs.
Configuration
Management

21. Configuration Management:
the Good
● Deals with low-level stuff
● Abstracts some details (distro, sometimes OS)
● Ensures convergence to a known state
● Library of reusable, composable templates

22. Configuration Management:
the Bad
● Steep learning curve
● Generally requires an agent
(or something to trigger e.g. « puppet apply »)
● Resource-intensive
(it's OK to run the agent on a 64 GB server,
it's less OK to run 100 agents on said server)

23. Configuration Management
● Reusability is just as good as modules are
(i.e. YMMV)
● Not as deterministic as you think
● Rollbacks are harder than you think
{ 'openssl' : ensure => present }
{ 'openssl' : ensure => '1.2.3-no-heartbleed-pls' }

24. Dockerfile
to the rescue

25. Dockerfile
● Doesn't have to deal with « low-level stuff »
(hardware, drivers... handled by the host)
● Doesn't need all the goodness of CM
(because it doesn't have to converge)
● Partial rebuilds are fast
(layered caching rebuilds only what is needed)
● Allows inheritance and composition
(FROM <mycustombase>; see also: ONBUILD)
● Easy learning curve
(if you know Shell, you already know Dockerfile)

26. But...
● Doesn't deal with « low-level stuff »
(hardware, drivers...)
● Doesn't define resource dependencies
(no before/after)
● Doesn't define what runs where

27. Puppet
to the rescue

28. Before/After
● Use Puppet to
setup hardware
(or virtual hardware),
install packages,
deploy code,
run services.
● Use Puppet to
setup hardware
(or virtual hardware),
install Docker,
run containers.
● Use Dockerfiles
to install packages,
deploy code,
run services.

29. Do one thing,
and do it well

30. First things first
https://github.com/garethr/garethr-docker
https://forge.puppetlabs.com/garethr/docker

31. Installing Docker with Puppet
include 'docker'
class { 'docker':
version => '0.8.1'
}

32. Warm up our image collection
# download the registry image
docker::image { 'stackbrew/registry':
}
# don't download all ubuntu,
# just 'precise'
docker::image { 'ubuntu':
image_tag => 'precise'
}

33. Run containers
docker::run { 'slavedb':
image => 'jpetazzo/postgresql'
command => '…'
ports => ['5432', '22'],
links => ['masterdb:master'],
use_name => true,
volumes => ['/var/lib/postgresql'],
volumes_from => '420fc7e8aa20',
memory_limit => 100000000, # bytes
username => 'postgres',
hostname => 'sdb.prod.dckr.io',
env => ['FUZZINESS=42', FOO=BAR', 'FOO2=BAR2'],
dns => ['8.8.8.8', '8.8.4.4'],
restart_service => true
}

34. Can I use Puppet
to build Docker
container images?

35. YES

36. Should I use Puppet
to build Docker
container images?

37. NO

38. OK,
let's do it anyway

39. My other VM is a container
● write a Dockerfile to install Puppet
● start tons of containers
● run Puppet in them (agent, or one-shot apply)
Good if you want a mix of containers/VM/metal
But slower to deploy, and uses more resources

40. Sample Dockerfile
FROM ubuntu:12.04
RUN apt-get install -qy wget
RUN mkdir /puppet
WORKDIR /puppet
RUN wget -q http://apt.puppetlabs.com/puppetlabs-release-precise.deb
RUN dpkg -i puppetlabs-release-precise.deb
RUN apt-get update -q
RUN apt-get install -qy puppet-common
CMD puppet agent --no-daemonize --verbose

41. Lightweight, portable VMs
● Start containers instead of VMs
– I can start 10 containers on this puny laptop!
– You can start those 10 containers too!
(Even though you have a totally different laptop!)
– We can start those containers in the Cloud!
● Deploy sshd, syslogd, crond, etc.
– You can... But do you have to?

42. The revolution will be containerized
● write a Dockerfile to install Puppet
● … and run Puppet as part of build process
● deploy fully baked, « golden » images
Faster to deploy
Easier to rollback

43. Sample Dockerfile
FROM ubuntu:12.04
RUN apt-get install -qy wget
RUN mkdir /puppet
WORKDIR /puppet
RUN wget -q http://apt.puppetlabs.com/puppetlabs-release-precise.deb
RUN dpkg -i puppetlabs-release-precise.deb
RUN apt-get update -q
RUN apt-get install -qy puppet-common
ENV FACTER_HOSTNAME database42
ADD ./site.pp /puppet/site.pp
RUN puppet apply site.pp

44. Beyond
Golden
Containers

45. Get rid of sshd, crond, syslogd...
● Remote access: nsenter
https://github.com/jpetazzo/nsenter
● Cron:
use a separate container
● Logs:
use a data container
http://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/

46. Why?
● Separate orthogonal concerns
(don't rebuild your app to change logging,
remote access, and other unrelated things)
● Have different policies in prod/dev/QA/etc
● Ship lighter containers

47. Thoughts...

48. What if we could...
● Run the Puppet agent outside of the container
● Run a single agent for many containers
● Share the cost of the agent

49. Thank you!

50. Shameless promo + Q&A
Tonight:
Docker and Mesos meet-up, at BrainTree
(requires cloning+teleportation)
The rest of the week:
A bunch of talks about Docker & Containers
(requires a LinuxCon pass)
http://docker.com/
@docker
@jpetazzo