Docker 2024 04

Schulung Docker 2024/04

In der folgenden Schulung soll ein grundlegendes Verständnis für die Containerisierung erworben werden.

Teilnehmer_innen sollen nach der Schulung in der Lage sein

• eigene Docker Images zu erstellen und diese mittels Docker Compose zu starten
• die bereitgestellten Ressourcen für Arbeitsspeicher und CPU Zeit zu modifizieren
• die Einsatzzwecke der verschiedenen Networking Modelle (insbesondere Bridged vs. Host Network) zu unterscheiden und diese gezielt anwenden können
• eine eigene Image Registry zu erstellen und dort Images ablegen und abrufen

Welche Bereiche werden explizit ausgeklammert:

• Limitierung von Netzwerkresourcen (siehe tc, Linux als Hostsystem erforderlich)
• Limitierung von Disk IO (siehe constraints, Linux als Hostsystem erforderlich)
• Limitierung von Speicherplatz (siehe XFS, Linux als Hostsystem erforderlich)

Virtualisierung vs Containerisierung

Beide Varianten bieten die Möglichkeit Applikationen isoliert von anderen Prozessen auszuführen. Im Gegensatz zur Containerisierung wird bei der Virtualisierung ein komplettes Betriebssystem mit entsprechenden Anwendungen gestartet.

Warum sollte man Anwendungen überhaupt mit hohem Isolationsgrad starten?
Fehlerhafte Anwendungen oder Sicherheitslücken wirken sich so mit nicht auf das Gesamte System aus.

Virtualisierung

Bei der Virtualisierung übernimmt der Hypervisor das erstellen, starten und das Zuteilen der Hardwareressource des Hosts, an die virtualisierten Gast Betriebssysteme. Hypervisoren können in verschiedene Typen eingeteilt werden:

• Typ 1, Läuft direkt auf der Hardware (z.B.: KVM, Microsoft Hyper-V und VMware vSphere)
• Typ 2, Läuft auf einem Host Betriebssystem (z.B.: VMware Workstation und Oracle VirtualBox)

https://bi-insider.com/posts/virtual-machines-vs-containers/

Containerisierung

Unter Containerisierung versteht man das Zusammenfassen von Softwarecode mit den für die Ausführung des Codes erforderlichen Betriebssystembibliotheken und Abhängigkeiten zu einer einzigen ausführbaren Datei, die als Container bezeichnet wird und in jeder Infrastruktur konsistent ausgeführt werden kann. Container sind portabler und ressourceneffizienter als virtuelle Maschinen (VMs) und haben sich de facto zu den Recheneinheiten moderner cloudnativer Anwendungen entwickelt.

Container Lösungen bieten im Vergleich zur Virtualisierung eine leichtgewichtigere Möglichkeit Applikationen isoliert zu starten. Folgende Informationen beziehen sich auf Docker, sind aber möglicherweise auch auf andere Container Lösungen (wie z.B.: LXC) übertragbar.

Im Gegensatz zur Virtualisierung wird bei der Containerisierung nur die zu startende Anwendung und ihre Abhängigkeiten gestartet. Es wird kein komplettes Betriebssystem initialisiert. Der Container teilt sich den Kernel mit dem Hostbetriebssystem. Die Isolierung zu den Hostanwendungen erfolgt durch verschiedene andere Mechanismen die im weiteren Verlauf erklärt werden.

https://bi-insider.com/posts/virtual-machines-vs-containers/

Docker

Docker ist eine der am weitesten verbreiteten und unterstützten Container Lösungen. Docker selbst kann nur in Verbindung mit dem Linux Kernel verwendet werden.

Natürlich kann Docker auf weiteren Betriebssystemen wie Windows oder MacOS verwendet werden. Jedoch wird hierbei ein Hostsystem mit Linux Kernel emuliert (starke Vereinfachung).

Container Isolierung

Um den starken Isolationsgrad zu erreichen, d.h.: Anwendungungen im Container von anderen Anwendungen zu trennen, werden einige Features des Linux Kernels benötigt. Das folgende wird möglicherweise auch das Verständnis von Isolation verbessern:

Namespaces

Namespaces are a feature of the Linux kernel that partition kernel resources such that one set of processes sees one set of resources, while another set of processes sees a different set of resources. The feature works by having the same namespace for a set of resources and processes, but those namespaces refer to distinct resources. Resources may exist in multiple spaces. Examples of such resources are process IDs, host-names, user IDs, file names, some names associated with network access, and Inter-process communication.

• PID Namespace - Jeder Container hat seinen eigenen Prozess-ID-Namespace, was bedeutet, dass die Prozesse in einem Container nur ihre eigenen Prozess-IDs sehen können und nicht die IDs der Prozesse außerhalb des Containers.

• Network Namespace - Docker erstellt für jeden Container einen eigenen Netzwerknamespace. Das bedeutet, dass jeder Container sein eigenes Netzwerkinterface, seine eigenen IP-Adressen, Routing-Tabellen usw. hat. Dadurch können Container voneinander isoliert sein und unabhängig voneinander agieren.

• Mount Namespace - Mount Namespaces isolieren das Dateisystem des Containers von dem des Hostsystems. Jeder Container hat sein eigenes Dateisystem, was es ermöglicht, dass verschiedene Container unterschiedliche Dateisysteme nutzen können, ohne sich gegenseitig zu beeinflussen.

• IPC Namespace - IPC (Inter Process Communication) Namespaces isolieren die Interprozesskommunikation, wie zum Beispiel die Verwendung von Shared Memory oder IPC Pipes. Dadurch sind die Kommunikationsmechanismen zwischen Prozessen in verschiedenen Containern getrennt.

CGroups

cgroups (abbreviated from control groups) is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, etc.[1]) of a collection of processes.

• CPU-Begrenzung - Mit cgroups kann Docker die CPU-Nutzung jedes Containers begrenzen. Dies ist wichtig, um sicherzustellen, dass ein Container nicht mehr CPU-Ressourcen verwendet als ihm zugewiesen wurden, und um sicherzustellen, dass andere Container und Anwendungen auf dem Hostsystem ausreichend CPU-Zeit erhalten.

• Speicherbegrenzung - Docker kann die Menge an Arbeitsspeicher, die von einem Container verwendet werden kann, mithilfe von cgroups begrenzen. Dies hilft dabei, zu verhindern, dass ein einzelner Container zu viel Arbeitsspeicher beansprucht und das gesamte System zum Absturz bringt.

• I/O-Begrenzung - Durch cgroups kann Docker die Ein- und Ausgabegeschwindigkeit für einen Container begrenzen. Dies ist wichtig, um sicherzustellen, dass ein Container nicht zu viel Festplatten- oder Netzwerkbandbreite beansprucht und dadurch die Leistung anderer Container beeinträchtigt.

Weitere Mechanismen

• SELinux
• AppArmor
• ...

Weitere Informationen finden sich hier

Aufbau von Docker

Docker besteht aus den folgend genannten Komponenten:

Images

Images bilden in sich abgeschlossenen Applikationen welche mit der Docker Engine erstellt und gestartet (Container) werden können.

Registry

Eine zentrale stelle an der Docker Images gespeichert und abgerufen werden kann. Die wohl bekannteste Registry ist dockerhub. Es kann jedoch auch eine eigene Registry erstellt werden.

Engine

Die Docker Engine ist das Herzstück von Docker. Sie besteht aus drei Komponenten:

1. Docker-Daemon - Der Docker-Daemon läuft als Hintergrundprozess auf dem Host System. Dieser ist die zentrale Steuerung der Docker Engine und ist zuständig für sämtliche Verwaltungsaufgaben (z.B.: Anlegen von Netzwerken, Volumes, Images und Containern)
2. REST Api - Dient der Kommunikation mit dem Docker Daemon
3. Command Line Interface - Kommuniziert über die REST Api mit dem Daemon und ermöglicht dem User das ausführen von Docker Befehlen

Images & Containers

Images & Container

   Parametrisierung: Umgebungsvariablen

   Storage: Mounts und Volumes

   Networking Überblick: Bridge vs Host Network

   Networking Konfiguration: Portforwarding

   Ressourcen Limitierung:

       CPU

       Network

       IO

   Mit Container verbinden

       Dateien von/zu Host Kopieren

       Interaktives Terminal verbinden

       ?Kommandos von Host in Container ausführen?

Docker-Compose

   Würde ich generell docker run vorziehen, da übersichtlicher

   Gemeinsames Fallbeispiel

Dockerfile

   Eigenes Dockerfile auf Grundlage eines bestehenden Base Images erstellen

   Dockerfile für eigene Anwendung erstellen

   docker-compose für Service Verbund erstellen (z.b.: App + Datenbank)

?Registry?