Migrar o n8n do RabbitMQ na DO para o Amazon MQ

TLDR: Apontar o consumidor n8n do marketing para o broker Amazon MQ compartilhado — ler a nova chave de remote state, usar o endpoint AMQPS (5671, TLS) e a API de management por HTTPS, para que o n8n conecte no broker gerenciado em vez do droplet desativado.

Contexto

O messagebroker compartilhado saiu de um droplet da DigitalOcean (RabbitMQ, AMQP em texto puro na 5672, management por HTTP) para o Amazon MQ for RabbitMQ na VPC AWS compartilhada (cluster HA, só TLS). No repo infrastructure o droplet está sendo destruído e a stack do Amazon MQ promovida ao caminho canônico src/shared/messagebroker/terraform, com a chave de state stacks/shared/messagebroker.

A stack n8n do marketing (automation/.infra/terraform) ainda consome o droplet antigo:

  • data.terraform_remote_state.messagebroker → chave stacks/shared/messagebroker/terraform.tfstate (era o droplet; depois da promoção, a stack do Amazon MQ — mesma chave, conteúdo novo)
  • provider "rabbitmq" com endpoint http://<messagebroker_public_ip>
  • RABBITMQ_HOST = messagebroker_private_ip, RABBITMQ_PORT = 5672
  • cria rabbitmq_vhost/user/permissions para marketing-automation--<env>

O Amazon MQ muda o contrato: sem IPs — hostnames; AMQPS na 5671 (TLS); API de management na 443 (HTTPS). A nova stack expõe messagebroker_amqp_host, messagebroker_amqp_port (5671), messagebroker_amqps_tls (true), messagebroker_management_host, messagebroker_management_url e messagebroker_admin_password.

Objetivos

  • n8n (worker/webhook) conecta no Amazon MQ por AMQPS 5671/TLS
  • O provider rabbitmq fala com a API de management do Amazon MQ por HTTPS 443
  • O vhost/usuário/permissões de marketing-automation--<env> são recriados no novo broker (mesmos recursos, novo alvo do provider)
  • Nenhuma configuração em texto puro na 5672 nem baseada em IP permanece

Fora de escopo

  • O droplet da DO é destruído antes, no repo infrastructure (janela de interrupção aceita antes deste cutover ser aplicado).
  • Workflows restaurados do n8n que ainda referenciam o hostname antigo do Swarm (rabbitmq) são uma correção de dados de workflow à parte, fora do escopo aqui.

Mudanças — automation/.infra/terraform

data.tf

  • Remote state: manter a chave stacks/shared/messagebroker (a stack promovida do Amazon MQ passa a viver ali).
  • provider "rabbitmq":
    • endpoint = https://${data.terraform_remote_state.messagebroker.outputs.messagebroker_management_host} (era http://…public_ip)
    • password = senha de admin do broker (de saída do remote state ou da variável existente)
    • O Amazon MQ apresenta certificado válido → não precisa de insecure.

secrets.tf

  • RABBITMQ_HOST = messagebroker_amqp_host (era messagebroker_private_ip)
  • RABBITMQ_PORT = "5671" (era "5672")
  • Adicionar RABBITMQ_TLS = "true" (o node RabbitMQ do n8n precisa conectar por AMQPS — conferir se os workflows/env honram a flag de TLS)
  • Manter RABBITMQ_VHOST/USER/PASSWORD vindos dos recursos rabbitmq_*

messagebroker.tf

  • rabbitmq_vhost/user/permissions ficam como estão (recriados no novo broker via o provider reapontado).

Como verificar

  • terraform plan em automation/.infra resolve as novas saídas e mostra o provider apontado para o host de management do Amazon MQ.
  • Depois do apply: o vhost/usuário/permissões existem no Amazon MQ (conferir no console messagebroker.ibft.app).
  • kubectl -n marketing-automation--<env> logs deploy/n8n-worker — sem erros de conexão com RabbitMQ; a fila Bull conecta por AMQPS 5671.
  • Um workflow do n8n que publica/consome via RabbitMQ roda de ponta a ponta.

Documentação

  • Se o provider cyrilgdn/rabbitmq ou o node do n8n exigirem configuração de TLS não óbvia contra o Amazon MQ, registrar um aprendizado em .project/docs/learnings/.