Glossário

O Airframe usa algumas dezenas de termos que vêm do Google Cloud, do GitLab, do Terraform ou da própria plataforma. Cada um é explicado aqui em palavras simples, em ordem alfabética, com um link para a página que se aprofunda quando ela existe. Se uma página usa um termo que você não conhece, ele deveria estar aqui.

Agente de código

Um assistente de inteligência artificial que escreve e muda código. No Airframe, um agente de código contribui por merge requests com exatamente os mesmos controles que uma pessoa, e só uma pessoa nomeada que não escreveu uma mudança pode dar a aprovação que permite o merge. Veja pronto para um agente de código.

Atestado

Uma declaração assinada de que algo aconteceu com uma imagem de contêiner específica. Depois que o construtor confiável constrói uma imagem a partir de um commit aprovado, uma identidade de assinatura separada, que só o executor pode usar, assina um atestado de compilação depois que o executor comparou a compilação com o registro do próprio Cloud Build; promover a imagem em direção à produção adiciona um segundo. Veja zero privilégio permanente.

Binary Authorization

Um serviço do Google Cloud que decide, quando um serviço é implantado, quais imagens de contêiner podem rodar. No projeto de produção de um produto com faturamento, sua política admite só uma imagem que tenha os dois atestados. Um serviço precisa aderir; todo serviço implantado pelo módulo de Cloud Run do golden path adere.

Borda compartilhada

A única entrada pública para o nome de host de cada produto: um balanceador de carga do Google Cloud, administrado pela raiz de rede do landing-zone, que direciona cada nome de host ao seu produto e o coloca atrás do login único, a menos que o produto declare uma rota pública.

Catálogo

O repositório git de pequenos arquivos YAML que descreve a organização: suas jornadas, domínios e contextos, suas equipes e pessoas, e seus produtos. É a única fonte da verdade: todo o resto na plataforma deriva dele. Veja o catálogo.

Catálogo de arquitetura

Um site que mapeia cada produto: seus serviços, os eventos que publica e consome, seus responsáveis, seu runbook e suas decisões. Cada repositório publica a sua própria parte quando uma mudança é integrada, e o mapa se reconstrói sozinho. Ele é construído com o EventCatalog, em catalog.projectairframe.dev, e não é a mesma coisa que o catálogo, do qual tira a sua lista de produtos. Veja o catálogo de arquitetura.

CODEOWNERS

Um arquivo de um repositório do GitLab que diz qual aprovação cada caminho precisa. No Airframe, o arquivo CODEOWNERS do repositório de um produto é escrito uma só vez, quando o repositório é criado. Só o arquivo do próprio catálogo é gerado a partir do modelo de responsáveis do catálogo e comparado com ele, depois de cada merge no catálogo e todo dia. Em todos os casos, o controle de aprovação lê o modelo diretamente. Veja o catálogo.

Componente

Uma peça reutilizável de pipeline, publicada pelo repositório control-plane: por exemplo, a que valida uma mudança ou a que aplica o Terraform. O arquivo de pipeline de um produto só pode incluir esses componentes. Veja políticas como código.

Concessão do Privileged Access Manager

Um acesso temporário que uma pessoa pede, com um motivo, pelo Privileged Access Manager do Google Cloud. Uma concessão de papéis administrativos precisa da aprovação de outro membro da plataforma e dura no máximo duas horas; toda concessão fica no registro de auditoria. Veja identidades e acesso.

Construtor confiável

O pool privado do Cloud Build da plataforma, que constrói as imagens de contêiner de cada produto a partir de commits aprovados, para que o que roda em produção tenha sido construído pela plataforma, não pelo pipeline do próprio produto. Veja o caminho de uma mudança.

Contexto

O nível do catálogo abaixo de um domínio: um grupo de produtos muito relacionados e as equipes que os constroem, como ordering no domínio store. Cada produto e cada equipe pertence a exatamente um contexto. Veja o catálogo.

Controle de aprovação

O serviço que julga um merge request. Ele verifica se os responsáveis atuais pela mudança, como o catálogo os nomeia, a aprovaram, e então adiciona sua própria aprovação e inicia o executor. Ele também faz falhar qualquer pipeline que ainda use uma versão da plataforma revogada. Veja o controle de aprovação e o executor.

Desvio

Uma diferença entre o que o código diz e o que realmente existe na nuvem, em geral porque algo foi mudado fora de um merge request. Um plano agendado de cada raiz o encontra todo dia e abre uma issue para a raiz que se desviou. Veja desvio.

Domínio

O nível do catálogo abaixo de uma jornada, como store na jornada shop. Um domínio tem líderes, e algumas mudanças precisam de um deles, por exemplo, aumentar o orçamento de um produto. Veja o catálogo.

Edição

Uma das duas cópias da infraestrutura compartilhada da plataforma: produção e não produção. Cada uma tem sua própria rede, seu próprio lugar para guardar o estado do Terraform e seu próprio perímetro. Um produto recebe um projeto em cada uma.

Executor

O pipeline confiável que planeja as mudanças de um produto, e constrói suas prévias, com as identidades de curta duração do próprio produto. Ele roda no runner confiável da plataforma, e só o controle de aprovação pode iniciá-lo, quando um merge request é aprovado. Veja o controle de aprovação e o executor.

Federação de identidade de carga de trabalho

O recurso do Google Cloud que permite a um job de pipeline trocar o token assinado que o GitLab lhe dá por uma identidade do Google de curta duração, sem nenhuma senha ou chave guardada. A identidade só é entregue a um job do repositório certo, no ambiente certo, em uma branch protegida. Veja identidades e acesso.

Golden path

O jeito recomendado de construir um produto: um template que gera o repositório de um produto novo para Java, Node ou Python, e módulos de Terraform que codificam os padrões da plataforma. É um padrão, não uma exigência. Veja qualquer pilha.

Jornada

O nível mais alto do catálogo: uma área ampla do negócio da organização. A organização de demonstração tem três, shop, fulfil e settle, e cada uma contém domínios. Veja o catálogo.

Lápide

Um arquivo mantido na pasta retired-names/ do catálogo para cada produto removido, de modo que seu nome nunca seja dado a outro produto no mesmo domínio. Veja o catálogo.

Login único

Entrar uma vez com uma conta da organização para chegar a cada produto interno. No Airframe é o Identity-Aware Proxy do Google na frente do nome de host de cada produto, que só admite o grupo de usuários do produto, a partir do catálogo.

Main protegido

A branch principal de um repositório, protegida no GitLab para que as mudanças só cheguem a ela por um merge request aprovado. Só um job em uma branch protegida pode obter a identidade de um produto que aplica mudanças.

Merge request

A proposta do GitLab para mudar um repositório: uma branch com seus commits, as verificações que rodam sobre ela, a discussão e as aprovações. No Airframe toda mudança, em um produto ou na própria plataforma, é um merge request. Veja o caminho de uma mudança.

Modelo de responsáveis

O arquivo do catálogo ownership/protected-paths.yaml, que diz qual aprovação cada tipo de mudança precisa, no repositório de um produto e no próprio catálogo. O controle de aprovação o lê diretamente em cada merge request, a partir da branch main protegida do catálogo. Veja o catálogo.

Módulo

Uma peça reutilizável de código Terraform do repositório golden-path, como um serviço de Cloud Run ou um banco de dados, que um produto pode usar em vez de declarar cada recurso da nuvem por conta própria.

Observabilidade

Poder ver o que um produto em execução faz, pelos seus logs, métricas e traces. No Airframe eles viajam para um único stack do Grafana Cloud, onde cada produto recebe painéis e regras de alerta da sua entrada no catálogo. Veja observabilidade.

Pacote de políticas

O conjunto de regras testadas, escritas para o Open Policy Agent, que verifica cada mudança no código Terraform de um produto, no seu arquivo de pipeline e nos seus Dockerfiles declarados. Uma regra recusa uma mudança, o que a interrompe, ou faz um alerta sobre ela, o que hoje não segura nada. Veja políticas como código.

Perímetro

Um limite do VPC Service Controls em volta de um grupo de projetos, pensado para impedir que os dados saiam deles pelas APIs do Google. Os perímetros do Airframe funcionam hoje em modo de teste: registram o que bloqueariam, e não bloqueiam nada.

Pipeline

O conjunto de jobs automáticos que o GitLab roda para um commit, como as verificações de um merge request ou o plan e o apply na branch main. Um job é um passo de um pipeline.

Plan e apply

Os dois passos do Terraform. Um plan calcula o que uma mudança faria na infraestrutura real sem fazê-lo; um apply faz. No Airframe, os plans rodam quando um merge request é aprovado, e os apply só depois do merge, na branch main protegida. Veja o controle de aprovação e o executor.

Prévia

Uma cópia de curta duração de um produto, construída para um merge request para que os revisores possam testar a mudança, com seu próprio nome de host. Ela é destruída quando o merge request é integrado ou fechado, ou quando seu tempo de vida acaba, o que acontecer primeiro. Veja prévias.

Produto

Uma peça de software que uma equipe tem a seu cargo e opera, como o serviço de pedidos da organização de demonstração. É declarado por um arquivo no catálogo, e recebe seus próprios projetos, repositório, painéis e nome de host. Veja o catálogo.

Raiz

Um diretório de código Terraform com seu próprio estado e suas próprias identidades de pipeline, planejado e aplicado como uma unidade. Um produto tem uma raiz por ambiente, como infra/prod e infra/np. Veja reconciliadores.

Reconciliador

Um job automático de pipeline que lê o catálogo e faz algo real corresponder a ele: o GitLab, projetos do Google Cloud, grupos ou painéis. Nada que um reconciliador cria é editado à mão. Veja reconciliadores.

Runners confiável e não confiável

As duas máquinas que rodam os jobs de pipeline da plataforma. O runner não confiável roda as verificações de cada merge request e não tem nenhuma credencial que um job possa usar. O runner confiável, dentro da rede da plataforma, roda os jobs que precisam das identidades da plataforma: as execuções do executor e os planos e as aplicações nas branches main protegidas. Veja o controle de aprovação e o executor.

Saída Ready

Um pequeno documento que a fábrica de projetos publica para cada produto quando seus projetos existem: para cada edição, o projeto, as identidades de plan e de apply, e os lugares para o estado do Terraform. As raízes do próprio produto, e as raízes seguintes da plataforma, o leem em vez de adivinhar. Veja reconciliadores.

Sandbox

Uma cópia de não produção de um produto, opcional e estável, contra a qual outros produtos fazem seus testes. Um produto precisa de uma quando outro produto o chama ou lê seus eventos.

Terraform

A ferramenta que descreve a infraestrutura na nuvem como código e faz a infraestrutura real corresponder a ele, em dois passos, um plan e um apply. Cada raiz do Airframe é código Terraform.

Versão da plataforma

Um conjunto datado das ferramentas de pipeline da própria plataforma, como 2026.09.30-2, que nomeia o commit exato de cada parte. Cada repositório usa uma versão. Uma versão com falha é revogada, e então o controle de aprovação recusa todo pipeline novo que a use. Veja versões da plataforma.

YAML

Um formato de texto simples para dados estruturados, escrito como linhas chave: valor com recuo. Cada arquivo do catálogo é YAML.