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
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)
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
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
16.
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 .
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!)
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' }
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
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.
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
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
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