Die CI-Pipeline dauerte von zwölf auf vier Minuten: Das Team wechselte zu „php:8.3-alpine“, entfernte die Apt-Layer und reduzierte das Bild von 680 MB auf 95 MB. Der Zusammenschluss wird gefeiert. Drei Tage später lädt die GD-Erweiterung keine TrueType-Schriftart mehr – musl und Bibliotheken fehlen – und der Miniaturbildgenerator erzeugt leere PNGs.
Leichte Images beschleunigen das Ziehen, Bereitstellen und Kaltstarten. Sie vereinfachen Ihre Bewerbung nicht automatisch. Die Verwechslung von „kleine Docker-Datei“ und „Stack enthalten“ führt zu Images, die schnell booten, aber im Produktions-Edge-Fall stillschweigend ausfallen.
Größe, Schichten und was wirklich Zeit kostet
Docker sendet inkrementelle Schichten. Ein „schweres“ Image mit einem guten lokalen Cache kann schneller bereitgestellt werden als ein „leichtes“ Image, das bei jedem Commit alles ungültig macht, weil „COPY. .` ist zu hoch platziert.
| Hebel | Typischer Gewinn | Risiko |
|---|---|---|
| Alpine Basis/schlank | −50 bis 80 % Größe | Libc-Inkompatibilitäten, fehlende Pakete |
| Mehrfachpraktikum | Toolchain aus der Laufzeit entfernen | Vergessen Sie eine Laufzeitbibliothek (ssl, tzdata) |
| .dockerignore | Stabilerer Cache | Eine erforderliche Datei vom Build ausschließen |
| Kombiniert RUN apt | Weniger Schichten | Bilder sind schwer Zeile für Zeile zu patchen |
Messen Sie die Pull- und Startzeit in Ihrer Registrierung und auf Ihrem Host – nicht nur lokal in „Docker-Images“.
Ein schlecht getestetes Lightweight-Image verlagert die Kosten auf das nächtliche Debuggen.
Mehrstufig: separate Build- und Laufzeit
Klassisches PHP/Node-Muster:
- Stage Builder: Composer-Installation, NPM-Run-Build, Kompilierungserweiterungen.
- Stufenlaufzeit: Kopieren Sie „vendor/“, „public/build/“, nur kompilierte Binärdateien.
Vermeiden Sie das Kopieren von „.git“, Tests, „node_modules“ dev oder Dokumentation. Überprüfen Sie, ob die PHP-Laufzeiterweiterungen („pdo_mysql“, „intl“, „opcache“) im final installiert sind, nicht nur im Builder.
Beim Hosting mit einer privaten Registry (Scaleway, GitLab, Harbor) reduzieren kompakte endgültige Images auch die Speicher- und Ausgangskosten – insbesondere bei zehn Microservices.
Alpine, schlank, distroless: Wählen Sie die libc
Alpine (musl): sehr klein, Pakete per APK. Häufige Probleme mit wkhtmltopdf, einigen PECL-Erweiterungen und Glibc-bezogenen Binärdateien.
Debian/Ubuntu Slim (glibc): etwas schwereres, vorhersehbareres Ökosystem für PHP und Python.
Distroless / Scratch: minimal, oft ohne Shell – hervorragend für Go oder Java, anspruchsvoller für PHP-FPM, wo das Debuggen zählt.
Minimale Testmatrix: Containerstart, Gesundheitsprüfung, kritischer Geschäftspfad (Bild hochladen, PDF, TLS-API-Aufruf).
.dockerignore und versteckte Abhängigkeiten – der falsche Weg
Ein übermäßig aggressives „.dockerignore“, das „composer.lock“ oder Konfigurationsdateien ausschließt, erzwingt ein implizites „Composer-Update“ für den Build – „leichtgewichtiges“ Image, nicht reproduzierbare Builds.
Umgekehrt bläht das Einschließen des gesamten Repos ohne Ignorieren den an den Daemon gesendeten Kontext auf und unterbricht den Cache bei jedem Dokument-Commit.
Listen Sie explizit auf, was in den Kontext kommt: Sperrdateien, Patches, benutzerdefinierte Erweiterungen. Dokumentieren Sie die erforderlichen Systembibliotheken in der Docker-Datei (Kommentar + „RUN apk add --no-cache...“).
Sicherheit, CVE und „neueste“ Bilder
„FROM node:latest“ oder „php:8-apache“ ohne gepatchtes Tag bläst und verschleiert Updates. Pin „php:8.3.12-fpm-bookworm“ und automatisieren Sie die Neuerstellung auf CVE.
Scannen Sie (Trivy, Grype) das endgültige Bild – nicht nur die Docker-Datei. Eine minimalistische alpine Basis mit einem anfälligen OpenSSL bleibt ein Risiko.
Der Gipfel: die Leichtigkeit, die das Unverständnis überdeckt
Es ist sinnlos, beim Pull-Vorgang Zeit zu sparen, wenn Sie eine Stunde damit verschwenden, im Kopf neu zu erstellen, was das alte Debian-Image implizit installiert hat.
Entscheide dich und gehe ohne blinden Fleck voran
Laufzeitbibliotheken dokumentieren, mehrstufig übernehmen, Grundlagen festlegen, Rauch im CI testen. Vergleichen Sie Alpine mit Slim auf Ihrem Stack, nicht auf einem generischen Benchmark.
Informationen zum Hosten von Registry, CI-Runnern und Docker VPS in Europa finden Sie in unserem Verzeichnis und Vergleich. Die Ratgeber decken den Containerrahmen ab.
Release-Checkliste: Leeres Image abrufen, Zustand ausführen, Geschäftsszenario ausführen, CVE-Scan – bevor die eingesparten Megabyte gefeiert werden.
Häufig gestellte Fragen
Ist Alpine immer noch die richtige Wahl für ein helles Bild?
Nein – testen Sie musl vs. glibc für Ihren Stack; Debian-Slim oder Distroless sind möglicherweise stabiler.
Was bietet ein mehrstufiger Build?
Trennt Kompilierung und Laufzeit; Das endgültige Bild enthält nicht die Toolchain.
Wie kann der Zug beschleunigt werden, ohne die Sicherheit zu beeinträchtigen?
Cache-Ebenen, .dockerignore, angeheftete Tags – Geschwindigkeit hängt sowohl vom Cache als auch von der Größe ab.
Benötige ich eine Shell im Produktionsimage?
Kompromiss zwischen Debug und Angriffsfläche; Wählen Sie entsprechend Ihrer externen Beobachtbarkeitsfähigkeit.
Ein Light-Image wird anhand der Bereitstellung am Freitagabend beurteilt – nicht anhand der „Docker-Images“ am Montagmorgen.