senn-techServer-OS-Wahl: Ubuntu vs. Alpine
Für VMs ist Ubuntu seit Jahren unsere erste Wahl. Alpine dominiert bei Containern. Die Entscheidung ist weniger ideologisch als praktisch.
Ubuntu: Das Arbeitspferd
Ubuntu Server LTS bringt glibc, Systemd, breiten Hardware-Support und einen vorhersehbaren Support-Zyklus von 5+5 Jahren. Nahezu jede Software hat ein Ubuntu-Paket oder einen getesteten Installationspfad.
In VMs ist das unser Standard — Proxmox-Host, dann Ubuntu-VM, dann Docker obendrauf. Der Overhead von ein paar hundert MB Image-Größe spielt bei VMs keine Rolle. Wichtiger ist: der Betrieb ist vorhersehbar, Security-Updates kommen per unattended-upgrades, und jeder im Team kann im Notfall ohne Einarbeitung eingreifen.
Alpine: Die Container-Königin
Alpine ist winzig — ~5 MB Basis-Image. Es nutzt musl statt glibc und busybox statt GNU-Coreutils. Das reduziert die Angriffsfläche und die Image-Größe, aber es bedeutet: manche Binaries erwarten glibc und laufen nicht ohne Anpassung.
In der Container-Registry dominiert Alpine deshalb zu Recht. Für Microservices, die nur ihre eigene Binärdatei und minimale Abhängigkeiten brauchen, gibt es nichts Schlankeres.
Der musl-Unterschied
musl ist korrekt, aber DNS-Auflösung verhält sich anders als unter glibc. Manche Software (etwa Node.js in älteren Versionen, manche Python-Wheels mit C-Extensions) macht Ärger. Das ist kein Grund gegen Alpine, aber man muss es wissen, bevor man drei Stunden debuggt.
Direkter Vergleich
| Kriterium | Ubuntu LTS | Alpine |
|---|---|---|
| libc | glibc | musl |
| Basis-Image | mehrere hundert MB | ~5 MB |
| Tooling | GNU-Coreutils, systemd | busybox |
| Kompatibilität | sehr breit | gelegentlich Anpassung nötig |
| Support | 5+5 Jahre LTS | rolling, schlank |
| Ideal für | VMs & Host-Systeme | Container / Microservices |
Die dritte Option: distroless & Wolfi
Zwischen "fett, aber kompatibel" und "winzig, aber musl" hat sich eine dritte Klasse etabliert: distroless-Images (nur die Anwendung plus Laufzeit, keine Shell, kein Paketmanager) und Wolfi/Chainguard-Images — minimal, aber glibc-basiert und mit Fokus auf möglichst wenige CVEs. Wo es auf kleine Angriffsfläche und glibc-Kompatibilität ankommt, sind sie oft die bessere Antwort als Alpine.
Unsere Faustregel
Ubuntu LTS für VMs und Host-Systeme. Alpine für Container, wo es passt. Wenn ein Container-Image auf Alpine nicht sauber läuft, weichen wir auf debian:slim oder ein Wolfi-Image aus — immer noch klein genug, aber glibc-kompatibel.
Fazit
Alpine ist kein Ersatz für Ubuntu, sondern der richtige Kernel für Container-Workloads. Ubuntu ist der richtige Kernel für alles, was länger als einen Tag laufen soll und von Menschen gewartet wird.
Sollten wir für kleinere Images alles auf Alpine umstellen?+
Nein. Der Artikel trennt klar: Ubuntu LTS für VMs und Host-Systeme, Alpine nur für Container, wo es passt. In VMs spielt der Overhead von ein paar hundert MB keine Rolle — wichtiger sind vorhersehbarer Betrieb und dass jeder im Team ohne Einarbeitung eingreifen kann. Läuft ein Container-Image auf Alpine nicht sauber, weichen wir auf debian:slim oder ein Wolfi-Image aus.
Welche Fallstricke bringt musl gegenüber glibc mit?+
musl ist korrekt, aber die DNS-Auflösung verhält sich anders als unter glibc. Manche Software macht Ärger — etwa ältere Node.js-Versionen oder Python-Wheels mit C-Extensions, die glibc erwarten und ohne Anpassung nicht laufen. Das ist kein Grund gegen Alpine, aber man sollte es wissen, bevor man drei Stunden mit der Fehlersuche verbringt.
Gibt es eine Option zwischen fettem Ubuntu und musl-Alpine?+
Ja. Distroless-Images enthalten nur die Anwendung plus Laufzeit — keine Shell, keinen Paketmanager. Wolfi- bzw. Chainguard-Images sind ebenfalls minimal, aber glibc-basiert und auf möglichst wenige CVEs ausgelegt. Wo kleine Angriffsfläche und glibc-Kompatibilität zugleich zählen, sind sie oft die bessere Antwort als Alpine.