Fix: migrate job no CI

TLDR: Remove o migrate-job do kustomization e os init containers wait-migrate dos deployments, passando a rodar o migrate via CI antes do ship.

Contexto

O migrate-job.yaml está listado no kustomization.yaml como recurso fixo. Jobs k8s são imutáveis — depois de o TTL expirar (ttlSecondsAfterFinished: 120) o Job é deletado pelo cluster, e o próximo kubectl apply -k não consegue recriá-lo (o Job já não existe para ser atualizado). Com isso, os 5 deployments (web, worker, worker-beat, worker-habits, worker-progress) ficam presos em Init:CrashLoopBackOff aguardando um Job que nunca reaparece, porque o init container wait-migrate aguarda indefinidamente por ele.

O mesmo problema existia no messenger-api e foi resolvido movendo o migrate para o CI (rodado via run-migrate.sh antes do ship), eliminando a dependência de runtime do k8s.

Objetivos

  • O migrate passa a rodar no CI, antes do kubectl apply -k, garantindo que as migrations já estão aplicadas quando os pods sobem
  • Os deployments sobem diretamente, sem init container de espera
  • O kustomization para de gerir recursos imutáveis (Job, RBAC, ConfigMap de scripts)

Fora de escopo

— (não registrado na spec original)

Mudanças

.infra/k8s/base/kustomization.yaml

  • Remover as entradas specs/migrate-job.yaml, specs/migrate-rbac.yaml e specs/scripts-configmap.yaml

Arquivos a deletar

  • .infra/k8s/base/specs/migrate-job.yaml
  • .infra/k8s/base/specs/migrate-rbac.yaml (ServiceAccount migrate-waiter, Role e RoleBinding associados)
  • .infra/k8s/base/specs/scripts-configmap.yaml (ConfigMap onion-scripts com o script migrate-wait.sh)

Deployments (web, worker, worker-beat, worker-habits, worker-progress)

Em cada .infra/k8s/base/specs/*-deployment.yaml: - Remover serviceAccountName: migrate-waiter - Remover o bloco initContainers inteiro (wait-migrate) - Remover a entrada do volume onion-scripts em volumes:

.github/workflows/deploy-staging.yml

  • Adicionar run_migrate: true no bloco with: do job delivery

Nota: o delivery.yml@v2 em ibft-corp/pipelines já suporta run_migrate. Ele usa o script run-migrate.sh e o template migrate-job.yaml presentes em ibft-corp/commons/shell/tasks/k8s/. O template do commons usa placeholders APP_NAME e MIGRATE_IMAGE, mas tem env vars de Rails (RAILS_MASTER_KEY). Para o onion-backend (Django), o migrate-job rodado via CI usa a imagem com o comando bin/migrate e lê os secrets do cluster — o template é substituído em runtime, portanto o que muda no onion é apenas ativar a flag run_migrate: true no workflow.

Fases de implementação

Change de infraestrutura (só YAML) — não há código de aplicação, então não se aplica o ciclo TDD. Cada passo é atômico e resulta em um commit:

  1. fix: remover migrate-job.yaml, migrate-rbac.yaml e scripts-configmap.yaml do kustomization e deletar os arquivos
  2. fix: remover serviceAccountName, initContainers e volume onion-scripts dos 5 deployments
  3. fix: adicionar run_migrate: true no deploy-staging.yml

Como verificar

  1. Push de tag v* aciona o deploy-staging.yml
  2. No step delivery, o CI executa o migrate via run-migrate.sh antes do ship — o Job aparece no cluster, completa com sucesso e é deletado pelo TTL
  3. kubectl apply -k roda sem o migrate-job no kustomization
  4. Pods sobem sem init container — nenhum pod fica em Init:CrashLoopBackOff
  5. kubectl get pods -n onion-backend--staging mostra todos os deployments em Running

Documentação

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