Pular para o conteúdo principal

Repositórios de Aplicação

Este documento descreve a convenção para repositórios de aplicação criados por meio dos Golden Paths do Backstage. Enquanto os repositórios {domain}-gitops e platform-gitops governam a camada de implantação, o repositório da aplicação dá às equipes de produto autonomia sobre a configuração específica de sua carga de trabalho.

Bootstrapping via Golden Path

Quando uma nova aplicação é criada via Backstage (ex: usando o template create-service), ele entrega um repositório totalmente configurado contendo:

  1. Código Fonte Base: Uma estrutura de aplicação boilerplate para o framework escolhido (ex: Node.js, .NET, Python).
  2. Dockerfile: Uma definição de contêiner otimizada, segura e não-root adaptada à linguagem.
  3. Pipeline de CI: Um pipeline pré-configurado (ex: .github/workflows/ci.yaml).
  4. Pasta .k8s/: Um diretório de configuração que capacita a equipe da aplicação a gerenciar os recursos específicos de sua carga de trabalho.

A Pasta .k8s e Múltiplas Fontes (Multiple Sources)

Nossa plataforma utiliza o padrão de Múltiplas Fontes (Multiple Sources) do ArgoCD para mesclar definições tanto do repositório GitOps do domínio quanto do repositório da aplicação:

  • Manifestos Base ({domain}-gitops/k8s/): Contém a configuração fundacional do Kubernetes (Deployments, Services, NetworkPolicies padrão) e arquivos de valores (values) para o serviço.
  • Sobrescrições da Aplicação (app-repo/.k8s/): Contém arquivos de configuração (como um values.yaml ou kustomize patch) gerenciados diretamente pela equipe da aplicação.

Essa estrutura permite que os desenvolvedores sobrescrevam parâmetros críticos de implantação nativamente no repositório de sua aplicação sem precisar de PRs no repositório GitOps. Valores comumente sobrescritos incluem:

  • Versão/tag da imagem
  • Número de réplicas (ou limites min/max do HPA)
  • Requests/limits de memória e CPU
  • Variáveis de ambiente específicas da aplicação

Fluxo de Integração Contínua (CI)

O pipeline do Golden Path é projetado para fornecer uma transição perfeita desde o commit do código até a prontidão para implantação. O pipeline de CI executa as seguintes etapas:

  1. Test & Lint: Valida o código fonte base.
  2. Build: Compila o código e constrói a imagem do contêiner usando o Dockerfile fornecido.
  3. Publish: Faz o upload da imagem do contêiner resultante para o registro central de contêineres.
  4. Atualização da Tag: O pipeline atualiza automaticamente a tag da imagem dentro da pasta .k8s/ do repositório da aplicação (ex: atualizando image.tag em .k8s/values.yaml) e faz o commit dessa alteração de volta no repositório.

Como o ArgoCD está configurado para observar o repositório da aplicação como uma fonte secundária, o novo commit da tag da imagem aciona imediatamente uma sincronização de implantação, enviando a nova versão para o ambiente de destino.