Migrar o CI de infra do onion-backend para ward/EKS

TLDR: Atualiza o workflow de CI de infra e os providers do terraform para que namespace e secrets sejam criados no cluster EKS, e o pipeline de deploy funcione ponta a ponta.

Contexto

O pipeline de deploy de staging (deploy-staging.yml) falha porque o namespace onion-backend--staging não existe no EKS. O namespace é criado pelo terraform (.infra/terraform/namespace.tf), mas:

  1. O provider kubernetes do terraform aponta para do-sfo3-shared-kubernetes (contexto de kubeconfig do DOKS) — o cluster antigo, que não existe mais
  2. O caller de CI infra.yml ainda usa a interface antiga (SOPS_AGE_KEY_*, DIGITALOCEAN_ACCESS_TOKEN), enquanto o pipelines/infra.yml@v2 agora espera ward_path + WARD_KEY
  3. O infra-pr.yml usa um padrão de decrypt SOPS local que também precisa migrar para ward

A spec 20260706235356_migrate_onion_backend_secrets_to_ward.md cobriu apenas os secrets. Esta cobre a migração completa de provider + CI necessária para os deploys de staging funcionarem.

Objetivos

  • O provider kubernetes do terraform conecta no EKS (via credenciais AWS + eks update-kubeconfig)
  • infra.yml usa pipelines/infra.yml@v2 com ward_path + WARD_KEY
  • infra-pr.yml usa plan baseado em ward (sem SOPS/age key)
  • Namespace onion-backend--staging e secrets criados pelo terraform apply no EKS
  • Pipeline de deploy de staging passa ponta a ponta

Fora de escopo

O banco e o cache continuam em DigitalOcean Managed — ficam lá (sem migração de dados). Só mudam o contexto do provider kubernetes e o wiring de CI.

Mudanças

.infra/terraform/versions.tf

  • Remover o provider sops
  • Manter digitalocean (banco/cache continuam na DO), kubernetes, cloudflare, rabbitmq

.infra/terraform/data.tf

  • Remover data.sops_file.secrets e local.secrets
  • Adicionar secrets baseados em variable (alimentados pelo ward via TF_VAR_*)
  • Corrigir a referência ao remote state kubernetes: o output kubernetes_cluster_id do DOKS usado nas firewall rules do banco precisa ser substituído — remover a firewall rule do k8s da DO, já que os nós do EKS acessam pelo endpoint público
  • Corrigir o remote state messagebroker: usar o output messagebroker_amqp_host em vez de messagebroker_public_ip
  • Remover data.terraform_remote_state.network

.infra/terraform/main.tf (provider kubernetes)

  • Substituir config_context = "do-sfo3-shared-kubernetes" pelo data source do EKS: hcl data "aws_eks_cluster" "shared" { name = "shared-kubernetes" } data "aws_eks_cluster_auth" "shared" { name = "shared-kubernetes" } provider "kubernetes" { host = data.aws_eks_cluster.shared.endpoint cluster_ca_certificate = base64decode(data.aws_eks_cluster.shared.certificate_authority[0].data) token = data.aws_eks_cluster_auth.shared.token }
  • Adicionar o provider aws (região us-east-1; credenciais via env vars AWS_* do ward)

.infra/terraform/secrets.tf

  • Substituir todas as referências local.secrets["<key>"] por variáveis var.<key> declaradas em variables.tf
  • O ward injeta os secrets como env vars TF_VAR_* — o terraform os pega automaticamente, sem wiring extra
  • Os valores de DATABASE_URL_* e REDIS_URL continuam sendo montados a partir dos recursos DO
  • do_token, cloudflare_api_token, cloudflare_zone_id etc. viram blocos variable alimentados por TF_VAR_*

.infra/terraform/database.tf / cache.tf

  • Remover os recursos digitalocean_database_firewall (referenciam kubernetes_cluster_id do state antigo do DOKS; os nós do EKS alcançam os bancos DO pelo endpoint público com SSL — firewall por IP é impraticável com autoscaler)
  • Manter todos os outros recursos DO de banco/cache inalterados

.github/workflows/infra.yml

  • Subir para a interface pipelines/infra.yml@v2: adicionar ward_path: onion-backend
  • Remover SOPS_AGE_KEY_*, DIGITALOCEAN_ACCESS_TOKEN, TERRAFORM_BACKEND_ACCESS_KEY/SECRET_KEY
  • Adicionar WARD_KEY: ${{ secrets.WARD_KEY }}

.github/workflows/infra-pr.yml

  • Substituir o decrypt SOPS local pelo plan baseado em ward (padrão do infra-pr.yml do marketing)

.ward/ (se ainda não migrado)

  • A spec 20260706235356 pode já ter feito isso. Verificar; se não, criar o vault ward com os equivalentes TF_VAR_* dos secrets SOPS atuais

Remover SOPS

  • Deletar o diretório .infra/terraform/secrets/ (arquivos enc + key) e o .sops.yaml, se presente

Como verificar

  • gh workflow run infra.yml --repo ibft-corp/onion-backend --ref <branch> → verde
  • kubectl get namespace onion-backend--staging → existe
  • kubectl get secret onion-backend-secrets -n onion-backend--staging → existe com as chaves corretas
  • gh workflow run deploy-staging.yml (ou push de tag) → deploy passa

Documentação

Nenhuma mudança de documentação necessária.