This document discusses Docker, an open-source containerization platform. It begins by outlining why Docker is useful for deploying applications reliably and at scale across various environments. It then explains the container metaphor and how Docker addresses challenges of shipping code similarly to how shipping containers standardized shipping goods. The document provides an overview of using Docker and building images with Dockerfiles. It concludes by discussing the Docker community, upcoming features, and the goals for Docker 1.0.

1. Scale Big With Docker
February 2014—Docker 0.8.0

2. Outline
●
Why should I care?
●
The container metaphor
●
Very quick demo
●
Working with Docker
●
Building images
●
Docker future

3. Outline
●
Why should I care?
●
The container metaphor
●
Very quick demo
●
Working with Docker
●
Building images
●
Docker future

4. Deploy everything
●
webapps
●
backends
●
SQL, NoSQL
●
big data
●
message queues
●
… and more

5. Deploy almost everywhere
●
Linux servers
●
VMs or bare metal
●
Any distro
●
Kernel 3.8 (or RHEL 2.6.32)

6. Deploy reliably & consistently
●
If it works locally, it will work on the server
●
With exactly the same behavior
●
Regardless of versions
●
Regardless of distros
●
Regardless of dependencies

7. Deploy easily
●
Don't learn a new CM tool
●
Reuse components and recipes
●
Don't install anything fancy locally
(One single local VM to handle all your apps)

8. Deploy at scale
●
Build once
●
Deploy anywhere
●
Deploy quickly
–
–
Docker runtime itself is lightweight
–
●
Images are lightweight
Fast start/stop times
Manage Docker with its REST API

9. Outline
●
Why should I care?
●
The container metaphor
●
Very quick demo
●
Working with Docker
●
Building images
●
Docker future

10. Problem: shipping goods
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?

11. Solution:
the intermodal shipping container

13. Problem: shipping code
django
web frontend
node.js
async API
background
workers
SQL
database
distributed
DB, big data
message
queue
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
my
laptop
your
laptop
staging
prod on
cloud VM
prod on
bare metal
QA

14. Solution:
the Linux container

15. High level approach:
it's a lightweight VM
●
I can SSH into it
●
I have root access
●
I can apt-get/yum install packages
●
I don't see the host system (or other containers)
« Machine Container »

16. Low level approach:
it's chroot on steroids
●
I can run a single program
●
container = isolated process(es)
●
share kernel with host
●
no device emulation → no overhead
« Application Container »

17. Outline
●
Why should I care?
●
The container metaphor
●
Very quick demo
●
Working with Docker
●
Building images
●
Docker future

19. Outline
●
Why should I care?
●
The container metaphor
●
Very quick demo
●
Working with Docker
●
Building images
●
Docker future

20. One-time setup
●
On your servers (Linux)
–
–
Single binary install (Golang FTW!)
–
●
Packages (Ubuntu, Debian, Fedora, Gentoo, Arch...)
Easy provisioning on Rackspace, Digital Ocean, EC2, GCE...
On your dev env (Linux, OS X, Windows)
–
–
boot2docker (25 MB VM image)
–
●
Vagrantfile
Natively (if you run Linux)

21. The Docker workflow 1/2
●
Work in dev environment
(local machine or container)
●
Other services can be perfect copies of prod
●
Whenever you want to test « for real »:
–
Build in seconds
–
Run instantly

22. The Docker workflow 2/2
●
Push your build to a registry (public or private)
●
Run it in CI/CD
●
Run it in production
●
Rejoice
Something goes wrong?
Just re-run previous version (it's still there!)

23. I'm starting a new project!
●
Each service will be in its own container(s)
●
Build an image for each service
●
Pin dependencies (packages etc.) accurately
●
Link services together
→ Recommended workflow!

24. I'm Dockerizing some code!
●
●
●
●
Making a single service runnable on Docker
Create a « Dockerfile »
(Think Makefile, Vagrantfile...)
If it's on GitHub, create a Trusted Build
(will automatically build ready-to-run images)
In any case, register it on index.docker.io

25. I'm migrating to Docker!
●
Easy if there is only one service per server
–
Dockerize the service
–
Containerize administrative functions (logs...)
●
Otherwise, try to split services
●
You don't need to move everything to Docker
●
Don't use containers as VMs, even if you can!

26. I'm already using
Chef/Puppet/Salt/Ansible/...!
●
Plan A: generic images
–
–
Run that image just like you would run a VM
–
●
Put your configuration management tool in an image
Great for mixed environments
Plan B: specialized images
–
Put your configuration management tool in an image
–
Run that image, freeze the result, run it!
–
Faster and safer

27. Outline
●
Why should I care?
●
The container metaphor
●
Very quick demo
●
Working with Docker
●
Building images
●
Docker future

28. Authoring images
with run/commit

29. 1) docker run ubuntu bash
2) apt-get install this and that
3) docker commit <containerid> <imagename>
4) docker run <imagename> bash
5) git clone git://.../mycode
6) pip install -r requirements.txt
7) docker commit <containerid> <imagename>
8) repeat steps 4-7 as necessary
9) docker tag <imagename> <user/image>
10) docker push <user/image>

30. Authoring images
with run/commit
●
Pros
–
–
●
Convenient, nothing to learn
Can roll back/forward if needed
Cons
–
Manual process
–
Iterative changes stack up
–
Full rebuilds are boring, error-prone

31. Authoring images
with a Dockerfile

32. FROM ubuntu
RUN
RUN
RUN
RUN
RUN
apt-get
apt-get
apt-get
apt-get
apt-get
-y update
install -y
install -y
install -y
install -y
g++
erlang-dev erlang-manpages erlang-base-hipe ...
libmozjs185-dev libicu-dev libtool ...
make wget
RUN wget http://.../apache-couchdb-1.3.1.tar.gz | tar -C /tmp -zxfRUN 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 .

33. Authoring images
with a Dockerfile
●
Almost nothing to learn
●
Rebuilds are easy
●
Caching system makes rebuilds faster
●
Single file to define the whole environment!

34. Outline
●
Why should I care?
●
The container metaphor
●
Very quick demo
●
Working with Docker
●
Building images
●
Docker future

35. Docker: the community
●
Docker: >330 contributors
●
Docker inc.: <20 engineers
●
latest milestone (0.8): >120 contributors
●
~50% of all commits by external contributors
●
GitHub repository: >1400 forks
...and counting!

36. Coming Soon
●
Network acceleration
●
Container-specific metrics
●
Consolidated logging
●
Plugins (compute backends...)
Those things are already possible,
but will soon be part of the core.

37. Docker 1.0
●
Multi-arch, multi-OS
●
Stable control API
●
Stable plugin API
●
Resiliency
●
Signature
●
Clustering

38. Thank you! Questions?
http://docker.io/
http://docker.com/
https://github.com/dotcloud/docker
@docker
@jpetazzo