Der letzte Artikel dieser Serie beschäftigte sich mit der Übersicht über die Software-Projekte Foreman und Katello. Wer die Anleitung aufmerksam befolgt hat, befand sich am Ende an einem Login-Screen einer frischen Foreman-Installation.

In diesem Teil wird die frische Installation mit Leben gefüllt: es werden Software-Inhalte hinzugefügt, um später damit Systeme aufzusetzen und zu verwalten.

Wer schon mal mit Spacewalk gearbeitet hat (welches das Upstream-Projekt für die vorherige Red Hat Satellite-Hauptversion war) dürfte von den neuen Begriffen, die in Katello verwendet werden, verwirrt sein:

• Repository
• GPG-Key
• Product
• Content View
• Composite Content View
• Lifecycle Path

Repository

Gehen wir mal der Reihe nach vor, der erste Punkt der oberen Liste dürfte noch relativ selbsterklärend sein - das Repository. Ein Repository steht meist für einen YUM-Spiegel, also sowas wie:

1http://mirror.centos.org/centos/7/updates/x86_64/

In diesem Beispiel sind unter der Adresse sämtliche CentOS 7-Updates für die x86_64-Architektur zu finden. Interessant ist jedoch, dass Katello nicht nur YUM-Repositories, sondern auch Docker-, Puppet- und sogar herkömmliche Datei-Repositories erlaubt. Das bedeutet, man kann auch Docker- und Puppet-Module verteilen - doch dazu später in einem weiteren Artikel mehr. Debian-Pakete werden derzeit übrigens offiziell nicht unterstützt, eine entsprechende Unterstützung ist jedoch gefragt und auch schon in Arbeit (maßgeblich durch die ATIX AG). Es ist also durchaus realistisch, dass Katello in Zukunft auch Debian- und Ubuntu-Systeme betanken kann.

GPG-Key

Wer schon mal ein YUM-Repository eingebunden hat, weiß, dass diese meistens signiert sind. Vor der ersten Verwendung muss ein Schlüssel installiert bzw. bestätigt werden:

1# yum install foobar
2...
3Importing GPG key 0x0608B895:
4 Userid: "EPEL (6) <epel@fedoraproject.org>"
5 From : http://download.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-6
6Is this ok [y/N]:

Innerhalb Katello werden pro Repository entsprechende GPG-Schlüssel hinterlegt, damit die Pakete nach dem Importieren verifiziert werden können. Darüber hinaus können über Foreman installierte Systeme direkt die benötigten Schlüssel importieren, sodass der automatischen Paket-Installation nichts mehr im Wege steht.

GPG-Schlüssel werden in der Web-Oberfläche unterhalb Content > GPG Keys verwaltet und können für mehrere Repositories, etc. verwendet werden.

Product

Ein Product umfasst im Wesentlichen die folgenden drei Elemente:

• Repository
• GPG-Schlüssel
• Synchronisationsregel

Es macht Sinn, zusammenhängende Software-Inhalte in einem Product zusammenzufassen - beispielsweise das Betriebssystem und alle zugehörigen Repositories (Updates, Extras, Quellcodes,...). Mithilfe der Synchronisationsregel kann festgelegt werden, wie häufig die Inhalte heruntergeladen werden sollen. Neben einer Uhrzeit kann festgelegt werden, ob die Synchronisation wöchentlich, täglich oder stündlich stattfinden soll.

Beim Erstellen eines Products können nach Angabe eines YUM-Spiegelservers verfügbare Repositories automatisch erkannt werden - diese Funktion nennt sich Repo Discovery.

In der Web-Oberfläche können Produkte unterhalb Content > Products verwaltet werden.

Ein Beispiel für eine gültige Product-Definition:

• Product: CentOS 7 x86_64
• GPG-Schlüssel: http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7
• Repositories:
  • OS: http://mirror.centos.org/centos/7/os/x86_64/
  • Updates: http://mirror.centos.org/centos/7/updates/x86_64/
• Synchronisation: täglich, 03:00 Uhr

Content View

Ein Content View (CV) bezeichnet einen Snapshot, der sich aus den folgenden Bestandteilen zusammensetzen kann:

• YUM-Repositories und -Filter
• Puppet-Module
• Docker- und OStree-Inhalte

YUM-Filter dienen dazu, Pakete anhand der folgenden Kriterien einzubeziehen oder auszuschließen:

• Namen
• Mitgliedschaft in Paketgruppen
• Errata-ID, -Datum oder -Typ

Vor allem die letzten Filter können von großem Interesse sein - beispielsweise, wenn Systeme nur quartalsweise aktualisiert werden dürfen. So könnte man die Aktualisierungen auf ein konkretes Datum "einfrieren" und nur bis dahin hinzugekommene Patches installieren. Ein weiteres Beispiel wäre es, auf einer Produktionsmaschine Entwicklungsprogramme per Definition auszuschließen.

Content Views werden in Versionen gesichert - eine Version stellt also die Summe aller zu dem Zeitpunkt der Erstellung verfügbaren Inhalte dar. Im Umkehrschluss bedeutet das jedoch auch, dass Content Views aktualisiert werden müssen, sofern neu hinzugekommene Pakete integriert werden sollen. Das ist ein großer Unterschied zu Spacewalk, bei welchem importierte Pakete sofort zur Verfügung standen. Diese Veränderung mag jetzt umständlich klingen, ergibt aber im übernächsten Abschnitt durchaus Sinn - ich verspreche es! 🙂

Wenn CVs automatisch aktualisiert werden sollen (z. B. jede Nacht für Entwicklungssysteme), kann das Aktualisieren mithilfe der hammer CLI oder katello-cvmanager bewerkstelligt werden.

Beim Veröffentlichen von Versionen können zusätzliche Kommentare das Nachvollziehen von Änderungen erleichtern - was vor allem in größeren Umgebunden sinnvoll ist. Wundert sich Kollege A, warum auf einmal bedeutend mehr Pakete in einem CV zur Verfügung stehen, ist ein Hinweis "Product XYZ hinzugefügt" von Kollege B oftmals hilfreich.

Sobald eine CV-Version gespeichert wurde, kann diese an ein Lifecycle Environment präsentiert werden - dazu gleich mehr.

Composite Content View

Ein Composite Content View (CCV) stellt einen Zusammenschluss mehrerer Content Views dar. Das ist vor allem bei größeren Setups eine Option, um die Übersichtlichkeit zu erhöhen und Verwaltungsaufwand zu reduzieren. So kann man beispielsweise je nach Funktion des Hosts entsprechende CCVs erstellen, die für Betriebsystem und Applikation alle benötigten Repositories enthalten. Wenn Betriebssystem und Applikation in unterschiedlichen Zyklen aktualisiert werden (z. B. Applikation wird häufiger/schneller als das Betriebssystem aktualisiert), kann das Pflegen von CCVs hilfreich sein. Ein anderer Use-Case könnte sein, dass Betriebssystem- und Applikationsbetreuung von verschiedenen Teams vorgenommen werden.

Die folgenden Grafiken zeigen die Unterschiede zwischen herkömmlichen CVs und CCVs in einer Umgebung mit den folgenden Produkten:

• Betriebsystem: CentOS 7
• Applikationen: App1, App2, App3

Betriebssystem und Applikation werden unabhängig voneinander aktualisiert. Manche Systeme hosten eine der Applikationen, manche nicht.

Bei der herkömmlichen Bereitstellung mit CVs stellt sich schnell heraus, dass hier administrativer Mehraufwand entsteht. Pro Applikation müssten dedizierte CVs erstellt werden, die jeweils wieder das Betriebssystem-Produkt enthalten. Da Betriebssystem und Applikation unabhängig voneinander aktualisiert werden, müssen häufiger Aktualisierungen versioniert werden. Wird das Betriebsystem aktualisiert, muss bedacht werden, dass alle anderen Applikations-CVs (App1, App2, App3) auch aktualisiert werden, da diese auch das Betriebssystem-Produkt enthalten.

Durch den Einsatz von CCVs kann der Aufwand reduziert werden. Hier werden pro Betriebssystem und Applikation entsprechende CVs gepflegt. Die können vollkommen unabhängig voneinander aktualisiert werden - auch von unterschiedlichen Teams. Die Zuordnung von Betriebsystem und Applikation wird in einem CCV erfasst - hier können spezifische Versionen der CVs referenziert werden. So ist es beispielsweise möglich, eine neuere Version der Applikation mit einer älteren Version des Betriebsystem-CVs zu kombinieren. Wird einer der referenzierten CVs aktualisiert, ist der Aufwand den CCV zu aktualisieren bedeutend geringer gegenüber einer vollständigen Neuerstellung eines kombinierten CVs (siehe oben).

Lifecycle Environments und Path

Ein großer Vorteil gegenüber Spacewalk ist meiner Meinung nach die Implementation von Lifecycle Paths und Environments. Systeme lassen sich je nach Verwendungszweck in verschiedenen Umgebungen zusammenfassen - besonders gängig ist die folgende Drei-Systemlandschaft, die sich hervorragend in Lifecycle Environments abbilden lässt:

• Entwicklung (Dev)
• Qualitätssicherung (QA)
• Produktion (Prod)

Wenn wir uns nun wieder auf das obige Beispiel der Aktualisierung von Content Views bei neu hinzugekommen Patches besinnen, ergibt sich hier ein neuer Verwendungszweck aus der Praxis. Neue Patches sollen möglicherweise nicht direkt allen Systemen zur Verfügung stehen - es wäre wesentlich sinnvoller diese zuerst auf Entwicklungs- und QA-Systemen zu testen, bevor diese auf produktiven Servern installiert werden; andernfalls wären nicht erwartete Seiteneffekte eine fatale Folge.

Ein Lifecycle Path schreibt vor in welcher Reihenfolge CV-Aktualisierungen veröffentlicht ("promoted") werden - um das obige Beispiel erneut aufzugreifen:

1. Dev
2. QA
3. Prod

Über die Web-Oberfläche muss diese Reihenfolge eingehalten werden; bei der Verwendung des Kommandozeilen-Tools hammer lässt sich dies jedoch umgehen.

Es ist durchaus möglich mehrere Lifecycle Environments und Paths zu definieren - beispielsweise wenn man mehrere Applikationen mit verschiedenen Staging-Umgebungen betreibt.

Beispiel: CentOS 7

Zeit, die Theorie in die Praxis umzusetzen. In diesem Beispiel sollen die benötigten Vorbereitungen getroffen werden, um CentOS 7-Installationen mit einer Anwendung zu betanken, die PostgreSQL 9.6 benötigt. Da CentOS 7 jedoch lediglich Version 9.2 der Datenbank ausliefert, wird ein Drittanbieter-Repository notwendig. Dieser Prozess soll den vollständigen Lifecycle Paths Dev, QA und Prod durchleben. Zusammengefasst werden also benötigt:

• Lifecycle Paths Dev, QA und Prod
• Synchronisationsregel
• CentOS 7-Product inklusive GPG-Key, Repositories und CV
• PostgreSQL 9.6-Product inklusive GPG-Key, Repository und CV
• Anwendungs-CCV beider definierter Products
• Versionieren der CVs und CCVs

Der erste Schritt ist die Erstellung der Lifecycle Paths - hierzu wird das Menü Content > Lifecycle Environments angewählt. Mit einem Klick auf Add New Environment wird ein Dialog gestartet, der wie folgt ausgefüllt wird:

• Name: Name der Umgebung
• Label: dazugehöriger interner Name
• Description: Kurzbeschreibung

Für Dev, QA und Prod werden entsprechende so nacheinander Lifecycle Environments erstellt.

Der nächste Schritt ist die Anlage der GPG-Keys, dies erfolgt über das Menü Content > GPG Keys. Mit einem Klick auf Create GPG Key wird ein Dialog gestartet:

• Name: Name des GPG-Keys, idealerweise Dateiname
• GPG Key Contents: Inhalt des GPG-Keys

Alternativ lässt sich ein GPG-Key auch als Datei hochladen.

Für dieses Beispiel werden die folgenden beiden GPG-Keys benötigt:

• http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7
• https://download.postgresql.org/pub/repos/yum/RPM-GPG-KEY-PGDG-96

Damit Foreman bzw. Katello weiß, wann Pakete herunterzuladen ist, werden eine oder mehrere Synchronisationsregeln benötigt. Um den dazugehörigen Assistent zu starten sind Klicks auf Content > Sync Plans > Create Sync Plan nötig. Anzugeben ist:

• Name: Name der Regel
• Description: Kurzbeschreibung
• Interval: stündlich (hourly), täglich (daily) oder wöchentlich (weekly)
• Start Date: Datum, ab welchem die Regel gültig ist
• Start Time: Uhrzeit der Ausführung

Anschließend werden die Products erstellt - um Repositories nicht manuell erstellen zu müssen bedienen wir uns der Repo Discovery-Funktionalität. Klicks auf Content > Products > New Product starten einen weiteren Assistenten. Wichtig ist diesmal:

• Name: Name des Products
• Label: dazugehöriger interner Name
• GPG Key: eben angelegter GPG-Key
• Sync Plan: eben angelegte Synchronisationsregel
• Description: Kurzbeschreibung

Im nächsten Schritt können dem Product Repositories hinzugefügt werden - mit einem Klick auf New Repository könnte man manuell diese manuell anlegen. Klickt man hingegen auf Content > Product > Repo Discovery wird ein Assistent gestartet, in welchem man rekursiv einen Spiegelserver durchsuchen kann. Das ist vor allem dann sinnvoll, wenn sich mehrere YUM-Repositories auf einem Server befinden und man nur einige davon benötigt - beispielsweise bei den CentOS-Repositories. Der Dialog ist wie folgt auszufüllen:

• Repository Type: Yum Repositories
• URL to Discover: Einstiegspunkt der Suche, in diesem Fall http://mirror.centos.org/centos-7/7/

Mit einem Klick auf Discover wird die Suche gestartet, anschließend lassen sich die erkannten Repositories anwählen und mit einem Klick auf Create Selected dem eben erstellten Product zuordnen. Hierbei ist es noch notwendig, die Option Existing Product und das vorhandene Product auszuwählen:

Nun kann ein erster CV auf Basis des Products erstellt werden: Content > Content Views > Create New View; anzugeben ist:

• Name: CentOS
• Label: automatisch generiert
• Description: CentOS product
• Composite View: Nein

Nach einem Klick auf Save werden automatisch alle verfügbaren Repositories aufgelistet. Die CentOS-Repositories und Add Repositories werden angeklickt. Abschließend wird mit Publish New Version eine neue Version des CVs erstellt - nach Angabe einer optionalen Kurzbeschreibung erfolgt ein Klick auf Save.

Neben CentOS wird noch ein Product für PostgreSQL benötigt - es folgen also wieder Klicks auf Content > Product > Create Product. Diesmal wird das dazugehörige Repository manuell erstellt. Nach einem Klick auf New Repository wird der Assistent mit den folgenden Informationen befüllt:

• Name: PostgreSQL 9.6
• Label:  
• Type: yum
• URL: https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-7-x86_64/
• Download Policy: On Demand
• Mirror on Sync: Ja

Foreman bietet drei verschiedene Download Policies an:

• Immediate: Metadaten und Pakete werden sofort heruntergeladen
• On Demand: Metadaten werden sofort heruntergeladen; Pakete erst dann, wenn ein Client diese anfordert (Standard)
• Background: Metadaten werden sofort heruntergeladen; Pakete werden anschließend im Hintergrund heruntergeladen

Die Angabe des GPG-Keys ist an dieser Stelle optional, da dieser schon auf Product-Ebene definiert wurde.

Die Option Mirror on Sync ist vor allem bei Repositories, die sehr häufig Programmversionen aktualisieren und alte Versionen restlos entfernen von großem Interesse. Sie bewirkt, dass entfernte veraltete Pakete auch lokal aus dem Bestand entfernt werden.

Für PostgreSQL wird ebenfalls ein CV benötigt - die oben genannten Schritte müssen nun also für dieses Product wiederholt werden.

Zuletzt wird noch ein CCV erstellt, der beide CVs enthält - Content > Content View > Create New View:

• Name: CentOS + PGSQL 9.6
• Label: automatisch generiert
• Description: CentOS and PostgreSQL 9.6
• Composite View: Ja

Nach der Erstellung des CCVs wird dieser in der Liste ausgewählt. Ein Klick auf Content Views > Add listet alle verfügbaren CVs auf, die hinzugefügt werden. In diesem Fall werden beide verfügbaren CVs ausgewählt. Ein Klick auf Publish New Version startet erneut den Assistenten zum Veröffentlichen einer neuen Version.

Tschakka! Nun muss die soeben generierte Version nur noch den einzelnen Lifecycle Environments zugewiesen werden. Ein Klick auf Promote zeigt einen Dialog, in welchem die entsprechende Umgebung ausgewählt wird. Dies wird für jede Stufe der System-Umgebungen wiederholt. 🙂

Der nächste Teil dieser Artikel-Serie wird sich mit dem Erstellen und Verwalten des ersten Hosts beschäftigen.