Docker_AGH_v0.1.3
31
-
Upload
witold-ficio-kopel -
Category
Documents
-
view
46 -
download
2
Transcript of Docker_AGH_v0.1.3
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
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
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
Docker Architecture
Container Image
docker commit
docker run
Docker file Docker dir
Docker Repository
docker pull
docker push
contained in
Text editoredits
docker build
Copyright (C) 2014 by Steve Litt
imported by Dockerfile "from" statement
6
What is Docker?
● Docker is an open platform for developers and sysadmins to build, ship, and run distributed applicationsfrom 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
Docker components
● Daemon (must be run as root)
● Client (local/remote)
Host Host
Docker daemon
ContainerContainerContainer
Docker client
Docker client
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
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
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
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 systemimage
metadata image1
image2
filesystemdelta
metadata
filesystemdelta
metadata image3a
completefile system
metadata
file systemdelta
image 3b
completefile system
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
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
... 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
... 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 containhttp://www.redhat.com/en/about/blog/shocking-shells-and-bleeding-hearts-do-you-know-what%E2%80%99s-inside-your-container.
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
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
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 editoredits
docker build
Copyright (C) 2014 by Steve Litt
imported by Dockerfile "from" statement
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 [email protected]
RUN aptget update q && aptget install opensshserver 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
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
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,
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
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
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
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
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
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
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 ...
31
References
http://www.troubleshooters.com/linux/docker/docker_newbie.htmhttp://martes13.net/
