Reconciliadores

Un reconciliador es un trabajo automático que lee el catálogo y hace que una parte del mundo real coincida con él: los proyectos en la nube, los grupos de Google, los repositorios de GitLab o los paneles. Después de cada merge en el catálogo, una cadena de reconciliadores se ejecuta en un orden fijo, y entre todos construyen o cambian todo lo que el catálogo describe. Así es como un archivo se convierte en un producto que funciona sin que nadie cree nada a mano.

Qué es un reconciliador

Cada reconciliador es una raíz de Terraform: un directorio de código Terraform que lee los archivos del catálogo y declara lo que debe existir. Terraform lo compara con lo que existe de verdad y hace la diferencia: crea lo que falta, cambia lo que difiere y quita lo que el catálogo ya no pide.

Cada raíz tiene su propia identidad de pipeline, y esa identidad solo puede cambiar su propia parte de la plataforma. La fábrica de proyectos del dominio shop/store puede crear proyectos en las carpetas de ese dominio, y nada más. La raíz que administra las membresías de GitLab no puede tocar un proyecto en la nube. Si una de ellas quedara comprometida, el daño se quedaría dentro de su propia parte.

El pipeline del propio catálogo no tiene ninguna de estas identidades. En la rama main del catálogo, revisa los archivos e inicia los pipelines de los otros repositorios, en orden; no puede crear un proyecto por sí mismo.

La cadena después de un merge en el catálogo

Cuando se integra un merge request en el catálogo, el pipeline del catálogo en main ejecuta estos pasos, y cada uno espera al anterior:

El ciclo de vida se ejecuta. Si el merge cambió el estado del ciclo de vida de un producto, por ejemplo a retiring, el propio pipeline del producto aplica primero ese cambio, con las identidades propias del producto. Los servicios de un producto tienen que salir antes de que algo más adelante elimine lo que usan.
landing-zone. Sus raíces crean la carpeta de un contexto nuevo, los grupos de Google y sus miembros, y, mediante la fábrica de proyectos del dominio del producto, los dos proyectos del producto, sus identidades de plan y de apply, sus lugares para el estado de Terraform y su salida Ready: un documento pequeño que le dice a cada raíz posterior qué se creó. Después, las raíces de red conectan los proyectos que tienen facturación.
operations. Sus raíces dan a las identidades nuevas lo que necesitan para enviar telemetría, y crean la carpeta, los paneles y las reglas de alerta del producto en Grafana.
control-plane. Sus raíces de GitLab crean el repositorio del producto, protegen su rama main, dan al equipo sus membresías y permisos de merge, y escriben el primer commit, generado desde la plantilla del golden path con los valores de la entrada del catálogo.
landing-zone otra vez. Una segunda pasada termina lo que necesitaba a los demás primero. Para un producto que se va, desvincula la facturación o elimina los proyectos, después de que control-plane y operations retiraron lo que habían otorgado a las identidades del producto.

Una nota en el merge request del catálogo ya integrado sigue estos pasos mientras avanzan, con sus horarios y enlaces. Para un producto nuevo, termina cuando el producto responde en su nombre de host, o nombra el paso que falló.

Por qué importa el orden

Cada paso usa lo que creó el paso anterior. Operations no puede otorgar nada a una identidad que todavía no existe, así que se ejecuta después de que landing-zone creó las identidades. Control-plane escribe el primer commit del repositorio a partir de la salida Ready, así que se ejecuta después de que la fábrica de proyectos la publicó. Y un producto que deja la plataforma primero tiene que dejar de funcionar, después perder sus permisos, y solo entonces perder sus proyectos: por eso el ciclo de vida va primero y la segunda pasada de landing-zone va al final.

La cadena es estricta con las fallas por la misma razón: cada paso espera a que su pipeline termine, y si uno falla, los pasos siguientes no se ejecutan. Nada más adelante actúa sobre algo que no se creó.

Qué significa “nada derivado se edita a mano”

Todo lo que crea un reconciliador queda registrado en su estado de Terraform, y el reconciliador es la única forma en que cambia. Las identidades de un proyecto, las protecciones de un repositorio, las membresías de un equipo y un panel se cambian cambiando el catálogo, nunca en la consola de Google Cloud ni en la configuración de GitLab.

Es una regla con dientes. Si alguien cambia a mano algo derivado, el siguiente plan de esa raíz ve la diferencia y la desharía, y un plan programado de cada raíz lo informa como deriva en un issue. La forma de cambiarlo de verdad es un merge request en el catálogo.

Cuando un reconciliador falla

Una falla detiene la cadena en ese paso, y la nota de progreso en el merge request del catálogo nombra el trabajo que falló y qué hacer después. Las causas habituales son un error en el catálogo que sus verificaciones no detectaron, una cuota de Google Cloud, o un bug en una raíz.

La corrección es un merge request: en el catálogo, si la entrada estaba mal, o en el repositorio de la raíz, si la raíz estaba mal. El merge vuelve a ejecutar la cadena, y como cada raíz solo hace la diferencia entre el catálogo y lo que existe, volver a ejecutarla es seguro: lo que ya se creó queda como está. La programación diaria de cada repositorio planifica sus raíces sin aplicarlas, así que nada cambia hasta que alguien integra una corrección.

Dónde está

En el repositorio catalog:

.gitlab-ci.yml: la cadena, en orden

En el repositorio landing-zone:

En el repositorio operations:

roots/grafana/: paneles y reglas de alerta

En el repositorio control-plane:

roots/gitlab-config-shop-store/: los repositorios de un dominio