Stacks e ISOs

Un stack es una aplicación desplegada: una o varias VMs en Proxmox creadas a partir de una plantilla. Es la sección principal de Horizon.

Crear un stack

1. Elegir una plantilla activa.
2. Configurarla trabajo a trabajo: el formulario dibuja las fases de la plantilla y cada trabajo tiene sus propios parámetros. Una plantilla con un máster pequeño y workers grandes se rellena exactamente así.
3. Adjuntar a cada VM lo que necesita: una dirección con nombre (reservada en la red), una llave SSH, el servidor Proxmox, su resource pool y, según la plantilla, una ISO. Si solo hay una opción posible, ya viene elegida.
4. Decidir la monitorización de cada VM: Nagios (con su host group) y Node Exporter. La sección de Nagios solo aparece si hay un servidor Nagios registrado.
5. Los trabajos marcados como múltiples ejecuciones (por ejemplo los workers de Kubernetes) empiezan con una y se añaden tantas como se quiera, cada una con su configuración.

El stack se guarda primero como borrador: se puede preparar, dejarlo y desplegarlo más tarde, o editarlo y tirarlo sin tocar ninguna infraestructura.

Desplegar

Al desplegar, Horizon construye las VMs en el orden de la plantilla: los trabajos de una fase en paralelo, y las fases una tras otra. Las máquinas de un mismo servidor Proxmox se construyen de una en una, ya que la subida por SSH del cloud-init no soporta dos a la vez.

Un stack fija la plantilla (y el commit de cada trabajo) con la que se creó, así que cambios posteriores en la plantilla no afectan a lo que ya está desplegado.

Si la plantilla declara checks de Nagios, el último paso de un despliegue correcto es publicar sus máquinas en Nagios. Un despliegue que falla no publica nada, y uno que pide un comando que Nagios no tiene se rechaza antes de empezar.

Seguimiento

• La lista y el detalle se actualizan en tiempo real.
• Cada stack guarda el historial de estados (quién, cuándo y el error si lo hubo) y el log completo del despliegue, que se puede pausar, filtrar por trabajo o ejecución, y descargar.
• El pipeline se dibuja tal como se ejecutó: una columna por fase, una tarjeta por ejecución de cada trabajo, con su estado. Un trabajo held no se llegó a ejecutar porque falló una fase anterior. Una tarjeta fallida muestra la primera línea de su error.
• Las salidas de cada trabajo (una IP, una contraseña generada, un comando de join, ...) se muestran agrupadas por trabajo. Las marcadas como secretas quedan ocultas tras un botón, y se pueden copiar sin mostrarlas.

El día a día

Editar

Edit permite cambiar nombre, descripción, etiquetas, parámetros y el número de ejecuciones:

• Cambiar un parámetro vuelve a aplicar la plantilla fijada con los nuevos valores (el botón dice Save and re-apply). Solo se re-aplican los trabajos afectados: subir la memoria de un worker re-aplica ese worker, no el clúster entero. Los trabajos que dependen de él se ejecutan otra vez.
• Añadir una ejecución construye su máquina y ejecuta sus scripts. Quitarla ejecuta primero sus scripts de limpieza y después destruye la VM. Antes de guardar, Horizon lista exactamente qué se creará y qué se destruirá, y pide confirmación.
• Sustituir una máquina es quitar una ejecución y añadir otra en el mismo guardado. Si la plantilla lo indica (replace by adding first), la nueva se construye antes de quitar la anterior, de forma que un clúster nunca se queda sin control plane.
• Las etiquetas de un stack de Proxmox también se escriben en las VMs.

El entorno no se puede cambiar una vez desplegado, y no se acepta ninguna edición mientras haya una ejecución en curso.

Acciones

Una plantilla puede ofrecer acciones sobre un stack desplegado: un pequeño Terraform (por ejemplo, crear un usuario de base de datos) o un script en una de sus máquinas (por ejemplo, renovar certificados). Los valores que necesitan llegan rellenados a partir de las salidas del stack y se pueden modificar. Las acciones de Terraform quedan como instancias que se pueden deshacer una a una; las de script quedan en el historial.

Run again

Cada tarjeta del pipeline ofrece Run again, que ejecuta de nuevo ese trabajo con las mismas respuestas. Es la forma de refrescar una salida que ha cambiado fuera de Horizon, como el kubeconfig de un clúster tras renovar sus certificados.

Reintentar

Un stack fallido ofrece Retry failed jobs, que solo ejecuta lo roto: lo que falló, lo que no llegó a ejecutarse y lo pendiente. Lo que terminó bien no se toca. En el mismo menú:

• Force retry failed jobs: vuelve a descargar el código de la rama antes de reintentar (la salida para un stack fijado en un commit roto).
• Retry everything: re-aplica todo el stack.

Editar un stack fallido también es la forma de corregir lo que lo rompió: la ejecución que aplica el cambio termina además lo pendiente.

Actualizar la plantilla

Cuando la plantilla ha cambiado desde que se fijó, un administrador puede pulsar Upgrade template. El stack pasa a usar la nueva definición en su siguiente ejecución. Si la nueva versión elimina trabajos, primero se destruyen con la versión que los creó.

Cancelar

Un paso bloqueado (por ejemplo, una máquina que nunca responde) dejaría el stack ocupado indefinidamente. Cancel run interrumpe Terraform y deja el stack como fallido. No es un rollback: lo creado se queda, y se recupera reintentando o eliminando.

Duplicar

Duplicate abre un borrador nuevo con la misma plantilla, entorno, etiquetas y respuestas, dejando vacío lo que no se puede compartir (direcciones y valores propios de cada máquina).

Eliminar

Remove quita primero las máquinas de Nagios, destruye lo creado por las acciones y después la infraestructura, libera sus direcciones y borra sus logs y estado. La actividad se mantiene.

Si el Terraform del stack está roto (un bug, un proveedor que ya no existe, máquinas borradas a mano), el borrado normal fallará siempre. Para eso, un administrador puede usar force-remove en un stack fallido: lo desvincula de Horizon sin destruir nada. La confirmación lista cada VM (con su id y nodo de Proxmox) y cada dirección que se libera, porque tras ello habrá que borrarlas a mano en Proxmox.

Startup

La sección Startup lista todas las VMs de todos los stacks de Proxmox en el orden en que arrancan cuando un host se reinicia, con su stack, entorno, trabajo, host y estado. El número de arranque se define en cada máquina al configurar el stack; las que no tienen arrancan al final.

ISOs

Muchas plantillas necesitan una imagen de instalación en Proxmox antes de crear una VM. La sección ISOs las construye a partir de una plantilla ISO, con el mismo tratamiento que los stacks: historial, log en directo, reintento y edición.

Una ISO construida está disponible para las VMs de su servidor y de cualquier otro nodo del mismo clúster. No se puede borrar mientras un stack la use.