Open Build Service – Dienstprogramm zum Erstellen und Veröffentlichen aktualisierter Pakete einer EOL-Distribution

Einführung

Wenn es um die Bereitstellung von erweitertem Support für End-of-Life (EOL) Linux-Distributionen geht, kann die traditionelle Methode, Pakete aus Quellen zu erstellen, 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 unterschiedlicher Build-Abhängigkeiten, was zu Problemen bei der Binärkompatibilität führt. Zusätzlich sind weitere Herausforderungen zu berücksichtigen, wie die Einrichtung einer isolierten und sauberen Build-Umgebung für verschiedene parallele Paket-Builds, die Implementierung einer effektiven Strategie zur Paketvalidierung und die Verwaltung der Repository-Veröffentlichung usw.

Um diese Herausforderungen zu meistern, wird dringend empfohlen, eine dedizierte Build-Infrastruktur zu haben, die das Erstellen von Paketen auf konsistente und reproduzierbare Weise ermöglicht. Mit einer solchen Infrastruktur können Teams diese Probleme effektiv angehen und sicherstellen, dass die notwendigen 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 bietet eine weithin anerkannte öffentliche Build-Infrastruktur, die RPM-basierte, Debian-basierte und Arch-basierte Paket-Builds unterstützt. Diese Infrastruktur ist bei Anwendern, die angepasste Paket-Builds auf wichtigen Linux-Distributionen benötigen, hoch angesehen. Zusätzlich kann OBS als private Instanz bereitgestellt werden, was eine robuste Lösung für Organisationen bietet, die private Softwarepaket-Builds durchführen. Mit seinem umfangreichen Funktionsumfang dient OBS als umfassende Build-Infrastruktur, die die Anforderungen von Teams erfüllt, um sicherheitsgepatchte Pakete auf Basis bereits vorhandener Pakete zu erstellen, um beispielsweise den Support von End-of-Life (EOL) Linux-Distributionen zu verlängern.

Fakten

Am 30. Juni 2024 haben zwei wichtige Linux-Distributionen, Debian 10 „Buster“ und CentOS 7, ihren End-of-Life (EOL)-Status erreicht. Diese Distributionen fanden in zahlreichen großen Unternehmensumgebungen weite Verbreitung. Aufgrund verschiedener Faktoren können Organisationen jedoch Schwierigkeiten haben, Migrationsprozesse rechtzeitig abzuschließen, was eine vorübergehende erweiterte Unterstützung für diese Distributionen erforderlich macht.

Wenn eine Distribution ihren End-of-Life (EOL)-Support vom Upstream erreicht, werden Spiegelserver und die entsprechende Infrastruktur typischerweise entfernt. Dies stellt eine erhebliche Herausforderung für Organisationen dar, die diese Distributionen noch verwenden und erweiterten Support suchen, da sie nicht nur Zugang zu einem lokalen Offline-Spiegel benötigen, sondern auch die Infrastruktur, um Pakete so neu zu erstellen, dass dies mit ihren früheren originalen Upstream-Builds konsistent ist, wann immer Pakete aus Sicherheitsgründen neu erstellt werden müssen.

Ziel

Um Dienstprogramme bereitzustellen, die Teams beim Erstellen von Paketen unterstützen, kann OBS ihnen helfen. Dabei hilft es ihnen auch, eine Build-Infrastruktur zu haben, die alle vorhandenen Quell- und Binärpakete zusammen mit ihren Sicherheitspatches in einer semi-originalen Build-Umgebung erstellt und so den Support für EOL Linux-Distributionen weiter verlängert. Dies wird erreicht, indem Paket-Builds auf einem ähnlichen Qualitäts- und Kompatibilitätsniveau wie ihre früheren originalen Upstream-Builds gehalten werden.

Anforderungen

Um das oben genannte Ziel zu erreichen, sind zwei wesentliche Komponenten erforderlich:

1. Lokaler Spiegel der EOL Linux-Distribution
2. Private OBS-Instanz.

Um eine private OBS-Instanz einzurichten, können Sie OBS aus dem Upstream-GitHub-Repository beziehen und auf Ihrem lokalen Rechner installieren sowie bauen, oder alternativ können Sie einfach den OBS Appliance Installer herunterladen, um eine private OBS-Instanz als neue Build-Infrastruktur zu integrieren.

Beachten Sie, dass der lokale Spiegel typischerweise nicht die Sicherheitspatches enthält, um den Support der EOL-Distribution ordnungsgemäß zu erweitern. Das bloße Neuerstellen der vorhandenen Pakete verlängert den Support solcher Distributionen nicht automatisch. Entweder müssen diese Sicherheitspatches von den Teams selbst gepflegt und manuell zum Paket-Update hinzugefügt werden, oder sie werden von einem Upstream-Projekt bezogen, das diese Patches bereits bereitstellt.

Nichtsdestotrotz kann die private OBS-Instanz, sobald sie erfolgreich installiert ist, mit dem lokalen Offline-Spiegel verknüpft werden, für den das Team den Support erweitern möchte, und als semi-originale Build-Umgebung konfiguriert werden. Dadurch kann die Build-Umgebung so nah wie möglich an die ursprüngliche Upstream-Build-Umgebung konfiguriert werden, um ein ähnliches Qualitäts- und Kompatibilitätsniveau zu gewährleisten, auch wenn Pakete für Sicherheitsupdates mit neuen Patches erstellt werden.

Auf diese Weise kann der bereits beendete Support einer Linux-Distribution verlängert werden, da ein dafür vorgesehenes Team nicht nur Pakete selbst erstellen, sondern auch Patches für Pakete bereitstellen kann, die von Fehlern oder Sicherheitslücken betroffen sind.

Ergebnis

Die OBS-Build-Infrastruktur bietet eine semi-originale Build-Umgebung, um den Paket-Build-Prozess zu vereinfachen, Inkonsistenzen zu reduzieren und Reproduzierbarkeit zu erreichen. Durch diesen Ansatz können Teams ihre Entwicklungs- und Test-Workflows vereinfachen und die Gesamtqualität und Zuverlässigkeit der generierten Pakete verbessern.

Demonstration

Wir möchten Ihnen demonstrieren, wie OBS als Build-Infrastruktur für Teams genutzt werden kann, um die benötigte Build- und Veröffentlichungs-Infrastruktur zur Verlängerung des Supports von End-of-Life (EOL) Linux-Distributionen bereitzustellen. Bitte beachten Sie jedoch, dass die folgenden Beispiele ausschließlich Demonstrationszwecken dienen und den spezifischen Ansatz möglicherweise nicht exakt widerspiegeln.

OBS konfigurieren

Sobald Ihre private OBS-Instanz eingerichtet ist, können Sie sich über die WebUI bei OBS anmelden. Sie müssen das Konto „Admin“ mit dem Standardpasswort „opensuse“ verwenden. Danach können Sie ein neues Projekt für die EOL Linux-Distribution erstellen sowie Benutzer und Gruppen für Teams hinzufügen, die an diesem Projekt arbeiten werden. Zusätzlich müssen Sie Ihr Projekt mit einem lokalen Spiegel der EOL Linux-Distribution verknüpfen und Ihr OBS-Projekt anpassen, um die frühere Upstream-Build-Umgebung zu replizieren.

OBS unterstützt die Funktion Download on Demand (DoD), die eine Verbindung zu einem lokalen Spiegel auf der OBS-Instanz mit dem dafür vorgesehenen Projekt innerhalb von OBS herstellen kann, um Build-Abhängigkeiten während des Build-Prozesses bei Bedarf abzurufen. Dies vereinfacht den Build-Workflow und reduziert den Bedarf an manuellen Eingriffen.

Hinweis: Einige Konfigurationen sind nur mit dem Admin-Konto verfügbar, darunter Benutzer verwalten, Gruppen und Download on Demand (DoD)-Repository hinzufügen.

Tauchen wir nun in die OBS-Konfiguration eines solchen Projekts ein.

DoD-Repository hinzufügen

Nachdem Sie ein neues Projekt in OBS erstellt haben, finden Sie die Option „DoD-Repository hinzufügen“ im Reiter „Repositories“ unter dem Admin-Konto.

Dort müssen Sie auf die Schaltfläche „DoD-Repository hinzufügen“ klicken, wie unten gezeigt:

Lokalen Spiegel über DoD verknüpfen

Als Nächstes können Sie eine URL angeben, um Ihren lokalen Spiegel über „DoD-Repository hinzufügen“ zu verknüpfen.

Dadurch konfigurieren Sie das DoD-Repository. Dafür müssen Sie:

• DoD-Repository benennen
• Geben Sie eine URL an, die auf den lokalen Spiegel verweist, der als Basis für das Erstellen von Paketen in unserem Projekt verwendet wird

Die Build-Abhängigkeiten sollten nun für OBS automatisch über die DoD-Funktion zum Download verfügbar sein.

Wie Sie im folgenden Beispiel sehen können, konnte OBS alle Build-Abhängigkeiten für das gezeigte Paket „kernel“ über DoD abrufen, bevor es tatsächlich mit dem Erstellen des Pakets begann:

Nachdem Sie den lokalen Spiegel mit der EOL Linux-Distribution verbunden haben, sollten wir auch die Projektkonfiguration anpassen, um die semi-originale Build-Umgebung des früheren Upstream-Projekts in unserem OBS-Projekt neu zu erstellen.

Projektkonfiguration

OBS bietet eine anpassbare Build-Umgebung über die Projektkonfiguration, die es Teams ermöglicht, spezifische Projektanforderungen zu erfüllen.

Es ermöglicht Teams, die Build-Umgebung über die Projektkonfiguration anzupassen, wodurch sie Makros, Pakete, Flags und andere Build-bezogene Einstellungen definieren können. Dies hilft, ihr Projekt an alle Anforderungen anzupassen, die zur Aufrechterhaltung der Kompatibilität mit den Originalpaketen erforderlich sind.

Die Projektkonfiguration finden Sie hier:

Werfen wir einen genaueren Blick auf einige Beispiele, die zeigen, wie die Projektkonfiguration für das Erstellen von RPM-basierten oder Debian-basierten Paketen aussehen könnte.

Je nach dem tatsächlichen Pakettyp, der von der EOL Linux-Distribution verwendet wurde, muss die Projektkonfiguration entsprechend angepasst werden.

RPM-basierte Konfiguration
Hier ist ein Beispiel für eine RPM-basierte Distribution, wo Sie Makros, Pakete, Flags und andere Build-bezogene Einstellungen definieren können.

Bitte beachten Sie, dass dieses Beispiel nur zu Demonstrationszwecken dient:

Debian-basierte Konfiguration

Dann gibt es ein weiteres Beispiel für eine Debian-basierte Distribution, wo Sie Repotype: debian angeben, vorinstallierte Pakete definieren und Build-bezogene Einstellungen in der Build-Umgebung festlegen können.

Auch hier gilt: Bitte beachten Sie, dass dieses Beispiel nur zu Demonstrationszwecken dient:

Wie Sie in den obigen Beispielen sehen können, definiert die Repotype das Repository-Format für die veröffentlichten Repositories. Preinstall definiert Pakete, die in der Build-Umgebung verfügbar sein sollten, während andere Pakete erstellt werden. Weitere Details zur Syntax finden Sie im Kapitel Build-Konfiguration im von OpenSuSE bereitgestellten Handbuch.

Mit dieser anpassbaren Build-Umgebungsfunktion beginnt jeder Build in einer sauberen Chroot- oder KVM-Umgebung, was Konsistenz und Reproduzierbarkeit im Build-Prozess gewährleistet. Teams können unterschiedliche Build-Umgebungen in verschiedenen Projekten haben, die isoliert sind und parallel erstellt werden können. Die getrennten Projekte, zusammen mit dedizierten Chroot- oder KVM-Umgebungen für das Erstellen von Paketen, verhindern Interferenzen oder Konflikte zwischen Builds.

Benutzerverwaltung

Zusätzlich zu Projekten bietet OBS eine flexible Zugriffssteuerung, 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.

Um diese Funktion ordnungsgemäß zu nutzen, müssen wir Benutzer und Gruppen über das Admin-Konto in OBS erstellen. Den Reiter „Benutzer“ finden Sie innerhalb des Projekts, wo Sie Benutzer und Gruppen mit unterschiedlichen Rollen hinzufügen können.

Das folgende Beispiel zeigt, wie Benutzer und Gruppen in einem bestimmten Projekt hinzugefügt werden:

Flexible Projekteinrichtung

OBS ermöglicht 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 zur Veröffentlichung an das Produktionsprojekt übermittelt werden.

Teststrategie mit Projekten

Bevor Pakete freigegeben und veröffentlicht werden, ist eine ordnungsgemäße Prüfung dieser Pakete entscheidend. Um dies zu erreichen, bietet OBS eine Repository-Veröffentlichungs-Integration, die bei der Implementierung einer Teststrategie hilft. Entwickler können ihre Pakete zuerst in einem entsprechenden Staging-Repository veröffentlichen lassen, bevor der Validierungsprozess der Pakete beginnt, damit sie an das Produktionsprojekt übermittelt werden können. Von dort aus werden sie dann veröffentlicht und anderen Systemen zur Verfügung gestellt.

Es integriert sich nahtlos in die lokale Repository-Veröffentlichung, wodurch sichergestellt wird, dass alle Pakete im Build-Prozess sofort verfügbar sind. Dies eliminiert die Notwendigkeit zusätzlicher Konfigurationen auf internen oder externen Repositories.

Das nächste Beispiel zeigt ein Projekt ‚home:andrew:internal-os:10:staging‘, das als Staging-Repository verwendet wird. Dort importieren wir das Nginx-Quellpaket, um es anschließend zu erstellen und zu validieren.

Build-Prozess starten

Sobald die Build-Abhängigkeiten über DoD heruntergeladen wurden, startet der Build-Prozess automatisch.

Sobald der Build-Prozess für ein Paket wie „nginx“ erfolgreich ist, werden wir es auch in der Oberfläche sehen:

Zu guter Letzt wird das Paket automatisch in einem Repository veröffentlicht, das bereit ist, mit Paketmanagern wie YUM verwendet zu werden. In unserem Testfall hilft uns das YUM-bereite Repository, die Validierung einfach durchzuführen, indem wir Tests auf VMs oder tatsächlicher Hardware durchführen.

Unten sehen Sie ein Beispiel dieses Staging-Repositorys (Index des YUM-bereiten Staging-Repositorys):

Bitte beachten Sie: Um die Teststrategie in unserem Beispiel zu erfüllen, sollten Pakete nur an das Produktionsprojekt übermittelt werden, sobald sie den Validierungsprozess im Staging-Repository erfolgreich durchlaufen haben.

Nach Validierung an Produktion übermitteln

Sobald wir die Funktionalität eines Pakets im Staging-Projekt und -Repository validiert haben, können wir fortfahren, indem wir das Paket an das Produktionsprojekt übermitteln. Unterhalb der Paketübersichtsseite (z. B. in unserem Fall das Paket „nginx“) finden Sie die Schaltfläche „Paket übermitteln“, um diesen Prozess zu starten:

In unserem Beispiel verwenden wir das Projekt ‚internal-os:10:prod‘ für das Produktions-Repository. Zuvor haben wir das Paket „nginx“ im Staging-Repository erstellt und validiert. Nun möchten wir dieses Paket in das Produktionsprojekt übermitteln, das wir ‚internal-os:10:prod‘ nennen.

Sobald Sie auf „Paket übermitteln“ klicken, sollte das folgende Dialogfeld erscheinen. Hier können Sie das Formular ausfüllen, um das neu erstellte Paket an die Produktion zu übermitteln:

Füllen Sie dieses Formular aus und klicken Sie auf „Erstellen“, sobald Sie bereit sind, das neue Paket an das Produktionsprojekt zu übermitteln.

Anfragen finden

Neben der Übermittlung eines Pakets muss ein sogenannter Repository-Master die neu erstellten Anfragen für das vorgesehene Projekt genehmigen. Dieser Master findet eine Liste aller Anfragen im Reiter Anfragen, wo er/sie die Anfragen-Überprüfung durchführen kann.

Der Master findet „Anfragen“ auf der Projektübersichtsseite wie folgt:

Hier sehen Sie ein Beispiel eines Pakets, das vom Staging an das Produktionsprojekt übermittelt wurde.

Der Master muss auf den mit einem roten Kreis markierten Link klicken, um die Anfragen-Überprüfung durchzuführen:

Dies öffnet die Oberfläche für die Anfragen-Überprüfung, in der der Repository-Master des Produktionsprojekts die Paketanfrage ablehnen oder annehmen kann:

Im Produktionsprojekt reproduzieren

Sobald das Paket in das Produktionsprojekt aufgenommen wurde, wird es automatisch alle erforderlichen Abhängigkeiten von DoD herunterladen und den Build-Prozess reproduzieren.

Das folgende Beispiel zeigt das erfolgreich erstellte Paket im Produktions-Repository, nachdem der Build-Prozess abgeschlossen wurde:

In YUM-bereitem Repository für Produktion veröffentlichen

Schließlich wird das Paket auch im YUM-fähigen Prod-Repository veröffentlicht, sobald das Paket erfolgreich erstellt wurde. Hier sehen Sie ein Beispiel für das YUM-fähige Prod-Repository, das OBS verwaltet.

(Hinweis: Sie können den Projekt- und Repository-Namen in Ihren Einstellungen festlegen):

Extras

In diesem Kapitel möchten wir uns einige mögliche zusätzliche Anpassungen für OBS in Ihren Build-Infrastrukturen ansehen.

Automatisierte Build-Pipelines

OBS unterstützt automatisierte Builds, die sich nahtlos in Delivery-Pipelines integrieren lassen. Teams können CI-Trigger einrichten, um neue Pakete in OBS zu übertragen und automatisch Builds basierend auf vordefinierten Kriterien zu initiieren. Dies reduziert den manuellen Aufwand und gewährleistet die zeitnahe Bereitstellung aktualisierter Pakete.

Pakete erhalten automatisierte Builds, wenn sie in ein OBS-Projekt übertragen werden, wodurch Administratoren automatisierte Builds einfach über Pipelines integrieren können:

OBS-Worker

Wenn Sie an der Integration einer privaten Build-Infrastruktur interessiert sind oder erweiterte Unterstützung für eine EOL-Linux-Distribution benötigen, kontaktieren Sie uns bitte. Unser Team verfügt über das Fachwissen, um Sie bei der Integration einer privaten OBS-Instanz in Ihre bestehende Infrastruktur zu unterstützen.

Dieser Artikel wurde ursprünglich von Andrew Lee verfasst.