1 Docker Open Source Engine Overview #
Docker Open Source Engine is a lightweight virtualization solution to run multiple virtual units (containers) simultaneously on a single control host. Containers are isolated with Kernel Control Groups ( Control groups ) and Namespace .
Full virtualization solutions such as Xen, KVM, or libvirt are based
on the processor simulating a complete hardware environment and
controlling the virtual machines. However, Docker Open Source Engine only provides operating
system-level virtualization where the Linux kernel controls isolated
containers.
Before going into detail about Docker Open Source Engine, let's define some of the terms used:
- Docker Open Source Engine
Docker Open Source Engine is a server-client type application that performs all tasks related to virtual machines. Docker Open Source Engine comprises the following:
daemon - is the server side of Docker Open Source Engine that manages all Docker objects (images, containers, network used by containers, etc.)
REST API - applications can use this API to communicate directly with the daemon
a CLI client - that enables you to communicate with the daemon. If the daemon is running on a different machine than the CLI client, the CLI client can communicate by using network sockets or the REST API provided by Docker Open Source Engine.
- Image
An image is a read-only template used to create a virtual machine on the host server. A Docker image is made by a series of layers built one over the other. Each layer corresponds to a permanent change, for example an update of an application. The changes are stored in a file called a
Dockerfile. For more details see the official Docker documentation.- Dockerfile
A
Dockerfilestores changes made on top of the base image. The Docker Open Source Engine reads instructions in the Dockerfile and builds a new image according to the instructions.- Container
A container is a running instance based on a particular Docker Image. Each container can be distinguished by a unique container ID.
- Registry
A registry is storage for already created images. It typically contains several repositories There are two types of registry:
public registry - where everyone (usually registered) can download and use images. A typical public registry is Docker Hub.
private registry - these are accessible for particular users or from a particular private network.
- Repository
A repository is storage in a registry that stores a different version of a particular image. You can pull or push images from or to a repository.
- Control groups
Control groups, also called
cgroups, is a Linux kernel feature that allows aggregating or partitioning tasks (processes) and all their children into hierarchically organized groups to isolate resources.- Namespace
Docker Open Source Engine uses namespaces for its containers that isolates resources reserved for particular containers.
- Orchestration
In a production environment you typically need a cluster with many containers on each cluster node. The containers must cooperate and you need a framework that enables you to manage the containers automatically. The act of automatic container management is called container orchestration and is typically handled by Kubernetes.
Docker Open Source Engine is a platform that allows developers and system administrators to manage the complete life cycle of images. Docker Open Source Engine makes it easy to build, ship and run images containing applications.
Docker Open Source Engine provides you with the following advantages:
Isolation of applications and operating systems through containers.
Near native performance, as Docker Open Source Engine manages allocation of resources in real time.
Controls network interfaces and resources available inside containers through cgroups.
Versioning of images.
Allows building new images based on existing ones.
Provides you with container orchestration.
On the other hand, Docker Open Source Engine has the following limitations:
Containers run inside the host system's kernel and cannot use a different kernel.
Only allows Linux guest operating systems.
Docker Open Source Engine is not a full virtualization stack like Xen, KVM, or
libvirt.Security depends on the host system. Refer to the official security documentation for more details.
1.1 Docker Open Source Engine Architecture #
Docker Open Source Engine uses a client/server architecture. You can use the CLI client to communicate with the daemon. The daemon then performs operations with containers and manages images locally or in registry. The CLI client can run on the same server as the host daemon or on a different machine. The CLI client communicates with the daemon by using network sockets. The architecture is depicted in Figure 1.1, “The Docker Open Source Engine architecture”.
1.2 Docker Open Source Engine Drivers #
1.2.1 Container Drivers #
Docker Open Source Engine uses libcontainer as the back-end driver to handle containers.
1.2.2 Storage Drivers #
Docker Open Source Engine supports different storage drivers:
vfs: this driver is automatically used when the Docker host file system does not support copy-on-write. This is a simple driver which does not offer some advantages of Docker Open Source Engine (like sharing layers, more on that in the next sections). It is highly reliable but also slow.devicemapper: this driver relies on the device-mapper thin provisioning module. It supports copy-on-write, hence it offers all the advantages of Docker Open Source Engine.btrfs: this driver relies on Btrfs to provide all the features required by Docker Open Source Engine. To use this driver the/var/lib/dockerdirectory must be on a Btrfs file system.AUFS: this driver relies on the AUFS union file system. Neither the upstream kernel nor the SUSE one supports this file system. Hence the AUFS driver is not built into the SUSE docker package.
SLE 12 uses the Btrfs file system by default, which leads Docker Open Source Engine
to use the btrfs driver.
It is possible to specify which driver to use by changing the value of
the DOCKER_OPTS variable defined inside of the
/etc/sysconfig/docker file. This can be done either
manually or using YaST by browsing to › › › › menu and entering the
-s storage_driver string.
For example, to force the usage of the
devicemapper driver enter the
following text:
DOCKER_OPTS="-s devicemapper"
/var/lib/docker
It is recommended to have /var/lib/docker mounted
on a separate partition or volume to not affect the Docker Open Source Engine host operating
system in case of a file system corruption.
In case you choose the Btrfs file system for
/var/lib/docker, it is strongly recommended to create
a subvolume for it. This ensures that the directory is excluded from file
system snapshots. If not excluding /var/lib/docker
from snapshots, the file system will likely run out of disk space soon
after you start deploying containers. What's more, a rollback to a
previous snapshot will also reset the Docker Open Source Engine database and images. Refer to
Creating and Mounting New Subvolumes in Section 7.1, “Default Setup”
for details.