SlideShare a Scribd company logo
Hugo González Labrador
Docker is an open platform for building, shipping and running
distributed applications. It gives programmers, development
teams and operations engineers the common toolbox they need
to take advantage of the distributed and networked nature of
modern applications.
Hugo González Labrador
Miércoles 7 de Octubre en el aula SO3 a las 17:00
HOLY SHIP!
“I once heard that hypervisors are
the living proof of operating system's incompetence”
Glauber Costa's talk at LinuxCon Europe 2012
https://lwn.net/Articles/524952/
Hypervisor
Physical Resources (RAM, CPU, Network …)
Kernel
HOST OS
OS Apps
VM
Kernel
OS Apps
Hypervisor
OS Apps
VM
Kernel
Hypervisor
OS Apps
VM
Kernel
Physical Resources (RAM, CPU, Network …)
Kernel
HOST OS
Container
OS Apps
Container
OS Apps
Container
OS Apps
Container
OS Apps
Container
OS Apps
Container
OS Apps
Can you run
1000 VMs
on your host ?
2334 web servers
running in containers on a single
Raspberry Pi 2.
Docker Dojo
Docker containers and orchestration
Elvin Sindrilaru
IT Data and Storage Services Group
Outline
• Understanding Linux containers
• Linux namespaces
• Linux cgroups
• Docker containers
• Containers orchestration
• Security considerations
• Benefits
4/16/2015 Docker containers and orchestration 3
What is a container?
4/16/2015 Docker containers and orchestration 4
"Cmglee Container City 2" by Cmglee - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons
Linux containers
• Based on two technologies
• Linux namespaces
• Linux control groups (cgroups)
4/16/2015 Docker containers and orchestration 5
Linux namespace (1)
• The purpose of a namespace is to wrap a particular
global system resource in an abstraction that makes
it appear to the process within the namespace that they
have their own isolated instance of the global
resource.
4/16/2015 Docker containers and orchestration 6
Linux namespace (2)
• Currently there are 6 namespaces implemented in the Linux
Kernel:
• Mount namespaces – isolate the set of file-system mount points
seen by a group of processes (Linux 2.6.19)
• UTS namespaces – isolate two system identifiers – nodename
and domainname. (UNIX Time-sharing System)
• IPC namespaces – isolate inter-process communication
resources e.g. POSIX message queues
4/16/2015 Docker containers and orchestration 7
Linux namespace (3)
• Network namespaces – provides isolation of system resources
associated with networking. Each network namespace has its
own network devices, IP addresses, port numbers etc.
• PID namespaces – isolate process ID number space. Processes
in different PID namespaces can have the same PID number.
• User namespace – isolates the process user and group ID
number spaces. A process’s UID and GID can be different inside
and outside a user namespace i.e a process can have full root
privileges inside a user namespace, but is unprivileged for
operations outside the namespace. (Linux 3.8)
4/16/2015 Docker containers and orchestration 8
Linux cgroups (1)
• Cgroups allow allocating resources to user-defined groups of
processes running on the system
• Cgroup subsystems (resources controllers) = kernel modules
aware of cgroups which allocate varying levels of system resources
to cgroups
• Everything is exposed through a virtual filesystem:
• /cgroups, /sys/fs/cgroup … - mountpoint may vary
• Currently up to 10 subsystems:
• blkio – set limits on input/output access to/from block devices such as
physical drives
• cpuset – assign individual CPUs and memory nodes to tasks in a cgroup
• memory – set limits on memory used by tasks in a cgroup
• etc …
4/16/2015 Docker containers and orchestration 9
Linux cgroups (2)
• libcgroup package provides command line utilities for
manipulating cgroups.
• lssubsys – list available subsystems
• lscgroup – list defined cgroups
• cgget – get parameters of cgroup
• cset – set parameters of cgroup
• cgexec – start a process in a particular cgroup
• cgclassify – move running task to one or more
cgroups
4/16/2015 Docker containers and orchestration 10
Linux containers a.k.a LXC
• Containers
• tool for lightweight virtualization
• provides a group of processes the illusion that they are
the only processes on the system
• Advantages in comparison to traditional VM:
• Fast to deploy - seconds
• Small memory footprint - MBs
• Complete isolation without a hypervisor
Namespaces + Cgroups => Linux containers
4/16/2015 Docker containers and orchestration 11
Linux containers – CLI
• lxc package contains tools to manipulate containers
• lxc-create
• Setup a container (rootfs and configuration)
• lxc-start
• Boot a container
• lxc-console
• Attach a console if started in background
• lxc-attach
• Start a process inside a container
• lxc-stop
• Shutdown a container
• lxc-destroy
• Destroy the container created with lxc-create
4/16/2015 Docker containers and orchestration 12
Docker containers
• “A container is a basic tool, consisting of any device
creating a partially or fully enclosed space that can be
used to contain, store and transport objects or materials.”
http://en.wikipedia.org/wiki/Container
• “Open-source project to easily create light-weight,
portable, self-sufficient containers from any application”
https://www.docker.com/whatisdocker/
• Docker motto: “Build, Ship and Run Any App, Anywhere”
4/16/2015 Docker containers and orchestration 13
Docker interaction
• Client-server model
• Docker daemon
• Process that manages the containers
• Creates files systems, assigns IP addresses, routes
packages, manages processes
=> needs root privileges
• Can bind to Unix or TCP sockets and supports TLS
• RESTful API
• Docker client
• Same binary as the daemon
• Makes GET and POST request to the daemon
4/16/2015 Docker containers and orchestration 14
Docker client-server interaction
4/16/2015 Docker containers and orchestration 15
• The client can run on the same host or on a different one
from the daemon
VMs vs. Docker containers
• VMs are fully virtualized
• Containers are optimized for single applications,
but can also run a full system
4/16/2015 Docker containers and orchestration 16
Docker filesystem
• Typical Linux system needs two filesystems:
• Boot file system (bootfs)
• Root file system (rootfs) - /dev, /etc, /bin, /lib …
• Docker uses by default Another Unionfs (AUFS) which is copy-on-
write
• AUFS
• Helps sharing common portions of the fs among containers
• Layers are read-only and the merger of these layers is visible to the processes
• Any changes to the fs go into the rd/wr layer
4/16/2015 Docker containers and orchestration 17
Docker Images
• Image
• Never changes
• Stack of read-only fs layers
• Changes go in the topmost
writable layer created when the container starts
• Changes are discarded by default when the container is
destroyed
• Where to get Docker Images from?
• https://registry.hub.docker.com/
• Similar to what GitHub is for Git - think “git repository for
images”
• Use your own private registry e.g. pull the docker registry
image and run it in a container
4/16/2015 Docker containers and orchestration 18
Docker Containers
• Container
• Read-write layer
• Information about Parent Image (RO layers)
• Unique id + network configuration + resource limits
• Containers have state: running / exited
• Exited container
• preserves file system state
• does NOT preserve memory state
• Containers can be promoted to an Image using “docker
commit”
Takes a snapshot of the whole filesystem (RW+RO)
4/16/2015 Docker containers and orchestration 19
Docker paradigm shift
• Motto: “write-once-run-anywhere”
• Developers:
• Concentrate on building applications
• Run them inside containers
• Avoid the all too common: “But it works fine on my machine …”
• Sysadmins/operations/DevOps:
• Keep containers running in production
• No more “dependency hell” … almost … at least not traditional ones
⇒ Clean separation of roles
⇒ Single underlying tool which (hopefully) simplifies:
⇒ code management
⇒ deployment process
4/16/2015 Docker containers and orchestration 20
Demo Docker containers
4/16/2015 Docker containers and orchestration 21
Docker workflow automation
• Dockerfile
• Repeatable method to build Docker images – makefile equivalent
• DSL(Domain Specific Language) representing instructions on setting up
an image
• Used together with the context by the “docker build” command to create a
new image
4/16/2015 Docker containers and orchestration 22
# Use the fedora base image
FROM fedora:20
MAINTAINER Elvin Sindrilaru, esindril@cern.ch, CERN 2015
# Add a file from the host to the container
ADD testfile.dat /tmp/testfile
# Install some packages
RUN yum -y --nogpg install screen emacs
# Command executed when container started
CMD /bin/bash
Containers orchestration
• Orchestration describes the automated
arrangement, coordination and management
of complex systems, middleware and
services.
• Library dependencies “sort of” become
container dependencies
4/16/2015 Docker containers and orchestration 23
Container data management using volumes
• Docker volume
• Directory separated from the container’s root filesystem
• Managed by the docker daemon and can be shared
among containers
• Changes to the volume are not captured by the image
• Used to mount a directory of the host system inside the
container
• A volume persists until the last container using it exits
• Data-only containers
• Expose a volume to other data-accessing containers
• Prevents volumes from being destroyed if containers stop
or crash
4/16/2015 Docker containers and orchestration 24
Linking containers
• Not all containers need to bind internal ports to host ports
• E.g. only front-end applications need to connect to backend services
• Linking within the same host
• Profit from the unified view that the docker daemon has over all
running containers
• Use the --link option:
• E.g. docker run --link CONTAINER_ID:ALIAS …
• Effectively alters the /etc/hosts file
• Cross host linking
• Requires a distributed, consistent discovery service
• Much more complicated
• Needs a distributed key-value store to keep info about running
containers e.g. etcd
• Application must be aware of the discovery service
4/16/2015 Docker containers and orchestration 25
Docker Machine & Compose
• Machine
• Creates Docker hosts on a variety of cloud providers
• Built-in support for: VirtualBox, OpenStack, GCE, AWS
etc.
• Manages the Docker daemon
• Configures the client to talk to the new Docker host
• Perfect starting point for OSX and Windows users
• Compose
• Define and run complex applications / multiple containers
• Provide the recipe in a YAML file
• Interact with the running containers
4/16/2015 Docker containers and orchestration 26
Other orchestration tools/frameworks
• Kubernetes
• https://github.com/GoogleCloudPlatform/kubern
etes
• Shipyard
• https://github.com/shipyard/shipyard
• LXC/LXD/CGManage
• https://linuxcontainers.org/
4/16/2015 Docker containers and orchestration 27
Demo Docker orchestration
4/16/2015 Docker containers and orchestration 28
Security considerations
• Docker containers are started with a reduced capability set which
restricts:
• Mount/unmount devices
• Managing raw sockets
• Some fs operations
• Fine-grained control of capabilities using the docker --cap-add --
cap-drop options
• End-goal is to run even the Docker daemon as a non-root user and
delegate operations to dedicated subprocesses
• Run Docker daemon on:
• Unix socket for single-instance setup
• TCP socket with TLS for multi-instance setup
• Keep the host Kernel updated with latest security patches
4/16/2015 Docker containers and orchestration 29
Docker – Benefits
• Portable deployment across machines – overcomes machine specific
configuration issues
• Application-centric – optimized for deployment of applications and not
machines
• Automatic build – can use any configuration management system
(puppet, chef, ansible etc) to automate the build of containers
• Versioning - git like capabilities to track container versions
• Component reuse – any container can become a base image
• Sharing – use the public registry to distribute container images, just like a
git repository
4/16/2015 Docker containers and orchestration 30
Docker Dojo

More Related Content

Docker Dojo

  • 1. Hugo González Labrador Docker is an open platform for building, shipping and running distributed applications. It gives programmers, development teams and operations engineers the common toolbox they need to take advantage of the distributed and networked nature of modern applications. Hugo González Labrador Miércoles 7 de Octubre en el aula SO3 a las 17:00
  • 3. “I once heard that hypervisors are the living proof of operating system's incompetence” Glauber Costa's talk at LinuxCon Europe 2012 https://lwn.net/Articles/524952/
  • 4. Hypervisor Physical Resources (RAM, CPU, Network …) Kernel HOST OS OS Apps VM Kernel OS Apps Hypervisor OS Apps VM Kernel Hypervisor OS Apps VM Kernel
  • 5. Physical Resources (RAM, CPU, Network …) Kernel HOST OS Container OS Apps Container OS Apps Container OS Apps Container OS Apps Container OS Apps Container OS Apps
  • 6. Can you run 1000 VMs on your host ?
  • 7. 2334 web servers running in containers on a single Raspberry Pi 2.
  • 9. Docker containers and orchestration Elvin Sindrilaru IT Data and Storage Services Group
  • 10. Outline • Understanding Linux containers • Linux namespaces • Linux cgroups • Docker containers • Containers orchestration • Security considerations • Benefits 4/16/2015 Docker containers and orchestration 3
  • 11. What is a container? 4/16/2015 Docker containers and orchestration 4 "Cmglee Container City 2" by Cmglee - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons
  • 12. Linux containers • Based on two technologies • Linux namespaces • Linux control groups (cgroups) 4/16/2015 Docker containers and orchestration 5
  • 13. Linux namespace (1) • The purpose of a namespace is to wrap a particular global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of the global resource. 4/16/2015 Docker containers and orchestration 6
  • 14. Linux namespace (2) • Currently there are 6 namespaces implemented in the Linux Kernel: • Mount namespaces – isolate the set of file-system mount points seen by a group of processes (Linux 2.6.19) • UTS namespaces – isolate two system identifiers – nodename and domainname. (UNIX Time-sharing System) • IPC namespaces – isolate inter-process communication resources e.g. POSIX message queues 4/16/2015 Docker containers and orchestration 7
  • 15. Linux namespace (3) • Network namespaces – provides isolation of system resources associated with networking. Each network namespace has its own network devices, IP addresses, port numbers etc. • PID namespaces – isolate process ID number space. Processes in different PID namespaces can have the same PID number. • User namespace – isolates the process user and group ID number spaces. A process’s UID and GID can be different inside and outside a user namespace i.e a process can have full root privileges inside a user namespace, but is unprivileged for operations outside the namespace. (Linux 3.8) 4/16/2015 Docker containers and orchestration 8
  • 16. Linux cgroups (1) • Cgroups allow allocating resources to user-defined groups of processes running on the system • Cgroup subsystems (resources controllers) = kernel modules aware of cgroups which allocate varying levels of system resources to cgroups • Everything is exposed through a virtual filesystem: • /cgroups, /sys/fs/cgroup … - mountpoint may vary • Currently up to 10 subsystems: • blkio – set limits on input/output access to/from block devices such as physical drives • cpuset – assign individual CPUs and memory nodes to tasks in a cgroup • memory – set limits on memory used by tasks in a cgroup • etc … 4/16/2015 Docker containers and orchestration 9
  • 17. Linux cgroups (2) • libcgroup package provides command line utilities for manipulating cgroups. • lssubsys – list available subsystems • lscgroup – list defined cgroups • cgget – get parameters of cgroup • cset – set parameters of cgroup • cgexec – start a process in a particular cgroup • cgclassify – move running task to one or more cgroups 4/16/2015 Docker containers and orchestration 10
  • 18. Linux containers a.k.a LXC • Containers • tool for lightweight virtualization • provides a group of processes the illusion that they are the only processes on the system • Advantages in comparison to traditional VM: • Fast to deploy - seconds • Small memory footprint - MBs • Complete isolation without a hypervisor Namespaces + Cgroups => Linux containers 4/16/2015 Docker containers and orchestration 11
  • 19. Linux containers – CLI • lxc package contains tools to manipulate containers • lxc-create • Setup a container (rootfs and configuration) • lxc-start • Boot a container • lxc-console • Attach a console if started in background • lxc-attach • Start a process inside a container • lxc-stop • Shutdown a container • lxc-destroy • Destroy the container created with lxc-create 4/16/2015 Docker containers and orchestration 12
  • 20. Docker containers • “A container is a basic tool, consisting of any device creating a partially or fully enclosed space that can be used to contain, store and transport objects or materials.” http://en.wikipedia.org/wiki/Container • “Open-source project to easily create light-weight, portable, self-sufficient containers from any application” https://www.docker.com/whatisdocker/ • Docker motto: “Build, Ship and Run Any App, Anywhere” 4/16/2015 Docker containers and orchestration 13
  • 21. Docker interaction • Client-server model • Docker daemon • Process that manages the containers • Creates files systems, assigns IP addresses, routes packages, manages processes => needs root privileges • Can bind to Unix or TCP sockets and supports TLS • RESTful API • Docker client • Same binary as the daemon • Makes GET and POST request to the daemon 4/16/2015 Docker containers and orchestration 14
  • 22. Docker client-server interaction 4/16/2015 Docker containers and orchestration 15 • The client can run on the same host or on a different one from the daemon
  • 23. VMs vs. Docker containers • VMs are fully virtualized • Containers are optimized for single applications, but can also run a full system 4/16/2015 Docker containers and orchestration 16
  • 24. Docker filesystem • Typical Linux system needs two filesystems: • Boot file system (bootfs) • Root file system (rootfs) - /dev, /etc, /bin, /lib … • Docker uses by default Another Unionfs (AUFS) which is copy-on- write • AUFS • Helps sharing common portions of the fs among containers • Layers are read-only and the merger of these layers is visible to the processes • Any changes to the fs go into the rd/wr layer 4/16/2015 Docker containers and orchestration 17
  • 25. Docker Images • Image • Never changes • Stack of read-only fs layers • Changes go in the topmost writable layer created when the container starts • Changes are discarded by default when the container is destroyed • Where to get Docker Images from? • https://registry.hub.docker.com/ • Similar to what GitHub is for Git - think “git repository for images” • Use your own private registry e.g. pull the docker registry image and run it in a container 4/16/2015 Docker containers and orchestration 18
  • 26. Docker Containers • Container • Read-write layer • Information about Parent Image (RO layers) • Unique id + network configuration + resource limits • Containers have state: running / exited • Exited container • preserves file system state • does NOT preserve memory state • Containers can be promoted to an Image using “docker commit” Takes a snapshot of the whole filesystem (RW+RO) 4/16/2015 Docker containers and orchestration 19
  • 27. Docker paradigm shift • Motto: “write-once-run-anywhere” • Developers: • Concentrate on building applications • Run them inside containers • Avoid the all too common: “But it works fine on my machine …” • Sysadmins/operations/DevOps: • Keep containers running in production • No more “dependency hell” … almost … at least not traditional ones ⇒ Clean separation of roles ⇒ Single underlying tool which (hopefully) simplifies: ⇒ code management ⇒ deployment process 4/16/2015 Docker containers and orchestration 20
  • 28. Demo Docker containers 4/16/2015 Docker containers and orchestration 21
  • 29. Docker workflow automation • Dockerfile • Repeatable method to build Docker images – makefile equivalent • DSL(Domain Specific Language) representing instructions on setting up an image • Used together with the context by the “docker build” command to create a new image 4/16/2015 Docker containers and orchestration 22 # Use the fedora base image FROM fedora:20 MAINTAINER Elvin Sindrilaru, esindril@cern.ch, CERN 2015 # Add a file from the host to the container ADD testfile.dat /tmp/testfile # Install some packages RUN yum -y --nogpg install screen emacs # Command executed when container started CMD /bin/bash
  • 30. Containers orchestration • Orchestration describes the automated arrangement, coordination and management of complex systems, middleware and services. • Library dependencies “sort of” become container dependencies 4/16/2015 Docker containers and orchestration 23
  • 31. Container data management using volumes • Docker volume • Directory separated from the container’s root filesystem • Managed by the docker daemon and can be shared among containers • Changes to the volume are not captured by the image • Used to mount a directory of the host system inside the container • A volume persists until the last container using it exits • Data-only containers • Expose a volume to other data-accessing containers • Prevents volumes from being destroyed if containers stop or crash 4/16/2015 Docker containers and orchestration 24
  • 32. Linking containers • Not all containers need to bind internal ports to host ports • E.g. only front-end applications need to connect to backend services • Linking within the same host • Profit from the unified view that the docker daemon has over all running containers • Use the --link option: • E.g. docker run --link CONTAINER_ID:ALIAS … • Effectively alters the /etc/hosts file • Cross host linking • Requires a distributed, consistent discovery service • Much more complicated • Needs a distributed key-value store to keep info about running containers e.g. etcd • Application must be aware of the discovery service 4/16/2015 Docker containers and orchestration 25
  • 33. Docker Machine & Compose • Machine • Creates Docker hosts on a variety of cloud providers • Built-in support for: VirtualBox, OpenStack, GCE, AWS etc. • Manages the Docker daemon • Configures the client to talk to the new Docker host • Perfect starting point for OSX and Windows users • Compose • Define and run complex applications / multiple containers • Provide the recipe in a YAML file • Interact with the running containers 4/16/2015 Docker containers and orchestration 26
  • 34. Other orchestration tools/frameworks • Kubernetes • https://github.com/GoogleCloudPlatform/kubern etes • Shipyard • https://github.com/shipyard/shipyard • LXC/LXD/CGManage • https://linuxcontainers.org/ 4/16/2015 Docker containers and orchestration 27
  • 35. Demo Docker orchestration 4/16/2015 Docker containers and orchestration 28
  • 36. Security considerations • Docker containers are started with a reduced capability set which restricts: • Mount/unmount devices • Managing raw sockets • Some fs operations • Fine-grained control of capabilities using the docker --cap-add -- cap-drop options • End-goal is to run even the Docker daemon as a non-root user and delegate operations to dedicated subprocesses • Run Docker daemon on: • Unix socket for single-instance setup • TCP socket with TLS for multi-instance setup • Keep the host Kernel updated with latest security patches 4/16/2015 Docker containers and orchestration 29
  • 37. Docker – Benefits • Portable deployment across machines – overcomes machine specific configuration issues • Application-centric – optimized for deployment of applications and not machines • Automatic build – can use any configuration management system (puppet, chef, ansible etc) to automate the build of containers • Versioning - git like capabilities to track container versions • Component reuse – any container can become a base image • Sharing – use the public registry to distribute container images, just like a git repository 4/16/2015 Docker containers and orchestration 30