Eine Build-Infrastruktur für den erweiterten Support von Linux-Distributionen am Ende der Lebensdauer haben

Einführung

Wenn es um die Bereitstellung von erweitertem Support für Linux-Distributionen am Ende der Lebensdauer (EOL) geht, kann die traditionelle Methode des Erstellens von Paketen aus dem Quellcode bestimmte Herausforderungen mit sich bringen. Eine der größten Herausforderungen ist die Notwendigkeit für einzelne Entwickler, Build-Abhängigkeiten in ihren eigenen Build-Umgebungen zu installieren. Dies führt oft zur Installation verschiedener alternativer Build-Abhängigkeiten, was zu Problemen im Zusammenhang mit der binären Kompatibilität führt. Darüber hinaus sind weitere Herausforderungen zu berücksichtigen, wie z. B. die Einrichtung einer isolierten und sauberen Build-Umgebung parallel zu verschiedenen Paket-Builds, die Implementierung einer effektiven Paketvalidierungsstrategie und die Verwaltung der Repository-Veröffentlichung usw.

Um diese Herausforderungen zu bewältigen, wird dringend empfohlen, über eine dedizierte Build-Infrastruktur zu verfügen, die das Erstellen von Paketen auf konsistente und reproduzierbare Weise ermöglicht. Mit der Build-Infrastruktur können Teams diese Probleme effektiv angehen und sicherstellen, dass die erforderlichen Pakete und Abhängigkeiten verfügbar sind, wodurch die Notwendigkeit für einzelne Entwickler entfällt, ihre eigenen Build-Umgebungen zu verwalten.

Der Open Build Service (OBS) von OpenSUSE

Am 30. Juni 2024 erreichen zwei wichtige Linux-Distributionen, Debian 10 „Buster“ und CentOS 7, ihren End-of-Life-Status (EOL). Diese haben in zahlreichen großen Unternehmensumgebungen eine breite Akzeptanz gefunden. Aufgrund verschiedener Faktoren können Unternehmen jedoch vor Herausforderungen bei der rechtzeitigen Durchführung von Migrationsprozessen stehen, was einen vorübergehenden erweiterten Support erforderlich macht.

Sobald eine Distribution ihr End-of-Life (EOL) erreicht hat, wird der Upstream-Support, einschließlich Spiegelserver und Infrastruktur, in der Regel entfernt. Dies stellt eine erhebliche Herausforderung für Organisationen dar, die erweiterten Support suchen, da sie nicht nur Zugriff auf einen lokalen Offline-Spiegelserver benötigen, sondern auch die Infrastruktur, um Pakete auf eine Weise zu erstellen, die mit den ursprünglichen Upstream-Builds übereinstimmt.

Um das Ziel zu erreichen, erweiterten Support für Linux-Distributionen am Ende der Lebensdauer (EOL) bereitzustellen, haben wir uns entschieden, einen lokalen Spiegelserver der EOL-Linux-Distribution und auch eine private OBS-Instanz zu haben. Um eine private OBS-Instanz zu haben, können Sie den OBS-Code aus dem Upstream-GitHub-Repository herunterladen und auf Ihrer lokalen Linux-Distribution installieren, oder alternativ können Sie einfach das OBS Appliance Installer herunterladen, um eine private OBS-Instanz als Build-Infrastruktur zu integrieren.

Durch die Einführung einer privaten OBS-Instanz als Build-Infrastruktur für den erweiterten Support von EOL-Linux-Distributionen können Teams den Paket-Build-Prozess vereinfachen, Inkonsistenzen minimieren und Reproduzierbarkeit erreichen. Dies vereinfacht nicht nur den Entwicklungs-Workflow, sondern verbessert auch die Gesamtqualität und Zuverlässigkeit der generierten Pakete. Replizieren Sie den semi-originalen Build-Prozess und stellen Sie sicher, dass die resultierenden Pakete die gleiche Qualität, Integrität und Kompatibilität wie die Upstream generierten beibehalten.

Erlauben Sie uns, zu demonstrieren, wie OBS für den erweiterten Support von Linux-Distributionen am Ende der Lebensdauer (EOL) verwendet werden kann. Bitte beachten Sie jedoch, dass die folgenden Beispiele rein Demonstrationszwecken dienen und möglicherweise nicht genau den spezifischen Ansatz oder das EOL-Produkt widerspiegeln, das in unserem tatsächlichen Projekt verwendet wird.

Lokalen Spiegelserver als DoD-Repository konfigurieren

Sobald Ihre private OBS-Instanz eingerichtet ist, können Sie sich über https mit ‚Admin‘ mit dem Standardpasswort ‚opensuse‘ in der OBS-WebUI anmelden. Sie können nur einige Konfigurationen mit dem Admin-Konto aktualisieren. Einschließlich der Verwaltung von Benutzern und Gruppen, Hinzufügen eines Download on Demand (DoD)-Repositorys, um eine Verbindung mit dem lokalen Spiegelserver in dem auf der privaten OBS-Instanz erstellten Projekt herzustellen.

DoD-Repository auf der Registerkarte Repository in Ihrer privaten OBS-Instanz hinzufügen:

DoD mit URL für internen lokalen Spiegelserver der EOL-Linux-Distribution konfigurieren:

Nachdem Sie den lokalen Spiegelserver mit der EOL-Linux-Distribution in der privaten OBS-Instanz verbunden haben, wurde die private OBS-Instanz zur Build-Infrastruktur, die verschiedene wichtige Distributionstypen unterstützt, was sie zu einer idealen Lösung für ein Team macht, das eine Infrastruktur sucht, um erweiterten Support für EOL-Linux-Distributionen bereitzustellen.

Vorteile der Build-Infrastruktur

OBS gewährleistet Konsistenz und Reproduzierbarkeit im Build-Prozess. Bietet auch eine anpassbare Build-Umgebung, die es Teams ermöglicht, die Umgebung an spezifische Projektanforderungen anzupassen.

• Konsistenz und reproduzierbare Builds: OBS bietet die Möglichkeit, Builds in sauberen Chroot- oder sauberen KVM-Umgebungen durchzuführen, wodurch konsistente und reproduzierbare Ergebnisse gewährleistet werden. Dies reduziert das Risiko unerwarteter Abweichungen oder Fehler während des Build-Prozesses.
• Anpassbare Build-Umgebung: OBS ermöglicht es Teams, die Build-Umgebung durch Projektkonfiguration anzupassen, wodurch sie Makros, Pakete, Flags und andere Build-bezogene Einstellungen definieren können. Dies gewährleistet die Kompatibilität mit den spezifischen Anforderungen der unterstützten EOL-Linux-Distribution.

Anpassbare Build-Umgebung.

• Isolation von Build-Umgebungen: OBS ermöglicht es Teams, separate Build-Umgebungen für verschiedene Projekte oder Distributionen zu erstellen, wodurch Interferenzen oder Konflikte zwischen Builds verhindert werden. Dies ermöglicht eine effiziente und parallele Entwicklung an mehreren EOL-Distributionen gleichzeitig.

Jeder Worker läuft isoliert mit einer anpassbaren Build-Umgebung effizient parallel.

• Release Number Control: OBS bietet Kontrolle über die Release-Nummern der erstellten Pakete, wodurch Kompatibilität und Konsistenz mit dem ursprünglichen Release-Nummerierungsschema gewährleistet werden. Dies ist besonders wichtig bei der Arbeit mit EOL-Distributionen.

Weitere Details: https://en.opensuse.org/openSUSE:Build_Service_prjconf#Release

Demonstration weiterer wichtiger Vorteile

Hier sind einige Vorteile der Verwendung von OBS mit Screenshots:

• Integrierte Zugriffskontrolle: OBS bietet eine flexible Zugriffskontrolle, die es Teammitgliedern ermöglicht, unterschiedliche Rollen und Berechtigungen für verschiedene Projekte oder Distributionen zu haben. Dies gewährleistet eine effiziente Zusammenarbeit und ein optimiertes Workflow-Management.

Benutzer und Gruppen und verschiedene Rollen verwalten:

• Download on Demand (DoD): OBS unterstützt die Download on Demand-Funktion, die Build-Abhängigkeiten bei Bedarf während des Build-Prozesses abruft. Dies vereinfacht den Build-Workflow und reduziert den Bedarf an manuellen Eingriffen.
• Offline Build Support: OBS ermöglicht die Erstellung einer Offline-Build-Umgebung über DoD, wodurch Teams Pakete ohne Internetverbindung erstellen können. Dies ist besonders wichtig bei der Arbeit mit EOL-Distributionen, bei denen der Internetzugang und offizielle Repositories möglicherweise nicht mehr verfügbar sind.

Build-Abhängigkeiten abrufen Pakete von Offline-Local-Mirror über DoD:

Starten Sie den Build-Prozess, nachdem Sie Build-Abhängigkeiten von DoD heruntergeladen haben:

• Flexible Project Setup: OBS ermöglicht es Teams, separate Projekte für Entwicklungs-, Staging- und Veröffentlichungszwecke zu erstellen. Dieser kontrollierte Workflow gewährleistet eine gründliche Prüfung und Validierung von Paketen, bevor sie an das Produktionsprojekt zur Veröffentlichung übermittelt werden.

Build-Ergebnis für Staging-Repo:

Automatisch im Staging-Repo veröffentlicht, sobald Pakete erstellt wurden:

Sie können den Paketvalidierungsprozess mit dem Staging-Repo starten. Und dann ein Paket von Staging zu Prod übermitteln, nachdem es den Validierungsprozess bestanden hat:

Die Paketübermittlungsanfrage kann vom Prod-Repo-Master überprüft werden, um sie anzunehmen oder abzulehnen:

• Repository Publish Integration: OBS lässt sich nahtlos in die lokale Repository-Veröffentlichung integrieren und stellt sicher, dass alle Pakete für den Build-Prozess leicht verfügbar und veröffentlicht sind. Dies macht eine zusätzliche Konfiguration auf internen oder externen Repositories überflüssig.

Der Build-Prozess startet, nachdem das Paket in das Prod-Repo aufgenommen wurde. Hier wird der Build-Status im Prod-Repo angezeigt:

Automatisch im Prod-Repo veröffentlicht, sobald Pakete erfolgreich erstellt wurden:

• Automatisierter Build über Pipelines: OBS unterstützt automatisierte Builds, die sich nahtlos in Delivery-Pipelines integrieren lassen. Teams können Trigger einrichten, um Builds automatisch basierend auf vordefinierten Kriterien zu initiieren, wodurch der manuelle Aufwand reduziert und die rechtzeitige Bereitstellung aktualisierter Pakete für Kunden sichergestellt wird.

Paket erhielt automatisierte Builds, wenn es in ein OBS-Projekt übertragen wurde. Einfache Integration in Delivery-Pipelines.

Zusammenfassend lässt sich sagen, dass OpenSUSE’s Open Build Service (OBS) eine robuste und umfassende Build-Infrastruktur für Teams bietet, die an erweitertem Support für EOL-Linux-Distributionen arbeiten.

Wenn Sie daran interessiert sind, eine Build-Infrastruktur zu integrieren oder erweiterten Support für eine EOL-Linux-Distribution benötigen, wenden Sie sich bitte an uns. Unser Team ist mit dem Fachwissen ausgestattet, um Sie bei der Integration einer privaten OBS-Instanz in Ihre bestehende Infrastruktur zu unterstützen.

Dieser Artikel wurde ursprünglich von Andrew Lee geschrieben