Revisado em 12/11/2026. A data de publicação original foi preservada.
Configurar cloud bursting no Docker Swarm exige preparar a aplicação, a rede e o retorno à capacidade base. Instalar um agente ou aumentar o número de réplicas não basta. Este guia organiza o fluxo de implantação assistida do SwarmBurst no cenário VPS + AWS; não é um instalador público nem uma promessa de conclusão em poucos minutos.
O atendimento começa pelo piloto do SwarmBurst. O pacote de instalação e as instruções específicas da versão são fornecidos na implantação. Não há criação de conta em um painel SaaS público, e você não deve executar comandos copiados de versões antigas sem confirmar sua correspondência com o pacote recebido.
Primeiro: confirme que o problema pede capacidade extra
Reúna métricas e logs durante o pico: uso de CPU e memória, tempo de resposta, erros, conexões e consultas ao banco. Compare com a operação normal. Se o gargalo for banco, armazenamento ou API externa, adicionar nós pode não ajudar e pode aumentar a pressão sobre a dependência.
O objetivo é selecionar um serviço que possa atender requisições em réplicas extras. O diagnóstico deve produzir um limite de carga aceitável e um critério para considerar o teste bem-sucedido. Veja como medir a capacidade com teste de carga.
Checklist de compatibilidade da aplicação
| Pergunta | Evidência a reunir |
|---|---|
| A aplicação está em Docker Swarm? | Estado do cluster e serviços implantados. Compose sozinho não equivale a Swarm. |
| O serviço pode rodar em outro nó? | Imagem disponível no registry e ausência de restrição que o prenda apenas à VPS. |
| Sessão e arquivos são compartilhados? | Destino das sessões, carrinho e uploads; nenhum dado necessário pode depender de disco efêmero. |
| O banco suporta mais réplicas? | Limite e consumo de conexões, carga de consultas e latência a partir dos nós temporários. |
| O tráfego alcança as réplicas? | Caminho do proxy/balanceador e teste real de atendimento por nó. |
| A aplicação encerra com segurança? | Comportamento ao receber sinal de parada e tempo para concluir requisições. |
Esses requisitos valem para a aplicação, não apenas para o agente. Estado local e balanceamento precisam ser resolvidos antes de liberar o burst.
Prepare a VPS e a conta AWS
Antes de qualquer instalação, combine uma janela, registre os serviços existentes e faça um backup restaurável, guardado também fora da VPS. Espaço livre, memória, portas e configuração do proxy precisam ser avaliados para evitar interferência nos projetos que já rodam nela.
Na AWS, defina região, imagem da máquina, rede, permissões e responsável pela conta. As credenciais devem ter acesso compatível com a implantação e ser entregues por um mecanismo seguro combinado com o operador. Não envie chaves ou senhas pelo WhatsApp nem as publique em arquivos do blog.
No fluxo atual, o cliente recebe um pacote de instalação por imagens. A preparação do manager inclui Docker Swarm, WireGuard e regras de rede. O painel pode ser publicado em um domínio do cliente com HTTPS; não existe um endereço universal de painel que sirva para todas as instalações.
Organize o que fica fixo e o que pode crescer
No cenário VPS + AWS, a VPS mantém o manager e os componentes permanentes. Os workers temporários são usados pelo serviço selecionado para expansão. Banco, arquivos e demais dependências devem ter localização e política de backup explícitas.
Entrada HTTPS → proxy / balanceamento → réplicas da aplicação
├─ VPS fixa
└─ worker AWS temporário
Réplicas → banco, sessões e arquivos persistentes definidos na arquitetura
O diagrama é uma ilustração de arquitetura, não uma garantia de disponibilidade. Se banco e entrada pública dependem da VPS, a queda dela continua afetando a aplicação.
Configure nós e réplicas como decisões diferentes
Um nó extra oferece recursos, mas não garante que a aplicação passe a usá-los. A documentação do Docker Swarm explica que tarefas existentes não são redistribuídas automaticamente apenas pela entrada de um nó.
Na configuração assistida do SwarmBurst, escolha o serviço da aplicação, as réplicas de base e quantas réplicas adicionais correspondem a cada nó temporário. Verifique que as regras de posicionamento e os recursos disponíveis permitem esse agendamento. Configure também os limites de nós, as condições de expansão e redução e o orçamento operacional.
A seleção de valores depende do teste da aplicação. Não use um percentual de CPU ou uma quantidade de réplicas como padrão universal.
Confira a rede entre VPS e workers
A implantação atual usa WireGuard para conectar os nós. Confirme que cada worker consegue entrar no Swarm, baixar a imagem e acessar as dependências necessárias. Rede de containers e túnel precisam funcionar também com respostas e uploads maiores; um teste que só consulta uma página pequena não cobre todo o caminho.
O acesso público deve passar pela entrada HTTPS definida. Evite expor painel, banco ou portas internas ao público como atalho de configuração. Regras de firewall precisam considerar tanto o Docker quanto o túnel e o proxy usados na instalação.
Faça um teste controlado de expansão
Use um ambiente de teste ou uma janela autorizada, com supervisão e critério de interrupção. Antes da carga, registre a capacidade base, o estado dos nós e o custo inicial disponível.
Durante o teste, confira separadamente:
- O agente detectou a condição esperada?
- A instância EC2 iniciou e entrou no cluster como worker?
- O serviço ganhou as réplicas previstas e elas ficaram saudáveis?
- As réplicas remotas receberam tráfego e acessaram banco e arquivos?
- Latência e erros permaneceram dentro do critério acordado?
- As dependências continuaram com folga suficiente?
Não conclua que funcionou só porque a EC2 aparece ligada. Capacidade útil é a que efetivamente atende a aplicação.
Teste a redução e confira a conta
Reduza a carga e acompanhe a volta às réplicas base, a retirada dos workers e a finalização das instâncias. Confirme que requisições em andamento, sessões e arquivos continuam corretos. Depois confira recursos remanescentes na AWS e a conciliação de custos disponível.
O orçamento do agente é um controle operacional, não uma garantia de fatura máxima. A AWS documenta que recursos associados podem continuar gerando cobrança mesmo quando a instância não está sendo faturada por execução. Alertas, limites e limpeza precisam ser conferidos no ambiente.
Se a expansão falhar, deve existir um plano de retorno conhecido: interromper novas expansões, retirar os recursos criados e restaurar a configuração validada. Isso não elimina o gargalo da VPS nem assegura que ela suporte o pico sozinha.
O que entregar ao final da implantação
O aceite deve registrar a configuração aplicada, o serviço escalado, os critérios de desempenho e custo, os testes executados e suas limitações. Inclua responsáveis, acesso ao painel, backup, procedimento de atualização e como verificar o retorno à base.
Não há promessa de disponibilidade sem interrupção ou economia percentual. O resultado precisa ser medido no ambiente do cliente. A implantação abordada usa AWS; outros provedores não fazem parte deste fluxo operacional.