Ir al contenido

Glosario

Airframe usa unas pocas decenas de términos que vienen de Google Cloud, de GitLab, de Terraform o de la propia plataforma. Aquí se explica cada uno en palabras simples, en orden alfabético, con un enlace a la página que profundiza cuando existe. Si una página usa un término que no conoces, debería estar aquí.

Un asistente de inteligencia artificial que escribe y cambia código. En Airframe, un agente de código contribuye mediante merge requests con exactamente los mismos controles que una persona, y solo una persona con nombre que no escribió un cambio puede dar la aprobación que permite integrarlo. Consulta listo para un agente de código.

Una declaración firmada de que algo le ocurrió a una imagen de contenedor específica. Cuando el constructor de confianza construyó una imagen a partir de un commit aprobado, una identidad de firma aparte, que solo el ejecutor puede usar, firma una atestación de compilación después de que el ejecutor comparó la compilación con el registro propio de Cloud Build; promover la imagen hacia producción agrega una segunda. Consulta cero privilegios permanentes.

Un servicio de Google Cloud que decide, cuando se despliega un servicio, qué imágenes de contenedor pueden ejecutarse. En el proyecto de producción de un producto con facturación, su política admite solo una imagen que lleve las dos atestaciones. Un servicio tiene que adherirse; todo servicio desplegado con el módulo de Cloud Run del golden path lo hace.

La única entrada pública para el nombre de host de cada producto: un balanceador de carga de Google Cloud, administrado por la raíz de red de landing-zone, que dirige cada nombre de host a su producto y lo pone detrás del inicio de sesión único, salvo que el producto declare pública una ruta.

El repositorio git de pequeños archivos YAML que describe la organización: sus recorridos, dominios y contextos, sus equipos y personas, y sus productos. Es la única fuente de verdad: todo lo demás en la plataforma se deriva de él. Consulta el catálogo.

Un sitio web que mapea cada producto: sus servicios, los eventos que publica y consume, sus responsables, su runbook y sus decisiones. Cada repositorio publica su propia parte cuando un cambio se integra, y el mapa se reconstruye solo. Está construido con EventCatalog, en catalog.projectairframe.dev, y no es lo mismo que el catálogo, del que toma su lista de productos. Consulta el catálogo de arquitectura.

Un archivo de un repositorio de GitLab que dice qué aprobación necesita cada ruta. En Airframe, el archivo CODEOWNERS del repositorio de un producto se escribe una sola vez, cuando se crea el repositorio. Solo el archivo del propio catálogo se genera a partir del modelo de responsables del catálogo y se compara con él, después de cada merge al catálogo y cada día. En todos los casos, la compuerta de aprobación lee el modelo directamente. Consulta el catálogo.

Una pieza reutilizable de pipeline, publicada por el repositorio control-plane: por ejemplo, la que valida un cambio o la que aplica Terraform. El archivo de pipeline de un producto solo puede incluir estos componentes. Consulta políticas como código.

El servicio que juzga un merge request. Verifica que los responsables actuales del cambio, tal como los nombra el catálogo, lo aprobaron, y luego agrega su propia aprobación e inicia el ejecutor. También hace fallar cualquier pipeline que todavía use una versión de la plataforma revocada. Consulta la compuerta de aprobación y el ejecutor.

Un acceso temporal que una persona pide, con un motivo, mediante Privileged Access Manager de Google Cloud. Una concesión de roles administrativos necesita la aprobación de otro miembro de la plataforma y dura como máximo dos horas; toda concesión queda en el registro de auditoría. Consulta identidades y acceso.

El pool privado de Cloud Build de la plataforma, que construye las imágenes de contenedor de cada producto a partir de commits aprobados, para que lo que se ejecuta en producción lo haya construido la plataforma y no el pipeline propio de un producto. Consulta el camino de un cambio.

El nivel del catálogo debajo de un dominio: un grupo de productos muy relacionados y los equipos que los construyen, como ordering en el dominio store. Cada producto y cada equipo pertenece a exactamente un contexto. Consulta el catálogo.

Una diferencia entre lo que dice el código y lo que de verdad existe en la nube, en general porque algo se cambió fuera de un merge request. Un plan programado de cada raíz la detecta cada día y abre un issue para la raíz que se desvió. Consulta deriva.

El nivel del catálogo debajo de un recorrido, como store en el recorrido shop. Un dominio tiene líderes, y algunos cambios necesitan a uno de ellos, por ejemplo, subir el presupuesto de un producto. Consulta el catálogo.

Una de las dos copias de la infraestructura compartida de la plataforma: producción y no producción. Cada una tiene su propia red, su propio lugar para guardar el estado de Terraform y su propio perímetro. Un producto recibe un proyecto en cada una.

El pipeline de confianza que planifica los cambios de un producto, y construye sus vistas previas, con las identidades de corta duración del propio producto. Se ejecuta en el runner de confianza de la plataforma, y solo la compuerta de aprobación puede iniciarlo, cuando se aprueba un merge request. Consulta la compuerta de aprobación y el ejecutor.

Federación de identidades de carga de trabajo

Sección titulada «Federación de identidades de carga de trabajo»

La función de Google Cloud que permite a un trabajo de pipeline cambiar el token firmado que le da GitLab por una identidad de Google de corta duración, sin ninguna contraseña ni clave guardada. La identidad se entrega solo a un trabajo del repositorio correcto, en el entorno correcto, en una rama protegida. Consulta identidades y acceso.

La forma recomendada de construir un producto: una plantilla que genera el repositorio de un producto nuevo para Java, Node o Python, y módulos de Terraform que codifican los patrones de la plataforma. Es una opción por defecto, no un requisito. Consulta cualquier pila.

Iniciar sesión una vez con una cuenta de la organización para llegar a cada producto interno. En Airframe es Identity-Aware Proxy de Google delante del nombre de host de cada producto, que admite solo al grupo de usuarios del producto, desde el catálogo.

Un archivo que se guarda en la carpeta retired-names/ del catálogo por cada producto eliminado, para que su nombre nunca se le dé a otro producto en el mismo dominio. Consulta el catálogo.

La rama principal de un repositorio, protegida en GitLab para que los cambios solo lleguen a ella mediante un merge request aprobado. Solo un trabajo en una rama protegida puede obtener la identidad de un producto que aplica cambios.

La propuesta de GitLab para cambiar un repositorio: una rama con sus commits, las verificaciones que se ejecutan sobre ella, la discusión y las aprobaciones. En Airframe todo cambio, en un producto o en la propia plataforma, es un merge request. Consulta el camino de un cambio.

El archivo del catálogo ownership/protected-paths.yaml, que dice qué aprobación necesita cada tipo de cambio, en el repositorio de un producto y en el propio catálogo. La compuerta de aprobación lo lee directamente en cada merge request, desde la rama main protegida del catálogo. Consulta el catálogo.

Una pieza reutilizable de código Terraform del repositorio golden-path, como un servicio de Cloud Run o una base de datos, que un producto puede usar en lugar de declarar cada recurso de la nube por su cuenta.

Poder ver qué hace un producto en marcha, a través de sus registros, sus métricas y sus trazas. En Airframe viajan a un único stack de Grafana Cloud, donde cada producto recibe paneles y reglas de alerta desde su entrada en el catálogo. Consulta observabilidad.

El conjunto de reglas probadas, escritas para Open Policy Agent, que revisa cada cambio al código Terraform de un producto, a su archivo de pipeline y a sus Dockerfiles declarados. Una regla rechaza un cambio, lo que lo detiene, o advierte sobre él, lo que hoy no detiene nada. Consulta políticas como código.

Un límite de VPC Service Controls alrededor de un grupo de proyectos, pensado para impedir que los datos salgan de ellos por las API de Google. Los perímetros de Airframe funcionan hoy en modo de prueba: registran lo que bloquearían, y no bloquean nada.

El conjunto de trabajos automáticos que GitLab ejecuta para un commit, como las verificaciones de un merge request o el plan y el apply en la rama main. Un trabajo (job) es un paso de un pipeline.

Los dos pasos de Terraform. Un plan calcula qué haría un cambio en la infraestructura real sin hacerlo; un apply lo hace. En Airframe, los planes se ejecutan cuando se aprueba un merge request, y los apply solo después del merge, en la rama main protegida. Consulta la compuerta de aprobación y el ejecutor.

Una pieza de software que un equipo tiene a su cargo y opera, como el servicio de pedidos de la organización de demostración. Se declara con un archivo en el catálogo, y recibe sus propios proyectos, repositorio, paneles y nombre de host. Consulta el catálogo.

Un directorio de código Terraform con su propio estado y sus propias identidades de pipeline, que se planifica y se aplica como una unidad. Un producto tiene una raíz por entorno, como infra/prod e infra/np. Consulta reconciliadores.

Un trabajo automático de pipeline que lee el catálogo y hace que algo real coincida con él: GitLab, proyectos de Google Cloud, grupos o paneles. Nada de lo que crea un reconciliador se edita a mano. Consulta reconciliadores.

El nivel más alto del catálogo: un área amplia del negocio de la organización. La organización de demostración tiene tres, shop, fulfil y settle, y cada una contiene dominios. Consulta el catálogo.

Las dos máquinas que ejecutan los trabajos de pipeline de la plataforma. El runner sin confianza ejecuta las verificaciones de cada merge request y no tiene ninguna credencial que un trabajo pueda usar. El runner de confianza, dentro de la red de la plataforma, ejecuta los trabajos que necesitan las identidades de la plataforma: las ejecuciones del ejecutor y los planes y apply en las ramas main protegidas. Consulta la compuerta de aprobación y el ejecutor.

Un documento pequeño que la fábrica de proyectos publica para cada producto una vez que sus proyectos existen: para cada edición, el proyecto, las identidades de plan y de apply, y los lugares para el estado de Terraform. Las propias raíces de un producto, y las raíces posteriores de la plataforma, lo leen en lugar de adivinar. Consulta reconciliadores.

Una copia de no producción de un producto, opcional y estable, contra la que otros productos hacen sus pruebas. Un producto necesita una cuando otro producto lo llama o lee sus eventos.

La herramienta que describe la infraestructura en la nube como código y hace que la infraestructura real coincida con él, en dos pasos, un plan y un apply. Cada raíz de Airframe es código Terraform.

Un conjunto fechado de las herramientas de pipeline de la propia plataforma, como 2026.09.30-2, que nombra el commit exacto de cada parte. Cada repositorio usa una versión. Una versión con una falla se revoca, y entonces la compuerta de aprobación rechaza todo pipeline nuevo que la use. Consulta versiones de la plataforma.

Una copia de corta duración de un producto, construida para un merge request para que los revisores puedan probar el cambio, con su propio nombre de host. Se destruye cuando el merge request se integra o se cierra, o cuando se vence su tiempo de vida, lo que ocurra primero. Consulta vistas previas.

Un formato de texto plano para datos estructurados, escrito como líneas clave: valor con sangría. Cada archivo del catálogo es YAML.

Licencia MIT. Copyright de los colaboradores de Airframe.

Este sitio describe la versión 2026.10.20-1 de la plataforma.