Systemverwaltung mit Foreman/Katello – Teil 2: Produkte, Repositories und Content Views
){kind=small}
Christian Stankowic
YUM-Filter erstellen
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!
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.
){kind=small}
Christian Stankowic
Dedizierte CVs pro OS bzw. Applikation
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.
){kind=small}
Christian Stankowic
Dedizierte CVs pro OS bzw. Applikation
- 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).
