Einige Leute sagen, dass Linux-Distributionen mit Containern keine Rolle mehr spielen. Alternative Ansätze wie Distroless- und Scratch-Container scheinen voll im Trend zu liegen. Es scheint, dass wir Technologieentscheidungen eher auf der Grundlage von Modebewusstsein und unmittelbarer emotionaler Befriedigung erwägen und treffen, als über die sekundären Auswirkungen unserer Entscheidungen nachzudenken. Wir sollten Fragen stellen wie:Wie werden sich diese Entscheidungen in sechs Monaten auf die Wartung auswirken? Was sind die technischen Kompromisse? Wie wirkt sich dieser Paradigmenwechsel im großen Maßstab auf unsere Build-Systeme aus?
Es ist frustrierend zuzusehen. Wenn wir vergessen, dass Engineering ein Nullsummenspiel mit messbaren Kompromissen ist – Vor- und Nachteile, mit Kosten und Nutzen unterschiedlicher Ansätze – erweisen wir uns selbst einen Bärendienst, wir erweisen unseren Arbeitgebern einen Bärendienst und wir erweisen unseren Kollegen einen Bärendienst, die schließlich unsere aufrechterhalten werden Code ein schlechter Dienst. Schließlich erweisen wir allen Betreuern (Heil an die Betreuer!) einen Bärendienst, indem wir ihre Arbeit nicht wertschätzen.
Das Problem verstehen
Um das Problem zu verstehen, müssen wir untersuchen, warum wir überhaupt angefangen haben, Linux-Distributionen zu verwenden. Ich würde die Gründe in zwei große Bereiche einteilen:Kernel und andere Pakete. Kernel zu kompilieren ist eigentlich ziemlich einfach. Slackware und Gentoo (ich habe immer noch eine Schwäche in meinem Herzen) haben uns das beigebracht.
Andererseits kann die enorme Menge an Entwicklungs- und Laufzeitsoftware, die für ein brauchbares Linux-System gepackt werden muss, entmutigend sein. Darüber hinaus können Sie nur sicherstellen, dass Millionen von Permutationen von Paketen installiert werden können und zusammenarbeiten, indem Sie das alte Paradigma verwenden:Kompilieren Sie es und versenden Sie es zusammen als ein Ding (d. h. eine Linux-Distribution). Warum also kompilieren Linux-Distributionen Kernel und alle Pakete zusammen? Ganz einfach:um sicherzustellen, dass alles zusammenpasst.
Lassen Sie uns zunächst über Kernel sprechen. Der Kern ist etwas Besonderes. Das Booten eines Linux-Systems ohne kompilierten Kernel ist eine kleine Herausforderung. Es ist der Kern eines Linux-Betriebssystems und das Erste, worauf wir uns beim Booten eines Systems verlassen. Kernel haben viele verschiedene Konfigurationsoptionen, wenn sie kompiliert werden, was einen enormen Einfluss darauf haben kann, wie Hardware und Software auf einem laufen. Ein sekundäres Problem in diesem Bucket ist, dass Systemsoftware wie Compiler, C-Bibliotheken und Interpreter auf die Optionen abgestimmt werden muss, die Sie in den Kernel eingebaut haben. Gentoo hat uns dies auf eine instinktive Weise beigebracht, was jeden zu einem Mini-Distributionsbetreuer gemacht hat.
Peinlicherweise (weil ich in den letzten fünf Jahren mit Containern gearbeitet habe) muss ich zugeben, dass ich vor kurzem Kernel kompiliert habe. Ich musste verschachteltes KVM auf RHEL 7 zum Laufen bringen, damit ich OpenShift auf virtuellen OpenStack-Maschinen, in einer virtuellen KVM-Maschine auf meinem Laptop sowie unser Container Development Kit (CDK) ausführen konnte. #justsayin Es genügt zu sagen, dass ich damals RHEL7 auf einem brandneuen 4.X-Kernel hochgefahren habe. Wie jeder gute Systemadministrator war ich ein wenig besorgt, dass ich einige wichtige Konfigurationsoptionen und Patches verpasst habe. Und natürlich hatte ich einiges verpasst. Der Schlafmodus funktionierte nicht mehr richtig, meine Dockingstation funktionierte nicht mehr richtig und es gab zahlreiche andere kleine, zufällige Fehler. Aber es funktionierte gut genug für eine Live-Demo von OpenShift auf OpenStack in einer einzelnen virtuellen KVM-Maschine auf meinem Laptop. Komm schon, das macht irgendwie Spaß, oder? Aber ich schweife ab…
Lassen Sie uns nun über alle anderen Pakete sprechen. Während der Kernel und die zugehörige Systemsoftware schwierig zu kompilieren sein können, besteht das viel, viel größere Problem aus Workload-Sicht darin, Tausende und Abertausende von Paketen zu kompilieren, um uns ein brauchbares Linux-System zu geben. Jedes Paket erfordert Fachwissen. Bei einigen Softwarekomponenten müssen nur drei Befehle ausgeführt werden:./configure , machen , und make install . Andere erfordern eine Menge Fachkenntnisse, die vom Hinzufügen von Benutzern bis zum Konfigurieren bestimmter Standardeinstellungen in usw. reichen zum Ausführen von Post-Installationsskripten und zum Hinzufügen von systemd-Unit-Dateien. Die Menge an Fähigkeiten, die für die Tausenden von verschiedenen Softwarekomponenten erforderlich sind, die Sie möglicherweise verwenden, ist für jede einzelne Person entmutigend. Wenn Sie jedoch ein brauchbares System mit der Möglichkeit wünschen, neue Software jederzeit auszuprobieren, müssen Sie lernen, wie die neue Software kompiliert und installiert wird, bevor Sie überhaupt damit beginnen können, sie zu verwenden. Das ist Linux ohne eine Linux-Distribution. Das ist das technische Problem, dem Sie zustimmen, wenn Sie auf eine Linux-Distribution verzichten.
Der Punkt ist, dass Sie alles zusammenbauen müssen, um sicherzustellen, dass es mit einem vernünftigen Maß an Zuverlässigkeit zusammenarbeitet, und es erfordert eine Menge Wissen, um eine verwendbare Kohorte von Paketen zu erstellen. Dies ist mehr Wissen, als ein einzelner Entwickler oder Systemadministrator jemals vernünftigerweise lernen und behalten wird. Jedes von mir beschriebene Problem gilt für Ihren Container-Host (Kernel und Systemsoftware) und Ihr Container-Image (Systemsoftware und alle anderen Pakete) – beachten Sie die Überschneidung; es gibt auch Compiler, C-Bibliotheken, Interpreter und JVMs im Container-Image.
Die Lösung
Sie wissen das bereits, aber Linux-Distributionen sind die Lösung. Hören Sie auf zu lesen und schicken Sie Ihrem nächstgelegenen Paketbetreuer (nochmals ein Hoch auf die Betreuer!) eine E-Card (warten Sie, habe ich gerade mein Alter verraten?). Im Ernst, diese Leute leisten eine Menge Arbeit, und das wird wirklich unterschätzt. Kubernetes, Istio, Prometheus und Knative:Ich sehe Sie an. Ihre Zeit kommt auch, wenn Sie im Wartungsmodus sind, überstrapaziert und unterschätzt werden. Ich werde denselben Artikel wahrscheinlich in sieben bis zehn Jahren noch einmal schreiben, wahrscheinlich über Kubernetes.
Erste Prinzipien mit Container-Builds
Es gibt Kompromisse zwischen dem Erstellen von Grund auf und dem Erstellen von Basisimages.
Auf Basis von Basisimages erstellen
Das Erstellen aus Basisimages hat den Vorteil, dass die meisten Erstellungsvorgänge nichts anderes als eine Paketinstallation oder -aktualisierung sind. Es stützt sich auf eine Menge Arbeit, die von Paketbetreuern in einer Linux-Distribution geleistet wird. Es hat auch den Vorteil, dass ein Patch-Ereignis in sechs Monaten – oder sogar 10 Jahren – ab jetzt (mit RHEL) ein Betriebs-/Systemadministrator-Ereignis (Yum-Update) ist, kein Entwickler-Ereignis (bei dem Code durchsucht werden muss, um herauszufinden, warum einige Funktionsargument funktioniert nicht mehr).
Lassen Sie uns darauf ein wenig doppelklicken. Anwendungscode stützt sich auf viele Bibliotheken, die von JSON-Munging-Bibliotheken bis hin zu objektrelationalen Mappern reichen. Im Gegensatz zum Linux-Kernel und Glibc ändern sich diese Arten von Bibliotheken ohne Rücksicht auf die Unterbrechung der API-Kompatibilität. Das bedeutet, dass Ihr Patch-Ereignis in drei Jahren wahrscheinlich zu einem Code-Änderungsereignis wird, nicht zu einem Yum-Update-Ereignis. Verstanden, lass das auf dich wirken. Entwickler, du wirst um 2 Uhr morgens per Pager benachrichtigt, wenn das Sicherheitsteam keinen Firewall-Hack finden kann, um den Exploit zu blockieren.
Das Erstellen von einem Basisimage ist nicht perfekt; Es gibt Nachteile, wie die Größe aller Abhängigkeiten, die hineingezogen werden. Dadurch werden Ihre Container-Images fast immer größer, als wenn Sie sie von Grund auf neu erstellen würden. Ein weiterer Nachteil ist, dass Sie nicht immer Zugriff auf den neuesten Upstream-Code haben. Das kann für Entwickler frustrierend sein, besonders wenn Sie einfach nur etwas veröffentlichen möchten, aber nicht so frustrierend, wie wenn Sie aufgefordert werden, sich eine Bibliothek anzusehen, an die Sie seit drei Jahren nicht mehr gedacht haben und die die Upstream-Betreuer die ganze Zeit geändert haben .
Wenn Sie ein Webentwickler sind und mit den Augen rollen, habe ich ein Wort für Sie:DevOps. Das heißt, Sie tragen einen Pager, mein Freund.
Von Grund auf neu bauen
Scratch-Builds haben den Vorteil, dass sie sehr klein sind. Wenn Sie sich nicht auf eine Linux-Distribution im Container verlassen, haben Sie viel Kontrolle, was bedeutet, dass Sie alles an Ihre Bedürfnisse anpassen können. Dies ist ein Best-of-Breed-Modell, das in bestimmten Anwendungsfällen gültig ist. Ein weiterer Vorteil ist, dass Sie Zugriff auf die neuesten Pakete haben. Sie müssen nicht auf eine Linux-Distribution warten, um etwas zu aktualisieren. Sie haben die Kontrolle, also entscheiden Sie, wann Sie die Entwicklungsarbeit aufwenden, um neue Software zu integrieren.
Denken Sie daran, dass es mit Kosten verbunden ist, alles zu kontrollieren. Das Aktualisieren auf neue Bibliotheken mit neuen Funktionen zieht häufig unerwünschte API-Änderungen nach sich, was bedeutet, dass Inkompatibilitäten im Code behoben werden (mit anderen Worten, Yaks rasieren). Yaks um 2 Uhr morgens zu rasieren, wenn die Anwendung nicht funktioniert, macht keinen Spaß. Glücklicherweise können Sie mit Containern am nächsten Werktag ein Rollback durchführen und die Yaks rasieren, aber es wird immer noch Ihre Zeit in Anspruch nehmen, um dem Unternehmen neuen Wert und neue Funktionen für Ihre Anwendungen zu bieten. Willkommen im Leben eines Systemadministrators.
OK, das heißt, es gibt Zeiten, in denen es sinnvoll ist, von Grund auf neu zu bauen. Ich gebe vollkommen zu, dass statisch kompilierte Golang-Programme und C-Programme zwei anständige Kandidaten für Scratch-/Distroless-Builds sind. Bei diesen Programmtypen ist jeder Container-Build ein Compile-Event. Sie müssen sich in drei Jahren immer noch Gedanken über API-Ausfälle machen, aber wenn Sie ein Golang-Shop sind, sollten Sie über die erforderlichen Fähigkeiten verfügen, um Probleme im Laufe der Zeit zu beheben.
Schlussfolgerung
Grundsätzlich erledigen Linux-Distributionen eine Menge Arbeit, um Ihnen Zeit zu sparen – auf einem normalen Linux-System oder mit Containern. Das Wissen, das Betreuer haben, ist enorm und wird so stark genutzt, ohne wirklich geschätzt zu werden. Die Übernahme von Containern hat das Problem noch verschlimmert, weil es noch weiter abstrahiert wird.
Mit Container-Hosts bietet Ihnen eine Linux-Distribution Zugriff auf ein breites Hardware-Ökosystem, das von winzigen ARM-Systemen über riesige 128-CPU-x86-Boxen bis hin zu VMs von Cloud-Anbietern reicht. Sie bieten sofort einsatzbereite Container-Engines und Container-Laufzeiten, sodass Sie einfach Ihre Container starten und jemand anderen sich darum kümmern können, dass die Dinge funktionieren.
Für Container-Images bieten Ihnen Linux-Distributionen einfachen Zugriff auf eine Menge Software für Ihre Projekte. Selbst wenn Sie von Grund auf neu bauen, werden Sie sich wahrscheinlich ansehen, wie ein Paketbetreuer Dinge erstellt und verschickt – ein guter Künstler ist ein guter Dieb –, also unterschätzen Sie diese Arbeit nicht.
Also vielen Dank an alle Betreuer von Fedora, RHEL (Frantisek, du bist mein Held), Debian, Gentoo und jeder anderen Linux-Distribution. Ich schätze Ihre Arbeit, obwohl ich ein "Container-Typ" bin.