Gérer RHEL à l'échelle — Satellite, content views et le lifecycle que nous livrons réellement

subscription-manager marche bien pour une poignée d'hôtes RHEL. À 300, vous avez besoin de Satellite — non pas parce que c'est obligatoire, mais parce que l'alternative est un patchwork de cron jobs, de post-its, et une panne du mardi après-midi quand la moitié de la flotte pull la même update cassée au même moment.

Voici la disposition Satellite que nous déployons pour les clients qui font tourner RHEL à l'échelle.

Les lifecycle environments

Library  →  Dev  →  Staging  →  Production
                                    ↑
                                    Promouvoir ici sur cadence de 2 semaines

# Créer un content view lié à un snapshot de repo spécifique
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"
 
# Promouvoir à travers le lifecycle
hammer content-view version promote --content-view "RHEL10-Server" \
  --version "1.0" --to-lifecycle-environment "Staging"

Un content view est un snapshot gelé de repos. Promouvez à travers le lifecycle et chaque hôte dans cet environnement pull depuis exactement le même set de packages. Pas de surprises.

L'article complet couvre :

• Composition de content view — base RHEL + EPEL + vos repos internes
• Activation keys par environnement + par classe d'hôte
• Hammer CLI vs l'UI Satellite — ce que nous automatisons et ce que nous ne faisons pas
• Plans de sync pour les repos Red Hat upstream (quand pull, quoi pin)
• Patching dirigé par les errata — appliquer uniquement les errata de sécurité, différer les autres
• La sync Satellite air-gapped pour les clients qui ne peuvent pas atteindre Red Hat directement

Nous déployons cette disposition pour chaque flotte RHEL managée au-delà de 50 hôtes.