05 Orquestração e Escalabilidade - KleberVales/Dominando-Docker GitHub Wiki

1. Introdução ao Docker Swarm

2. Conceitos de Kubernetes para desenvolvedores

3. Deploy de microsserviços com Docker e Spring Cloud

4. Monitoramento e logging de containers

5. Preparando sua aplicação para produção em nuvem


||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||


Introdução ao Docker Swarm

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.

O que é Docker Swarm?

  • 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.

Conceitos principais

  • 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.

Inicializando um Swarm

No nó manager:

docker swarm init

Isso 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>:2377

Criando um serviço no Swarm

docker 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.

Gerenciando serviços

Listar serviços:

docker service ls

Ver detalhes de um serviço:

docker service ps web

Escalar serviço:

docker service scale web=5

Benefícios do Docker Swarm

  • 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.

Comparação rápida: Swarm vs Kubernetes

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

Conceitos de Kubernetes para desenvolvedores

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.

O que é Kubernetes?

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.

Conceitos fundamentais para desenvolvedores

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.

Fluxo básico de deploy no Kubernetes

  1. Definir um Deployment → descreve a aplicação e quantas réplicas devem rodar.

  2. Criar um Service → expõe os Pods para comunicação.

  3. Aplicar ConfigMaps/Secrets → parametriza a aplicação sem alterar código.

  4. Gerenciar escalabilidade → aumentar ou reduzir réplicas conforme demanda.

  5. Monitorar e atualizar → Kubernetes garante que a versão mais recente esteja rodando.

Benefícios para desenvolvedores

  • 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.

Deploy de microsserviços com Docker e Spring Cloud

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.

O que são microsserviços?

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).

Papel do Docker no deploy de microsserviços

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).

Exemplo de Dockerfile para um microsserviço Spring Boot:

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY target/pedido-service.jar app.jar
EXPOSE 8081
ENTRYPOINT ["java", "-jar", "app.jar"]

Papel do Spring Cloud

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.

Deploy com docker-compose

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.

Boas práticas

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.

Cenário típico de produção

  1. Cada microsserviço é empacotado em uma imagem Docker.

  2. As imagens são publicadas em um registry (Docker Hub, GHCR, ECR).

  3. O deploy é feito com docker-compose, Swarm ou Kubernetes.

  4. Spring Cloud garante integração entre serviços (configuração, discovery, gateway).

  5. Observabilidade e monitoramento são adicionados para garantir resiliência.

Monitoramento e logging de containers

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.

Por que monitorar e coletar logs?

  • 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.

Monitoramento de containers

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.

Logging de containers

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.

Integração com orquestradores

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.

Boas práticas

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).

Fluxo típico de monitoramento e logging

  1. Aplicação gera logs estruturados (JSON).

  2. Docker envia logs via driver para Fluentd/Logstash.

  3. Logs são armazenados no ElasticSearch.

  4. Kibana exibe dashboards e permite buscas.

  5. Prometheus coleta métricas de containers.

  6. Grafana exibe métricas e dispara alertas.

Preparando sua aplicação para produção em nuvem

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.

Ajustes de arquitetura

  • 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.

Configuração e variáveis de ambiente

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.

Observabilidade (monitoramento e logging)

  • 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).

Segurança

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.

Escalabilidade e resiliência

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.

Automação com CI/CD

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.

⚠️ **GitHub.com Fallback** ⚠️