Über den Einsatz und den Gebrauch von Dockerfiles wurde schon viel geschrieben. Der nachfolgende Artikel betrachtet einen bestimmten Teilbereich des Dockerfiles und versucht diesen näher zu beleuchten.
Betrachten wir hier zunächst nur die erste Zeile aus dem Dockerfile.
In der ersten Zeile steht die Anweisung “FROM“. Mit dieser Anweisung wird ausgewählt, auf welches Basisimage alle nachfolgenden Anweisungen aufsetzen.
In dieser ersten Zeile wird damit ausgewählt welches Betriebssystem (OS) wir für unser Docker Image wählen.
Natürlich kann in der Anweisung “FROM” auch der Verweis auf ein Image stehen, welches schon mehr als nur das reine OS enthält, aber nichts desto trotz muss ich mich beim Container Bau damit auseinandersetzen, welches OS ich verwenden möchte.
Da es heutzutage in Docker Hub und anderen Container Registries schon Container Images in allen Geschmacksrichtungen gibt, ist die Versuchung groß einfach ein vorgefertigtes Image für die aktuelle Problemstellung zu verwenden. Aber Vorsicht vor zu großen Versuchungen! Der Preis den es vielleicht später zu bezahlen gilt, könnte hoch sein.
Wenn man Container im professionellen Umfeld einsetzt, kommt man nicht darum herum sich im Vorfeld das Thema Betriebssystem für seine Container Images näher anzuschauen. In einem professionellen Umfeld kommt es aus verschiedenen Gründen nicht in Frage vorgefertigte Container Images zu verwenden. Zu groß ist die Gefahr die sich aus den Themen Größe, Aktualität, Sicherheit und Wartbarkeit ergibt.
Von daher versuche ich im Folgenden ein paar Betriebssysteme für Container zu vergleichen und dabei auch meine eigenen Überlegungen, Erfahrungen und Gedanken zu dem Thema mit einfließen zu lassen.
Überlegung 1 – Lange Supportintervalle
Auch wenn Container meist nur kurzlebig sind, möchte ich doch beim OS des Containers eher auf eine Lösung setzen, welche möglichst lange Supportintervalle für Patches und vor allem von Security Patches bedient. Es nützt mir auch beim Container Bau nichts, wenn ich immer den neusten Trends hinterherlaufe, damit mein Container OS auf dem neusten Stand ist. Daher setze ich bei der Auswahl eines Container OS lieber auf die Varianten, welche als LTS (long term support) gekennzeichnet sind.
Passt: RedHat, CentOS, Debian, Ubuntu LTS
Passt nicht: Fedora, Alpine, Ubuntu
Überlegung 2 – Lizenzierung
Ich weiß das Thema nötigt jedem System Admin ein Stöhnen ab. Zu vielfältig sind die Lizenzbedingungen und zu trocken die Formulierungen in den Lizenz Klauseln, was man darf und was nicht.
Aber trotzdem ist das Thema sehr wichtig, da in einem Containerumfeld die Anzahl und der Umfang der benötigten Lizenzen kaum abgeschätzt werden kann. In einem solchen Fall ist man meist hoffnungslos Über- oder Unterlizensiert. Bei solchen Distributionen gilt die Aussage über die Lizenzen meist auch für die Supportverträge, welche die Unternehmen gerne abschließen
Von daher bevorzuge ich bei meinen OS Überlegungen immer die Distribution, welche mir eine Open Source Lizenz liefert die auch wirklich frei ist.
Passt: CentOS, Fedora, Debian, Alpine, Ubuntu
Passt nicht: RedHat
Überlegung 3 – Betriebssysteme
Linux-Betriebssysteme sind in Serverumgebungen heutzutage in vielen Ausprägungen vertreten und erledigen dort einen hervorragenden Job. Auf der Anwenderseite sieht es ein wenig anders aus. Obwohl die Unterstützung für Treiber und Grafische Oberflächen durch die verschiedenen Linux Distributoren für Laptop und Desktop PCs in den letzten Jahren immer besser geworden ist, fristet Linux an dieser Stelle eher ein Nischendasein.
Aber worauf ich eigentlich hinaus will ist, dass ich für meine Überlegungen für ein OS Base Image für meine Container Images lieber auf ein OS setze, welches sich eher für ein Enterprise Umfeld eignet als für den Einsatz auf Endanwendergeräten.
Passt: RedHat EE, CentOS, Debian, Alpine, Ubuntu LTS
Passt nicht: Fedora, Ubuntu
Überlegung 4 – Sicherheit
Sicherheit ist das Thema, welches alle anderen Themen überlagert und in allen Facetten meist heiß diskutiert wird. Dieses Thema ist riesig und vielfältig und soll hier auch gar nicht weiter vertieft werden. Meine Überlegung beim Bau von Container Images beschränke ich meistens darauf, dass es Tools gibt, welche regelmäßige Security Scans der Container Images durchführen und Schwachstellen (vulnerabilities) anzeigen und auch angeben, ob Patches für die erkannten Schwachstellen vorliegen.
Dabei ist es mir wichtig, dass die Dokumentation der Schwachstellen am besten in unabhängigen Datenbanken gespeichert ist, welche nicht direkt den Linux Distributoren zugeordnet sind.
Ein guten Beispiel dafür ist die die Internet Seite https://cve.mitre.org/
In meinem aktuellen Projekt setzen wir Quay als Image Registry ein. In dieser Registry werden alle Container Images fortlaufend durch den Security Scanner “Clair“ geprüft. Dabei werden die Schwachstellen der einzelnen OS Komponenten gewichtet, beschrieben und es wird angezeigt, wenn ein Patch für diese Schwachstelle vorliegt. Dadurch bekomme ich aktuell vor Augen geführt in welcher Geschwindigkeit sich Schwachstellen in den Container Images entdeckt und wie schnell auch Patches für diese Schwachstellen zur Verfügung gestellt werden.
Mit diesen Informationen, muss ich mir selbst eingestehen, dass das Bauen der OS Base-Images von Hand kaum noch möglich ist, da ständig neue Patche ausgerollt werden, welche die Sicherheit des OS Images verbessern.
Fast täglich werden neue Schwachstellen in den Container-Images erkannt. Teilweise dauert es auch ein paar Tage bis selbst für Schwachstellen mit der Kennzeichnung “Hoch“ ein Patch zur Verfügung steht. All das zeigt mir jedoch, dass die Scans funktionieren und auch die Beseitigung der Schwachstellen funktioniert.
Bei den meisten aktuellen Alpine Security Scans wird keine Schwachstelle erkannt. Dies liegt zu einem großen Teil daran, dass Alpine nur sehr wenige Pakete installiert hat. Auf der anderen Seite macht es mich stutzig, wenn keine Schwachstellen im Container Image gefunden werden. Ein OS ohne Schwachstellen gibt es nicht! Das ist Fakt. Von daher verwende ich lieber ein OS, bei welchem ich die Erkennung und die Beseitigung von Schwachstellen sichtbar vor Augen geführt bekomme.
Passt: RedHat EE, CentOS, Debian, Fedora, Ubuntu
Passt nicht: Alpine
Letzte Überlegung – Standards
Ich weiß, dass viele Container Images auf der Linux Distribution Alpine basieren und das Alpine in der Docker Comunity sehr beliebt ist. Auch weiß ich wo Alpine herkommt. Der Anspruch von Alpine war einmal von der Größe her auf eine Diskette zu passen. Ja, Disketten, die Älteren unter uns erinnern sich noch. Es gab mal eine Zeit, in der war Speicherplatz das kostbarste Gut auf einem Computer. Disketten hatten damals eine maximale Speicherkapazität von 1,44 MB.
Aber Schluss mit schwelgen in Erinnerungen! Seit der Ära der Disketten und den heutigen Container Images ist viel Zeit verstrichen und Speicherplatz spielt heute kaum noch eine Rolle, oder lässt sich bei Bedarf günstig nachrüsten.
Nun aber zu meiner Überlegung. Ich bin nicht unbedingt ein Freund von Alpine. Auch wenn „glibc“ und „musl c“ in ihrer Funktionsweise recht ähnlich sind, habe ich in der Vergangenheit doch einige Inkompatibilitäten zwischen Alpine und dem Rest der aufgeführten Linux Distros erlebt.
Und auch wenn das Basisimage von Alpine faszinierend klein und kompakt ist wächst es doch mit der Installation von Zusatzpaketen schnell an und der Größenvorteil von Alpine relativiert sich.
Von daher versuche ich den Einsatz von Alpine beim Bau von Container-Images zu vermeiden.
Passt: RedHat EE, CentOS, Debian, Fedora, Ubuntu
Passt nicht: Alpine
| Image Typ | Debian | Fedora | RedHat EE | Ubuntu | CentOS | Alpine |
| Abstammung | RedHat | Debian | RedHat EE | |||
| C Libary | glibc | glibc | glibc | glibc | glibc | musl c |
| Paket Format | dpkg | rpm | rpm | dpkg | rpm | apk |
| Core Utilities | GNU Core Utils | GNU Core Utils | GNU Core Utils | GNU Core Utils | GNU Core Utils | Busybox |
| Version | Buster | 31 | 8 | 20.04 LTS | 8.0 | 3.10 |
| Unterstützt bis | 2024 | update Zwang nach 13 Monaten | 2029 | wahrscheinlich 2025 | 2029 | 2021 |
| Tracking | OVAL Data, CVE Database, & Errata | Errata | OVAL Data, CVE Database, Vulnerability API & Errata, Lab Tools | OVAL Data, CVE Database, & Errata | Announce List, Errata | Limited Database |
Alle Daten beziehen sich auf den Informationsstand vom November 2019
Zusammenfassung
Bevor der (Shit)Sturm nun heraufzieht. Die oben genannten Überlegungen beruhen auf meinen eigenen Überlegungen und Erfahrungen. Ich bin mir durchaus bewusst, dass jede dieser Überlegungen nicht dem Meinungsbild Anderer entsprechen müssen und dass es sicher auch plausible Gegenargumente gibt.
Die oben aufgeführten Überlegungen entsprechen meinen Erfahrungen aus vielen Jahre IT. Auch habe ich den Großteil meiner Erfahrungen im Konzern Umfeld gesammelt und schaue deswegen auch durchaus mit einer etwas anderen Brille auf die Dinge.
Das Thema Image-Größe habe ich beispielsweise in meinen Überlegungen gar nicht berücksichtigt. Außer Alpine, welches mit seiner geringen Größe hervorsticht, haben alle anderen Distributionen mittlerweile ebenfalls auf Contaimer-Images angepasste Versionen, die wenig Speicherplatz benötigen.
Nichtsdestotrotz freue ich mich aber über Feedback zu dem Artikel.