Atualizar o n8n de 1.63.4 para o 2.x mais recente

TLDR: Subir o n8n de 1.63.4 para o 2.x estável mais recente (hoje 2.28.5), para que o amqplib embutido (≥ 0.10.7) conecte no broker RabbitMQ 4.2 do Amazon MQ; rollout começando por staging e com backup, já que a atualização roda migrations irreversíveis e traz breaking changes do n8n 2.0.

Progresso

  • Staging atualizado para 2.28.5 e validado (feito). TF_VAR_n8n_version subiu para 2.28.5 apenas no ward de staging (produção ficou em 1.63.4, para o CI não tocar nela); aplicado localmente (make terraform.staging.apply). O amqplib passou a ser 0.10.6 e conecta no broker Amazon MQ (AMQPS OK — o bloqueio original). Dados intactos depois das migrations: 1 usuário, 86 workflows, 17 credenciais, ~10 mil execuções, cadeia de migrations completa; healthz = 200.
  • Armadilha de ownership no banco (corrigida em staging, PRECISA repetir em produção). A migration do n8n 2.x AddMissingPrimaryKeyOnAnnotationTagMapping… falhou com must be owner of table, porque o clone do banco (pg_restore --no-owner) deixou 29 das 30 tabelas com dono postgres (o master), não o usuário da app mkt. Resolvido rodando REASSIGN OWNED BY postgres TO mkt no banco n8n (como usuário master) antes das migrations. Produção foi clonada do mesmo jeito, então precisa do mesmo REASSIGN antes da sua atualização.
  • Corrida de migrations (transitória). main e worker tentam rodar as migrations no boot; o worker bateu em duplicate key … pg_type_typname_nsp_index enquanto o main migrava. Resolvido deixando o main terminar e depois reiniciando worker/webhook. Esperar o mesmo em produção.
  • Problema separado, ainda aberto (não resolvido pela atualização): a credencial rabbitmq do n8n ainda tem host rabbitmq (o droplet DO antigo), então workflows falham na ativação com getaddrinfo ENOTFOUND rabbitmq. A atualização resolveu a camada amqplib/frame_max; o host da credencial precisa ser trocado para o endpoint do Amazon MQ (b-…mq.us-east-1.on.aws, 5671, SSL, usuário automation, vhost marketing-automation--<env>) na UI do n8n.

Pendente

  • Rollout em produção: backup → REASSIGN OWNED BY postgres TO mkt → subir o ward de produção para 2.28.5 → make terraform.production.apply → reiniciar os pods → validar.
  • Atualizar o host da credencial rabbitmq do n8n nos dois ambientes.

Contexto

A stack n8n do marketing roda 1.63.4, que embute amqplib 0.10.3. O RabbitMQ 4 (o broker do Amazon MQ, rodando 4.2.8) tem um breaking change documentado: amqplib < 0.10.7 (ou qualquer cliente que negocie frame_max < 8192) não consegue conectar — o broker completa o TLS, envia Connection.Start e fecha o socket (“Socket closed abruptly during opening handshake”). Isso trava todos os workflows RabbitMQ do n8n.

A causa raiz foi provada forçando frameMax=131072 num cliente de teste (conecta) contra os defaults (falha), e confirmando amqplib 0.10.3 no pod em execução. O frame_max não é configurável no lado do broker Amazon MQ (um aws_mq_configuration com frame_max é rejeitado: BadRequestException: invalid key [frame_max] — ver o PR revertido #17/#18 na infra). A correção precisa ser no cliente.

O n8n corrigiu isso na 1.94.0 (amqplib 0.10.3 → 0.10.6, PR n8n-io/n8n#15418). Miramos o 2.x estável mais recente (2.28.5), para ficar em dia. É um salto grande (1.63 → 2.28) que:

  • roda migrations irreversíveis no primeiro boot do pod main (sem rollback);
  • traz breaking changes do n8n 2.0: task runners ligados por padrão (node Code isolado), acesso a variáveis de ambiente bloqueado a partir dos nodes Code, ExecuteCommand/LocalFileTrigger desabilitados por padrão, modo de dado binário em memória removido, novo paradigma de Save/Publish.

O banco de produção acabara de ser clonado de staging (usuários, 17 credenciais, 86 workflows, ~10 mil execuções), então os dois ambientes têm os mesmos dados a migrar.

Objetivos

  • n8n rodando o 2.x estável mais recente em staging e produção; workflows RabbitMQ conectando no Amazon MQ
  • Staging validado por completo antes de tocar em produção
  • Um backup restaurável de cada ambiente antes da sua atualização
  • Breaking changes conhecidos do 2.0 avaliados contra os 86 workflows antes do rollout

Fora de escopo

Reabilitar ExecuteCommand/LocalFileTrigger ou reescrever workflows com node Code — se a avaliação encontrar algum caso, ele vira tarefa de desdobramento.

Mudanças

Pin de versão (automation/.infra/terraform + ward):

  • TF_VAR_n8n_version no ward: 1.63.4 → 2.28.5 (por ambiente: staging primeiro, depois produção). Aplicado via kustomize.tf, que faz o patch de image: n8nio/n8n:${var.n8n_version} nos deployments main/worker/webhook.

Procedimento de rollout (operacional, staging → produção):

  1. Pré-avaliação (uma vez): rodar a ferramenta de Migration Report do n8n contra uma cópia dos workflows, para levantar problemas de nível de workflow do 2.0 (acesso a env no node Code, uso de ExecuteCommand/LocalFileTrigger, nodes depreciados). Registrar o resultado.
  2. Backup do banco de staging (pg_dump do banco n8n, como feito no clone; guardar fora do repo).
  3. Atualizar staging: subir TF_VAR_n8n_version (staging) → apply. O pod main roda as migrations no boot.
  4. Validar staging: main/worker/webhook em Running; migrations concluídas nos logs (sem erro); login funciona; lista de workflows intacta; um workflow RabbitMQ conecta no broker (a correção do amqplib); credenciais ainda decriptam; conferir por amostragem os workflows com node Code, por conta da mudança de task runner do 2.0.
  5. Backup do banco de produção.
  6. Atualizar produção: subir TF_VAR_n8n_version (produção) → apply → validar do mesmo jeito.

Como verificar

  • kubectl get pods -n marketing-automation--<env> mostra main/worker/webhook em Running na imagem n8nio/n8n:2.28.5
  • Os logs do pod main mostram as migrations aplicadas sem erro
  • A UI do n8n carrega; os usuários existentes logam; os 86 workflows estão lá; as credenciais resolvem
  • Um node RabbitMQ executa contra o Amazon MQ sem “Socket closed abruptly” (o bloqueio original) — confirma amqplib ≥ 0.10.7
  • O Migration Report não mostra problemas bloqueantes em aberto (ou eles estão registrados como desdobramentos)

Documentação

  • Registrar um aprendizado com a cadeia de causa raiz: RabbitMQ 4 exige amqplib ≥ 0.10.7 / frame_max ≥ 8192; frame_max não é configurável no broker do Amazon MQ (PR revertido #17); o n8n corrigiu na 1.94.0; atualizações rodam migrations irreversíveis (backup + staging primeiro).
  • Atualizar as notas de infra/app para registrar a nova versão fixada do n8n e as notas de breaking change do 2.0 relevantes aos workflows.