Alpine vs Debian als Basis-Image - die richtige Wahl treffen

Die Wahl des Basis-Images beeinflusst Image-Größe, Kompatibilität, Debugging-Komfort und manchmal das Laufzeitverhalten. Es gibt keine universelle Antwort — aber klare Kriterien.

Alpine Linux

Alpine basiert auf musl libc statt der üblichen glibc und verwendet busybox statt der GNU-Coreutils. Das Ergebnis ist ein minimales Image:

alpine:3.18    →  7.3 MB

• Vorteile:
• Sehr kleine Image-Größe
• Minimale Angriffsfläche (weniger installierte Pakete = weniger CVEs)
• Schnell gepullt und deployed

• Nachteile:
• musl libc ist nicht vollständig glibc-kompatibel — native Extensions (Python, Ruby, bestimmte npm-Pakete) können nicht oder nur nach Patches kompiliert werden
• Debugging auf Alpine ist aufwendiger: viele bekannte Tools fehlen oder verhalten sich anders
• Fehlermeldungen aus nativen Bibliotheken können in Alpine-Containern irreführend sein

Debian und debian:slim

debian:bookworm       →  117 MB
debian:bookworm-slim  →   75 MB

Debian-basierte Images nutzen glibc und haben breite Paket-Kompatibilität. debian:slim ist eine abgespeckte Variante ohne Dokumentation und Locale-Dateien — gut für Produktions-Images.

• Vorteile:
• Volle glibc-Kompatibilität → keine Überraschungen mit nativen Bibliotheken
• Bekannte Toolchain, vertrautes Verhalten
• Einfacheres Debugging (apt-get install verfügbar)

• Nachteile:
• Größer als Alpine
• Mehr potenzielle CVE-Oberfläche

Wann was verwenden

• Alpine sinnvoll für:
• Statisch gelinkte Go-Binaries (CGO_ENABLED=0 — kein glibc-Bedarf)
• Einfache Shell-Skripte und Tools
• Situations, wo Image-Größe kritisch ist

• Debian/slim sinnvoll für:
• Python (native Extensions wie numpy, cryptography, psutil brauchen glibc)
• Java, Ruby, PHP
• Alles, das native Linux-Bibliotheken einbindet

# Go: Alpine ist ideal — statisch gelinkt
FROM alpine:3.18
COPY server /app/server

# Python: Debian-slim ist sicherer
FROM python:3.12-slim

Distroless als dritte Option

Google's Distroless-Images (gcr.io/distroless/base) enthalten weder Shell noch Paketmanager — nur die Laufzeit-Bibliotheken. Noch kleiner als Alpine, aber kein sh für Debugging.

FROM gcr.io/distroless/python3
COPY app.py /app/
CMD ["app.py"]

Für maximale Sicherheit in Produktion interessant. Im Fehlerfall jedoch kaum debuggbar — nur mit docker cp oder Sidecar-Containern.

Fazit

Anfangen mit den offiziellen slim-Images der jeweiligen Laufzeit (python:3.12-slim, node:20-slim). Zu Alpine wechseln, wenn man die Kompatibilität kennt und Image-Größe ein tatsächliches Kriterium ist.