RHEL im großen Stil managen — Satellite, Content Views und der Lifecycle, den wir tatsächlich ausliefern

subscription-manager funktioniert gut für eine Handvoll RHEL-Hosts. Bei 300 brauchen Sie Satellite — nicht weil es Pflicht ist, sondern weil die Alternative ein Flickenteppich aus Cron-Jobs, Klebezetteln und einem Dienstagnachmittags-Ausfall ist, wenn die halbe Flotte gleichzeitig dasselbe kaputte Update zieht.

Dies ist das Satellite-Layout, das wir für Kunden ausrollen, die RHEL im großen Stil fahren.

Die Lifecycle Environments

Library  →  Dev  →  Staging  →  Production
                                    ↑
                                    Hier promoten im 2-Wochen-Takt

# Einen Content View erstellen, der an einen bestimmten Repo-Snapshot gebunden ist
hammer content-view create --name "RHEL10-Server" --organization "Customer"
hammer content-view add-repository --name "RHEL10-Server" \
  --repository "Red Hat Enterprise Linux 10 Server"
hammer content-view publish --name "RHEL10-Server" --description "Weekly 2026-05-14"
 
# Über den Lifecycle promoten
hammer content-view version promote --content-view "RHEL10-Server" \
  --version "1.0" --to-lifecycle-environment "Staging"

Ein Content View ist ein eingefrorener Snapshot von Repos. Promoten Sie über den Lifecycle, und jeder Host in dieser Umgebung zieht aus exakt demselben Paket-Set. Keine Überraschungen.

Der vollständige Beitrag behandelt:

• Content-View-Komposition — Basis-RHEL + EPEL + Ihre internen Repos
• Activation Keys pro Umgebung + pro Host-Klasse
• Hammer-CLI vs Satellite-UI — was wir automatisieren und was nicht
• Sync-Pläne für Upstream-Red-Hat-Repos (wann ziehen, was pinnen)
• Errata-getriebenes Patching — nur Security-Errata anwenden, die anderen aufschieben
• Der Air-gapped-Satellite-Sync für Kunden, die Red Hat nicht direkt erreichen

Wir deployen dieses Layout für jede gemanagte RHEL-Flotte über 50 Hosts.