Container

Ein Container ist wie eine Lunchbox für Software. Wenn du dein Mittagessen (Nudeln) einfach so in den Rucksack wirfst, vermischt es sich mit deinen Büchern (Chaos). Wenn du es in eine Lunchbox tust, ist es sicher und du kannst es überall hin mitnehmen (Schule, Arbeit, Picknick). Software hat das gleiche Problem: Sie vermischt sich oft mit dem Betriebssystem und geht kaputt. In einem Container ist alles drin, was die Software braucht (Code, Bibliotheken). Sie läuft dadurch auf jedem Computer gleich.

Merksatz: Eine isolierte Umgebung, die Software und alle ihre Abhängigkeiten verpackt, damit sie überall läuft.

Das wichtigste Tool für Container ist Docker. Prozess:

Entwickler schreibt Code.
Entwickler packt Code in Container ("Build").
Entwickler gibt Container an Server.
Server führt Container aus ("Run").

Vorteil: "Bei mir läuft es, aber auf dem Server nicht" gibt es nicht mehr. Wenn der Container auf dem Laptop läuft, läuft er auch in der Cloud.

:level1

Praxisbruecke: Ein Container ist kein kompletter Computer. Er nutzt den Kernel des Hosts, bringt aber eigene Dateien, Prozesse und Umgebungsvariablen mit. Ports und Volumes verbinden ihn gezielt mit der Aussenwelt.

1. Isolation (Namespaces & Cgroups)

Wie funktioniert die Magie? Linux-Features!

Namespaces: Lügen dem Prozess vor, er wäre allein auf der Welt. "Du bist Prozess Nr. 1 und hast dein eigenes Netzwerk."
Cgroups (Control Groups): Begrenzen die Ressourcen. "Du darfst nur 512 MB RAM und 1 CPU-Kern nutzen."

2. Microservices

Container sind der Baustein für moderne Architektur. Statt einem Riesen-Programm (Monolith) baut man 50 kleine Container (Microservices), die miteinander reden. Wenn einer abstürzt, laufen die anderen 49 weiter.

:level2

Technisch endet ein Container, wenn sein Hauptprozess endet. Darum ist wichtig, welcher Prozess im Vordergrund läuft, welche Dateien persistent sind und welche Daten beim Loeschen verschwinden.

1. Linux Kernel Namespaces

Die größte Illusion der Informatik. Ein Container "existiert" eigentlich gar nicht als echtes Objekt, er ist nur ein normaler Linux-Prozess, dem der Kernel Scheuklappen anlegt. Das passiert mit Namespaces.

PID Namespace: Der Browser im Container denkt, er ist der einzige Prozess (PID 1). Tatsächlich ist er auf dem Host-System in Wahrheit Prozess Nummer 34091.
Net Namespace: Der Container erhält eine isolierte Netzwerkkarte (veth-Interface) und eine eigene IP-Adresse. Er "sieht" die Netzwerkkarten des Host-Systems nicht.
Mount Namespace: Der Container bekommt einen fingierten Datei-Baum (/). Er kann physikalisch die Festplatte des Hosts /home/user nicht "sehen" oder mounten, es sei denn, man perforiert diesen Namespace explizit via Bind-Mounts.

2. Cgroups (Control Groups)

Wenn Namespaces sagen "Was darf der Container sehen?", dann sagen Cgroups, "Wie viel darf er verbrauchen?". Cgroups sind ein Kernel-Feature (ursprünglich von Google entwickelt). Sie rationieren Hardware. Man kann einen Container in eine Cgroup packen und definieren: Maximal 500 MB RAM, nur Zugriff auf CPU Core 2, und maximal 10 Megabyte pro Sekunde Schreibgeschwindigkeit auf der SSD (Solid State Drive). Versucht der Code mehr RAM anzufordern, greift der Kernel hart ein und killt den Prozess (OOM-Kill, Out of Memory).

3. Layered File Systems (UnionFS / OverlayFS)

Wenn 10 Container auf einem Server laufen und jeder ein Ubuntu-Base-Image (70 MB) hat, verbraucht das nicht 700 MB Speicherplatz. Container nutzen OverlayFS. Ein Container-Image besteht aus schreibgeschützten (Read-Only) Schichten (Layers). Haben zehn Container denselben Base-Layer, liegt diese 70 MB Schicht nur ein einziges Mal physikalisch auf der SSD. Darüber legt Docker beim Start eine extrem dünne "Read/Write"-Schicht für den jeweiligen Container (oft nur wenige KB groß). Wenn der Container stirbt, wirft Docker nur diese oberste R/W-Folie weg, die Read-Only Schichten darunter bleiben unberührt. Das macht das Starten von Containern blitzschnell (Millisekunden) und speichereffizient.