Skip to content

Latest commit

 

History

History
259 lines (172 loc) · 7.97 KB

SLIDESHOW.md

File metadata and controls

259 lines (172 loc) · 7.97 KB
Raw

Docker Know How

An Introduction to Containers

Agenda

  1. History
  2. Containers
  3. Linux Primitives
  4. Docker
  5. Docker breakdown

History

  • 2010: dotCloud YC funded
  • March 2013: Solomon Hykes @PyCon 2013
  • April 2013: Docker is released
  • 2015: Open Container Initiative

Containers

It is important to know that containers are not new this world, by any means.

  • BSD Jails
  • Sun Zones
  • OpenVZ
  • LXC - Still Active Development

Think of Containers as chroot on steroids, minus the virtualized hardware, and but with all the isolations primitives of a VM.

vm vs container

Linux Primitives

Idea of containers is not new and they use three main kernel primitives, namespaces, cgroups and capabilities, to achieve isolation, control and privileges.

  • Namespaces
  • Cgroups
  • Capabilities

Namespaces

One of the overall goals of namespaces to support container isolation, providing the process(es) within them an illusion that they are the only processes in the system.

  • Mount namespaces (CLONE_NEWNS)
  • UTS namespaces (CLONE_NEWUTS)
  • IPC namespaces (CLONE_NEWIPC)
  • PID namespaces (CLONE_NEWPID)
  • Network namespaces (CLONE_NEWNET)
  • User namespaces (CLONE_NEWUSER)

CGroups

CGroups provide a mechanisms to the derive quotas on the use of linux subsystems, and define mechanisms for processes to be restricted within these quotas.

  • cpuset - assigns individual processor(s) and memory nodes to task(s) in a group;
  • cpu - uses the scheduler to provide cgroup tasks access to the processor resources;
  • cpuacct - generates reports about processor usage by a group;
  • io - sets limit to read/write from/to block devices;
  • memory - sets limit on memory usage by a task(s) from a group;
  • devices - allows access to devices by a task(s) from a group;
  • freezer - allows to suspend/resume for a task(s) from a group;
  • net_cls - allows to mark network packets from task(s) from a group;
  • net_prio - provides a way to dynamically set the priority of network traffic per network interface for a group;
  • perf_event - provides access to perf events to a group;
  • hugetlb - activates support for huge pages for a group;
  • pid - sets limit to number of processes in a group.

Linux Capabilities

At a very basic level privileges in linux come twos, regular user and root. If a regular user requires the do some privileges operation of say, using a port number lesser than 1024, the user might require root priveleges. Unfortunately giving root privileges to a user would be giving access to all the resources without limitations, and when that user gets compromized the options are unlimited. To overcome this linux came up with capabilities that give more granular restrictions on what a particular user could do on the system. Hence reducing the attack surface if that user is compromised.

LXC

LXC provided good abrstactions over the Namespaces, CGroups and Capabilities, to contain linux images like ubuntu or fedora. This project is in active development, fixing many of the security and resource management flaws, as they try to me more mainstream. But somehow they failed to captivate the imagination as much as docker did. I feel that the reasons for these where

  • It was positioned more as virtualization model than a packaging model
  • Development was slow as it was a community owned project
  • Barriers of entry was pretty, with much focus on the kernel primitives
  • Interfaces were not conginitive enough for developer adoption
  • Had not matured enough in the given time frame
  • Developed in C

lmctfy(lum-cut-ee-fy)

Seeing the emergence of docker, Google could no longer hide it's container ship behind the curtains of close source. In 2014, Google opensourced their container mechanism to work with a very strange name, lmctfy(Let Me Contain That For You). But failed to make any impact as the feature to feature comparison did not live up to docker's mechanics, also the C++ codebase meant it was for the elitists.

Others in the Room

Well there were others(vagga and rkt) who challenged the monopoly that Docker was gonna be, but fell short. As much as I really want a true competition for Docker nothing really worthy has come around yet. In fact all that the challengers could do was the impact the course of docker, as you would see later in this writing.

Docker

  1. Docker is platform run containers.
  2. docker is service that manages containers.
  3. Docker is company driving the container movement. Docker Inc.

Docker Evolution

lxc

  • Docker as a facade over LXC
  • LXC did the bulk of the heavy lifting
  • Docker provided Image management
  • docker was the the service and the client

libcontainer

  • 0.9.0 release ships with libcontainer
  • Interfaces with namespaces, cgroups and capabilities
  • Provides interfaces to docker daemon
  • Lead the way to become platform agnostic

Monolith

Though docker was moving along pretty fast but there was one problem, the docker engine codebase it was still a monolith doing all the following operations.

  • Providing docker API to the client to operate on
  • Providing the image management services for creating and managing images
  • Managing the container lifecycle by using libcontainerd
  • Providing the network subsystem for containers to communicate with the host as well other containers

Breaking the Monolith

  • Ease of innovation
  • Fast development model
  • The ecosystem demanded the change

OCI - Open Container Initiative

runc

  • Reference is implementation of the OCI Runtime Spec
  • Does only one thing, creates containers
  • Wraps around libcontainer
  • runc exits as soon as the container is created

docker-containerd

  • Interface glue between the dockerd and runc
  • Provides standard interfaces for container lifecycle managements
  • Implements consumers for intefaces exported by OCI Runtime Spec
  • Also includes image management
  • Part of the OCI

docker-containerd-shim

  • daemonless containers
  • Allows the runtimes to exit
  • Owns up as parent of the running container
  • Ensure the dockerd and docker-containerd could upgrade
  • Reports back exit status of the running container to docker-containerd

docerkd

  • API interface to the docker client
  • Implements interface with docker-containerd
  • Provides network
  • Provides storage

Big Picture

The following depict all of the things we discussed above put together.

docker process

Moby

daemon.json

  • Docker starts with default configuration
  • /etc/docker/daemon.json
  • man dockerd to see defaults
  • To debug set it in this file
{
  'debug': true
}

Dockerfile

  • Definition to build docker images
  • Derives FROM other other docker images
  • Docker hub is repo of images
    • Verfied
    • Non verified
  • RUN, CMD, ENTRYPOINT
FROM alpine

RUN apk update
RUN apk add nginx

RUN mkdir -p /run/nginx

EXPOSE 80
CMD ["/usr/sbin/nginx","-g","daemon off;"]