Namespaces sind ein Feature des Linux-Kernels, welches die Ressourcen des Kernels aufteilt,
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.
\emph{\glqq A namespace wraps a global system resource in an abstraction that
Dies funktioniert, indem die Ressourcen und Prozesse in einem Namespace zusammengefasst werden,
makes it appear to the processes within the namespace that they have
die Namespaces beziehen sich dabei eigenständige Ressourcen.
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}
Ein Kernel-Namespace verpackt eine globale Systemressource in eine Abstraktion, diese lässt die Ressource
innerhalb des Namespaces so aussehen, als hätte der Prozess seine eigene isolierte Instanz der globalen Ressource.
Änderungen die an der globalen Ressource vorgenommen werden sind für andere Prozesse sichtbar, die Teil des Namespace sind.
Für andere Prozesse sind diese Änderungen aber unsichtbar.
Folgende Arten von Systemressourcen können von Namespaces abstrahiert werden:
Folgende Arten von Systemressourcen können von Namespaces abstrahiert werden:
\begin{itemize}
\begin{itemize}
\item Cgroup - Cgroup root directory
\item Cgroup - Cgroup root directory
\item IPC - System V IPC, POSIX message queues
\item IPC - System V IPC, POSIX message queues
\item Network - Network devices, stacks, ports, etc.
\item Network \cite{man-pages: network-namespaces}- Network devices, stacks, ports, etc.
\item Mount - Mount points
\item Mount - Mount points
\item PID - Process IDs
\item PID - Process Identifiers ()
\item Time - Boot and monotonic clocks
\item Time - Boot and monotonic clocks
\item User - User and group IDs
\item User - User and group IDs
\item UTS - Hostname and NIS, domain name
\item UTS - Hostname and NIS, domain name
\end{itemize}
\end{itemize}
\emph{\glqq A namespace wraps a global system resource in an abstraction that
Der PID-Namespace bietet Isolation für die Allokation von PIDs, Listen von Prozessen und deren Details.
makes it appear to the processes within the namespace that they have
Ein neuer Namespace ist isoliert von anderen \emph{Geschwistern}, jedoch nicht von seinem \glqq{Eltern}-Namespace
their own isolated instance of the global resource. Changes to the
worin alle Prozesse des \emph{Kind}-namespaces sichtbar sind, jedoch mit anderen PIDs.
global resource are visible to other processes that are members of
the namespace, but are invisible to other processes. One use of
Mit dem Network-Namespace werden sowohl physische als auch virtuelle Netwerkgeräte, so wie iptables, firewall routing tables
namespaces is to implement containers.\grqq}\cite{man-pages: namespaces}
isoliert. Die Network-Namespaces können untereindander mit virtuellen Ethernet Geräten (veth) verbunden werden.
Namespaces können mit dem Programm \emph{unshare},
dem gleichnamigen syscall oder dem syscall \emph{clone} und einer Flag erzeugt werden.
\item[Cgroups]
\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}
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}
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}
Sie erlauben außerdem das Messen der benutzten Ressourcen.
Eine Cgroup wird von einem Verzeichnis repräsentiert, das die Dateien enthält, die die Cgroup beschreiben.
Dazu gehört eine Lists von Tasks (PID), die zu der Cgroup gehören. Sowie Cgroup.procs eine Liste von Thread-Gruppen-IDs.
Weiterführender Artikel auf LWN.net zu \glqq Process containers\grqq\cite{lwn.net: process containers}
Weiterführender Artikel auf LWN.net zu \glqq Process containers\grqq\cite{lwn.net: process containers}
\item[Union-File-Systems]
\item[Union-File-Systems]\label{ufs}
Ein Union-File-System stellt ein Dateisystem dar, indem es Verzeichnisse und Dateien in Branches gruppiert.
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.
Diese Branches können übereinander gestapelt werden, sodass mehrere Layer entstehen.
Auf diese Art werden Images für Container erstellt.
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,
Teilen Images für Container die selbe Basis (die selben Layer), müssen diese nicht neu angelegt werden,
sondern existieren als Referenz.
sondern existieren als Referenz.
Als unterster Layer für einen Container dient ein bootfs, das einem typischen Linux boot Dateisystem ähnelt.
Der darauf folgende Layer ähnelt einem root Dateisystem.
Für den Einsatz mit Containern wird dabei das Copy-on-Write Prinzip verwendet.
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.
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.
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.
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 Kopie verdeckt anschlißend die Referenz in dem Image. \cite{gitbooks: docker}
Bereits exitierende Images, können daher weiderverwendet werden, da sie bei Verwendung nicht verändert werden.
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}
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}
\end{description}
\section{Docker}
\section{Docker}
Wie bereits einleitend erwähnt baut Docker auf diesen Technologien auf.
Docker ist eine OpenSource Plattform, deren Technik auf GitHub\footnote{\url{https://github.com/docker}} unter der Apache-2.0 Lizenz veröffentlicht wird.
Docker ist ein Werkzeug mit dem diese verwendet und verwaltet werden können,
Die Technik ermöglicht es Programme zu entwicklen, verbreiten und auszuführen, und gleichzeitig von der Infrastruktur zu separieren.
sodass sie zusammen als Container verwendet werden können.
Das ermöglicht das schnelle Ausliefern von Software.
\cite{docker-docks: overview}
\emph{\dots Fortsetzung folgt}
Die Basis für die von Docker eingesetze Technik bieten die Eingangs beschriebenen Container.
Diese bieten Docker im Vergleich zu virtuellen Maschinen die Vorteile, dass kein Hypervisor benötigt wird, keine Virtualisierung stattfindet
sonder direkt der Kernel verwendet wird, es können sogar Container innerhalb von virtuellen Maschinen ausgeführt werden.
Dadurch sind Container deutlich leichtgewichtiger, als virtuelle Maschienen, sodass viele Container auf einem Host parallel ausgeführt werden können.
Ein Container kann, als Distributionseinheit für Tests und Auslieferung dienen.
Hierbei spielt es keine Rolle, ob das Ziel der lokale Destkop zur Entwicklung ist oder ein Rechenzentrum, um mit der Anwendung
in den produktiv Betrieb zu gehen.
\subsection{Docker Engine}
Auf der untersten Ebene arbeitet der Docker-Daemon (\emph{dockerd}), dies ist ein durchlaufender Prozess (Daemon),
welcher das Erzeugen und Ausführen von Containern übernimmmt.
Dazu gehören des Weiteren das Managen von Images, Netzwerken und Volumen.
Der Docker-Daemon ist außerdem in der Lage mit anderen dockerd Instanzen zu Kommunizieren, um verteilte Docker-Dienste zu managen.
Über eine Schnittstelle, die \emph{dockerd} zur Verfügung stellt, kann ein Docker-Client (z.B. der Befehlt \emph{docker}) mit dem Daemon interagieren.
Die Interaktion kann dabei, sowohl lokal als auch über das Netzwerk stattfinden (UNIX-Sockets oder REST API).
Docker bietet darüber hinaus auch eine Registry, den Docker-Hub, für Images an.
Die ist eine öffentlich zugängliche Plattform, auf der für jeden zugänglich Images bereitgestellt werden können.
Docker ist standardmäßig so eingestellt, dass dort nach Images für Container gesucht wird.
Es gibt aber auch Möglichkeiten eine eigene Registry zu betreiben, falls diese nicht öffentlich sein soll.
Mit dem Befehl \emph{docker pull} werden Images von der Registry abgerufen und heruntergeladen.
Bei der Verwendung von Docker interagiert man hauptsächlich mit zwei Arten von Objekten, den bereits erwähnten Images und Containern.
Ein Image ist ein schreibgeschütztes Template, das die Instruktionen zum Erstellen eines Containers enthält.
Da die Images auf Union-File-Systems basieren, können Images auch aufeinander aufbauen.
Zum Beispiel ist es möglich, als Grundlage ein Ubuntu-Image zu benutzen und darauf einen Apache-Webserver, eine eigene Anwendung und
Konfigurationsdetails, die für die Anwendung notwendig sind, zu installieren.
Es ist sowohl möglich, eigene Images zu definieren und zu verwenden, als auch den bereits erwähnten Docker-Hub zu nutzen.
Um ein eigenes Image zu erstellen, muss ein \emph{Dockerfile} angelegt werden, in dem in einer einfachen Syntax die Schritte
definiert werden, die für das Erzeugen des Images notwendig sind.
\begin{description}
\item[FROM] Hiermit lässt sich ein Image angeben, auf dem aufgebaut werden soll.
\item[COPY] Mit diesem Befehl können Verzeichnisse und Dateien in das zu erzeugende Image kopiert werden.
\item[RUN] Ausführen von Befehlen beim Erstellen des Images, z.B. aufrufen des Paketmanagers zum Installieren von Paketen
oder ausführen von Programmen und etwas innerhalb des Images zu konfigurieren, erzeugen oder kompilieren.
\item[EXPOSE] Öffnet den angegebenen Port, sodass ein Service der innerhalb des Containers auf diesem Port läuft
erreicht werden kann.
\item[CMD] Mit dieser Anweisung kann ein Befehl definiert werden, der wenn das Image als Container ausgeführt wird gestartet werden soll.
\end{description}
Mit jedem dieser Befehle im Dockerfile wird ein neuer Layer des Union-File-System erzeugt.
Der Befehl \emph{docker build} gibt die Anweisung an den Docker-Daemon das Image in dem angegebenen Dockerfile zu bauen.
Nimmt man eine Änderung an dem Dockerfile vor weist docker an das Image erneut zu bauen, dann werden nur die Layer des Images neu
gebaut, die sich geändert haben.
Die zweite wichtige Art von Objekt bei der Verwendung von Docker sind die eigentlichen Container.
Ein Container ist eine ausführbare Instanz eines Images.
Da ein Image nur ein Template ist, können mit ein und dem selben Image mehrere Container erstellt werden.
Da ein Image schreibgeschützt ist, sind Änderungen im Container die während er ausgeführt wird nicht permanent.
Wird ein Containern gestoppt, dann sind alle Änderungen aufgehoben.
Sollen die Änderungen nicht verloren gehen, gibt es zwei Möglichkeiten. Zum einen ist es möglich, den Zustand eines laufenden Containers
in einem neuen Image zu speichern, dieses Image ist dann wiederum schreibgeschützt und es können neue Container auf Basis dieses Images
erzeugt werden.
Zum anderen ist es möglich mit Docker Volumes zu erzeugen. Ein Volume kann innerhalb des Container gemountet werden und die Änderungen die dort
vorgenommen werden bleiben in dem Volume erhalten. Über den Docker Client ist es auch möglich den Daemon anzuweiesen, dass ein Volume in
mehreren Containern gemountet werden soll, sodass sich mehrere Container das Volume teilen und es für alle sichtbar ist.
Hierbei kann definiert werden ob das Volume nur lesbar gemountet werden soll oder ob auch Schreibrechte genehmigt werden.
Alternativ ist es möglich ein Verzeichnis des Hostsystems in den Container zu mounten, sodass dort z.B. Konfigurationen abgelegt und geändert werden
können und sie weiterhin vom Host aus zugänglich sind.
Standardmäßig ist ein Container gut isoliert, zum Beispiel das Dateisystem des Hosts nicht eingebunden und zugänglich ist.
Auch der Netzwerkzugriff ist abgegränzt zum Hostsystem. Es ist jedoch ähnlich wie beim Dateisystem möglich, die Container über
separat mit dem Docker-Daemon angelegte Netzwerk-Namespaces miteinander zu verbinden, zum Beispiel einen Container in dem eine Anwendung ausgeführt mit
einem weiteren Datenbank Container. Für andere Container die ausgeführt werden aber nicht diesem Netzwerk zugewiesen wurden, ist dann zum Beispiel
der Datenbank Container nicht sichtbar.
\subsection{Docker-Client}
Für die Interaktion mit Containern steht ein Auswahl von Befehlen zur Verfügung. Kleine Übersicht:
\begin{description}
\item[docker build] Build a docker image, specified by a Dockerfile
\item[docekr pull] Pull the given image from the DockerHub
\item[docker run] Start a container based on the specified image
\item[docker ps] Show the currently running containers
\item[docker exec] Run a command inside the context/namespace of the container (see also \emph{nsenter})
\end{description}
\begin{thebibliography}{}
\begin{thebibliography}{}
...
@@ -159,6 +259,10 @@
...
@@ -159,6 +259,10 @@
Linux Programmers's Manual:
Linux Programmers's Manual:
\emph{namespaces - overview of Linux namespaces}\\
\emph{namespaces - overview of Linux namespaces}\\
\item Introduction into docker images \\\url{https://jfrog.com/knowledge-base/a-beginners-guide-to-understanding-and-building-docker-images/}
\item Understanding containerization by recreating docker\\\url{https://itnext.io/linux-container-from-scratch-339c3ba0411d}
\item Playing with namespaces \\\url{https://pulsesecurity.co.nz/articles/docker-rootkits}
\item Containers namespacs cgroups and some filesystem magic\\\url{https://www.slideshare.net/jpetazzo/anatomy-of-a-container-namespaces-cgroups-some-filesystem-magic-linuxcon}
\item Deep dive into docker storage drivers \\\url{http://jpetazzo.github.io/assets/2015-07-01-deep-dive-into-docker-storage-drivers.html#83}
