Infraestructura comprobada antes de existir

La mayoría de los fallos de infraestructura se descubren tarde. Un plan mal escrito, un servicio instalado antes que aquel del que depende, una variable de entorno que nadie recordó definir: todos superan la revisión y fallan cuando ya están en marcha. Provisioning se apoya en una decisión que adelanta esos fallos: cada pieza de infraestructura se declara en un lenguaje tipado y se valida antes de llegar a un sistema en marcha.

Una única fuente de verdad, y tipada

Provisioning describe servidores, servicios de tarea y clústeres como esquemas de Nickel. La misma declaración sirve sea cual sea el proveedor que la lleve a cabo:

{
  servers = [
    {
      name = "web-01",
      plan = "medium",       # un tamaño abstracto, traducido por cada proveedor
      provider = "upcloud",  # o "aws", o "local"
    }
  ]
}

TOML y YAML siguen existiendo (las herramientas los necesitan), pero son salida generada, nunca la fuente de verdad. Un cambio se hace en la declaración Nickel, se comprueba contra su esquema y solo entonces se traduce al formato que lea cada herramienta. Un servidor mal formado o una combinación imposible se rechazan en el esquema, no se descubren con un despliegue fallido.

El orden forma parte de la declaración

Los componentes de infraestructura dependen unos de otros: Kubernetes necesita containerd y etcd, Cilium necesita Kubernetes. En lugar de codificar ese orden en un script, un servicio de tarea declara sus dependencias y Provisioning las resuelve:

{
  taskservs = ["cilium"]  # resuelve containerd → etcd → kubernetes → cilium
}

Un workspace se compone como un grafo de dependencias tipado, con la integridad referencial comprobada en el esquema. El orquestador ejecuta después ese grafo (en paralelo donde el grafo lo permite, con puntos de control y vuelta atrás), de modo que el orden de las operaciones es una propiedad de la declaración y no de quien escribió el último script.

Configuración, nunca un valor fijado en el código

La tercera fuente de fallos tardíos es la configuración repartida entre variables de entorno y literales. Provisioning mantiene aquí una invariante: nada se fija en el código; todo es configuración, resuelta en un orden de precedencia fijo:

argumentos de ejecución  >  entorno  >  configuración de usuario  >  configuración de infraestructura  >  valores por defecto

Cada valor tiene un lugar en esa jerarquía, y cada lugar está declarado. Pasar un workspace de desarrollo a producción cambia qué capa aporta un valor, nunca el código que lo lee.

Lo que se gana

• La revisión ocurre sobre la declaración. Los esquemas, los módulos Nickel y los flujos Nushell viven en Git, así que cada cambio de infraestructura se versiona, se revisa y se revierte.
• Los proveedores siguen siendo intercambiables. Como la declaración no depende del proveedor y los proveedores implementan una interfaz común, llevar un servidor de una nube a otra es cambiar un campo, no reescribir.
• Los fallos se adelantan. Lo que antes fallaba en un nodo ahora falla en el esquema, donde es barato de corregir e imposible de publicar.

La declaración y el sistema en marcha son dos ruedas del mismo mecanismo. El trabajo de Provisioning es que giren juntas.