Große Debian Repositories mit Pulp verwalten
Pulp ist eine kostenlose Open-Source-Plattform für die Verwaltung von Software Repositories. Man kann damit Inhalte von verschiedenen Quellen abrufen, hochladen und verteilen. Die Versionierung des Repository stellt sicher, dass nichts verloren geht, da man jederzeit zu früheren Versionen zurückkehren kann. Mit dem pulp_deb-Plug-in gibt es APT Repository Support.
Pulp Debian Support gibt es schon seit einiger Zeit; die ATIX hat sie vor ein paar Jahren für die Verwendung mit Katello erweitert. Das funktioniert hervorragend für kleine bis mittelgroße Repositories, allerdings ist die Leistung nicht ideal.
Die Herausforderung
Im Jahr 2019 wollten unsere Consultants für eine Demo Debian Stretch und Ubuntu Xenial synchronisieren. Leider mussten sie feststellen, dass dies in der Regel etwa fünf Stunden dauert, nur um dann mit dem Fehler „Cannot allocate memory“ abzubrechen. Was war da los?
Kostenloses E-Book
Infrastructure Automation mit Linux und Open Source Tools
Das kostenlose E-Book zeigt praxisnah, wie Sie mit Linux und Open-Source-Tools wiederkehrende Aufgaben vereinfachen, Fehler reduzieren und skalierbare IT-Prozesse aufbauen.
Jetzt entdecken.
Um diese Frage zu beantworten, mussten sie einen genaueren Blick auf die pulp_deb-Implementierung werfen. Der Code ist in mehrere Schritte unterteilt. Die Implementierung stützt sich stark auf die python-debpkgr-Abhängigkeit, die wiederum auf deb822 aus der python-debian-Bibliothek zurückgreift. python-debpkgr ist hauptsächlich dazu gedacht, Debian-Pakete in einem APT Repository zu organisieren. Die Struktur von Debian Repositories sieht wie folgt aus:
/dists/ stretch / Release
/dists/ stretch /main/binary -amd64/ Packages
/dists/ stretch / contrib /binary -amd64/ Packages
/dists/ stretch /non -free/binary -amd64/ Packages
/pool/
Während einer Synchronisation gibt es den „MetadataStep“, der eine Liste von Releases, Komponenten und Paketen (mit Metadaten) aus der MongoDB erhält. Er führt eine gewisse Logik aus: Für jede Kombination von Architektur, Komponente und Release wird eine Liste von Paketen erstellt. Diese Listen enthalten die Pfade zu den tatsächlichen .deb-Paketdateien auf der Festplatte. Schließlich wird jede Liste als Argument an einen debpkgr Call übergeben.
debpkgr ist in erster Linie dazu gedacht, Debian-Pakete in ein Paketarchiv zu verwandeln. Also macht es genau das: Auf jede .deb-Datei wird auf der Festplatte zugegriffen, um die Metadaten zu extrahieren, die debpkgr benötigt. Aufgrund der Art und Weise, wie sich die Paketlisten für verschiedene Architekturen überschneiden, werden viele dieser .deb-Dateien tatsächlich mehrfach geparst.
Die Lösung
Der erste Gedanke unserer Experts war: Eventuell gibt es eine schnelle und einfache Lösung? Sie zogen allerdings auch kompliziertere Ansätze in Betracht, wie die vollständige Umgestaltung der Art und Weise, wie debpkgr arbeitet. Alternativ überlegten sie auch, debpkgr (aus dem MetadataStep) fallen zu lassen und alles selbst zu implementieren.
Die Grundidee bestand darin, ausschließlich Informationen aus der MongoDB zu verwenden, um die Repository-Struktur zu erstellen. Die alte Implementierung musste bereits die Metadaten aus der MongoDB parsen, um die Listen zu erzeugen, die dann an debpkgr übergeben wurden. Das blieb im Wesentlichen unverändert. Unsere Experts mussten die gewünschte Verzeichnisstruktur selbst erstellen. Auch die Symlinks zu den eigentlichen .deb-Dateien mussten sie selbst anlegen. Dann brauchten sie die Möglichkeit, Pakete und Release-Dateien zu schreiben. Wie das immer ist, stießen sie auf ein paar Stolpersteine …
debpkgr erzeugt md5sum, sha1 und sha256 für Metadaten. Das bestehende Datenbankmodell speicherte nur sha256-Hashes. Die tatsächliche Verwendung der Metadaten aus der Datenbank offenbarte einen Fehler. Userdefinierte Metadatenfelder wurden im bestehenden Datenbankmodell nicht gespeichert.
Am Ende kamen unsere Consultants zu folgenden Ergebnissen:
-
Zwei große Pull Requests:
- Ein Ende unserer Speicherprobleme
-
Doppelt so schnelle Synchronisationen für mittelgroße Repositories (1500 Pakete)
-
Eine Dauer von ca. 3,5 Stunden für die Synchronisierung von Ubuntu Xenial (main, restricted, universe, multiverse) für amd64 (53837 Pakete) auf dem Testsystem
Was alle daraus gelernt haben? Es ist wichtig, die eigenen Werkzeuge zu kennen. Zudem muss man sich genug Zeit nehmen, um die Architektur zu planen und sich das erforderliche Fachwissen anzueignen.
Das könnte Sie auch interessieren:
Der ATIX-Crew besteht aus Leuten, die in unterschiedlichen Bereichen tätig sind: Consulting, Development/Engineering, Support, Vertrieb und Marketing.
