Vermeidung von Vendor-Lock-in mit einer kompatiblen, migrationsfreundlichen und transparenten Container-Distribution

Laut Gartner werden bis 2027 mehr als 90 % der globalen Unternehmen containerisierte Anwendungen in der Produktion einsetzen, ein Anstieg von nur 40 % im Jahr 2021. Und da Open-Source-Komponenten 70–90 % einer durchschnittlichen Unternehmens-Codebasis ausmachen, wird ein Großteil der heutigen Innovation durch Open-Source-Betriebssysteme vorangetrieben.

Für Entwickler, Platform Engineers, Infrastruktur-Teams und DevOps-Führungskräfte bedeutet dies, dass die Wahl der richtigen Linux-Distribution als Basis für ihre containerisierten Workloads keine Entscheidung ist, die man leichtfertig treffen sollte. Die Distribution, für die Sie sich entscheiden, bestimmt nicht nur, wie effizient und effektiv Ihre Anwendungen heute sind, sondern auch, wie anpassungsfähig Ihr Stack an die Innovationen von morgen sein wird.

Wenn Sie neugierig auf die Beweggründe und den Hintergrund der Entscheidung von Chainguard sind, eine eigene Distribution zu entwickeln, lesen Sie unsere Blogserie über die Entstehung von Chainguard OS.

Die Bewertung von Linux-Distributionen ist komplex. Nach der Zusammenarbeit mit über 250 Kunden ist eine häufige Bewertungsfrage, die Chainguard von Kunden hört, die nach dem „Vendor-Lock-in“ – also der Anbieterbindung –, bei der der Wechsel zu einer Alternative oder die Interoperabilität außerhalb einer bestimmten Plattform unerschwinglich teuer, technologisch herausfordernd oder riskant wird.

Um bei der Bewertung von Distributionen im Kontext von Lock-in zu helfen, ist es nützlich, vier Kernfragen zu stellen:

1. Interoperiert die Distribution gut mit meinen Toolsets und Prozessen sowie dem breiteren Ökosystem als Ganzes?

2. Sind die Build-Prozesse der Distribution transparent und zugänglich?

3. Ist die Migration zu dieser Distribution einfach?

4. Wie schwierig ist es, diese Distribution bei Bedarf wieder zu verlassen?

Wenn Sie diese vier Fragen beantworten können, sind Sie bereits in der Lage, intelligentere und zukunftssicherere Entscheidungen zu treffen. Lassen Sie uns jeden Punkt aufschlüsseln.

Kompatibilität: Wie passt sie zum Ökosystem?

Kompatibilität und Interoperabilität sind in containerisierten Umgebungen entscheidend. Die von Ihnen gewählte Distribution sollte sich nahtlos in Ihre bestehende Toolchain integrieren, einschließlich CI/CD-Pipelines, Schwachstellen-Scannern, Artefakt-Repositories und privaten Registries, ohne Sie zu fragmentierten Workflows oder unnötiger Duplizierung zu zwingen.

Dies bedeutet zumindest die Einhaltung weit verbreiteter Standards und Protokolle. Beispiele hierfür sind:

• OCI-konforme Container, die Portabilität gewährleisten.

• SBOMs auf Basis von CycloneDX oder SPDX für transparente Lieferketten-Metadaten.

• Multi-Architektur-Unterstützung, einschließlich x86 und ARM.

Es bedeutet auch die Übernahme zugrunde liegender Architekturen, die zwar keine expliziten Standards sind, aber weit verbreitete Toolsets darstellen. Im Falle von containerisierten Workloads könnten dies Standardbibliotheken wie glibc, FHS-Konformität und weit verbreitete Paketmanager wie apk sein.

In der Praxis reduziert eine breit kompatible Distribution Reibungsverluste bei Entwicklung und Betrieb, verringert die Ausbreitung zusätzlicher Tools sowie Kontextwechsel und erleichtert die Durchsetzung von Sicherheitsrichtlinien sowie die Erfüllung von Compliance-Vorgaben.

Build-Transparenz: Sind die Build-Prozesse der Distribution transparent und zugänglich?

Neben Kompatibilität und Interoperabilität sind einfache Transparenz und Zugänglichkeit wichtig. Macht die Distribution die Tools und Prozesse, die für das Builden mit ihr erforderlich sind, öffentlich zugänglich? Dies wird zu einem kritischen Element, um bei einer bestimmten Distribution „unter die Motorhaube zu schauen“, um deren Reproduzierbarkeit zu verstehen, während gleichzeitig ein klares Verständnis dafür vermittelt wird, welche Tools auf Seiten der Distribution erforderlich sind, um das Endergebnis Ihres eigenen Anwendungsfalls zu erzielen.

Wenn der Build-Prozess verschleiert ist oder die Tools unzugänglich sind oder keine zugängliche Dokumentation haben, sollte dies Fragen aufwerfen, ob die Distribution proprietäre Prozesse nutzt, die Sie binden könnten.

Migration: Wie einfach ist die Einführung?

Die Migration von Workloads auf eine neue Distribution kann von unkompliziert bis entmutigend reichen. Der entscheidende Faktor ist oft, wie standardisiert und vollständig das Ökosystem der Distribution ist.

Wichtige Überlegungen sind:

• Paketverfügbarkeit: Ein tiefes und gut gepflegtes Repository erhöht die Wahrscheinlichkeit, dass die Software, von der Sie bereits abhängen, sofort unterstützt wird.

• Unternehmenssupport: Bei kommerziellen Distributionen können SLAs, professionelle Expertise und die Unterstützung durch den Anbieter bei der Behandlung von Sonderfällen von unschätzbarem Wert sein.

• Dokumentation und Tools: Migrationsleitfäden, Automatisierungsskripte und eine robuste Dokumentation erleichtern den Übergang.

Und übersehen Sie nicht die Lebensqualität nach der Migration. Fragen Sie sich selbst:

• Wie schnell patcht die Distribution CVEs?

• Reduziert sie die Angriffsfläche durch kleinere Basis-Images?

• Sind moderne kryptografische Bibliotheken standardmäßig enthalten?

• Veröffentlicht der Anbieter signierte SBOMs, Herkunftsdaten und Signaturen?

Eine Distribution, die hier überzeugt, vereinfacht nicht nur die Migration, sondern macht den Wechsel durch verbesserte Sicherheit, Leistung und Wartbarkeit auch lohnenswert.

Migration weg: Wie schwer ist es, sie zu verlassen?

Wenn man die Entscheidung trifft, zu etwas Neuem zu migrieren, ist es schwer, sich eine Zukunft vorzustellen, in der man bereits wieder wegmigriert. Aber technologische Prioritäten verschieben sich, betriebliche Anforderungen ändern sich und manchmal nimmt die organisatorische Ausrichtung eine unerwartete Wendung. Wenn das passiert, möchten Sie nicht durch das Ökosystem eines Anbieters gefangen sein oder der Lizenzmacht des Anbieters ausgeliefert sein.

Die Bewertung von Exit-Kosten bedeutet, nach denselben Merkmalen zu suchen, die Ihre ursprüngliche Migration ermöglicht haben: standardbasierte Komponenten und Architektur, breite Paketverfügbarkeit und minimales proprietäres Lock-in. Idealerweise sollte die von Ihnen gewählte Distribution vermeiden, einzigartige Abhängigkeiten einzuführen, die Sie an einen einzigen Anbieter oder ein einziges Ökosystem binden. Entscheidend für die Vermeidung von Lock-in ist sicherzustellen, dass Sie dauerhaften Zugriff auf das Betriebssystem behalten, von dem Sie wegmigrieren, sei es durch Ihre ursprüngliche kommerzielle Vereinbarung oder Open Source.

Wie Chainguard OS abschneidet

Chainguard OS ist ein minimales, gehärtetes Linux-basiertes Betriebssystem, das für die sichere, containerisierte Softwarebereitstellung entwickelt wurde. Es wurde intern von Chainguard entwickelt, dient als Grundlage für die Container-Produkte von Chainguard und legt den Schwerpunkt auf kontinuierliche Integration, unveränderliche Artefakte und die Ausrichtung auf Upstream-Software. Das Wolfi-Projekt ist das Open-Source-Gegenstück zu Chainguard OS und treibt die kostenlosen Starter-Container-Images von Chainguard an. Innerhalb weniger Jahre haben beide bei Unternehmen und Open-Source-Anwendern gleichermaßen an Bedeutung gewonnen, da sie moderne Sicherheits- und Leistungspraktiken mit der von Teams geforderten Interoperabilität verbinden.

Kompatibilität

Chainguard OS nutzt die glibc-Implementierung und apk, zwei weit verbreitete Bausteine, die eine umfassende Unternehmenskompatibilität ermöglichen. Es läuft sowohl auf x86 als auch auf ARM und bietet jetzt einen vollständigen Kernel für Container-Hosts, Anwendungen und VM-Basis-Images, wodurch es möglich wird, Chainguard OS für Anwendungsfälle außerhalb der Containerisierung zu standardisieren. Als Beispiel für die Kompatibilität von Chainguard sind unsere FIPS-validierten Container-Images kernelunabhängig, was bedeutet, dass sie die Compliance aufrechterhalten können, während sie auf einem beliebigen zugrunde liegenden Host-Betriebssystem ausgeführt werden.

Alle Chainguard-Container-Images sind OCI-konform und verfügen über Integrationen für SPDX, CycloneDX und Sigstore/Cosign, um die SBOM-Generierung und kryptografische Signierung zu vereinfachen. Dies stellt sicher, dass sich Chainguard OS nahtlos in bestehende CI/CD- und DevSecOps-Workflows einfügt und gleichzeitig mit einer Vielzahl von Scannern und Artefakt-Repositories kompatibel ist.

Build-Transparenz und Open-Source-Tooling

Chainguard OS verfügt über offene, zugängliche Tools, die es jedem ermöglichen, einen Chainguard-Build nachzubilden. Melange und apko sind zwei der Kernwerkzeuge, die Chainguard verwendet, um sicherzustellen, dass Image-Builds vollständig transparent und reproduzierbar sind. Melange ist ein Paket-Build-System, mit dem Sie in einem einfachen, deklarativen YAML-Format definieren können, wie Software aus dem Quellcode in APK-Pakete gebaut wird, und apko ist ein Werkzeug zum Zusammenstellen dieser APK-Pakete zu minimalen, OCI-konformen Container-Images.

Zusammen ermöglichen sie es jedem, dieselben Build-Definitionen zu verwenden, die auch Chainguard nutzt, diese lokal oder in eigenen CI/CD-Systemen auszuführen und ein Container-Image auf Basis von Chainguard OS oder Wolfi zuverlässig zu reproduzieren.

Auch wenn Sie vielleicht nicht daran interessiert sind, Ihr vollständiges Basis-Image von Grund auf neu zu erstellen, garantieren die Offenheit und Verfügbarkeit der Tools Verifizierbarkeit, Transparenz der Lieferkette und Vertrauen, während gleichzeitig deutlich wird, dass Benutzer nicht von proprietären Tools abhängig gemacht werden.

Migration

Im Gegensatz zu herkömmlichen Distributionen setzt Chainguard OS auf minimale, distroless, zweckgebundene Container-Images. Es unterscheidet zwischen -dev-Varianten (mit Shells und Paketmanagern) und Produktionsvarianten (die auf das Wesentliche reduziert sind), wodurch die Angriffsfläche verringert wird, ohne die Funktionalität zu beeinträchtigen. Dies trägt dazu bei, die Einführung unserer Images zu rationalisieren. Darüber hinaus haben wir Open-Source-Tools wie den Dockerfile Converter entwickelt, der Entwicklern hilft, die Migration zu Chainguard Containers zu automatisieren.

Mit einem Repository von über 15.000 Paketen (das je nach Kundenbedarf wächst), beseitigt Chainguard OS viele Migrationsprobleme durch eine vollständige Abdeckung der Abhängigkeiten von Entwicklern. Teams finden weitaus eher die Pakete und Versionen, die sie benötigen, ohne ihre Anwendungen umschreiben oder Abhängigkeiten ersetzen zu müssen – was die Einführung insgesamt vereinfacht.

Chainguard OS und Wolfi profitieren zudem von einer schnell wachsenden Open-Source-Community sowie von Dokumentation, Tools und professionellem Support auf Unternehmensniveau. Kunden wie Snowflake, BitDefender, Confluent, Shift5 und Snap waren mit Chainguard erfolgreich und führen dies nicht nur auf die Kompatibilität zurück, sondern auch auf die verbesserte Sicherheitslage und Leistung der Chainguard-Container-Images.

Migration weg von Chainguard

Ein Wechsel weg von Chainguard OS würde höchstwahrscheinlich die Änderung von Dockerfiles und möglicherweise von Helm-Chart-Konfigurationen erfordern, um alternative Images und Pakete zu verwenden. Dank architektonischer Grundlagen wie glibc und dem breiten, aus dem Quellcode erstellten Paket-Repository von Chainguard können Unternehmen darauf vertrauen, dass die benötigten Pakete in Upstream-Distributionen verfügbar sein werden.

Wir alle wissen, wie frustrierend es sein kann, wenn Unternehmen versuchen, die Lizenzen zu ändern, nachdem man bereits in die Einführung investiert hat. Seien Sie versichert, dass Sie, egal für welche Richtung Sie sich entscheiden, immer eine unbefristete Lizenz zur Nutzung des von Ihnen bezahlten Chainguard OS haben, sodass alle abgerufenen und/oder gespiegelten Container-Images weiterhin verwendet werden können.

Zusammenfassend lässt sich sagen, dass Chainguard OS auf Open Source basiert, Open-Source- und frei zugängliche Build-Tools nutzt und weit verbreitete Standards einhält, was Unternehmen in die Lage versetzt, Anwendungen auf einem „Secure-by-Design“-Fundament zu erstellen, ohne das Risiko eines Vendor-Lock-ins. Dieselbe Kompatibilität, Paketvielfalt und der auf Standards basierende Ansatz, die die Migration zu Chainguard erleichtern, reduzieren auch die Hürden bei einer Abwanderung.

Wenn Sie tiefer eintauchen möchten, lesen Sie unser „Chainguard your OS“-Whitepaper, um mehr über den Ansatz hinter Chainguard OS zu erfahren, oder kontaktieren Sie unser Team, um zu erkunden, wie Chainguard Containers in Ihre Umgebung passen können.