Este projeto define uma infraestrutura de Docker Swarm de nÃvel de produção na AWS. A arquitetura utiliza um modelo hÃbrido onde o Terraform provisiona a infraestrutura e o GitHub Actions gerencia o ciclo de vida das aplicações (CI/CD).
Docker, Cron, Rabbitmq, Opentelemetry e Banco de dados MySQL são componentes inaugurais, instalados
via userdata (terraform_data) usando diferentes arquiteturas de Sistema Operacional (ARM64 vs x86)
visando otimização de custos e performance extrema.
SSH Temporal & Segurança
Segurança ativa via módulo ssh_temp_provision:
- Instância
t4g.nanocriada apenas durante oapply. - Managers e Database em sub-redes privadas sem IP público (Isolamento total).
- Restrições de acesso condicional via
ssh_cidr_blocks. - Túnel SSH efêmero destruÃdo após o provisionamento.
Persistência de Rede
Uso de Elastic IPs Fixos (data.aws_eip):
- IP do NLB e NAT Gateway permanecem idênticos em recriações.
- Evita atualizações constantes de DNS externo e quebras de integração.
- Segurança em white-lists de parceiros e serviços de terceiros.
- NAT Gateway fixo para saÃda controlada de dados.
Camada de Borda: NLB, Traefik e Cloudflare
Network Load Balancer
Roteia tráfego TCP puro (80, 443, 3306) diretamente para IPs privados, preservando a performance e o IP de origem.
Traefik Proxy
Gerencia certificados SSL Let's Encrypt automaticamente via desafio HTTP-01 e faz o roteamento inteligente dos containers.
Cloudflare
Ambiente de teste com modo "Full/Strict". Proxy desativado (Grey Cloud) na primeira emissão para validação ACME.
Dashboard Traefik: Protegido por Basic Auth injetado dinamicamente via openssl no ato do provisionamento Terraform.
Pipeline CI/CD (GitHub Actions)
Compilação Java (Maven) e build Docker Cross-Architecture (Buildx).
Envio para o Amazon ECR com Tag Imutável baseada no SHA do commit.
AWS SSM injeção de variáveis e Rolling Update em containers stateless.
Sincronização via repo de infra, garantindo estado fiel ao Git.
Abstração de CD (GitOps)
As aplicações são agnósticas ao deploy. Um template wildcard no Manager é preenchido dinamicamente. O repositório da aplicação apenas dispara o gatilho:
- Desacoplamento entre App e Infra
- Notificação via repository_dispatch
name: Notify GitOps
on: [push]
jobs:
trigger:
runs-on: ubuntu-latest
steps:
- run: |
curl -X POST -H "Authorization: Bearer ${{ secrets.TOKEN }}" \
https://api.github.com/repos/org/continuosdeploy/dispatches \
-d '{"event_type": "trigger-deploy", "client_payload": {"APP": "my-api"}}'Inventário de Recursos e Instâncias
| Recurso | Instância / Tipo | Arquitetura | Função Técnica |
|---|---|---|---|
| Manager Leader | t3.small | x86_64 | LÃder do Swarm e Proxy Traefik. |
| Managers HA | t3.small | x86_64 | Quorum e Failover do Cluster. |
| Database Host | t4g.small | ARM64 | MySQL Dedicado (Foco em IOPS). |
| OpenTelemetry | t4g.nano | ARM64 | Coleta de Métricas e Traces. |
| SSH Provision | t4g.nano | ARM64 | Bastion temporário (Efêmero). |
Otimização de Custos
- Graviton (ARM64): Redução de até 20% no custo de instâncias DB e OTel.
- ECR Lifecycle: Purga automática de imagens Docker antigas.
- Alta Densidade: Orquestração leve comparada ao footprint do K8s.
Por que Swarm vs EKS?
Diferente do EKS, focamos no equilÃbrio entre Alta Disponibilidade e baixo custo operacional.
- • Sem taxa horária de Control Plane do EKS.
- • NLB direto para a malha (IP Preserving).
- • Simplicidade nativa: Manutenção reduzida.
- • Provisionamento Multi-AZ real.
Arquitetura Visual (MIRO)
Observabilidade & Telemetria
OpenTelemetry
Gateway Centralizado
Implementamos o padrão ouro da indústria para monitoramento de aplicações. O OTel Collector atua como um hub inteligente na instância t4g.small, processando sinais de todas as aplicações Spring Boot do cluster.