Como Configurar Cloud Bursting no Docker Swarm em 15 Minutos

2025-10-18 · Equipe SwarmBurst · 9 min de leitura

Neste tutorial, vamos configurar cloud bursting completo no seu cluster Docker Swarm usando o SwarmBurst. Ao final, seu cluster será capaz de escalar automaticamente para a AWS quando a demanda aumentar e reduzir quando ela diminuir — tudo sem intervenção manual.

Pré-requisitos

Antes de começar, certifique-se de que você tem:

  • 2+ servidores (VPS ou on-premise) com Docker instalado (versão 24.0+)
  • Uma conta AWS com acesso programático (Access Key e Secret Key)
  • Uma conta SwarmBurst (crie uma gratuita em swarmburst.io)
  • Acesso SSH aos servidores
  • Portas abertas: 2377/tcp, 7946/tcp+udp, 4789/udp entre os nós

Passo 1: Inicializando o Docker Swarm (3 minutos)

Se você já tem um cluster Docker Swarm rodando, pule para o Passo 2.

No servidor que será o nó manager, execute:

# Inicializar o Swarm
docker swarm init --advertise-addr <IP_DO_MANAGER>

O comando retornará um token para adicionar workers. Nos demais servidores, execute:

# Adicionar workers ao cluster
docker swarm join --token <TOKEN_RETORNADO> <IP_DO_MANAGER>:2377

Verifique se todos os nós estão no cluster:

docker node ls

Você deve ver algo como:

ID                           HOSTNAME    STATUS    AVAILABILITY   MANAGER STATUS
abc123def456 *               manager-1   Ready     Active         Leader
ghi789jkl012                 worker-1    Ready     Active
mno345pqr678                 worker-2    Ready     Active

Passo 2: Instalando o Agente SwarmBurst (2 minutos)

O agente SwarmBurst roda como um serviço no nó manager do seu cluster. A instalação é feita via Docker Compose.

Crie o arquivo de configuração no nó manager:

mkdir -p /opt/swarmburst && cd /opt/swarmburst

Crie o arquivo docker-compose.yml:

version: "3.8"

services:
  swarmburst-agent:
    image: swarmburst/agent:latest
    deploy:
      placement:
        constraints:
          - node.role == manager
      restart_policy:
        condition: on-failure
        delay: 5s
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./config:/etc/swarmburst
    environment:
      - SWARMBURST_API_KEY=${SWARMBURST_API_KEY}
      - SWARMBURST_CLUSTER_NAME=${CLUSTER_NAME}
    ports:
      - "9090:9090"
    networks:
      - swarmburst-net

networks:
  swarmburst-net:
    driver: overlay

Defina suas variáveis de ambiente:

export SWARMBURST_API_KEY="sua-api-key-do-painel-swarmburst"
export CLUSTER_NAME="producao-principal"

Faça o deploy do agente:

docker stack deploy -c docker-compose.yml swarmburst

Verifique se o agente está rodando:

docker service ls | grep swarmburst

ID             NAME                        MODE         REPLICAS   IMAGE
x1y2z3a4b5    swarmburst_swarmburst-agent  replicated   1/1        swarmburst/agent:latest

Neste ponto, o agente já está coletando métricas do cluster. Você pode verificar acessando http://<IP_DO_MANAGER>:9090/health.

Passo 3: Configurando os Thresholds de Scaling (3 minutos)

Os thresholds definem quando o SwarmBurst deve provisionar ou remover nós na nuvem. Crie o arquivo de configuração:

touch /opt/swarmburst/config/scaling-policy.yml

Edite o arquivo scaling-policy.yml:

# /opt/swarmburst/config/scaling-policy.yml

scaling:
  # Política de scale-up (adicionar nós)
  scale_up:
    conditions:
      - metric: cpu_percent
        threshold: 75
        duration: 120s        # CPU > 75% por 2 minutos
        operator: ">"

      - metric: memory_percent
        threshold: 80
        duration: 60s         # Memória > 80% por 1 minuto
        operator: ">"

      - metric: requests_per_second
        threshold: 1000
        duration: 60s         # Mais de 1000 req/s por 1 minuto
        operator: ">"

    # Qualquer UMA das condições acima dispara o scale-up
    match: any

    # Máximo de nós adicionais na nuvem
    max_burst_nodes: 5

    # Cooldown entre scale-ups (evita oscilação)
    cooldown: 300s

  # Política de scale-down (remover nós)
  scale_down:
    conditions:
      - metric: cpu_percent
        threshold: 40
        duration: 300s        # CPU < 40% por 5 minutos
        operator: "<"

      - metric: memory_percent
        threshold: 50
        duration: 300s        # Memória < 50% por 5 minutos
        operator: "<"

    # TODAS as condições devem ser verdadeiras para scale-down
    match: all

    # Cooldown entre scale-downs
    cooldown: 600s

    # Tempo mínimo que um nó burst fica ativo
    min_node_lifetime: 900s

As configurações acima são um bom ponto de partida para a maioria das aplicações. Vamos entender os pontos principais:

  • duration: Evita que picos momentâneos (1-2 segundos) disparem scaling desnecessário
  • cooldown: Previne oscilação rápida entre scale-up e scale-down
  • min_node_lifetime: Garante que nós burst fiquem ativos por tempo suficiente para justificar o custo de provisionamento
  • match: any no scale-up: Basta uma métrica ultrapassar o limite para escalar (mais responsivo)
  • match: all no scale-down: Todas as métricas devem estar abaixo do limite para desescalar (mais conservador)

Passo 4: Configurando as Credenciais AWS (3 minutos)

O SwarmBurst precisa de acesso à AWS para provisionar instâncias EC2. Recomendamos criar uma IAM policy específica com permissões mínimas.

Criando a IAM Policy na AWS

No console da AWS, crie uma nova policy com o seguinte JSON:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceStatus",
        "ec2:CreateTags",
        "ec2:DescribeImages",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeKeyPairs",
        "ec2:RequestSpotInstances",
        "ec2:CancelSpotInstanceRequests",
        "ec2:DescribeSpotInstanceRequests"
      ],
      "Resource": "*"
    }
  ]
}

Crie um usuário IAM, atribua essa policy e gere as chaves de acesso.

Configurando o Provider AWS no SwarmBurst

Crie o arquivo de configuração do provider:

# /opt/swarmburst/config/provider.yml

provider:
  type: aws
  region: sa-east-1          # São Paulo

  credentials:
    access_key_id: "AKIAIOSFODNN7EXAMPLE"
    secret_access_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

  instance:
    type: c5.xlarge           # 4 vCPU, 8GB RAM
    ami: ami-0abcdef1234567890  # Amazon Linux 2 com Docker pré-instalado
    key_pair: swarmburst-nodes
    security_group: sg-swarmburst
    subnet: subnet-abc123

    # Usar instâncias Spot para economia máxima
    use_spot: true
    spot_max_price: "0.08"    # Preço máximo por hora em USD

    # Script de inicialização (já inclui Docker e join no Swarm)
    user_data_template: default

  # Tags aplicadas às instâncias burst
  tags:
    Environment: production
    ManagedBy: swarmburst
    Cluster: producao-principal

Importante sobre segurança: Em produção, recomendamos usar AWS Secrets Manager ou variáveis de ambiente em vez de colocar as credenciais diretamente no arquivo. O SwarmBurst suporta ambas as abordagens:

# Alternativa usando variáveis de ambiente
credentials:
  access_key_id: "${AWS_ACCESS_KEY_ID}"
  secret_access_key: "${AWS_SECRET_ACCESS_KEY}"

Passo 5: Configurando Limites de Custo (2 minutos)

Um diferencial importante do SwarmBurst é o controle de custos integrado. Configure limites para evitar surpresas na fatura:

# /opt/swarmburst/config/cost-limits.yml

cost_control:
  # Limite máximo de gasto mensal com burst (em USD)
  monthly_budget: 150.00

  # Alerta quando atingir % do orçamento
  alerts:
    - threshold: 50
      notify: ["email:devops@suaempresa.com"]
    - threshold: 80
      notify: ["email:devops@suaempresa.com", "slack:#infra-alerts"]
    - threshold: 95
      notify: ["email:devops@suaempresa.com", "email:cto@suaempresa.com", "slack:#infra-alerts"]
      action: block_new_scaling   # Bloqueia novos scale-ups

  # Estimativa de custo em tempo real no dashboard
  show_realtime_cost: true

  # Preferir instâncias Spot sempre que possível
  prefer_spot: true

  # Encerrar nós burst se o custo mensal for atingido
  hard_limit: true

Com essa configuração, você nunca gastará mais do que US$ 150/mês com burst, e será alertado conforme se aproxima do limite.

Passo 6: Aplicando as Configurações e Testando (2 minutos)

Com todos os arquivos de configuração criados, reinicie o agente para aplicar:

docker service update --force swarmburst_swarmburst-agent

Verifique se as configurações foram carregadas corretamente:

# Verificar logs do agente
docker service logs swarmburst_swarmburst-agent --tail 50

Você deve ver mensagens como:

[INFO] SwarmBurst Agent v2.4.1 starting...
[INFO] Cluster 'producao-principal' connected successfully
[INFO] Scaling policy loaded: scale_up (3 conditions, match=any), scale_down (2 conditions, match=all)
[INFO] AWS provider configured: region=sa-east-1, instance_type=c5.xlarge, spot=enabled
[INFO] Cost control active: monthly_budget=$150.00, hard_limit=true
[INFO] Monitoring started. Current nodes: 3 (0 burst)
[INFO] Current metrics: cpu=32%, memory=45%, rps=234

Teste manual de scaling

Para verificar que tudo funciona, você pode disparar um scale-up manual via API:

curl -X POST http://localhost:9090/api/v1/scale \
  -H "Authorization: Bearer ${SWARMBURST_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"action": "up", "nodes": 1, "reason": "manual-test"}'

Acompanhe o provisionamento no dashboard do SwarmBurst (painel web acessível em https://app.swarmburst.io) ou pelos logs:

[INFO] Scale-up triggered: reason=manual-test
[INFO] Provisioning 1 Spot instance (c5.xlarge) in sa-east-1...
[INFO] Instance i-0abc123def456 launching...
[INFO] Instance i-0abc123def456 running (52s)
[INFO] Joining instance to Swarm cluster...
[INFO] Node 'burst-node-1' joined cluster successfully
[INFO] Current nodes: 4 (1 burst) | Estimated burst cost: $0.06/hr

Para remover o nó de teste:

curl -X POST http://localhost:9090/api/v1/scale \
  -H "Authorization: Bearer ${SWARMBURST_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"action": "down", "nodes": 1, "reason": "manual-test-cleanup"}'

Estrutura Final de Arquivos

Após completar todos os passos, sua estrutura deve estar assim:

/opt/swarmburst/
├── docker-compose.yml
└── config/
    ├── scaling-policy.yml
    ├── provider.yml
    └── cost-limits.yml

Dashboard e Monitoramento

Após a configuração, acesse o dashboard do SwarmBurst em https://app.swarmburst.io para visualizar:

  • Métricas em tempo real: CPU, memória e requisições de cada nó
  • Histórico de scaling: Quando e por que cada scale-up/down aconteceu
  • Custos acumulados: Quanto foi gasto com burst no mês atual
  • Projeção de custos: Estimativa do gasto até o final do mês baseada no padrão atual
  • Mapa do cluster: Visualização dos nós fixos e burst ativos

Referência: Veja o screenshot do dashboard em nossa documentação em docs.swarmburst.io/dashboard para uma visão completa da interface de monitoramento.

Dicas de Otimização

Depois que o SwarmBurst estiver rodando por alguns dias, considere estas otimizações:

Ajuste os thresholds baseado em dados reais

# Exemplo: se seu app é CPU-intensive, reduza o threshold de CPU
scale_up:
  conditions:
    - metric: cpu_percent
      threshold: 65           # Mais agressivo para CPU
      duration: 90s

Configure scaling por horário

# Scaling mais agressivo durante horário comercial
schedule:
  business_hours:
    cron: "0 8 * * 1-5"      # Seg-Sex 8h
    scale_up_threshold_cpu: 60
    max_burst_nodes: 5

  off_hours:
    cron: "0 19 * * 1-5"     # Seg-Sex 19h
    scale_up_threshold_cpu: 85
    max_burst_nodes: 2

Use instâncias diferentes para workloads específicos

# Nós compute-optimized para processamento
instance_profiles:
  default:
    type: c5.xlarge
    use_spot: true

  memory_intensive:
    type: r5.xlarge
    use_spot: true
    trigger_label: "workload=memory"

Solução de Problemas

Problema Causa Provável Solução
Agente não conecta ao cluster Docker socket sem permissão Verifique o volume mount do docker.sock
Instância AWS não entra no Swarm Portas bloqueadas Abra 2377, 7946, 4789 no Security Group
Scale-up muito lento AMI sem Docker pré-instalado Use a AMI recomendada do SwarmBurst
Custo acima do esperado Instâncias Spot não disponíveis Verifique a região e o spot_max_price
Nós burst não recebem tráfego Rede overlay não configurada Verifique se a rede overlay está acessível

Próximos Passos

Com o cloud bursting configurado, você pode:

  1. Monitorar o comportamento por 1-2 semanas e ajustar thresholds
  2. Configurar alertas no Slack ou email para eventos de scaling
  3. Otimizar custos testando diferentes tipos de instância e regiões
  4. Configurar scaling preditivo para antecipar picos antes que aconteçam

Precisa de Ajuda?

Se encontrar dificuldades durante a configuração, temos várias formas de suporte:

Quer uma proposta personalizada? Fale com nosso time e receba um diagnóstico completo da sua infraestrutura.

Falar com Especialista →

Tutorial atualizado para SwarmBurst Agent v2.4.1. Se você está usando uma versão anterior, consulte o guia de migração em docs.swarmburst.io/upgrade.