Workshops::Systemverwaltung mit Foreman/Katello

Systemverwaltung mit Foreman/Katello – Teil 2: Produkte, Repositories und Content Views

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:

Dev
QA
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

Christian Stankowic

CVs pro Applikation, CCVs je Use-Case

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:

Christian Stankowic

GPG-Key importieren

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