Professional Documents
Culture Documents
01-Docker For Sysadmins What S in It For Me
01-Docker For Sysadmins What S in It For Me
Sysadmins:
what's in it
for me?
1 / 76
Who am I?
Jrme Petazzoni (@jpetazzo)
French software engineer living in California
Joined Docker (dotCloud) more than 4 years ago
(I was at Docker before it was cool!)
I have built and scaled the dotCloud PaaS
I learned a few things about running containers
(in production)
Started an hosting company in 2004
Sysadmin since 1999
2 / 76
Outline
Intro / pop quizz about Docker and containers
Sysadmin point of view: VMs vs containers
Ops will be ops, devs will be devs
Composing stacks of containers
Is it safe to use it yet?
3 / 76
Recap
about Docker
and containers
4 / 76
5 / 76
6 / 76
7 / 76
8 / 76
9 / 76
Command-line tools
(AWS CLI, Ffmpeg...)
10 / 76
Command-line tools
(AWS CLI, Ffmpeg...)
Desktop apps
(Chrome, LibreOffice, Skype, Steam...)
11 / 76
12 / 76
13 / 76
14 / 76
15 / 76
16 / 76
17 / 76
18 / 76
19 / 76
20 / 76
21 / 76
22 / 76
23 / 76
24 / 76
25 / 76
26 / 76
27 / 76
VMs vs
containers
28 / 76
Portability
Containers can run on top of public cloud
(run the same container image everywhere)
Nested hypervisors (VMs in VMs) exist, but still rare
Containers are easy to move
(thanks to layers, distribution protocol, registry...)
VM images have to be converted and transferred
(both are slow operations)
29 / 76
30 / 76
31 / 76
32 / 76
33 / 76
Blurring lines
Intel Clear Containers; Clever Cloud
(stripped down VMs, boot super fast, tiny footprint)
Joyent Triton
(Solaris "branded zones," running Linux binaries securely,
exposing the Docker API)
Ongoing efforts to harden containers
(GRSEC, SELinux, AppArmor)
34 / 76
VMs vs
containers
(hoster/ops
perspective)
35 / 76
Inside
VMs need a full OS and associated tools
(Backups, logging, periodic job execution, remote access...)
Containers can go both ways:
machine container
(runs init, cron, ssh, syslog ... and the app)
application container
(runs the app and nothing else;
relies on external mechanisms)
36 / 76
VM lifecycle
Option 1: long lifecycle
(provisioningupdateupdateupdatedisposal)
easily leads to configuration drift
(subtle differences that add up over time)
requires tight configuration management
Option 2: golden images
(phoenix servers, immutable infrastructure ...)
create new image for each modification
deploy by replacing old servers with new servers
nice and clean, but heavy and complex to setup
37 / 76
Container lifecycle
Containers are created from an image
Image creation is easy
Image upgrade is fast
Immutable infrastructure is easy to implement
38 / 76
39 / 76
40 / 76
Bloated containers
Containers have all the software required for production
In dev mode, only essential processes are started
In prod mode, additional processes run as well
Problems:
bigger containers
behavior can differ (because of extra processes)
extra processes duplicated between containers
hard to test those extra processes in isolation
41 / 76
Separation of
concerns
(let ops do ops,
and devs do dev)
42 / 76
Principle
"Do one thing, do it well"
One container for the component itself
One container for logging
One container for monitoring
One container for backups
One container for debugging (when needed)
etc.
43 / 76
44 / 76
Let's dive
into the details
45 / 76
46 / 76
47 / 76
Logging takeaways
Application can be "dumb" about logging
Log collection and shipping happens in Docker,
or in separate(s) container(s)
Run custom log analyzer without changing app container
(e.g. apachetop)
Migrate logging system without changing app container
48 / 76
"Yes, but..."
"What about performance overhead?"
no performance overhead
both containers access files directly
(just like processes running on the same machine)
"What about synchronization issues?"
same as previous answer!
49 / 76
Backups (file-based)
Store mutable data on Docker volumes
(same mechanism as for logs)
Share volumes with special-purpose backup containers
Put backup tools in the backup container
(boto, rsync, s3cmd, unison...)
docke
rru
n-vol
um
es
fr
o
mm
y
db
1u
b
u
nt
u\
rs
yn
c-av/
va
r
/l
i
b/b
ac
k
up
@
r
em
o
te
h
o
st
:
mydb1/
The whole setup doesn't touch the app (or DB) container
50 / 76
Backups (network-based)
Run the backup job (p
g
_d
u
m
p, m
ys
q
l
du
m
p
, etc.)
from a separate container
Advantages (vs. running in the same container):
nothing to install in the app (or DB) container
if the backup job runs amok, it remains contained (!)
another team can maintain backup jobs
(and be responsible for them)
51 / 76
Network analysis
Packet capture (tc
p
du
m
p
,n
g
re
p
, nt
o
p, etc.)
Low-level metrics (ne
t
s
ta
t
,s
s
, etc.)
Install required tools in a separate container image
Run a container in the same network namespace
docke
rru
n-d-na
mewe
b
1n
g
in
x
docke
rru
n-t
i-n
etco
n
ta
i
n
er
:
we
b
1t
c
pd
u
m
ppnieth0
docke
rru
n-t
i-n
etco
n
ta
i
n
er
:
we
b
1u
b
un
t
us
s-n--tcp
52 / 76
Service discovery
Docker can do linking and generic DNS injection
Your code connects to e.g. r
ed
i
s
(pretending that re
di
sresolves to something)
Docker adds a DNS alias* so that r
ed
i
sresolves
to the right container, or to some external service
In dev, Docker Compose manages service dependencies
In prod, you abstract service discovery from the container
53 / 76
54 / 76
55 / 76
56 / 76
57 / 76
58 / 76
General pattern
Your code runs in the same container in dev and prod
Add "sidekick*" containers for additional tasks
Developers don't have to be bothered about ops
Ops can do their job without messing with devs' code
59 / 76
Composing
stacks of
containers
60 / 76
Docker Compose
61 / 76
docker-compose.yml
rng:
build: rng
hasher:
build: hasher
webui:
build: webui
links:
- redis
ports:
- "80:80"
volumes:
- "webui/files/:/files/"
redis:
image: redis
worker:
build: worker
links:
- rng
- hasher
- redis
62 / 76
Docker Compose
Start whole stack with do
c
k
er
co
m
p
os
eup
Start individual containers (and their dependencies)
with do
ck
er
-co
mp
os
eu
px
y
z
Takes care of container lifecycle
(creation, update, data persistence, scaling up/down...)
Doesn't automatically solve networking and discovery (yet)
63 / 76
Docker Compose
Start whole stack with do
c
k
er
co
m
p
os
eup
Start individual containers (and their dependencies)
with do
ck
er
-co
mp
os
eu
px
y
z
Takes care of container lifecycle
(creation, update, data persistence, scaling up/down...)
Doesn't automatically solve networking and discovery (yet)
... However ...
64 / 76
docker-compose.yml, reloaded
hashe
r
:
b
u
ild
:ha
she
r
worke
r
:
b
u
ild
:wo
rke
r
l
i
nks
:
-r
ng
-h
as
he
rpr
ox
y:
h
as
h
er
-r
ed
is
hashe
r
pro
xy
:
i
m
age
:jp
eta
zz
o/
h
am
b
a
l
i
nks
:
-h
as
he
r
c
o
mma
nd
:80ha
sh
e
r8
0
(This was automatically generated by a tiny Python script.)
65 / 76
Heads up!
Docker networking is evolving quickly
Docker 1.7 has hooks to support:
"networks" as first class objects
multiple networks
overlay driver allowing to span networks across
multiple hosts
networking plugins from ecosystem partners
66 / 76
Conclusions
67 / 76
Conclusions
Containers can share more context than VMs
We can use this to decouple complexity
(think "microservices" but for ops/devs separation)
All tasks typically requiring VM access
can be done in separate containers
As a result, deployments are broken down
in smaller, simpler pieces
Complex stacks are expressed with simple YAML files
Docker isn't a "silver bullet" to solve all problems,
but it gives us tools that make our jobs easier
68 / 76
69 / 76
70 / 76
71 / 76
72 / 76
73 / 76
74 / 76
75 / 76
Thanks!
Questions?
@jpetazzo
@docker