control-plane

El repositorio control-plane guarda la maquinaria que convierte un merge request aprobado en un cambio en la nube. Contiene la compuerta de aprobación que juzga los merge requests, el ejecutor que ejecuta sus planes y compilaciones, los componentes de pipeline que incluye cada repositorio, el paquete de políticas que revisa cada cambio, y las raíces de Terraform que configuran el propio GitLab a partir del catálogo. Cuando un pipeline de Airframe hace algo, el código que lo hace casi siempre vive aquí.

Para qué sirve

Un equipo de producto no debería tener que escribir su propio pipeline de despliegue, y no debería poder escribir uno que se salte las verificaciones de la plataforma. control-plane provee las piezas de pipeline una vez, para todos, junto con los dos servicios de confianza que hacen lo que un pipeline sin confianza no debe hacer: la compuerta de aprobación y el ejecutor. También guarda la configuración de GitLab, grupos, repositorios, protecciones y membresías, en código derivado del catálogo.

Qué contiene

gate/: la compuerta de aprobación, un servicio pequeño en TypeScript sobre Cloud Run. Verifica el token firmado de cada pipeline, evalúa el modelo de responsables, da o retiene su aprobación, inicia el ejecutor, y define la verificación de estado de costo. La página de la compuerta de aprobación y el ejecutor la explica.
executor/: los scripts que el runner de confianza ejecuta para un merge request aprobado: planes, precios, compilación de imágenes con el constructor de confianza, vistas previas y su limpieza.
templates/: los componentes de pipeline que incluye un repositorio, como validate, tf-apply (plan, policy y apply en main, y el plan diario de deriva), image-build, promote-artifact y drift-report.
policy/airframe/: el paquete de políticas, las reglas en Rego y sus pruebas. Consulta políticas como código.
roots/: las raíces que configuran GitLab a partir del catálogo (gitlab, gitlab-config y una gitlab-config-<journey>-<domain> por dominio), y las raíces del runner de confianza, del runner sin confianza, del ejecutor y del constructor de confianza.
releases/: los manifiestos y la lista de versiones de la plataforma permitidas.
cli/: el comando airframe: airframe validate, airframe pin y airframe release.
images/: las imágenes base de la plataforma, desde las que debe partir todo Dockerfile de producto, y las imágenes en las que se ejecutan sus propios trabajos.
security-policies/: un espejo exacto de las políticas de seguridad de GitLab, guardado para un arranque futuro: la raíz gitlab las escribió desde aquí una vez, y un trabajo, policy:schema, falla cuando el espejo y la rama main del repositorio security-policies difieren.

Cómo se conecta

Cada repositorio incluye sus componentes. El archivo de pipeline de un producto solo puede incluir estos componentes, fijados al commit de una versión, así que los planes y los apply de cada producto ejecutan el mismo código probado.
Lee el catálogo. Sus raíces de GitLab crean el repositorio de cada producto, protegen su rama main, definen sus permisos de merge y sus membresías, y escriben su primer commit desde la plantilla de golden-path. Se ejecutan en tercer lugar en la cadena después de un merge en el catálogo.
Lee las salidas de landing-zone. Las raíces de dominio toman la salida Ready de cada producto para generar su primer commit, y el ejecutor toma la autoridad de un producto de la misma publicación.
Inició security-policies. La raíz gitlab escribió una vez las políticas de seguridad del grupo, en el arranque; desde entonces, un cambio en una política es un merge request en el propio security-policies.
Se publica con otros cuatro repositorios. golden-path, los módulos, security-policies y platform-skills fijan un commit de control-plane, y una versión los nombra a todos.

Quién lo cambia, y cómo

Los cambios son merge requests aprobados por el equipo de plataforma, con la aprobación de la compuerta obligatoria. En un merge request, el pipeline ejecuta las pruebas de lo que cambió: las pruebas y los casos del paquete de políticas, las del ejecutor, las de los componentes, las del comando airframe, y las verificaciones de versión cuando cambia una versión. En main, cada raíz planifica, pasa el paquete de políticas y aplica con su propia identidad; el servicio de la compuerta lo despliega su propia raíz de la misma forma.

Una raíz es la excepción: roots/gitlab, que guarda las configuraciones de GitLab fijadas en el arranque. Se aplica desde una laptop con el token de un día de la cuenta de administrador de GitLab, y cada ejecución queda registrada. Todo otro cambio en GitLab pasa por el pipeline.

Dónde está

En el repositorio control-plane: