Server-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.

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 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.