control-plane

O repositório control-plane guarda a maquinaria que transforma um merge request aprovado em uma mudança na nuvem. Ele contém o controle de aprovação que julga os merge requests, o executor que roda seus planos e compilações, os componentes de pipeline que cada repositório inclui, o pacote de políticas que verifica cada mudança, e as raízes de Terraform que configuram o próprio GitLab a partir do catálogo. Quando um pipeline do Airframe faz algo, o código que faz isso quase sempre vive aqui.

Para que serve

Uma equipe de produto não deveria ter que escrever seu próprio pipeline de implantação, e não deveria poder escrever um que pule as verificações da plataforma. O control-plane fornece as peças de pipeline uma vez, para todos, junto com os dois serviços confiáveis que fazem o que um pipeline não confiável não deve fazer: o controle de aprovação e o executor. Ele também guarda a configuração do GitLab, grupos, repositórios, proteções e associações, em código derivado do catálogo.

O que ele contém

gate/: o controle de aprovação, um pequeno serviço em TypeScript no Cloud Run. Ele verifica o token assinado de cada pipeline, avalia o modelo de responsáveis, dá ou retém sua aprovação, inicia o executor, e define a verificação de status de custo. A página do controle de aprovação e do executor o explica.
executor/: os scripts que o runner confiável roda para um merge request aprovado: planos, preços, compilação de imagens pelo construtor confiável, prévias e sua limpeza.
templates/: os componentes de pipeline que um repositório inclui, como validate, tf-apply (plan, policy e apply na main, e o plano diário de desvio), image-build, promote-artifact e drift-report.
policy/airframe/: o pacote de políticas, as regras em Rego e seus testes. Veja políticas como código.
roots/: as raízes que configuram o GitLab a partir do catálogo (gitlab, gitlab-config e uma gitlab-config-<journey>-<domain> por domínio), e as raízes do runner confiável, do runner não confiável, do executor e do construtor confiável.
releases/: os manifestos e a lista de versões da plataforma permitidas.
cli/: o comando airframe: airframe validate, airframe pin e airframe release.
images/: as imagens base da plataforma, das quais todo Dockerfile de produto precisa partir, e as imagens em que seus próprios jobs rodam.
security-policies/: um espelho exato das políticas de segurança do GitLab, guardado para uma inicialização futura: a raiz gitlab as escreveu daqui uma vez, e um job, policy:schema, falha quando o espelho e a branch main do repositório security-policies diferem.

Como ele se conecta

Cada repositório inclui seus componentes. O arquivo de pipeline de um produto só pode incluir esses componentes, fixados no commit de uma versão, então os planos e as aplicações de cada produto rodam o mesmo código testado.
Ele lê o catálogo. Suas raízes do GitLab criam o repositório de cada produto, protegem sua branch main, definem suas permissões de merge e associações, e escrevem seu primeiro commit a partir do template do golden-path. Elas rodam em terceiro lugar na cadeia depois de um merge no catálogo.
Ele lê as saídas do landing-zone. As raízes de domínio pegam a saída Ready de cada produto para gerar seu primeiro commit, e o executor pega a autoridade de um produto da mesma publicação.
Ele iniciou o security-policies. A raiz gitlab escreveu uma vez as políticas de segurança do grupo, na inicialização; desde então, uma mudança em uma política é um merge request no próprio security-policies.
Ele é lançado com outros quatro repositórios. golden-path, os módulos, security-policies e platform-skills fixam um commit do control-plane, e uma versão nomeia todos eles.

Quem o muda, e como

As mudanças são merge requests aprovados pela equipe de plataforma, com a aprovação do controle obrigatória. Em um merge request, o pipeline roda os testes do que mudou: os testes e casos do pacote de políticas, os do executor, os dos componentes, os do comando airframe, e as verificações de versão quando uma versão muda. Na main, cada raiz planeja, passa pelo pacote de políticas e aplica com sua própria identidade; o serviço do controle de aprovação é implantado pela sua própria raiz do mesmo jeito.

Uma raiz é a exceção: roots/gitlab, que guarda as configurações do GitLab fixadas na inicialização. Ela é aplicada a partir de um notebook com o token de um dia da conta de administrador do GitLab, e cada execução é registrada. Toda outra mudança no GitLab passa pelo pipeline.

Onde fica

No repositório control-plane: