Red Hat Satellite¶

Siehe auch

Verwandte Artikel

Offizielle Dokumentation

Linuxfabrik

Red Hat Satellite ist eine zentrale Plattform für Content-, Subscription- und Lifecycle-Management einer Server-Flotte. Im Fokus stehen Red-Hat-Enterprise-Linux-Hosts, doch über deb-Repositories lassen sich auch Debian- und Ubuntu-Hosts mit Content versorgen. Das Subscription- und Entitlement-Management bleibt dagegen Red-Hat-spezifisch. Satellite spiegelt Pakete und Errata aus dem Red Hat Content Delivery Network (CDN) sowie aus Drittquellen, kuratiert sie und liefert sie kontrolliert und versioniert an die verwalteten Hosts aus.

Im Kern besteht Satellite aus den Open-Source-Projekten Foreman (Provisionierung und Lifecycle-Management der Hosts), Katello (Foreman-Plug-in, das Pulp und Candlepin in Foreman integriert und die Satellite-Abstraktionen wie Content Views, Lifecycle Environments und Activation Keys beisteuert), Pulp (Repository- und Content-Spiegelung, siehe Pulp) und Candlepin (Subscription- und Entitlement-Engine: Manifest, Subscriptions, Entitlement-Zertifikate, Gegenstelle für subscription-manager auf den Hosts).

Begriffe

Satellite Server: zentrale Instanz; trägt die Management-Funktion und einen integrierten Capsule Server
Capsule Server: spiegelt ausgewählte Inhalte des Satellite Servers und liefert sie näher beim Host aus, optional samt DHCP, DNS, TFTP und weiteren Diensten
Content Host: ein bei Satellite registrierter, verwalteter Linux-Host (Client-Seite, siehe unten)
SCA (Simple Content Access): Subscription-Modus, in dem Hosts Content beziehen, ohne eine Subscription zu belegen

Links

Homepage: https://www.redhat.com/en/technologies/management/satellite
Doku: https://docs.redhat.com/en/documentation/red_hat_satellite
Source Code: https://github.com/theforeman (Foreman), https://github.com/Katello (Katello)
Wikipedia: (en) https://en.wikipedia.org/wiki/Foreman_(software)

Server-Seite und Client-Seite¶

Zum Satellite-Ökosystem auf der Server-Seite gehören der Satellite Server und die Capsule Server (beide oben unter Begriffe). Die Management-Funktion liegt allein beim Satellite Server. Da im Satellite Server ein Capsule Server integriert ist, können Hosts auch ohne separaten Capsule direkt am Satellite Server registriert und verwaltet werden. Ein eigenständiger Capsule Server wird zuerst als Content Host des Satellite Servers registriert und anschliessend zum Capsule befördert, kann also beide Rollen tragen.

Ein Content Host ist dagegen ein Client: ein verwaltetes Zielsystem, das per subscription-manager oder Global Registration angebunden wird und Pakete und Errata bezieht. Es registriert sich gegen den Satellite Server oder einen Capsule Server.

Die Begriffe Host und Content Host meinen dieselbe Maschine aus zwei Blickwinkeln: Host ist die Foreman-Sicht (Provisionierung, Konfiguration, Inventar), Content Host die Katello-Sicht (Subscriptions, Repositories, Content). In aktuellen Satellite-Versionen sind beide zu einem einzigen Host-Objekt mit einem Content-Tab zusammengeführt.

Objektmodell¶

Die folgende Übersicht zeigt, wie die zentralen Satellite-Objekte zusammenhängen, von der Subscription bis zum registrierten Host.

ORGANIZATION  (oberste Isolationsgrenze fuer Content und Subscriptions)
  |
  |  LOCATION  (geografische Achse, orthogonal zur Organization)
  |
  v
SUBSCRIPTION MANIFEST  (eines pro Organization, aus dem Customer Portal)
  |  liefert
  v
SUBSCRIPTIONS  ->  enthalten ENTITLEMENTS  ->  schalten Red-Hat-Repos frei
  |
  v
PRODUCT  (gruppiert verwandte Repositories)
  |
  +-- REPOSITORY  (RPMs, Container, Files; mit Download-Policy und GPG-Key)
  |        ^                         |
  |        | assigned to            | Sync zieht Inhalte nach
  |   SYNC PLAN                      v
  |   (automatischer Sync)      LIBRARY  (Anfang jedes Environment Path,
  |                              laufend mit den Quellen synchron)
  |                                  |  Repos werden referenziert von
  v                                  v
CONTENT VIEW  (kuratierte Repo-Auswahl + Filter)
  |  publish  =>  CONTENT VIEW VERSION (1, 2, 3, ... fortlaufend)
  |  promote  =>  sequenziell entlang des Pfads
  v
ENVIRONMENT PATH:  Library -> Dev -> Test -> Prod
  |                (jede Umgebung haelt eine promotete Content-View-Version)
  v
ACTIVATION KEY  (buendelt Lifecycle Environment, Content View,
  |              Subscriptions, Products/Repos, Host-Collection)
  |  weist bei der Registrierung zu
  v
HOST (Content Host)  ->  genau 1 Lifecycle Environment + 1 Content View,
  |                      zugeordnet zu Organization und Location
  v
HOST COLLECTION  (logische Gruppe fuer Sammel-Aktionen;
                  ein Host kann in mehreren Collections sein)

Auslieferung an die Hosts laeuft ueber den CAPSULE SERVER.

Organisationen und Standorte¶

Eine Organization ist die oberste Isolationsgrenze. Content-bezogene Objekte wie Products, Repositories und Content Views existieren immer im Kontext genau einer Organization. Organisationen bilden logische Gruppen nach Eigentum, Zweck, Sicherheitsstufe oder Abteilung. Eine frische Installation enthält die Default Organization.

Eine Location ist die dazu orthogonale, geografische Achse und lässt sich verschachteln (etwa Land, darunter Stadt). Jede Aktion in der Web-UI oder per hammer läuft im Kontext einer Organization und einer Location. Die mitgelieferte Default Location dient als Platzhalter für nicht zugeordnete Hosts und sollte nicht gelöscht werden; mindestens eine Location muss in der Umgebung immer existieren. Capsule Server lassen sich wahlweise je Organization oder je Location zuordnen.

Wie sich die wichtigsten Satellite-Objekte verteilen:

Objekt	Organization	Location
Activation Key	x
Content View (mit Versionen und Filtern)	x
Host Collection	x
Lifecycle Environment	x
Product	x
Repository	x
Subscription / Entitlement	x
Subscription Manifest	x
Sync Plan	x
Capsule Server	x	x
Compute Resource	x	x
Domain	x	x
Host	x	x
Host Group	x	x
Provisioning Template	x	x
Subnet	x	x
User	x	x

Ein Host gehört zu genau einer Organization und genau einer Location. Die übrigen Objekte in der unteren Gruppe lassen sich mehreren Organisationen und Locations gleichzeitig zuweisen. Reine Location-Objekte gibt es im Datenmodell nicht: Die Location ist die topologische Achse für Provisioning und Capsule-Routing, der Content sitzt immer auf der Organization.

Subscriptions und Entitlements¶

Pro Organization wird im Red Hat Customer Portal ein Manifest erzeugt und in Satellite importiert. Das Manifest bringt die Subscriptions mit, deren Kern die Entitlements sind. Ein Entitlement ist die eigentliche Zugriffsberechtigung auf Red-Hat-Content und beantwortet drei Fragen:

Freischalten: Welche Red-Hat-Repositories darf die Organization aktivieren und spiegeln? Ohne passendes Entitlement lässt sich das zugehörige CDN-Repository nicht aktivieren. Eigene Custom-Repos brauchen kein Entitlement.
Menge und Laufzeit: Jedes Entitlement trägt eine Quantity, ein Start- und ein End-Date sowie ein Support-Level. Manifest-Renewals sind rechtzeitig vor dem End-Date einzuplanen.
Verbrauch: Im klassischen Modell belegt jeder registrierte Host beim Attachen einer Subscription ein Entitlement, womit die Lizenzmenge durchgesetzt wird.

Bemerkung

Mit Simple Content Access (SCA) entfällt der client-seitige Verbrauch. Entitlements werden dann nur noch auf Organization-Ebene verwaltet: Alle entitelten Repositories stehen automatisch allen Hosts der Organization zur Verfügung, und die Content Views übernehmen die Einschränkung, welcher Host welchen Content sieht. Subscriptions müssen dann nicht mehr an Activation Keys oder Hosts gehängt werden. Seit Satellite 6.16 ist SCA der einzige Subscription-Modus.

Products, Repositories und Sync Plans¶

Content ist der Sammelbegriff für die eigentlichen Software-Artefakte, die Satellite verwaltet und verteilt: RPM- und deb-Pakete, Errata, Container-Images, Module Streams und beliebige Dateien. Ein Repository ist dagegen der benannte Behälter, der solchen Content aus einer Quelle (CDN, Upstream-URL, Upload) spiegelt und versioniert. Kurz: Content ist das Was, das Repository das Wo.

Ein Product gruppiert verwandte Repositories (verschiedene Versionen, Architekturen und ergänzende Repos). Beim Aktivieren eines Red-Hat-Repositories wird das passende Product automatisch angelegt, falls es noch nicht existiert. Beispiel: Das Product Red Hat Enterprise Linux for x86_64 fasst die BaseOS- und AppStream-Repositories zusammen.

Jedes Repository hat eine Download-Policy (immediate lädt Metadaten und Pakete sofort, on_demand zunächst nur die Metadaten) und einen GPG-Key. Ein deaktiviertes Repository wird nicht aus dem Storage entfernt, da der Speicher zwischen Organisationen geteilt wird.

Ein Sync Plan automatisiert die Synchronisation und wird Products zugewiesen (nicht einzelnen Repositories). Ein Sync Plan läuft in einem Intervall oder per Cron. Reichen für alle Products dieselben Attribute, genügt ein einziger Sync Plan; eigene Pläne lohnen sich nur bei abweichenden Anforderungen, um unnötigen Netzwerkverkehr zu vermeiden.

hammer repository list --organization myorg --fields Id,Name
hammer repository synchronize --id 2

Library und Lifecycle-Umgebungen¶

Eine Lifecycle Environment bildet eine Stufe des Software-Lifecycles ab (etwa Dev, Test, Prod). Die Reihenfolge dieser Stufen ergibt einen Environment Path. Pro Organization lassen sich beliebig viele Pfade anlegen, um unterschiedliche Lifecycles abzubilden. Ein Host ist immer genau einer Lifecycle Environment zugeordnet.

Die Library ist die erste Umgebung jedes Environment Path und hat eine Sonderrolle. Sie ist kein kontrollierter Stage wie Dev oder Prod, sondern der zentrale Sammel- und Ausgangspunkt:

Auffangbecken: Alles, was die Sync Plans aus den Repositories ziehen, landet zuerst in der Library und wird dort laufend aktuell gehalten. Die Library enthält damit immer den kompletten, neuesten Stand aller aktivierten Repos.
Pflicht-Startpunkt: publish einer Content View landet immer zuerst in der Library; erst von dort wird sie in die weiteren Umgebungen promotet (Details unter Content Views).
Optionaler Bleeding-Edge-Zugang: Ein direkt der Library zugeordneter Host erhält sofort die neuesten Pakete und Errata, ohne Promote-Workflow. Das eignet sich für Validierungs-Hosts, die eingehenden Content prüfen, nicht aber für normale Dev-/Test-/Prod-Hosts, deren Zweck gerade die Versionskontrolle ist.

Kurz: Die Library ist der ungefilterte, immer aktuelle Pool, aus dem gezielt versionierte Schnappschüsse in die kontrollierten Umgebungen promotet werden.

hammer lifecycle-environment create \
    --organization myorg \
    --name Dev \
    --description "Development Environment" \
    --prior Library

hammer lifecycle-environment paths --organization myorg

Content Views¶

Eine Content View ist ein kuratiertes Content-Repository, das nur die Software bereitstellt, die eine bestimmte Host-Gruppe benötigt. Sie verweist auf eine Auswahl von Repositories und kann mit Filtern verfeinert werden (Pakete, Paketgruppen, Errata, Module Streams).

Eine Änderung an Repositories oder Filtern wird erst durch publish wirksam und erzeugt eine fortlaufend nummerierte Content View Version. Mit promote wird eine Version sequenziell entlang des Environment Path weitergereicht (Library, dann Dev, Test, Prod). Satellite hält für jede Content View in jeder Umgebung ein eigenes Repository. So nutzen Produktionshosts eine getestete, ältere Version, während Entwicklungshosts auf die neueste Version zugreifen.

Empfehlungen aus der Praxis: Wenige Content Views sind leichter zu pflegen, da die Grösse einer View die Dauer von Publish und Promote beeinflusst. Bei gefilterten Views ist sicherzustellen, dass alle Paket-Abhängigkeiten enthalten sind. Kickstart-Repositories gehören nicht in Content Views, da sie nur beim initialen Provisionieren gebraucht werden.

Activation Keys und Host Collections¶

Ein Activation Key automatisiert die Erstkonfiguration eines Hosts bei der Registrierung und bündelt dazu:

eine Lifecycle Environment und eine Content View
zugeordnete Subscriptions und deren Attach-Verhalten (ohne SCA relevant)
verfügbare Products und Repositories
die Mitgliedschaft in einer oder mehreren Host Collections

Ein Activation Key greift nur zum Registrierungszeitpunkt. Spätere Änderungen am Key wirken sich nicht auf bereits registrierte Hosts aus. Ein Host kann mit mehreren Keys registriert werden; bei Konflikten gewinnt der zuletzt angegebene Key.

hammer activation-key create \
    --name "rhel-prod" \
    --unlimited-hosts \
    --description "RHEL Produktion" \
    --lifecycle-environment "Prod" \
    --content-view "rhel-base" \
    --organization myorg

Eine Host Collection ist eine logische Gruppe registrierter Hosts mit ähnlichen Merkmalen und dient dazu, Aktionen gesammelt auf alle Mitglieder anzuwenden. Host Collections sind auf Organization-Ebene definiert. Ein Host muss registriert sein, um aufgenommen zu werden, und kann gleichzeitig zu mehreren Collections gehören.

Host Groups¶

Eine Host Group (Foreman) ist nicht mit der Host Collection zu verwechseln. Sie ist ein Provisioning-Template, das Defaults für neue Hosts bündelt: OS, Partition Table, Provisioning- und Kickstart-Templates, Puppet- und Ansible-Rollen, Compute Profile, Activation Key, Content View, Lifecycle Environment und Parameter. Host Groups sind hierarchisch schachtelbar; ein Kind erbt vom Elternteil und überschreibt gezielt einzelne Werte. Ein Host gehört zu genau einer Host Group (oder zu keiner) und ist sowohl einer Organization als auch einer Location zugeordnet.

Abgrenzung zur Host Collection: Die Host Group ist der Bauplan für neue Hosts und greift bei Provisioning oder Registrierung; die Host Collection ist die Mitgliederliste für Sammel-Aktionen auf bereits registrierte Hosts. Ein Host hat eine Host Group, kann aber gleichzeitig in mehreren Host Collections sein.