Open Source im professionellen Einsatz
Linux-Magazin 05/2012
© Aaron Amat, 123RF

© Aaron Amat, 123RF

Automatisches Softwaredeployment mit Pulp

Filmreif austeilen

"Ich bin Mr. Wolf. Ich löse Probleme." Ob Zitate wie dieses hilfsbereite von Harvey Keitel aus Tarantinos "Pulp Fiction" die Macher der im Folgenden vorgestellten Softwareverteilung inspiriert haben, lässt sich nicht sicher sagen. Was das Red-Hat-Community-Projekt Pulp ausmacht aber schon.

632

Yum [1] mildert die Leiden von Administratoren, die RPM-basierte Systeme pflegen, erheblich. Mit Hilfe von Yum-Repositories installiert der Admin das Zielpaket wie bei Debian oder Gentoo und das Paketmanagement löst alle Abhängigkeiten eigenständig auf. Auch Updates und das Installieren aus mehreren Quellen unterstützt Yum.

Aber was macht der Admin, wenn er nicht ein paar, sondern 10, 50 oder 1000 Rechner verwaltet, die möglichst gleich oder in Gruppen gleicher Systeme installiert sein sollen? Dazu kommt vielleicht noch eine Mischung aus Centos, Fedora und Red Hat Enterprise Linux. Entweder steht viel Handarbeit an oder es entsteht eine bunte Skriptsammlung.

Einen Ausweg schafft das Pulp-Projekt [2], eine Softwareverteilung für Red Hat Enterprise Linux 5 und 6, Fedora 15 und 16 sowie Centos. Das Prinzip der Software (seit Februar 2012 mit der Versionsnummer 1.0) ist es, dass der Administrator die RPM-Sammlungen lokal vor- und aktuell hält und dass sich angeschlossene Clients daraus bedienen.

In das System eingebundene Clients verwenden es einfach als Yum-Repository, ihnen stehen dann alle Pakete aus den Quellen, für die sie sich beim Server registriert haben, zur Verfügung. Der Clou des Systemes ist aber, dass der Server Pakete auch an die Clients verteilen kann und für bereits installierte Pakete Updates einspielt. Somit lässt sich der Softwarestand auf allen angeschlossenen Systemen zentral administrieren.

Pulp eröffnet Möglichkeiten, Systeme zu Gruppen zusammenzufassen, um zum Beispiel alle Systeme der Buchhaltung mit einem Kommando mit dem Update der Buchhaltungssoftware auszustatten; auf dem Webserver, der in einer anderen Gruppe gelistet ist, landet die Buchhaltungssoftware damit nicht. Zudem besitzt das System die für Software-Inventarisierungen typischen Abfragemöglichkeiten, zum Beispiel welche Systeme welche Pakete verwenden.

Dreiteilige Architektur

Pulp ist in Python programmiert und enthält drei logische Komponenten:

  • Den Yum-Server, der die Pakete und die Verwaltungsinformationen vorhält und die Installationen steuert.
  • Den Yum-Client beziehungsweise Consumer, er bezieht seine RPM-Pakete vom Yum-Server oder bekommt sie von ihm zugeteilt.
  • Optional gibt es noch den Yum Content Delivery Server (CDS), der in verteilten Installationen die Last und den Netzwerktraffic entzerrt. Dazu hält er eine lokale Kopie der RPMs vor, damit diese gegebenenfalls nicht über eine langsame WAN-Leitung auf dem Client landen.

Seine Verwaltungsinformationen speichert das System in einer Mongo DB [3]. Die Kommunikation der Komponenten erfolgt zum einen über HTTPS, zum anderen über einen eigenen Messagebus auf Basis von Apache Qpid [4]. Es ist vorgesehen, diese Kommunikation mit SSL abzusichern, wobei sich der Server beim Client und auch der Client beim Server authentisiert. Abbildung 1 zeigt die Zusammenhänge.

Abbildung 1: Logische Struktur einer Pulp-Architektur. (Quelle: Pulp-Projekt)

Paketquellen zuweisen

Repositories, also Paketquellen von zum Beispiel einer Version der Fedora-Distribution, sind für Pulp zentral. Dass Pulp auch für den eigentlichen Installationsprozess Yum verwendet, macht die Zuordnung einfach: Jedes Repository entspricht einem Yum-Repository, das der Pulp-Server aus einer externen Quelle füllt (und aktuell hält) und aus dem sich die Clients oder Consumer bedienen oder betankt werden.

Der Administrator weist dem Pulp-Consumer ein oder mehrere Repositories zu (Datei »pulp.repo« ). Für den Consumer sind sie alle per Yum erreichbar. Verbleiben die Originaleinträge aus der Installation in »/etc/yum.repos.d« oder stehen sie auf »enabled« , so führt auch eine zentrale Installation dazu, dass sich der Client – auf dem ja »yum install« periodisch läuft – gegebenenfalls das Paket über die Repository-Quelle aus dem Internet lädt.

Repositories automatisch zu synchronisieren beherrscht Pulp von sich aus. Der Administrator gibt einfach ein Schedule vor, das definiert, wie oft der Server sich mit der externen Quelle abgleicht. Dabei kann er Bandbreitenlimits vorgeben oder DVDs sowie andere Dateiquellen als Repository-Gegenüber bestimmen. Der Administrator darf zudem mehrere Repositories als Gruppe deklarieren, zum Beispiel alle Versionen von Fedora. Ebenso kann er Gruppen von Consumern bilden und dort mit nur einem Kommando ein Patch auf allen Gruppenmitgliedern ausrollen.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 4 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

comments powered by Disqus

Ausgabe 10/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.