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
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
18.
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
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!
