Gestionar RHEL a escala — Satellite, content views y el ciclo de vida que de verdad entregamos

subscription-manager funciona bien para un puñado de hosts RHEL. A 300, necesitas Satellite — no porque sea obligatorio, sino porque la alternativa es un parcheo de cron jobs, post-its, y una caída de martes por la tarde cuando la mitad de la flota tira de la misma actualización rota al mismo tiempo.

Esta es la disposición de Satellite que desplegamos para clientes que ejecutan RHEL a escala.

Los lifecycle environments

Library  →  Dev  →  Staging  →  Production
                                    ↑
                                    Promocionar aquí con cadencia de 2 semanas

# Crear un content view ligado a un snapshot de repo específico
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"
 
# Promocionar a través del lifecycle
hammer content-view version promote --content-view "RHEL10-Server" \
  --version "1.0" --to-lifecycle-environment "Staging"

Un content view es un snapshot congelado de repos. Promociona a través del lifecycle y cada host en ese entorno tira de exactamente el mismo set de paquetes. Sin sorpresas.

El artículo completo cubre:

• Composición de content view — RHEL base + EPEL + tus repos internos
• Activation keys por entorno + por clase de host
• Hammer CLI vs la UI de Satellite — qué automatizamos y qué no
• Sync plans para repos Red Hat upstream (cuándo tirar, qué pinear)
• Parcheo dirigido por errata — aplicar solo erratas de seguridad, diferir las demás
• La sync de Satellite air-gapped para clientes que no pueden alcanzar Red Hat directamente

Desplegamos esta disposición en cada flota RHEL gestionada de más de 50 hosts.