Bosh-Package-Manager

Warum möchten wir eine Paketverwaltung für Bosh?

Jeder, der mit einem Unix basierenden Betriebssystem oder einem modernen Build-Management-Tool gearbeitet hat, kennt Paketverwaltungssoftware. Laut Ian Murdock, Gründer des Debian Projekts, ist Paketverwaltung die größte Errungenschaft die Linux auf der Industrie brachte. Sie erleichtert das modulare Entwickeln von Software erheblich.

Bosh nutzt bereits Pakete als Container für Software, die ein Release Engineer installieren möchte. Jedoch werden derzeit solche Software Pakete per kopieren und einfügen zwischen Releases geteilt. Das bedeutet, dass wenn eine neue Java Version in allen Releases installiert werden soll, muss es in jedem einzelnen manuell aktualisiert werden. Dies ist eine sehr repetitive Aufgabe, die schlimmer wird, wenn die Pakete abhängig von anderen sind, da in diesem Fall diese ebenfalls kopiert werden müssen. Solche Themen können durch Implementation einer Paketverwaltungssoftware behandelt werden und bringen Release Engineering einen Schritt näher an Kommandozeilen-Befehle wie ‘apt-get update’, die Linux Anwender zu schätzen lernten.

Wie entwickeln wir eine Paketverwaltung für Bosh?

Wie bereits erwähnt, nutzt Bosh eine Paketstruktur mit Abhängigkeiten, weshalb eine solide Basis zum Entwickeln existiert. Jedes dieser Pakete ist durch eine spec Datei beschrieben und enthält Informationen wie Namen, Datenliste sowie deren Speicherort und einer Liste von Paketen, von denen es selbst abhängig ist. Diese spec Dateien werden in schemafreien Yaml geschrieben, weshalb es möglich ist, sie mit weiteren Feldern zu erweitern, ohne Komplikationen zu verursachen. Diese Felder sind Name des Herausgebers des Pakets, eine Semver-konforme Versionsnummer, eine Beschreibung, eine URL für weitere Informationen zur gepackten Software und ein Feld für Daten zur Stemcell, auf der das Paket ausgeführt werden soll.  Zur expliziten Identifizierung eines Paketes sind Name Version und Name des Herausgebers erforderlich, weshalb die Abhängigkeitsliste um die Version und den Herausgebernamen der referenzierten Pakete erweitert wird. Diese Daten werden mit zusätzlichen Informationen zur Zugriffskontrolle und zur Erreichbarkeit in einem Elastic Search-Cluster gespeichert. Auf diese Weise können die Daten einfach durchsucht werden.

Die Software selbst, wird als strukturierte Zip-Datei in einem Amazon S3-Bucket gespeichert und kann über den Dateinamen aufgerufen werden. Diese Struktur enthält die spec Datei selbst, das Packaging Script und die Software entweder als Quellcode oder als Binärdatei. Dieser Name ist eine eindeutige Kennung, die zusammen mit den anderen Informationen zum Paket im Elastic Search-Cluster gespeichert wird. Der S3-Bucket wird von Amazon IAM gesichert und kann nur mit einem temporären Sicherheitstoken aufgerufen werden.

Die Authentifizierung von Benutzern ist eine heikle und zeitaufwendige Angelegenheit, weshalb Keycloak verwendet wird, um dies zu handhaben. Der Service ermöglicht das Handout eines öffentlichen Clients, mit dem JSON-Web-Tokens erstellt werden können, um dem Benutzer Zugriff auf bestimmte Pakete zu gewähren oder eigene Pakete hochzuladen. Benutzer registrieren sich in der Keycloak-Instanz.

Wie benutzen wir den Bosh-Package-Manager?

Um mit dem Bosh-Paketmanager zu interagieren, installieren Benutzer das Bosh-Paketmanager-CLI-Tool neben dem Bosh-CLI-Tool auf ihrem Computer. Die CLI-Befehle von Package Manager wurden nach den gleichen Entwurfsprinzipien wie die Bosh-CLI erstellt, sodass sie sich gut in den Workflow von Bosh integrieren lassen. Die Basisoperationen, die ein Operator des Paketmanagers verwenden kann, werden nun folgen. Der Paketmanager lädt das Paket mit all seinen Abhängigkeiten und Unterabhängigkeiten herunter und platziert deren Inhalt wie Skripte, Binärdateien und Quellcode an der richtigen Stelle im Bosh-Release.

Nachdem alles eingerichtet ist, kann er nun versuchen, dieses Kafka-Paket mit dem Befehl bpm upload kafka aus dem Stammordner des Releases hochzuladen. Das Backend gibt die Freigabe zum hochladen, wenn kein anderes Paket mit diesem Namen und dieser Version im Namen des Herausgebers hochgeladen wurde. Alle Abhängigkeiten werden genauso behandelt wie das Root-Paket.
Das Backend signiert das Paket mit der Benutzer-ID des Autors, um sicherzustellen, dass die Herkunft nachvollziehbar ist.

Source code des Backends finden Sie hier,  das CLI-Tool hier und Informationen über BOSH hier.