Minimale Container-Images verzichten auf Komponenten wie Shells oder Paketmanager, die zur Laufzeit normalerweise nicht gebraucht werden. Sie sind auch als "distroless" oder "chiseled" Images bekannt. Weil weniger Komponenten weniger Schwachstellen bedeuten, reduzieren diese Images die Angriffsfläche und erhöhen dadurch die Sicherheit.
Schlüsselfertige Images für ein Basis-Linux sowie die Sprachen PHP, Python, Java, C# und Node.js hat Teil 2 der Artikelserie vorgestellt. Diese vorkonfektionierten Images passen jedoch nicht immer zu den eigenen Anforderungen und es kann notwendig sein, eigene zu erstellen. Dieser Artikel zeigt, wie Softwareentwicklerinnen und -entwickler eigene minimale Images basierend auf den Angeboten Ubuntu Chiseled, Chainguard/WolfiOS und Azure Linux bauen (siehe die folgende Tabelle).
| Drei Anbieter minimaler Images im Vergleich | |||
| Bewertungskriterium | Ubuntu Chiseled | WolfiOS / Chainguard | Azure Linux |
| Verfügbare Pakete | ~500 | ~3000 | ~3000 |
| Qualität der Dokumentation / Schwierigkeit der Nutzung | ➕➕ | ➕➕➕ | ➕ |
| Integrationsgeschwindigkeit von Paket-Versionsupdates (Upstream) | Langsam | Schnell | Mittel |
| Reproduzierbare Image-Builds / Pinnen der zu installierenden Paket-Versionen | ❌ | ✅ | ❌ |
| Kommerzieller Support | ✅ | ✅ | ❌ |
Canonical verwendet die Bezeichnung "Chiseled" für minimale, Ubuntu-basierte Images. Ein Blogbeitrag stellt das Chisel-CLI von Ubuntu vor. Chisel ist ein Build-Tool, das Entwickler mit der gewünschten Ubuntu-Version (beispielsweise "24.04") und einer Liste von "Slices" aufrufen, die Chisel zu einem neuen Root-Filesystem zusammenbaut. Dieses Filesystem kopiert man anschließend in ein leeres scratch-Image, wie der Ablaufplan in Abbildung 1 verdeutlicht:
Bau eines Chiseled-Image via Multi-Stage Dockerfile (Abb.1)
Das Ubuntu-Team hat einige (jedoch nicht alle) der offiziellen Ubuntu-Pakete in mehrere Slices aufgeteilt und diese auf GitHub veröffentlicht. Falls Slices für ein gewünschtes Paket fehlen, sollte man auf andere im Artikel erwähnte Ansätze wechseln. Denn bestehende GitHub Issues zeigen, dass reine Feature-Requests lange oder gänzlich ignoriert werden, und der Zeitinvest für die Einarbeitung für eigene Pull Requests (PRs) hoch ist.
