Swarm Cluster (Overview / Welcome)

Visão Geral do Cluster

O Swarm Cluster é a plataforma de execução de aplicações, APIs, serviços internos e ferramentas operacionais da empresa.

Ele foi construído utilizando containers Docker e orquestração Docker Swarm, com o objetivo de fornecer um ambiente padronizado, previsível e observável para execução de software.

A plataforma foi projetada seguindo alguns princípios fundamentais:

O cluster funciona como uma plataforma interna onde novas aplicações podem ser publicadas de forma padronizada, utilizando imagens Docker versionadas e deploy via stacks.

A infraestrutura também fornece serviços compartilhados como:

Dessa forma, os desenvolvedores podem focar nas aplicações enquanto o cluster fornece toda a base operacional necessária.

Engine do Cluster

Engine Operacional do Cluster

O cluster opera baseado em alguns pilares fundamentais:

Orquestração

Responsável por manter containers rodando, reiniciar serviços, distribuir cargas e gerenciar deploys.

Tecnologia: Docker Swarm

Rede

Rede overlay interna permitindo comunicação entre serviços independentemente do nó.

Storage

Volumes persistentes via AWS EFS compartilhado entre todos os nós.

Observabilidade

Logs, métricas e alertas centralizados.

Segurança

TLS automático, WAF, autenticação SSO e isolamento por redes internas.

Deploy

Deploy versionado via imagens Docker e stacks.

Arquitetura

Componente Função
Traefik Proxy reverso / entrada HTTP
Docker Swarm Orquestração de containers
Portainer Gerenciamento visual
Loki Armazenamento de logs
Alloy Coleta de logs
Prometheus Métricas
Grafana Dashboards
EFS Storage compartilhado
Redis Cache e sessões
Authentik SSO
WAF Web Application Firewall

Fluxo de requisição

  Internet                   Internet                                  
     ↓                          ↓                                  
  Traefik                    Traefik                                   
     ↓                          ↓                                  
  WAF                        WAF                                   
     ↓                          ↓                                  
  NGINX                      GO APP                                 
     ↓
  PHP-FPM/APP

Stack de Infraestrutura

Stack de Infraestrutura

Introdução

A Stack de Infraestrutura reúne o conjunto de serviços compartilhados disponibilizados pelo cluster para atender necessidades comuns das aplicações e das operações internas.

Embora cada projeto possa, conforme seus requisitos, publicar componentes próprios de infraestrutura, como bancos de dados, serviços de cache ou ferramentas auxiliares, o cluster já oferece um pacote inicial de recursos reutilizáveis. Esse modelo reduz o esforço de implantação, evita duplicação desnecessária de serviços e promove maior padronização operacional entre as stacks.

Esses serviços não substituem totalmente a possibilidade de infraestruturas dedicadas por aplicação. Em cenários que exijam isolamento, requisitos específicos de desempenho, compatibilidade de versão, compliance ou autonomia operacional, cada stack poderá prover seus próprios componentes. Ainda assim, para boa parte dos cados, o conjunto compartilhado do cluster atende de forma satisfatória as demandas iniciais e intermediárias dos projetos.

A seguir, são apresentados os principais serviços de infraestrutura atualmente disponibilizados.

Stack de Infraestrutura

Proxy de Entrada e Roteamento

O acesso HTTP e HTTPs ao cluster é centralizado pelo Traefik, que atua como proxy reverso de borda. Ele é responsável por receber as requisições externas, aplicar o roteamento com base em domínio e encaminhar o tráfego para os serviços corretos dentro do ambiente.

Além do roteamento, o Traefik também concentra responsabilidades como terminação TLS, publicação padronizada de aplicações web e integração com regras de exposição controlada.

Esse componente representa a porta de entrada principal do cluster para aplicações publicadas via web.

Stack de Infraestrutura

Gerenciamento Operacional

O Portainer é disponibilizado como interface de gerenciamento visual do ambiente Docker Swarm. Sua função é facilitar inspeções operacionais, acompanhamento de serviços, análise de containers, volumes, redes e demais recursos do cluster.

Embora o gerenciamento automatizado e o deploy padronizado devam privilegiar CLI e versionamento em arquivos declarativos, a presença do Portainer reduz a dependência exclusiva de acesso terminal para inspeções e ações operacionais controladas.

Stack de Infraestrutura

Storage Compartilhado

O cluster disponibiliza armazenamento compartilhado  em rede para aplicações que necessitem persistência de arquivos entre réplicas ou entre diferentes serviços.

Esse armazenamento é provido por volumes montados sobre NFS/EFS, permitindo uso compartilhado em cenários como :

A existência dessa camada compartilhada simplifica a execução de aplicações stateful que precisem manter arquivos fora do ciclo de vida efêmero dos containers.

Navegação de arquivos em volumes compartilhados

Para facilitar a inspeção e navegação de arquivos persistidos nos volumes montados em NFS, o cluster também disponibiliza um frontend web baseado em FileBrowser.

Esse serviço permite visualizar, enviar, baixar e organizar arquivos armazenados nos diretórios compartilhados, o que pode ser útil para apoio operacional, conferência de uploads, validações manuais e administração de conteúdos persistidos por aplicações.

Stack de Infraestrutura

Bancos de Dados Compartilhados

O cluster já oferece serviços de banco de dados que podem ser utilizados por aplicações quando não houver necessidade de instância dedicada.

Atualmente, estão disponíveis: 

Esses serviços compartilhados podem ser úteis para aplicações internas, ferramentas administrativas, provas de conceito, ambientes de desenvolvimento ou sistemas cujo perfil não exija isolamento completo da camada de banco.

Ainda assim, cada projeto deve avaliar cuidadosamente se o uso compartilhado é adequado ao seu contexto. Aplicações com exigências específicas de performance, segurança, versionamento ou governança podem demandar bancos dedicados.

Stack de Infraestrutura

Ferramenta de Acesso a Banco de Dados

Para facilitar a administração dos bancos disponibilizados no cluster, também existe o CloudBeaver, que fornece uma interface web para navegação, consulta e administração de diferentes motores de banco de dados.

Seu objetivo é oferecer um ponto centralizado e amigável para operações de inspeção, troubleshooting e apoio ao desenvolvimento, reduzindo a necessidade de acesso direto por clientes externos em cenários simples.

Stack de Infraestrutura

Cache e Dados Temporários

O cluster disponibiliza Redis como serviço compartilhado para uso por aplicações que necessitem mecanismos de cache, armazenamento temporário, filas leves, controle distribuído ou compartilhamento de sessão.

Esse recurso é especialmente útil em aplicações web com múltiplas réplicas, onde sessões e cache precisam ser centralizados para manter consistência entre instâncias.

Assim como nos demais componentes, nada impede que uma aplicação use uma instância própria de Redis quando houver necessidade específica de isolamento ou configuração dedicada.

Stack de Infraestrutura

Autenticação e Federação de Identidade

O cluster disponibiliza o Authentik como componente central para autenticação e federação de identidade.

Seu papel é atuar como broker entre aplicações internas e diferentes provedores de autenticação, permitindo integrar o ambiente ao sistema de identidade da empresa e a fluxos de autenticação federada.

Essa abordagem favorece a padronização de acesso aos serviços internos e reduz o acoplamento direto de cada aplicação com provedores externos específicos. Em vez de cada sistema implementar integrações independentes, o Authentik passa a intermediar essa relação, centralizando autenticação, políticas e governança de acesso.

Em termos práticos, isso permite:

Stack de Infraestrutura

Gestão de Segredos e Dados Sensíveis

O cluster também prevê o uso de ferramentas voltadas à gestão de dados sensíveis, entre elas o Vaultwarden.

Esse componente pode ser utilizado como apoio à administração segura de credenciais, segredos operacionais e informações restritas relacionadas ao ecossistema da plataforma, sempre observando os critérios internos de segurança e governança.

Stack de Infraestrutura

Observabilidade Básica Compartilhada

O cluster oferece uma base padronizada de observabilidade aplicada especialmente aos logs emitidos na saída padrão dos containers.

Essa capacidade permite centralizar e consultar logs de serviços executados na plataforma, fornecendo suporte a troubleshooting, inspeção operacional e análise de falhas.

Como a observabilidade possui arquitetura, objetivos e componentes próprios, sua descrição detalhada é apresentada em seção específica, evitando repetição nesta página.

Stack de Infraestrutura

Papel da Stack de Infraestrutura

A Stack de Infraestrutura deve ser entendida como um conjunto de serviços-base oferecidos pelo cluster para acelerar a publicação e a operação de aplicações.

Seu objetivo não é impor um modelo único para todos os projetos, mas disponibilizar um ponto de partida padronizado e funcional. Cada aplicação pode consumir esses recursos compartilhados ou optar por implantar componentes próprios, de acordo com suas necessidades técnicas e operacionais.

Em resumo, essa stack existe para:

Engine da Observabilidade

Engine da Observabilidade

Introdução

A Engine de Observabilidade do cluster é o conjunto de serviços responsáveis por coleta, armazenamento, consulta e visualização de logs, métricas e eventos operacionais de toda a plataforma.

O objetivo da observabilidade é permitir:

A observabilidade é tratada como parte fundamental da infraestrutura, e não como um recurso opcional.

Engine da Observabilidade

Arquitetura da Observabilidade

A arquitetura da observabilidade do cluster é composta pelos seguintes componentes:

Componente Função
Alloy Coleta e roteamento de logs
Loki Armazenamento e consulta de logs
Prometheus Coleta de métricas
Grafana Visualização e dashboards
Node Exporter Métricas dos servidores
cAdvisor Métricas dos containers

Fluxo de Logs

Container → Docker Logging → Alloy → Loki → Grafana

Fluxo de Métricas

Node Exporter / cAdvisor → Prometheus → Grafana

Engine da Observabilidade

Coleta de Logs com Alloy

Todos os containers do cluster enviam seus logs através do Docker Logging Driver utilizando o protocolo Syslog.

Os logs não são enviados diretamente para o Loki. Existe uma camada intermediária chamada Alloy, que atua como agente de coleta e roteamento de logs.

Vantagens dessa arquitetura

Cada nó do cluster executa uma instância do Alloy em modo global, funcionando como endpoint local de ingestão de logs.

Os containers enviam logs para:

tcp://127.0.0.1:51893

Isso garante que os logs sempre sejam enviados localmente ao nó, evitando dependência de rede overlay.

Engine da Observabilidade

Armazenamento de Logs com Loki

O Loki é o sistema responsável pelo armazenamento e consulta de logs do cluster.

Diferente de sistemas tradicionais de logs, o Loki não indexa o conteúdo dos logs, apenas labels. Isso reduz drasticamente o consumo e armazenamento.

Os logs são indexados principalmente pelos seguints labels:

Isso permite consultas como:

O Loki funciona como backend de logs e é consultado através do Grafana.

Engine da Observabilidade

Métricas com Prometheus

O Prometheus é responsável pela coleta de métricas do cluster e dos serviços.

As métricas coletadas incluem:

Métricas de Infraestrutura

Métricas de Containers

As métricas são coletadas principalmente através de:

Exporter Função
Node Exporter Métricas do host
cAdvisor Métricas dos containers
Prometheus Coleta e armazenamento
Engine da Observabilidade

Visualização com Grafana

O Grafana é a interface de visualização da observabilidade.

Atravéd do Grafana é possível:

O grafana funciona como interface única de observabilidade da plataforma.

Engine da Observabilidade

Filosofia da Observabilidade

A observabilidade do cluster foi projetada seguindo alguns princípios:

Logs são obrigatórios

Todo serviço deve gerar logs.

Logs centralizados

Nenhum log deve ficar apenas dentro do container.

Métricas antes de problemas

Problemas devem ser detectados por métricas antes de usuários perceberem.

Troubleshooting deve ser rápido

Deve ser possível descobrir o problema em minutos, não horas.

Observabilidade faz parte da plataforma

Não é responsabilidade de cada aplicação individual.

Tudo deve ser observável

Engine da Observabilidade

Resumo da Engine de Observabilidade

A Engine de Observabilidade do cluster é composta por:

Camada Ferramenta
Coleta de Logs Alloy
Armazenamento de Logs Loki
Coleta de Métricas Prometheus
Métricas de Host Node Exporter
Métricas de Containers cAdvisor
Visualização Grafana

Diagrama resumido

                +-------------+
                |   Grafana   |
                +------+------+
                       |
          +------------+-------------+
          |                          |
     +----+----+                +----+-------+
     |  Loki   |                | Prometheus |
     +----+----+                +----+-------+
          |                          |
        Alloy                   Node Exporter
          |                          |
      Containers                 cAdvisor

Por que Docker Swarm e não Kubernetes?

A escolha do Docker Swarm foi baseada em critérios técnicos, operacionais e de complexidade.

Comparação conceitual

Característica Docker Swarm Kubernetes
Complexidade Baixa Alta
Facilidade de operação Alta Média/Baixa
Curva de aprendizado Baixa Alta
Overhead de infraestrutura Baixo Alto
Ideal para clusters pequenos/médios Sim Nem sempre
Tempo de deploy Muito rápido Mais complexo
Integração com Docker Nativa Indireta
Manutenção Simples Complexa

Filosofia adotada

Escolhemos a ferramenta mais simples que resolve o problema de forma confiável.

O Docker Swarm oferece:

Para o tamanho e necessidades do ambiente, o Swarm atende perfeitamente com muito menos complexidade operacional.

Princípio adotado

Preferimos um sistema que entendemos completamente do que um sistema extremamente complexo que apenas sabemos operar.

Filosofia de Operação

Filosofia de Operação

Introdução

O cluster não é apenas um conjunto de servidores executando containers, mas uma plataforma operacional construída sobre alguns princípios fundamentais.

Esses princípios orientam a forma como aplicações são desenvolvidas, empacotadas, implantadas e operadas dentro do ambiente.

O objetivo dessa filosofia é manter o ambiente previsível, auditável, escalável e operável por qualquer pessoa da equipe com conhecimento da plataforma.

Filosofia de Operação

Infraestutura como Plataforma

O cluster deve ser entendido como uma plataforma interna de execução de software, e não apenas como um conjunto de máquinas onde aplicações são instaladas manualmente.

Aplicações não devem depender de configurações manuais em servidores específicos.
Toda aplicação deve ser executada através de containers e publicada via stack.

Isso garante:

O servidor deixa de ser importante; o que importa é o serviço.

Filosofia de Operação

Containers são Efêmeros

Containers devem ser tratados como descartáveis.

Nenhuma informação importante deve existir apenas dentro de um container.
Tudo que precisa persistir deve estar em:

Se um container puder ser destruído e recriado sem perda de dados, então o sistema está corretamente arquitetado.

Filosofia de Operação

Deploy é Versionado

Toda aplicação publicada no cluster deve possuir:

O cluster não deve rodar código sem versão identificável.

Isso permite:

Filosofia de Operação

Um Processo por Container

O cluster adota o princípio de:

Um container deve executar apenas uma responsabilidade.

Isso melhora:

Exemplo de separação comum:

Responsabilidade Serviço
Web nginx
Aplicação php-fpm
Scheduler schedule
Worker queue
Migration migrate
Seeder seeder

Essa separação é parte fundamental da arquitetura do cluster.

Filosofia de Operação

Logs e Métricas são Obrigatórios

Todo serviço deve gerar logs e métricas.

Se um serviço não gera logs, ele não pode ser operado corretamente.
Se não existem métricas, não existe monitoramento real.

A observabilidade não é opcional, ela faz parte da plataforma.

Filosofia de Operação

Automação antes de operação manual

Sempre que possível, tarefas devem ser automatizadas.

Evitar:

Preferir:

O objetivo é que qualquer ambiente possa ser recriado do zero apenas com código e configurações versionadas.

Filosofia de Operação

Simplicidade Operacional

Uma das decisões arquiteturais do cluster foi priorizar simplicidade operacional.

Isso significa:

A complexidade é considerada um custo operacional.

Filosofia de Operação

Padronização

Aplicações publicadas no cluster devem seguir padrões definidos para:

Padronização reduz erros, facilita troubleshooting e permite que qualquer pessoa da equipe opere qualquer serviço.

Filosofia de Operação

Responsabilidade do Cluster vs Responsabilidade da Aplicação

Divisão clara de responsabilidades:

Cluster Aplicação
Rede Regra de negócio
Proxy Código
TLS Queries
Logs Validação
Métricas Processamento
Storage Modelos
Autenticação Interface
Observabilidade APIs
Deploy Features

O cluster fornece a infraestrutura e a plataforma, a aplicação fornece a lógica de negócio.

Filosofia de Operação

Resumo da Filosofia

O cluster foi projetado para ser previsível, reproduzível, observável e operável.

Aplicações devem ser empacotadas como containers, implantadas de forma versionada, gerar logs, expor métricas e não depender de servidores específicos.

A plataforma deve abstrair a infraestrutura para que as equipes possam focar no desenvolvimento de software, enquanto o cluster fornece rede, segurança, storage, observabilidade e mecanismos de deploy.

A simplicidade operacional, a padronização e a automação são princípios fundamentais da operação do ambiente.