Problema

En entornos de laboratorio o pruebas de concepto, los equipos de DevOps suelen necesitar clústeres OpenShift completos en AWS para validar configuraciones, probar operadores o entrenar al personal. La instalación UPI (User‑Provisioned Infrastructure) es la única forma que deja visible todo el stack de red, VPC, balanceadores y DNS, lo que resulta ideal para aprender y depurar. Sin embargo, crear manualmente cada recurso (subnets, NAT, security groups, Elastic IPs, etc.) y luego ejecutar el instalador de OpenShift es una tarea lenta, propensa a errores y difícil de reproducir.

El patrón que se repite en muchos laboratorios es:

  1. Provisionar infraestructura con Terraform o CloudFormation.
  2. Ejecutar el instalador de OpenShift, esperando a que el bootstrap complete.
  3. Ajustar recursos (por ejemplo, reemplazar nodos caídos) de forma manual.
  4. Destruir todo al final del día, a menudo dejando recursos huérfanos que siguen generando costos.

Cuando la rutina se repite varias veces al mes, el tiempo invertido supera el valor del propio laboratorio y aparecen facturas inesperadas. La falta de una solución integral que abarque despliegue, verificación, costo y teardown es la raíz del problema.

Causa

  1. Fragmentación de herramientas – Terraform crea la red, Ansible ejecuta el instalador, scripts ad‑hoc manejan la eliminación. Cada capa tiene su propio estado y variables, lo que genera desalineación.
  2. Ausencia de ciclo de vida completo – La mayoría de los proyectos open‑source cubren solo la fase de install; el teardown no elimina recursos creados por el propio OpenShift (por ejemplo, ELB del Ingress Operator) porque están fuera del control de Terraform.
  3. Gestión de costos limitada – Sin una vista en tiempo real del gasto, es fácil sobrepasar el presupuesto, sobre todo cuando se usan Spot Instances sin monitorizar su precio.
  4. Versionado inconsistente – El instalador, el cliente oc y la AMI de RHCOS deben coincidir. Un desajuste provoca fallos en la fase de bootstrap que son difíciles de diagnosticar.
  5. Falta de automatización de tareas post‑install – Aprobar CSRs, validar ClusterOperators o reparar nodos reclamados son pasos que suelen hacerse a mano y que interrumpen el flujo.

Solución

Construir una capa de orquestación ligera que tome como entrada un único archivo declarativo (cluster.yaml) y genere automáticamente:

  • Variables de Terraform y Ansible.
  • install-config.yaml con la versión exacta del instalador.
  • Scripts de teardown que respeten el orden de dependencia (ELB → SG → DNS → VPC).

El flujo recomendado es:

  1. Definir el clúster en cluster.yaml. Campos típicos: versión de OpenShift, número de workers, tipo de instancia (Spot o On‑Demand), zona de disponibilidad y flag de “budget safety net”.
  2. Ejecutar el comando de orquestación (ocplab deploy). Internamente:
    • terraform apply crea la VPC, subnets, NAT y security groups.
    • Ansible genera install-config.yaml y lanza el instalador.
    • Un watcher aprueba automáticamente los CSRs del bootstrap y de los workers.
  3. Validar con ocplab verify, que comprueba ClusterVersion, estado de nodos y operadores críticos.
  4. Monitorear costos con ocplab cost. El comando consulta la API de AWS, aplica precios Spot cuando corresponde y muestra el gasto acumulado.
  5. Reparar nodos perdidos con ocplab repair, que recrea la instancia y vuelve a aprobar su CSR.
  6. Apagar temporalmente con ocplab power off para evitar cargos mientras el clúster está inactivo.
  7. Destruir con ocplab destroy, que ejecuta Terraform destroy y luego elimina recursos externos creados por OpenShift en el orden correcto.

Alternativas prácticas

  • Uso directo de Terraform + Ansible – Si prefieres no introducir una capa extra, puedes crear módulos Terraform que incluyan null_resource para lanzar el instalador y usar local-exec para aprobar CSRs. El reto sigue siendo la coordinación del teardown.
  • Utilizar ROSA o IPI – Cuando la visibilidad total de la infraestructura no es crítica, ROSA simplifica la gestión pero oculta la capa de red, lo que no sirve para laboratorios de aprendizaje profundo.
  • Integrar con GitOps – Almacenar cluster.yaml en un repo y usar Argo CD para disparar el despliegue permite versionar el laboratorio como cualquier otro entorno.

Cuándo aplicar esta solución

Se recomienda cuando:

  • Necesitas crear y destruir clústers OpenShift de forma frecuente (diaria o semanal) en AWS.
  • El objetivo es aprendizaje o PoC, no producción.
  • Quieres control de costos y evitar facturas inesperadas.
  • Necesitas visibilidad total de la infraestructura (VPC, LB, DNS) para depurar problemas de red o de instalación.

No es adecuada si:

  • Requieres alta disponibilidad multi‑AZ, múltiples NAT gateways o arquitectura de producción.
  • Tu organización impone políticas que prohíben la ejecución de scripts que manipulen recursos fuera de Terraform.
  • El presupuesto es tan bajo que incluso los Spot Instances resultan prohibitivos.

Código

# 1. Clonar el repositorio y entrar al directorio
git clone https://github.com/LuixyToledo97/openshift-upi-aws.git
cd openshift-upi-aws

# 2. Editar cluster.yaml (ejemplo mínimo)
cat > cluster.yaml <<EOF
name: lab-cluster
region: us-east-1
availability_zone: a
openshift_version: "4.22"
worker_count: 2
worker_instance_type: t3.medium
use_spot_instances: true
budget_limit_usd: 20
EOF

# 3. Desplegar
./ocplab deploy

# 4. Verificar estado
./ocplab verify

# 5. Consultar costo en tiempo real
./ocplab cost

# 6. Apagar cuando no se use
./ocplab power off

# 7. Destruir al terminar
./ocplab destroy

Verificación

  1. Estado de Terraform – terraform state list debe mostrar recursos de VPC, subnets, NAT y security groups sin errores.
  2. CSRs aprobados – Ejecuta oc get csr y verifica que todos los certificados del bootstrap y workers tengan Approved=True.
  3. ClusterVersion – oc get clusterversion debe indicar Available=True y la versión deseada.
  4. Operadores – oc get co debe devolver AVAILABLE en todos los operadores críticos (authentication, ingress, monitoring, etc.).
  5. Costo – ocplab cost debe reflejar un gasto acorde a la configuración (por ejemplo, < $1/h para una configuración mínima con Spot).

Si alguno de los pasos falla, revisa los logs generados en logs/ (Terraform, Ansible, instalador) y corrige la configuración de cluster.yaml antes de volver a ejecutar ocplab deploy.

Notas adicionales

  • Version pinning – Mantén un archivo versions.yaml que asocie la versión de OpenShift con la AMI de RHCOS y la versión del cliente oc. Actualizarlo en bloque evita incompatibilidades.
  • Budget safety net – El script crea una AWS Budget con umbral bajo y una Lambda que detiene instancias cuando se supera. Asegúrate de que la cuenta tenga permisos para crear budgets y Lambda.
  • Spot reclamación – Los masters no pueden usar Spot porque UPI no soporta ControlPlaneMachineSet. Si el master se interrumpe, el teardown fallará a menos que lo recrees manualmente.
  • Web UI opcional – ocplab web start lanza una interfaz local en 127.0.0.1:8080. Es útil para observar el progreso sin abrir múltiples terminales, pero no es necesaria para la automatización CI/CD.
  • Persistencia de estado – Guarda el directorio .terraform en un bucket S3 remoto si planeas ejecutar despliegues desde diferentes máquinas; de lo contrario, perderás el estado y el teardown no funcionará correctamente.