This document discusses containerization and the Docker ecosystem. It provides a brief history of containerization technologies and an overview of Docker components like Docker Engine, Docker Hub, and Docker Inc. It also discusses developing with Docker through concepts like Dockerfiles, images, and Fig for running multi-container apps. More advanced topics covered include linking containers, volumes, Docker Machine for provisioning, and clustering with Swarm and Kubernetes.
Presentation by Patrick Chanezon & Tim Park from Microsoft. Focus on developer relations and their expertise.
Formation of DevOps groups and insights into the cloud market, exploring public, hybrid, and private cloud categories.Overview of containerization evolution from 1960s to 2013, highlighting Docker and the Linux container ecosystem.
Explaining what containers are, their VM-like characteristics, network configurations, and filesystem mounting.
Analysis of performance including boot time, disk, and memory usage, showcasing Docker's efficiency.
Initial goals of LXC engine, Docker's ability to build, ship, and run applications seamlessly.
Dockerfiles show how to define container environments, enabling easy creation and management of images.
Discusses how Docker containers enable consistent application deployments regardless of the environment.
Separation of concerns in DevOps, highlighting roles of developers and ops teams in containerization.
Details on Docker Engine, Hub, community contributors, and the company’s portable services.
Guidance on environment setup across different systems and the ease of deployment on various platforms.
Using fig for stack management and integrating CI/CD processes with Docker for automated builds.
Summary of Docker's capabilities, advanced concepts, and future prospects including deployment options.
Discussion on tools like Kubernetes, Deis, and collaboration opportunities for enhancing cloud services.
Wrap-up focusing on strategic engagement, collaboration potential, and various helpful resources.
History of containerization
1960’smainframe
1990’s hardware virtualization
1990’s OS virt precursors: BSD Jails, Solaris zones
2006 Cloud IaaS
2009 platform virtualization (PaaS)
2013 Docker
See @bcantrill’s deck http://www.slideshare.net/bcantrill/docker-and-the-future-of-containers-in-production
It looks likea VM
Private process space
Can run stuff as root
Private network interface and IP address
Custom routes, iptables rules, etc.
Can mount filesystems and more
15.
Faster to boot,less overhead than a VM
$ time docker run ubuntu echo hello world
hello world
real 0m0.258s
Disk usage: less than 100 kB
Memory usage: less than 1.5 MB
16.
Isolation using Linuxkernel features
namespaces
pid
mnt
net
uts
ipc
user
cgroups
memory
cpu
blkio
devices
17.
How does itwork?
Copy-on-write storage
Create a new machine instantly
(Instead of copying its whole filesystem)
Storage keeps track of what has changed
Multiple storage plugins available
(AUFS, device mapper, BTRFS, overlayfs, VFS)
18.
Union Filesystems
(AUFS, overlayfs)
Copy-on-write
blockdevices
Snapshotting
filesystems
Provisioning Superfast
Supercheap
Average
Cheap
Fast
Cheap
Changing
small files
Superfast
Supercheap
Fast
Costly
Fast
Cheap
Changing
large files
Slow (first time)
Inefficient (copy-up!)
Fast
Cheap
Fast
Cheap
Diffing Superfast Slow Superfast
Memory usage Efficient Inefficient
(at high densities)
Inefficient
(but may improve)
Drawbacks Random quirks
AUFS not mainline
Overlayfs bleeding edge
Higher disk usage
Great performance (except
diffing)
ZFS not mainline
BTRFS not as nice
Bottom line Ideal for PAAS, CI/CD, high
density things
Works everywhere,
but slow and inefficient
Will be great once memory
usage is fixed
Storage options
19.
Initial goals
LXCcontainer engine to build a PaaS
Containers as lightweight VMs
(complete with syslog, cron, ssh...)
Part of a bigger puzzle
(other parts: builders, load balancers...)
Say again?
Build:package your application in a container
Ship: move that container from a machine to another
Run: execute that container (i.e. your application)
Any application: anything that runs on Linux
Anywhere: local VM, cloud instance, bare metal...
Dockerfiles
Recipe tobuild a container
Start FROM a base image
RUN commands on top of it
Easy to learn, easy to use
24.
Authoring images
with aDockerfile
Minimal learning curve
Rebuilds are easy
Caching system makes rebuilds faster
Single file to define the whole environment
Single file to define the whole component
25.
FROM ubuntu:14.04
RUN apt-getupdate
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
docker build -t jpetazzo/web .
docker run -d -P jpetazzo/web
« docker build» goodness
Takes a snapshot after each step
Re-uses those snapshots in future builds
Doesn't re-run slow steps (package install...)
when it is not necessary
Deploy reliably &consistently
Images are self-contained, independent from
host
If it works locally, it will work on the server
With exactly the same behavior
Regardless of versions
Regardless of distros
Regardless of dependencies
Execution is fastand lightweight
Containers have no* overhead
Lies, damn lies, and other benchmarks:
http://qiita.com/syoyo/items/bea48de8d7c6d8c73435
http://www.slideshare.net/BodenRussell/kvm-and-docker-lxc-benchmarking-with-openstack
*For some definitions of « no »
35.
Is there reallyno overhead at all?
Processes are isolated,
but run straight on the host
Code path in containers
= code path on native
CPU performance
= native performance
Memory performance
= a few % shaved off for (optional) accounting
Network and disk I/O performance
= small overhead; can be reduced to zero
Docker: the cast
Docker Engine
Docker Hub
Docker, the community
Docker Inc, the company
42.
Docker Engine
OpenSource engine to commoditize LXC
Uses copy-on-write for quick provisioning
Written in Go, runs as a daemon, comes with a CLI
Everything exposed through a REST API
Allows to build images in standard, reproducible way
Allows to share images through registries
Defines standard format for containers
(stack of layers; 1 layer = tarball+metadata)
43.
… Open Source?
Nothing up the sleeve, everything on the table
Public GitHub repository: https://github.com/docker/docker
Bug reports: GitHub issue tracker
Mailing lists: docker-user, docker-dev (Google groups)
IRC channels: #docker, #docker-dev (Freenode)
New features: GitHub pull requests (see CONTRIBUTING.md)
Docker Governance Advisory Board (elected by contributors)
44.
Docker Hub
•Collection ofservices to make Docker more useful.
Library of official base images
Public registry
(push/pull your images for free)
Private registry
(push/pull secret images for $)
Automated builds
(link github/bitbucket repo; trigger build on commit)
More to come!
45.
Docker, the community
>700 contributors
~20 core maintainers
>40,000 Dockerized projects on GitHub
>60,000 repositories on Docker Hub
>25000 meetup members,
>140 cities, >50 countries
>2,000,000 downloads of boot2docker
46.
Docker Inc, thecompany
Headcount: ~70
Revenue:
t-shirts and stickers featuring the cool blue whale
SAAS delivered through Docker Hub
Support & Training
Per-project setup
WriteDockerfiles
Write fig.yml file(s)
Test the result
(i.e.: Make sure that « git clone ; fig up »
works on new Docker machine works fine
55.
Per-developer setup
Makesure that they have Docker
(boot2docker or other method)
git clone ; fig up
Done
56.
Development workflow
Editcode
Iterate locally or in a container
(use volumes to share code between local
machine and container)
When ready to test « the real thing », fig up
57.
Going to production
There are many options
full 45-minutes talk about
« Docker to production »
58.
Implementing CI/CD
Eachtime I commit some code, I want to:
build a container with that code
test that container
if the test is successful, promote that container
59.
Docker Hub tothe rescue
Automated builds let you link github/bitbucket
repositories to Docker Hub repositories
Each time you push to github/bitbucket:
Docker Hub fetches your changes,
builds new containers images,
pushes those images to the registry.
60.
Coming next onDocker Hub...
Security notifications
Automated deployment to Docker hosts
Docker Hub Enterprise
(all those features, on your infrastructure)
61.
Summary
•With Docker, Ican:
put my software in containers
run those containers anywhere
write recipes to automatically build containers
use Fig to effortlessly start stacks of containers
automate testing, building, hosting of images,
using the Docker Hub
62.
Advanced concepts
naming
give a unique name to your containers
links
connect containers together
volumes
separate code and data
share data between containers
Deis (http://deis.io)
• Opensource PaaS platform that builds on CoreOS.
• Replicates the popular Heroku devops workflow.
• Primary mechanism for pushing applications is through git.
• Developer experience is not unlike Azure Websites…
• …but is built on Linux so full support for open source stacks.
• Enables us to win migrations from Salesforce to Azure.
• Hackfest in November to enable Deis for Tagboard.
• Enables us to win startups that expect this workflow.
78.
tpark:www$ git pushdeis master
• Git pushes master to deis git remote on endpoint
• Deis senses static web application
• Selects Heroku Buildpack
• Uses buildpack to build application Docker container.
• Pushes this container to a private Docker registry.
• Orchestrates the creation or update of this container on
the cluster.
• Updates routing mesh to route to these containers.
tpark:api$ git pushdeis master
• Git pushes master to deis git remote on endpoint
• Deis senses node.js application
• Selects Heroku node.js Buildpack
• Uses buildpack to build application Docker container.
• Pushes this container to a private Docker registry.
• Orchestrates the creation or update of this container on
the cluster.
• Updates routing mesh to route to these containers.
tpark:api$ deis config:set
DATABASE_URL=postgres://user:pass@example.com:54
32/db
•Applications in Deis are configured through environmental variables.
• MUST READ: http://12factor.net/
• Key point: Code is separated from config.
• Enables generic containers that are configured at runtime.
• Every app container spun up by Deis will have a copy of these config
environmental variables.
87.
tpark:api$ deis logs
•Deis automatically rolls and consolidates logs from all
containers.