1. Two faces of Docker
Witold Kopel, ficio@poczta.fm
Kraków, AGH, 19.05.2015

2. 2
Agenda
● Industry background
● This fever started in 2013 ...
● Architecture overview
● It's all about content ... Docker images – internals
● Containers a'la Docker – devil lies in details
● One hub to rule them all – Docker repositories
● Roll your own image
● How it works in practice
● Where we are heading with all this … - response from
competition/industry

3. 3
Industry background
● Docker, Inc is privately held startup company, started within dotCloud, Inc
(yet another PaaS), located in California (near SF), staff of ~120 (Apr
2015)
http://www.docker.com
● Docker software is publicly available through GitHub
(https://github.com/docker/docker) licensed on Apache License v2.0
model.
● Written in Go!Lang
● Lead by Ben Golub (Cluster, Plaxo) CEO, originated by Solomon Hykes
CTO
● Collaboration with top industry players (RedHat, Google, Amazon,
Microsoft, VMware)
● Support from OpenStack, OpenShift, CoreOS, Google, Amazon, Heroku ...
● $150 mln – investment over 15 months (Jan 2014 - Mar 2015)

4. 4
History
● All started in March 2013 – first drop of Docker to GitHub
● Sep 2013 – alliance with RH
● Oct 2013 – native support from OpenStack (Nova)
● Nov 2013 – v0.7 - support for any Linux distro (storage drivers)
● Apr 2014 – included in RHEL 7.0 and Ubuntu 14.04 LTS, support on AWS
(Elastic Beanstalk)
● Jun 2014 – v1.0
● Jul 2014 – first acquisitions (Orchard & Fig)
● Aug 2014 – sold dotCloud PaaS business to focus on containers, partnership
with Vmware
● Oct 2014 – partnership with Microsoft
● Nov 2014 – EC2 service on AWS, first paid offering
● Feb 2015 – Swarm, Machine, Compose
– orchestration tools for Docker platform,
v1.5

5. 5
Docker Architecture
Container Image
docker commit
docker run
Docker file Docker dir
Docker
Repository
docker pull
docker push
contained in
Text editor
edits
docker build
Copyright (C) 2014 by Steve Litt
imported by Dockerfile "from" statement

6. 6
What is Docker?
● Docker is an open platform for developers and
sysadmins to build, ship, and run distributed
applications
from Docker site
● Misconception clarified:
Runs only on Linux and only for Linux software stack
– for this leverages significant uniformity of Linux ecosystem – common
kernel,
– support for Windows/OSX – through full virtualization (boot2docker –
dedicated Linux distro, you still need HV to run it - like VirtualBox)
– Docker client - native for Windows (experimental)

7. 7
Docker components
● Daemon (must be
run as root)
● Client (local/remote)
Host Host
Docker daemon
ContainerContainerContainer
Docker client
Docker client

8. 8
Basic operations
● Pull (download) image(s) from registry (public/private)
● Run instance(s) of an image as a container – then manage
lifecycle of the container
– start/stop/destroy,
– no snapshot, memory aware suspend/resume,
● You might interact with live container (depending on how it has
been started)
– shell,
– ssh,
– stdin/out,
● Any changes to the container won't affect image
● From existing container create new image with commit operation
● Push (upload) new image(s) to registry – share with others

9. 9
Docker image – what's inside
● Image of filesystem
– completely independent from host fs,
– layered architecture (implementation depends on storage driver),
● Metadata
– host OS interaction settings (networking setup, volume mount
points, entry point, resource control),
– default CT settings (users, working dir),
– reference to internal, underlying image,
● can be loaded/saved to tar file (only way to flatten
image at expense of losing metadata, docker
squash still not implemented)

10. 10
Docker image - naming
● Within host identified by looong ID
# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL
SIZE
[...]
google/debian wheezy 11971b6377ef 3 months ago 88.23 MB
# docker inspect 119
[{
[...]
"Id": "11971b6377ef7b0e3f4c20cd14370abcc70f5d377e9c134817fdb37f99ae348a",
[...]
● for repository identification
REGISTRYHOST/REPONAME/NAME like
172.16.13.1:5000/noc/database, one set per image
● tag as you like

11. 11
Layers (ogres, onions have layers) ...
● Misconception clarified: Layers like onion, not like cake
● Encapsulation, no way to sneak & replace internal
layer
● Writes only to top layer, all inside is RO, commit seals layer making it RO
● Enforcing incremental
evolution of the image
● limited to
128 layers
file system
image
metadata i
m
a
g
e
1
i
m
a
g
e
2
file
system
delta
metadata
file
system
delta
metadata i
m
a
g
e
3a
complete
file system
metadata
file system
delta
i
m
a
g
e 3b
complete
file system

12. 12
Docker container
● Misconception clarified: Docker containers are not virtualization and while may
aspire to paravirtualization, we can argue about this. Think isolation.
● All CTs share host kernel, but not userspace.
● Instance of image
– adds writable layer on top of image,
– runtime specified configuration complements/overrides metadata,
● Identified by long ID and human-friendly name (like whacky_enistein)
● Lifecycle detemined by top process (but might have multiple child processes)
– PID 1 is your top process,
– use system control tools to manage processes within CT (like supervisord),
● Persists until explicitly destroyed (via docker rm ID)
● No explicit snapshot, but can be exported/imported – just FS, memory is
volatile, no suspend/resume,
● Interaction:
– run /bin/bash as top process,
– run ssh daemon and open 'remote' console,
– disable interaction at all (run in daemon mode and no TTY),

13. 13
Why containers are good ...
● Containers are nothing new in Unix world (Solaris
Zones, AIX application WPARs, OpenVZ, BSD Jails,
chroot(), LXC)
● Benefits of virtualization without performance penalties
– isolation (proces, filesystem, network, user)
– resource utilization control
– inter-host migration (for some implementations)
● Eliminate virtualization layers to improve
performance/scalability – at cost of flexibility of
software stack in guest

14. 14
... but Docker implementation is sometimes just OK...
● No LXC anymore (since v0.9/Mar2014), instead Docker's own
dedicated libcontainer library,
● Still leveraging namespaces and control groups of linux Kernel
● Good isolation of FS between CTs
– allows customization by mounted volumes
● from host - up to file level,
● or other CT (data container concept),
– CT to host depends on storage driver,
● and good networking setup
– chose none, bridge, host or container mode,
– but no multiple ifaces oobox,
– and all within host (use weave, swarm)
● and good process namespace isolation

15. 15
... and sometimes simply not
● but then users space isolation – sub-par:
– daemon must run as root,
– all CT run by host root by default, guest root equivalent of host root,
– docker client needs root access (sudo or member of dedicated group),
– all operators are equal and can peek into all CTs,
– not effective userspace isolation (CT vs host),
● and resources control is limited
– CPU (only weighting, no limits),
– memory (not always work oobox),
– no I/O control at all,
● and storage driver woes adds complexity to setup and limit portability
– aufs – won't be in mainline kernel (don't be fooled by Ubuntu 14.04 LTS),
– devmapper – slow and unflexible,
– btrfs – lacks support for security,
– overlayfs – still in it's infancy,
As Red Hat put this clearly – Docker containers do not fully contain
http://www.redhat.com/en/about/blog/shocking-shells-and-bleeding-hearts-do-you-know-what%E
2%80%99s-inside-your-container
.

16. 16
Docker repositories (third does not mean ugly)
● Promote image reuse (incremental building)
● So we need repository to start with then share with others
● One main public repo (maintained by Docker, Inc.)
https://hub.docker.com
– over 45k images, ~100 base images,
– trusted images – special category,
– full engine to build images from Dockerfiles (available for public
inspection),
● Docker image to setup private repo
● Fully specified, maintained API

17. 17
Building Docker image
● Take base image of desired Linux flavor,
● Run it with bash as top process,
● Do what you need (install, configure etc)
– hmm – you want to copy files from host to CT ? Mount host volumes!
– at least network should work OK – mount NFS/CIFS,
– do not forget to clean up FS after yourself,
● Stop CT
● Commit CT to new image
● Good for experimenting/reconnaissance
● Traditional lifecycle model

18. 18
Automate building of Docker image
● Define Dockerfile (makefile) with steps
● Run build – it will execute and produce right image
● Key concept – intermediate image reuse
– will speedup building process,
– but might miss changes in more complex scenario,
Container Image
docker commit
docker run
Docker file Docker dir
Docker
Repository
docker pull
docker push
contained in
Text editor
edits
docker build
Copyright (C) 2014 by Steve Litt
imported by Dockerfile "from" statement

19. 19
Automate building of Docker image
● Define Dockerfile with steps to build desired image
● Define build context – host directory with dependent files
● Run build
FROM ubuntu
MAINTAINER ficio@poczta.fm
RUN apt­get update ­q && apt­get install openssh­server ­­yes
RUN mkdir ­p /var/run/sshd
RUN mkdir ­p /root/.ssh
COPY ficio_id_rsa.pub /root/.ssh/ficio_id_rsa.pub
RUN cat /root/.ssh/ficio_id_rsa.pub >> /root/.ssh/authorized_keys
; rm /root/.ssh/ficio_id_rsa.pub
CMD ["/usr/sbin/sshd", "­D"]
#CMD /usr/sbin/sshd ­D
base image
give credit where credit is due
run commands
copy from context
top process
comment (alternate syntax for top
process wrapped in shell)

20. 20
Docker build – behind the scene
● Build process executed by Docker daemon
– Dockerfile sent to daemon,
– along with context archive (avoid big files),
– .dockerignore (a'la .gitignore),
● Dependencies:
– via context (can't use absolute path for COPY) – as only context is sent
to docker daemon,
– from network (bridge networking mode during build),

21. 21
Docker build – dissected
● At each build step – find right image:
– in image tree – inspect all childs of current image if
suitable found – move on image tree,
● If no transformation – build new image:
– bring intermediate CT with bash as top process,
– executes command,
– commits CT to intermediate image,
– destroys CT,

22. 22
from http://martes13.net/
Docker image tree - example

23. 23
Dockerfile – images are meant to be generic
● Intentionally limited configuration of CT during
build – limit proliferation of the images,
● Docker daemon involvement – promote reuse of
existing images (base images, intermediate
images)
● Repeatable build process - build everywhere,
resulting image can be run everywhere
● Plan your Dockerfile – start from general level then
move to specialization (and forget about data)

24. 24
Docker pains – real world example
● Goal – build image with Oracle DB for
development
● Problems to solve:
– individual copies for separated develpoment,
– deal with evolution of the schema,
– deal with data retention on production,

25. 25
Container clone – ouch – why big is not good !?
● Troubles doing copy of the CT
– missing private registry,
– how badly import behaves (no streaming – seriously !?),
– portability, yeah, sort of (differences in aufs vs devmapper
storage back-end),
– no build-in shutdown control in CT (gracefully kill Oracle),
● But created CT and committed image - good !
● … till first schema change – back to life-cycle management
issues
– apply manually on existing CT ? - Nooooo not in this water again,
– seal existing CT as new image and add on top of it,

26. 26
Hmm – let's use data containers
● Schema modification - do you want to make it part of the image build ? Yes!
● High level idea – one Dockerfile, put sql scripts in context and execute them
during build
– if we will start from the same image, then will lose accumulated data in CT – but
simple schema modification path – always full set of scripts – this won't work for
production,
– we can start from 'latest' image and try to control sql scripts set – but need to
produce 'latest' image before build – production will be OK ...
– but Oracle internals turned this idea unfeasible in general – immediate copy of
database files (image swelling beyond control)
● Ok – our fault, let's use data volumes (data won't be part of the image) –
hmm – no clear boundary between configuration data and user data ...
– turned out to be pointless as Docker building do not support data CTs during build !
● Principle strikes back - images are for runtime, not for data!

27. 27
Gosh – we want to distribute runtime
● If your software stack does not have clean separation
runtime from data (configuration, user) – then bad for
you
● Our solution - make application to control sql schema
(Flyway)
● Generic Oracle image + data CTs
– separate data CTs allow independent management of data,
– Oracle evolution via image,
– need to work out boundaries between configuration and
user data,

28. 28
Summary
● It looks like Docker is more about software distribution model than
another virtualization model
● We need to learn new paradigms
● Docker is tool – use it wisely (Don't force it – just get a bigger hammer)
● Dangers
– image closely tied to Docker container implementation (one environment to run),
– not always fits architecture of current systems (separation of runtime vs config vs
user data),
● Benefits
– transition to new software distribution model – supporting move to new software
life-cycle,
– much easier management of system build from standardized components,
– suitable for well known and controlled workloads tolerating parallelization,

29. 29
Competition and ripple effect
● Rocket – from CoreOS – you and your damn
platform plans, we want containers done right
● Project Atomic (by RH) – you do not need full
RHEL to run containers, don't you ?
● Vagga – yeah, let's fix what Docker broke
● Microsoft – err, containers ? namespaces ? this
is kernel stuff ...

30. 30
Thank You!
ficio@poczta.fm

31. 31
References
http://www.troubleshooters.com/linux/docker/doc
ker_newbie.htm
http://martes13.net/