Haben wir einen distroless Kipppunkt erreicht?
Dies ist der zweite Teil einer dreiteiligen Serie, die sich mit der Bereitstellung von Open-Source-Software befasst — der jüngsten Vergangenheit, dem Wendepunkt der Gegenwart und der Zukunft.
Im ersten Beitrag befassen wir uns mit den Grundlagen, die Unix- und Linux-Betriebssystemdistributionen erstellt und definiert haben, und den Herausforderungen, die sich aus dem traditionellen Distributionsstatus quo ergeben. Wenn Sie keine Chance hatten, es zu fangen, gute Nachrichten: Es ist immer noch für Sie da.
Heute werden wir darüber sprechen, warum jetzt ein Wendepunkt ist, um diesen Status quo zu ändern.
Es gibt einen positiven Kreislauf in der Technologie, der die Grenzen dessen, was gebaut wird und wie es verwendet wird, verschiebt. Es entsteht eine neue Technologieentwicklung, die die Aufmerksamkeit der Welt auf sich zieht. Die Menschen beginnen zu experimentieren und entdecken neuartige Anwendungen, Anwendungsfälle und Ansätze, um das Innovationspotenzial zu maximieren. Diese Anwendungsfälle generieren einen erheblichen Wert, was die Nachfrage nach der nächsten Iteration der Innovation anheizt, und im Gegenzug schafft eine neue Welle von Innovatoren die nächste Generation von Anwendungsfällen, die weitere Fortschritte vorantreiben.
Die Containerisierung ist zur Grundlage moderner, Cloud-nativer Softwareentwicklung geworden und unterstützt neue Anwendungsfälle und Ansätze zum Aufbau widerstandsfähiger, skalierbarer und portabler Anwendungen. Es enthält auch die Schlüssel für die nächste Software-Innovation, die gleichzeitig die Entwicklung zu einer sicheren, kontinuierlich aktualisierten Software erfordert und als Mittel dient, um dorthin zu gelangen.
Im Folgenden werde ich einige der Innovationen besprechen, die zu unserer containerisierten Revolution geführt haben, sowie einige der Merkmale der Cloud-nativen Softwareentwicklung, die zu diesem Wendepunkt geführt haben – einer, die die Welt dazu gebracht hat, sich von traditionellen Linux-Distributionen und einem neuen Ansatz für die Bereitstellung von Open-Source-Software zu entfernen.
Iteration hat uns der Allgegenwart näher gebracht
Es gab viele Innovationen, die den Weg für eine sicherere, leistungsfähigere Open-Source-Bereitstellung geebnet haben. Im Interesse Ihrer Zeit und meiner Wortzahl werde ich drei besondere Meilensteine nennen. Jeder Schritt, von Linux Containers (LXC) über Docker bis hin zur Open Container Initiative (OCI), baute auf seinem Vorgänger auf, adressierte Einschränkungen und erschloss neue Möglichkeiten.
LXC legte den Grundstein, indem es die Fähigkeiten des Linux-Kernels (nämlich cgroups und Namespaces) nutzte, um leichte, isolierte Umgebungen zu schaffen. Zum ersten Mal konnten Entwickler Anwendungen mit ihren Abhängigkeiten verpacken und so ein gewisses Maß an Konsistenz über verschiedene Systeme hinweg bieten. Die Komplexität von LXC für die Benutzer und das Fehlen eines standardisierten Bildverteilungskatalogs behinderten jedoch die breite Akzeptanz.
Docker entwickelte sich zu einem bahnbrechenden, demokratisierenden Container-Technologie. Es vereinfachte den Prozess der Erstellung, Ausführung und Freigabe von Containern und machte sie einem breiteren Publikum zugänglich. Die benutzerfreundliche Oberfläche von Docker und die Schaffung von Docker Hub, einem zentralen Repository für Container-Images, förderten ein lebendiges Ökosystem. Diese Benutzerfreundlichkeit hat zu einer raschen Einführung geführt, aber auch Bedenken hinsichtlich der Anbieterbindung und der Notwendigkeit der Interoperabilität geäußert.
In Anerkennung des Fragmentierungspotenzials hat die OCI (Open Containers Initiative) die Containerformate und -laufzeiten standardisiert. Durch die Definition offener Spezifikationen stellte das OCI sicher, dass Container über verschiedene Plattformen gebaut und betrieben werden konnten, was eine gesunde, wettbewerbsfähige Landschaft förderte. Projekte wie runC und containerd, die aus dem OCI hervorgegangen sind, bildeten eine gemeinsame Grundlage für Containerlaufzeiten und ermöglichten eine größere Portabilität und Interoperabilität.
Die OCI-Standards ermöglichten es Kubernetes (einem weiteren herstellerneutralen Standard) auch, eine wirklich tragbare Plattform zu werden, die auf einer Vielzahl von Infrastrukturen ausgeführt werden kann und es Unternehmen ermöglicht, ihre Anwendungen konsistent über verschiedene Cloud-Anbieter und lokale Umgebungen hinweg zu orchestrieren. Diese Standardisierung und die damit verbundenen Innovationen erschlossen das volle Potenzial von Containern und ebneten den Weg für ihre allgegenwärtige Präsenz in der modernen Softwareentwicklung.
[Containerisierte] Software frisst die Welt
Die Fortschritte bei Linux, die schnelle Demokratisierung von Containern durch Docker und die Standardisierung von OCI wurden alle durch die Notwendigkeit vorangetrieben, wobei die Entwicklung von Cloud-nativen Anwendungsfällen für Apps die Orchestrierung und Standardisierung vorantreibt. Diese Cloud-nativen Anwendungseigenschaften zeigen auch, warum ein universeller Ansatz für Linux-Distributionen Softwareentwicklern nicht mehr die sichersten, aktuellsten Grundlagen bietet, auf denen sie entwickeln können:
Microservice-orientierte Architektur: Cloud-native Anwendungen werden in der Regel als eine Sammlung kleiner, unabhängiger Dienste erstellt, wobei jeder Microservice eine bestimmte Funktion ausführt. Jeder dieser Microservices kann unabhängig erstellt, bereitgestellt und gewartet werden, was ein enormes Maß an Flexibilität und Ausfallsicherheit bietet. Da jeder Microservice unabhängig ist, benötigen Softwareentwickler keine umfassenden Softwarepakete, um einen Microservice auszuführen, und verlassen sich nur auf das Nötigste in einem Container.
Ressourcenschonend und effizient: Cloud-native Anwendungen sind so konzipiert, dass sie effizient und ressourcenschonend sind, um die Belastung der Infrastruktur zu minimieren. Dieser reduzierte Ansatz passt natürlich gut zu Containern und einer kurzlebigen Bereitstellungsstrategie, wobei ständig neue Container bereitgestellt und andere Workloads auf den neuesten verfügbaren Code aktualisiert werden. Dadurch werden Sicherheitsrisiken reduziert, indem die neuesten Softwarepakete genutzt werden, anstatt auf Distributions-Patches und Backports zu warten.
Portabilität: Cloud-native Anwendungen sind so konzipiert, dass sie portabel sind, mit konsistenter Leistung und Zuverlässigkeit, unabhängig davon, wo die Anwendung ausgeführt wird. Durch die Standardisierung der Umgebung von Containern können Entwickler über die uralten Kopfschmerzen der Vergangenheit hinausgehen, „es funktionierte gut auf meiner Maschine“.
Der tugendhafte Kreislauf der Innovation, der neue Anwendungsfälle und letztendlich neue Innovationen antreibt, ist klar, wenn es um die Containerisierung und die weit verbreitete Einführung von Cloud-nativen Anwendungen geht. Entscheidend ist, dass dieser Wendepunkt der Innovations- und Anwendungsfallanforderungen zu einer unglaublichen Veränderungsrate bei Open-Source-Software geführt hat und unterstreicht, wie wichtig es ist, einen neuen Ansatz für die Bereitstellung von Open-Source-Software zu finden.
Im letzten Blog der Serie werden wir darüber sprechen, wie Chainguard einen neuen distroless-Ansatz entwickelt hat, die wichtigsten Merkmale und die Auswirkungen, die er auf Open-Source-Container-Images haben kann.
Wenn Sie dies nützlich fanden, lesen Sie unbedingt unser Whitepaper zu diesem Thema und die umfassendere Methode, mit der wir dieses Problem für Unternehmen gelöst haben.
Share this article
Related articles
- engineering
Breaking the release monolith: How OutSystems platform engineering restored trust in delivery
Maria Chec, Technical Program Manager, Outsystems, and João Brandão, Release Engineering Director, Outsystems
- engineering
Owning the boundary: Introducing the Chainguard FIPS Provider for OpenSSL 3.4.0
Dimitri John Ledkov, Senior Principal Software Engineer, and Mandy Hubbard, Senior Technical Product Marketing Manager
- engineering
FIPS-ing the Un-FIPS-able: Apache Kafka
Jamon Camisso, Senior Manager, Software Engineering
- engineering
This Shit is Hard: The complexities of fixing Python library security issues at scale
Wesley Wiedenmeier, Senior Software Engineer
- engineering
How I learned to stop worrying and love the latest tag
Adrian Mouat, Staff Developer Relations Engineer
- engineering
The tech leader’s mandate: Use engineering to accelerate sales velocity
Sam Katzen, Staff Product Marketing Manager