Airframe

Por qué Airframe

Cualquier pila; el golden path es una opción por defecto

La plataforma le exige pocas cosas a un producto: una entrada en el catálogo, solo componentes de CI de la plataforma en el archivo de pipeline, una imagen base de la plataforma bajo cada Dockerfile y un conjunto completo de etiquetas en cada recurso que lleva etiquetas. Lo demás es una opción por defecto. La plantilla genera el primer commit de un producto; desde ahí, la aplicación, su Dockerfile y su Terraform son del equipo, que puede cambiarlos bajo los mismos controles.

Qué es obligatorio y qué es una opción por defecto

  1. Tres pilas listas para usar

    El golden path parte de una plantilla de Copier que ofrece tres pilas: Java (Spring), Node y Python (FastAPI). La plataforma genera con ella el repositorio de un producto nuevo, con la pila que nombra su entrada del catálogo, con las raíces de Terraform, el Dockerfile y un pipeline hecho de los componentes de la plataforma. Cada cambio a la plantilla vuelve a generar los tres ejemplos y los compara con los que están en el repositorio; el ejemplo de cada pila se compila y se prueba cada vez que cambia su parte de la plantilla o el pipeline.

  2. O tu propio Dockerfile

    Después del primer commit, la aplicación es del equipo: puede cambiar el Dockerfile o agregar otro, listado en .airframe/images.yaml. Cada FROM debe nombrar una de las imágenes base de la plataforma, fijada: hoy Node, Python, Java, Bun, PostgreSQL y Redis, y una pila que no tiene la suya le pide a la plataforma que la agregue. El compilador de confianza compila cada imagen listada en la aprobación y la atesta, como hace con las de la plantilla. Los jobs de compilación y pruebas de la plataforma conocen solo las tres pilas de la plantilla: otra pila no ejecuta ninguno, y sus merge requests no pasan la compuerta de cobertura hasta que su entrada del catálogo baja quality.minimum_coverage, algo que aprueba un líder de equipo o un líder de dominio.

  3. Los módulos ayudan; los recursos directos se permiten

    Los módulos de Terraform del golden path codifican los patrones, y una raíz de producto puede declarar recursos propios en su lugar. El paquete de políticas advierte sobre cada recurso que una raíz de producto declara fuera de un módulo y pide una razón en el merge request; una advertencia no detiene nada. Lo que el paquete deniega, lo deniega sin importar cómo se escribió el recurso: un conjunto incompleto de etiquetas, el acceso público, o una red o un proyecto, que son de la plataforma.

  4. Un servicio se aprueba una vez

    Un servicio de Google Cloud además de los que recibe todo proyecto de producto se aprueba una vez, como una entrada en la lista de servicios aprobados del catálogo, por el equipo de plataforma. Después, cualquier producto puede declararlo en su entrada: un líder de dominio aprueba la declaración (el equipo de plataforma lo reemplaza cuando el líder no tiene cuenta), y la fábrica de proyectos habilita la API del servicio en los proyectos con facturación del producto y otorga sus roles solo a las identidades de apply de ese producto. Memorystore for Redis es el primero.

Obligatorio y opcional

Lo que la plataforma exige a un producto, junto a lo que ofrece por defecto, fila por fila
ObligatorioOpcional
Una entrada en el catálogoLa pila: Java, Node o Python con la compilación y las pruebas de la plataforma, u otra sobre una imagen base de la plataforma sin ellas
Incluye solo componentes de CI de la plataforma; los jobs propios del equipo no pueden desplegarLos módulos de Terraform del golden path
Una imagen base de la plataforma, fijada, en cada FROMLa aplicación de la plantilla, que el equipo puede cambiar después del primer commit
Las etiquetas de la plataforma en cada recurso que lleva etiquetasUna base de datos, tópicos, un sandbox, servicios aprobados

Qué lo hace cierto

Cada pila se compila y se prueba cuando cambia su parte de la plantilla.
El pipeline de golden-path vuelve a generar los tres ejemplos desde el catálogo vivo y exige que coincidan con los que están en el repositorio cada vez que cambian la plantilla, los ejemplos o el pipeline (template:render). Compila y prueba el ejemplo de una pila (template:test, template:test-python, template:test-java) cuando cambian los archivos de la plantilla de esa pila, su ejemplo o el pipeline. El catálogo de la demo declara un producto activo en cada pila: tracking en Java, invoicing en Python, tax-rules en Node.
Tu propio Dockerfile se compila sobre una imagen base de la plataforma.
Las reglas de Dockerfile del paquete deniegan un FROM o un COPY --from fuera de las imágenes base de la plataforma, uno sin fijar y uno calculado a partir de un argumento de compilación, en los Dockerfiles que lista .airframe/images.yaml. Desde la versión de la plataforma 2026.10.01-1, la validación inyectada las ejecuta en cada merge request que cambia un Dockerfile listado llamado Dockerfile, Dockerfile.* o *.Dockerfile, y airframe validate las ejecuta localmente. El compilador de confianza compila y atesta exactamente esa lista en la aprobación.
Los recursos directos se permiten, con una advertencia.
El paquete advierte sobre cada recurso administrado que una raíz de producto declara fuera de un módulo y pide una razón en el merge request, y una advertencia no hace fallar nada. Sus reglas de denegación se aplican a cada recurso, directo o no, y los tipos que son de la plataforma, como las redes, los proyectos y los perímetros, se deniegan en una raíz de producto.