Container-Virtualisierung
Container-Virtualisierung packt eine Anwendung mit allem, was sie zum Laufen braucht — Bibliotheken, Werkzeuge, Konfiguration — in einen Container. Der Container läuft auf jedem Rechner mit passender Laufzeitumgebung gleich, egal was dort sonst installiert ist. Anders als eine virtuelle Maschine bringt ein Container kein eigenes Betriebssystem mit. Alle Container auf einem Rechner teilen sich dessen Betriebssystemkern.
Im IT-Alltag heißt das meist einfach Container. Mit Schiffs- oder Baucontainern hat der Begriff nur das Bild gemeinsam: eine genormte Kiste, die überall gleich verladen werden kann, egal was drin ist.
Wie Container funktionieren
Ein Container ist technisch ein gewöhnlicher Prozess, den der Betriebssystemkern abschottet. Unter Linux, wo Container zu Hause sind, sorgen dafür zwei Funktionen des Kerns:
| Funktion | Aufgabe |
|---|---|
| Namespaces | der Prozess sieht nur seine eigenen Prozesse, Dateien, Netzwerkschnittstellen und Benutzer |
| Control Groups (cgroups) | begrenzen, wie viel Prozessor, Speicher und Ein-/Ausgabe der Prozess verbrauchen darf |
Dazu kommt ein Dateisystem aus Schichten: Der Container startet aus einem Image, das schreibgeschützt ist. Änderungen landen in einer eigenen Schicht darüber und verschwinden, wenn der Container gelöscht wird.
Image und Container
| Begriff | Bedeutung |
|---|---|
| Image | die unveränderliche Vorlage: Dateisystem und Startbefehl einer Anwendung |
| Container | eine laufende Instanz eines Images, beliebig viele aus einem Image |
| Registry | ein Verzeichnis, aus dem Images heruntergeladen werden, öffentlich oder im eigenen Netz |
| Laufzeitumgebung (Runtime) | die Software, die Container aus Images startet und verwaltet |
Images und Laufzeitumgebungen folgen den Spezifikationen der Open Container Initiative (OCI), die 2015 gegründet wurde. Deshalb laufen Images, die mit einem Werkzeug gebaut wurden, auch mit anderen.
Container oder virtuelle Maschine
| Container | Virtuelle Maschine | |
|---|---|---|
| Eigenes Betriebssystem | nein, Kern des Hosts wird geteilt | ja |
| Trennung | über Funktionen des Kerns, schwächer | über den Hypervisor, stärker |
| Startzeit | Sekundenbruchteile bis Sekunden | Sekunden bis Minuten |
| Größe | Megabyte | Gigabyte |
| Andere Betriebssysteme | nur mit passendem Kern: Linux-Container auf Linux | beliebig |
| Typischer Einsatz | einzelne Anwendungen und Dienste, viele davon | ganze Server |
Beides schließt sich nicht aus. In Rechenzentren und Clouds laufen Container meist in virtuellen Maschinen, um die stärkere Trennung der VM mit der Leichtigkeit der Container zu verbinden.
Auf Windows und macOS laufen Linux-Container in einer kleinen Linux-VM im Hintergrund. Für Windows gibt es zusätzlich eigene Windows-Container.
Warum Container
Gleiche Umgebung überall. Was auf dem Rechner des Entwicklers läuft, läuft im Test und im Betrieb genauso. Die Ausrede „bei mir geht es“ entfällt.
Schnell und dicht. Container starten in Sekunden und brauchen wenig Speicher. Auf einem Server laufen viele mehr als virtuelle Maschinen.
Zerlegung in Dienste. Statt einer großen Anwendung laufen viele kleine Dienste in eigenen Containern, die sich einzeln aktualisieren und vervielfachen lassen (Microservices).
Unveränderlich. Ein Container wird nicht aktualisiert, sondern durch einen neuen aus einem neuen Image ersetzt. Das macht Änderungen nachvollziehbar und leicht rückgängig.
Grenzen
- Daten, die bleiben sollen, gehören nicht in den Container, sondern in angebundene Speicher (Volumes). Wer das übersieht, verliert sie beim nächsten Neustart.
- Die Trennung ist schwächer als bei virtuellen Maschinen. Eine Lücke im Betriebssystemkern betrifft alle Container auf dem Host.
- Images bringen ihre eigenen Bibliotheken mit — und deren Sicherheitslücken. Sie müssen regelmäßig neu gebaut werden.
- Viele Container auf vielen Servern brauchen eine Orchestrierung, die sie verteilt, überwacht und neu startet. Dafür gibt es Kubernetes.
Werkzeuge
| Werkzeug | Rolle |
|---|---|
| Docker | machte Container ab 2013 populär; Bauen, Verteilen und Starten aus einer Hand |
| Podman | Alternative zu Docker, ohne zentralen Hintergrunddienst, Container auch ohne Administratorrechte |
| containerd, CRI-O | Laufzeitumgebungen, die vor allem unter Kubernetes arbeiten |
| LXC | ältere Container-Technik unter Linux, die ganze Systeme statt einzelner Anwendungen kapselt |