Gerenciar RHEL em escala — Satellite, content views e o lifecycle que de fato entregamos

subscription-manager funciona bem para um punhado de hosts RHEL. Com 300, você precisa de Satellite — não porque seja obrigatório, mas porque a alternativa é uma colcha de retalhos de cron jobs, post-its, e um outage de terça à tarde quando metade da frota puxa o mesmo update quebrado ao mesmo tempo.

Esta é a disposição do Satellite que implantamos para clientes rodando RHEL em escala.

Os lifecycle environments

Library  →  Dev  →  Staging  →  Production
                                    ↑
                                    Promover aqui numa cadência de 2 semanas

# Criar um content view atrelado a um snapshot específico de repo
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"
 
# Promover ao longo do lifecycle
hammer content-view version promote --content-view "RHEL10-Server" \
  --version "1.0" --to-lifecycle-environment "Staging"

Um content view é um snapshot congelado de repos. Promova pelo lifecycle e cada host nesse ambiente puxa exatamente o mesmo conjunto de pacotes. Sem surpresas.

O artigo completo cobre:

• Composição de content view — RHEL base + EPEL + seus repos internos
• Activation keys por ambiente + por classe de host
• Hammer CLI vs a UI do Satellite — o que automatizamos e o que não
• Sync plans para repos Red Hat upstream (quando puxar, o que pinar)
• Patching dirigido por errata — aplicar só os errata de segurança, adiar os outros
• O sync de Satellite air-gapped para clientes que não conseguem alcançar a Red Hat diretamente

Implantamos esta disposição em cada frota RHEL gerenciada acima de 50 hosts.