Deploy de uma App Rails com SSM e Docker

O que é esse fluxo

Este playbook descreve um deploy contínuo (CD) baseado em git para um
host Docker compartilhado, orquestrado inteiramente pelo AWS Systems
Manager (SSM) — sem chaves SSH, sem bastion, sem shell interativo.

O modelo mental é simples:

push na main
  -> CI (audit + lint + testes) fica verde
    -> job de deploy autentica na AWS
      -> aws ssm send-command (AWS-RunShellScript) na instância
        -> no host: git fetch/reset --hard + docker compose up -d --build
          -> healthcheck (curl /up)

Por que SSM em vez de SSH

• Sem porta 22 de entrada. A instância nunca expõe SSH para a internet;
  o SSM conecta pelo agente SSM (saída). Menor superfície de ataque.
• Sem chave de longa duração para vazar. O GitHub Actions autentica na
  AWS com uma credencial de curta duração (role OIDC) e é autorizado a rodar
  exatamente um command document em exatamente uma instância.
• Auditável. Cada deploy é uma invocação de comando SSM com logs no
  CloudWatch — você ganha um registro por deploy de graça.

Quando usar

• Você tem um único host compartilhado rodando vários apps pequenos atrás
  de uma rede compartilhada, Postgres e Redis. Você quer adicionar mais um
  app sem subir novos serviços de dados nem um orquestrador completo
  (ECS/K8s).
• Você quer que o deploy seja um efeito colateral do merge na main, não
  um ritual manual.

Quando NÃO usar

• Você precisa de blue/green ou zero-downtime em várias réplicas — use
  ECS/K8s. Este fluxo recria um único container e tem uma janela breve
  enquanto o novo container sobe.

Os passos abaixo montam o fluxo do zero: o compose de deploy, os segredos no
host, o job de CD que dispara o comando SSM, migrations no boot, verificação
(com uma pegadinha de timing) e rollback.