Die Begriffe Docker und Container werden häufig verwendet.
Docker ist hierbei wohl der geläufigere Begriff.
Sie werden durchaus auch zusammen oder synonym als Docker-Container verwendet.
Weshalb dies jedoch nicht richtig ist, soll im Folgenden erläutert werden.
Um erklären zu können was Docker ist, muss zunächst ein Verständnis dafür geschaffen werden, was ein Container ist.
\section{Container}
\emph{\glqq A container is a standard unit of software delivery that allows engineering teams to ship software reliably and automatically.\grqq}
\cite{padok: what is a container}
Aus diesem Satz lassen sich mehrere Eigenschaften eines Containers ableiten: \\
Ein Container \dots
\begin{itemize}
\item wird dazu verwendet Software auszuliefern.
\item unterliegt gewissen Standards.
\item erhöht Zuverlässigkeit.
\item ermöglicht Automatisierung.
\end{itemize}
Die einzelnen Punkte lassen sich noch besser verstehen,
wenn man einen Blick auf die technischen Details wirft, die einen Container ausmachen.
Ein Container setzt sich aus drei ihm zugrundeliegenden Technologien zusammen,
den Namespaces\cite{man-pages: namespaces}, Control Groups\cite{kernel: cgroups} und Union-File-Systems\cite{Unionfs: website}. \cite{docker-docs: underlying-technology}
Zusammen ergeben sie einen Container, dessen Format von der OCI\footnote{
\emph{\glqq Die Open-Container-Initiative ist ein Projekt der Linux-Foundation,
um offene Standards für Container zu definieren.\grqq}\cite{wiki: oci}}
definiert wird.
Dies dient dazu, dass verschiedene Werkzeuge und die Container zu einander kompatibel sind.
Namespaces und Control Groups sind beide Feature des Linux-Kernels, wurden jedoch unabhängig voneinander entwickelt und sind nicht nur für Container verwendbar.
\begin{description}
\item[Namespaces]\cite{wiki: namespaces}
Namespaces sind ein Feature des Linux-Kernels, welches die Ressourcen des Kernels aufteilt,
sodass eine Gruppe von Prozessen ein Set von Ressourcen sieht,
während eine andere Gruppe von Prozessen ein anderes Set an Ressourcen sieht.
Dies funktioniert, indem die Ressourcen und Prozesse in einem Namespace zusammengefasst werden,
die Namespaces beziehen sich dabei eigenständige Ressourcen.
Folgende Arten von Systemressourcen können von Namespaces abstrahiert werden:
\begin{itemize}
\item Cgroup - Cgroup root directory
\item IPC - System V IPC, POSIX message queues
\item Network - Network devices, stacks, ports, etc.
\item Mount - Mount points
\item PID - Process IDs
\item Time - Boot and monotonic clocks
\item User - User and group IDs
\item UTS - Hostname and NIS, domain name
\end{itemize}
\emph{\glqq A namespace wraps a global system resource in an abstraction that
makes it appear to the processes within the namespace that they have
their own isolated instance of the global resource. Changes to the
global resource are visible to other processes that are members of
the namespace, but are invisible to other processes. One use of
namespaces is to implement containers.\grqq}\cite{man-pages: namespaces}
\item[Cgroups]
Control Groups (cgroups) sind ebenfalls ein Kernel-Feature. Es dient dazu die Nutzung von Ressourcen (CPU, RAM, disk I/O, etc.) für eine Gruppe von Prozessen zu limitieren und isolieren. \cite{wiki: cgroups}
Darüber hinaus kännen mit Cgroups Prozesse hierarchisch organisiert werden, sodass eine Baumstruktur an Prozessen ensteht, wobei jeder Prozess nur einer Cgroup angehört. Somit gehören auch alle Threads eines Prozesses zu einer Cgroup. \cite{kernel: cgroups}
Weiterführender Artikel auf LWN.net zu \glqq Process containers\grqq\cite{lwn.net: process containers}
\item[Union-File-Systems]
Ein Union-File-System stellt ein Dateisystem dar, indem es Verzeichnisse und Dateien in Branches gruppiert.
Diese Branches können übereinander gestapelt werden, sodass mehrere Layer entstehen.
Auf diese Art werden Images für Container erstellt.
Teilen Images für Container die selbe Basis (die selben Layer), müssen diese nicht neu angelegt werden,
sondern existieren als Referenz.
Für den Einsatz mit Containern wird dabei das Copy-on-Write Prinzip verwendet.
Das bedeutet, dass beim Start eines Containers keine Dateine geladen oder kopiert werden müssen.
Soll eine Datei geändert werden, dann wird diese Datei kopiert und die Änderung in der Kopie vorgenommen.
Hierzu werden leere read-write Layer für jeden Layer des Images angelegt, die Änderungen finden in diesen Layern statt.
Die Kopie verdeckt anschlißend die Referenz in dem Image. \cite{gtibooks: docker}
Die Images für Container können sehr klein sein, da sich mehrere Images das selbe Base-Image (z.B. mit einem Debian Betriebsystem) teilen. Nur die Änderungen und Ergenzungen für das neuen Image benötigen zusätzlichen Speicher.\cite{wiki: unionfs}
\end{description}
\section{Docker}
Wie bereits einleitend erwähnt baut Docker auf diesen Technologien auf.
Docker ist ein Werkzeug mit dem diese verwendet und verwaltet werden können,
sodass sie zusammen als Container verwendet werden können.
\emph{\dots Fortsetzung folgt}
\begin{thebibliography}{}
\begin{bibcomment}
Die Online Quellen beziehen sich auf den Stand im Mai 2020.
