05 Orquestração e Escalabilidade - KleberVales/Dominando-Docker GitHub Wiki
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
O Docker Swarm é a solução nativa de orquestração de containers oferecida pelo Docker. Ele permite transformar múltiplos hosts Docker em um cluster que pode ser gerenciado como se fosse uma única instância, facilitando o deploy, escalabilidade e alta disponibilidade de aplicações.
-
Swarm Mode: modo especial do Docker que habilita recursos de orquestração.
-
Cluster: conjunto de máquinas (nós) que trabalham em conjunto para rodar containers.
-
Gerenciamento centralizado: você interage com o cluster como se fosse um único Docker Engine.
-
Manager Node: nó responsável por gerenciar o cluster, distribuir tarefas e manter o estado.
-
Worker Node: nó que executa containers conforme instruções do manager.
-
Service: definição de como containers devem rodar (imagem, réplicas, rede, volumes).
-
Task: instância de um container dentro de um service.
-
Overlay Network: rede que conecta containers em diferentes nós do cluster.
No nó manager:
docker swarm initIsso cria um cluster com um nó inicial. O comando retorna um token de join para adicionar novos workers:
docker swarm join --token <token> <IP-do-manager>:2377docker service create --name web --replicas 3 -p 8080:80 nginx-
Cria um serviço chamado web.
-
Executa 3 réplicas do Nginx distribuídas entre os nós.
-
Expõe a porta 8080 para acesso externo.
Listar serviços:
docker service lsVer detalhes de um serviço:
docker service ps webEscalar serviço:
docker service scale web=5-
Escalabilidade: aumenta ou reduz réplicas facilmente.
-
Alta disponibilidade: containers são redistribuídos automaticamente em caso de falha.
-
Balanceamento de carga: requests são distribuídos entre réplicas.
-
Simplicidade: integração nativa com Docker, sem necessidade de ferramentas externas.
| Aspecto | Docker Swarm | Kubernetes |
|---|---|---|
| Facilidade de uso | Mais simples | Mais complexo |
| Recursos avançados | Limitados | Extensos |
| Escalabilidade | Boa | Excelente |
| Integração | Nativa Docker | Ecossistema amplo |
O Kubernetes é a plataforma de orquestração de containers mais utilizada no mundo. Ele abstrai a complexidade de gerenciar aplicações distribuídas, oferecendo escalabilidade, resiliência e automação. Para desenvolvedores, entender seus conceitos fundamentais é essencial para criar aplicações modernas e prontas para produção.
Plataforma open-source para orquestração de containers.
Automatiza deploy, escalonamento e gerenciamento de aplicações.
Funciona em clusters de máquinas (nós), tratando-os como um único ambiente.
| Conceito | Descrição |
|---|---|
| Cluster | Conjunto de máquinas (nós) que executam aplicações. |
| Node | Cada máquina dentro do cluster (pode ser física ou virtual). |
| Pod | Unidade mínima de execução. Contém um ou mais containers que compartilham rede e armazenamento. |
| Deployment | Controlador que gerencia réplicas de Pods, garantindo que a aplicação esteja sempre disponível. |
| Service | Abstração que expõe Pods para comunicação interna ou externa, com balanceamento de carga. |
| ConfigMap | Armazena configurações não sensíveis (ex.: URLs, parâmetros). |
| Secret | Armazena dados sensíveis (ex.: senhas, tokens). |
| Namespace | Permite organizar recursos em ambientes isolados (ex.: dev, staging, prod). |
| Ingress | Recurso que gerencia acesso externo (HTTP/HTTPS) às aplicações. |
| Volume | Permite persistência de dados além do ciclo de vida dos Pods. |
-
Definir um Deployment → descreve a aplicação e quantas réplicas devem rodar.
-
Criar um Service → expõe os Pods para comunicação.
-
Aplicar ConfigMaps/Secrets → parametriza a aplicação sem alterar código.
-
Gerenciar escalabilidade → aumentar ou reduzir réplicas conforme demanda.
-
Monitorar e atualizar → Kubernetes garante que a versão mais recente esteja rodando.
-
Escalabilidade automática (Horizontal Pod Autoscaler).
-
Resiliência: reinicia Pods em caso de falha.
-
Portabilidade: roda em qualquer ambiente (cloud, on-premise, híbrido).
-
Integração com CI/CD: pipelines podem aplicar novas versões automaticamente.
-
Observabilidade: métricas e logs integrados com Prometheus, Grafana, ELK.
O desenvolvimento baseado em microsserviços traz flexibilidade e escalabilidade, mas também aumenta a complexidade de deploy e gerenciamento. Usando Docker para empacotar cada serviço e Spring Cloud para fornecer ferramentas de integração, conseguimos criar ambientes distribuídos mais organizados e resilientes.
Arquitetura onde a aplicação é dividida em módulos independentes.
Cada serviço tem seu próprio ciclo de vida, podendo ser desenvolvido, escalado e implantado separadamente.
Comunicação geralmente feita via REST APIs ou mensageria (Kafka, RabbitMQ).
Cada microsserviço é empacotado em um container isolado.
Facilita a padronização do ambiente (mesmo runtime em dev, test e prod).
Permite escalar serviços horizontalmente com réplicas.
Integração com orquestradores (Docker Swarm, Kubernetes).
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY target/pedido-service.jar app.jar
EXPOSE 8081
ENTRYPOINT ["java", "-jar", "app.jar"]Spring Cloud fornece ferramentas para resolver desafios comuns em microsserviços:
-
Service Discovery: com Eureka, os serviços se registram e se encontram dinamicamente.
-
Config Server: centraliza configurações externas (profiles dev/prod).
-
API Gateway (Spring Cloud Gateway): roteia requisições para os serviços corretos.
-
Circuit Breaker (Resilience4j/Hystrix): aumenta resiliência contra falhas.
-
Distributed Tracing (Sleuth + Zipkin): rastreia chamadas entre serviços.
Um exemplo simples de deploy de microsserviços com docker-compose:
version: '3.8'
services:
config-server:
image: usuario/config-server:1.0
ports:
- "8888:8888"
eureka-server:
image: usuario/eureka-server:1.0
ports:
- "8761:8761"
pedido-service:
image: usuario/pedido-service:1.0
environment:
- SPRING_PROFILES_ACTIVE=prod
- EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=http://eureka-server:8761/eureka
depends_on:
- eureka-server
- config-server
ports:
- "8081:8081"
pagamento-service:
image: usuario/pagamento-service:1.0
environment:
- SPRING_PROFILES_ACTIVE=prod
- EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=http://eureka-server:8761/eureka
depends_on:
- eureka-server
- config-server
ports:
- "8082:8082"O que acontece aqui:
O Config Server centraliza configurações.
O Eureka Server gerencia o service discovery.
Os microsserviços (pedido-service, pagamento-service) se registram no Eureka e usam configurações do Config Server.
Cada serviço roda em seu próprio container, mas todos se comunicam via rede interna do Docker.
Separar perfis de configuração (dev, test, prod) com Spring Cloud Config.
Automatizar builds com CI/CD (GitHub Actions, GitLab CI).
Monitorar serviços com Prometheus + Grafana.
Usar gateway para centralizar autenticação e roteamento.
Escalar horizontalmente microsserviços críticos.
-
Cada microsserviço é empacotado em uma imagem Docker.
-
As imagens são publicadas em um registry (Docker Hub, GHCR, ECR).
-
O deploy é feito com docker-compose, Swarm ou Kubernetes.
-
Spring Cloud garante integração entre serviços (configuração, discovery, gateway).
-
Observabilidade e monitoramento são adicionados para garantir resiliência.
Gerenciar containers em produção exige monitoramento contínuo e coleta estruturada de logs. Esses dois pilares garantem visibilidade sobre o desempenho da aplicação, ajudam na detecção de falhas e permitem auditoria e análise de comportamento.
-
Detecção de problemas: identificar falhas de aplicação ou infraestrutura.
-
Performance: acompanhar uso de CPU, memória, rede e disco.
-
Segurança: rastrear acessos e eventos suspeitos.
-
Auditoria: manter histórico de execução e mudanças.
-
Escalabilidade: ajustar recursos com base em métricas reais.
Ferramentas e práticas para acompanhar métricas em tempo real:
- Docker stats: comando nativo para ver consumo de recursos.
docker stats-
cAdvisor: coleta métricas de containers e integra com Prometheus.
-
Prometheus + Grafana: stack popular para métricas e dashboards.
-
ELK/EFK Stack: ElasticSearch + Logstash/Fluentd + Kibana para métricas e logs.
-
Healthchecks: configurados em docker-compose ou Kubernetes para verificar se o container está saudável.
Os logs são fundamentais para entender o comportamento da aplicação.
- Logs nativos do Docker:
docker logs -f meu-container-
Drivers de logging: Docker suporta diferentes backends (json-file, syslog, fluentd, awslogs).
-
Centralização de logs:
-
Fluentd ou Logstash para coletar e enviar logs.
-
ElasticSearch para armazenar.
-
Kibana para visualizar.
-
-
Estruturação de logs: usar formato JSON facilita análise automatizada.
Kubernetes: logs e métricas são integrados via kubectl logs, Prometheus e Fluentd.
Docker Swarm: serviços podem ser monitorados com stacks de observabilidade (Prometheus, ELK).
Alertas: configurar alertas automáticos (via Alertmanager, Grafana) para eventos críticos.
Não armazenar logs dentro do container → sempre enviar para sistemas externos.
Usar correlação de logs → incluir IDs de requisição para rastrear chamadas entre microsserviços.
Configurar níveis de log → DEBUG, INFO, ERROR conforme ambiente.
Automatizar coleta → pipelines devem integrar logs e métricas.
Segurança → nunca logar dados sensíveis (senhas, tokens).
-
Aplicação gera logs estruturados (JSON).
-
Docker envia logs via driver para Fluentd/Logstash.
-
Logs são armazenados no ElasticSearch.
-
Kibana exibe dashboards e permite buscas.
-
Prometheus coleta métricas de containers.
-
Grafana exibe métricas e dispara alertas.
Levar uma aplicação para produção em nuvem exige mais do que apenas rodar containers. É necessário pensar em escalabilidade, segurança, observabilidade e automação. A preparação correta garante que sua aplicação seja resiliente, performática e fácil de manter.
-
Containerização: empacotar a aplicação em Docker para garantir consistência entre ambientes.
-
Orquestração: usar Kubernetes, Docker Swarm ou serviços gerenciados (EKS, AKS, GKE).
-
Microserviços: dividir a aplicação em módulos independentes para facilitar escalabilidade.
-
Load Balancer: distribuir tráfego entre réplicas.
Usar ConfigMaps e Secrets (Kubernetes) ou serviços equivalentes (AWS Secrets Manager, Azure Key Vault).
Separar perfis (dev, staging, prod) para evitar configurações incorretas.
Nunca versionar credenciais sensíveis em repositórios.
-
Logs centralizados: enviar logs para ELK/EFK Stack (ElasticSearch + Fluentd/Logstash + Kibana).
-
Métricas: coletar com Prometheus e visualizar em Grafana.
-
Tracing distribuído: usar Spring Cloud Sleuth + Zipkin ou OpenTelemetry para rastrear chamadas entre microsserviços.
-
Alertas: configurar notificações automáticas (PagerDuty, Slack, e-mail).
Políticas de rede: limitar comunicação entre serviços.
Autenticação e autorização: usar OAuth2, JWT ou serviços gerenciados de identidade.
TLS/HTTPS: sempre criptografar tráfego.
Imagens seguras: escanear imagens Docker com Trivy ou Clair.
Menos privilégios: containers não devem rodar como root.
Horizontal Pod Autoscaler (HPA): aumentar réplicas automaticamente conforme carga.
Liveness/Readiness probes: garantir que apenas containers saudáveis recebam tráfego.
Circuit Breaker: usar Resilience4j para evitar cascata de falhas.
Cache distribuído: Redis ou Memcached para aliviar carga em bancos de dados.
Build automatizado: pipelines (GitHub Actions, GitLab CI, Jenkins) constroem e versionam imagens.
Deploy automatizado: integração com Kubernetes (kubectl, Helm, ArgoCD).
Rollback rápido: manter versões anteriores prontas para reverter em caso de falha.