Pular para o conteúdo principal

Capacidades Principais

Capacidade 1 — Self-Service de Serviços​

Um engenheiro de produto executa create-service no Backstage e seleciona o sistema (domínio, repositório e AppProject resolvidos automaticamente), nome e tipo do serviço (api / worker / frontend / grpc / cronjob), imagem de container, porta, perfil de recursos e ambientes-alvo.

O template estrutura um repositório de aplicação GitHub completo (com Dockerfile, pipeline de CI GitHub Actions e base para TechDocs), gera manifestos k8s para cada ambiente com labels corretas, ResourceQuota, NetworkPolicy, HPA e PDB — abre dois PRs GitOps e registra o Component no catálogo. O serviço está rodando em dev em minutos após os dois PRs serem mesclados.

Capacidade 2 — Self-Service de Infraestrutura​

Um tech lead executa create-resource no Backstage e seleciona um provedor de nuvem e tipo de recurso, o nível de propriedade (domain / system / component) e configurações específicas do provedor.

O template cria Claims do Crossplane por ambiente com dimensionamento adequado (dev: mínimo, prod: HA), define deletionPolicy: Orphan em prod, abre um PR no repositório do domínio e registra entidades Resource no catálogo. Nenhuma intervenção da equipe de plataforma necessária.

Capacidade 3 — Observabilidade Full-Stack no Backstage​

Na página do Component para gateway-api:

  • Aba Kubernetes — saúde dos pods por ambiente por cluster via um único label selector (project=payments,service=api encontra todos os ambientes em todos os clusters automaticamente)
  • Aba ArgoCD — status de sincronização e tag de imagem atual por ambiente
  • Aba Relações — grafo completo de dependências (bancos de dados, filas, caches que esse serviço usa)
  • Páginas de Resource — cada recurso vinculado exibe o status READY/SYNCED do Crossplane

Capacidade 4 — Aplicação de Convenção​

Todo repositório de domínio executa um workflow de CI de validação (validate-conventions.yaml) que verifica a nomenclatura de namespaces (via validate-namespaces.sh), todas as 9 labels obrigatórias, limites de recursos de containers, validação de schema Kubernetes (kubeconform) e dry-run diff do ArgoCD. Violações de convenção bloqueam o merge do PR. Não existe caminho de exceção.

Capacidade 5 — Onboarding de Equipe em Minutos​

  1. create-group — cria entidade Group, bindings RBAC para domínios de propriedade, papéis de projeto ArgoCD
  2. create-user (uma vez por membro) — cria entidade User, bindings RBAC, acesso de usuário ArgoCD

Após mesclar os dois PRs, novos membros podem fazer login no Backstage, ArgoCD e Kubernetes com o nível de acesso correto. Nenhum ticket manual necessário.

Capacidade 6 — Gerenciamento Seguro de Segredos​

Um desenvolvedor que precisa armazenar configurações sensíveis executa o template create-secret no Backstage. Ele criptografa localmente seu segredo em texto claro usando a CLI kubeseal com o certificado público do cluster, e fornece o payload criptografado ao template.

O template registra com segurança o manifesto SealedSecret no repositório GitOps do domínio. O controlador sealed-secrets da plataforma o descriptografa automaticamente dentro do cluster em um Secret padrão do Kubernetes. Nenhum segredo em texto claro é commitado no Git, e os desenvolvedores usam self-service sem abrir tickets.