Servidores web
pela lente da F1.

Etapa 01 papel do servidor web

Para que serve um servidor web

O problema

O conceito

Um servidor web é o ponto por onde toda requisição HTTP entra antes de chegar (ou não) à aplicação. A aplicação, também chamada de backend ou servidor de aplicação (Node.js, PHP-FPM, Tomcat, Gunicorn), executa a lógica de negócio. O servidor web cuida de tudo o que está ao redor dela. Um servidor web moderno assume, tipicamente, seis funções:

• Servir conteúdo estático: entrega HTML, CSS, JavaScript, imagens e vídeos direto do disco, sem acionar código de aplicação.
• Fazer proxy para aplicações dinâmicas: encaminha requisições para PHP-FPM, Tomcat, Node.js, Gunicorn e similares.
• Balancear carga: distribui as requisições entre vários servidores de aplicação.
• Terminar TLS: gerencia certificados e criptografia em um ponto central, em vez de espalhar essa tarefa por cada instância.
• Fazer cache: guarda respostas já produzidas para entregá-las mais rápido depois, sem repetir o trabalho.
• Controlar acesso e segurança: filtra tráfego malicioso e aplica autenticação antes que o ataque chegue perto da aplicação.

O Apache HTTP Server teve seu primeiro lançamento em 1995, então a categoria tem mais de três décadas de uso. Quando o servidor web responde antes de qualquer aplicação existir (por exemplo, um 404 para um arquivo inexistente), ele mostra que é uma camada própria, e o cabeçalho Server da resposta identifica qual software atendeu. As etapas seguintes aprofundam cada função: proxy na Etapa 03, MPMs do Apache na Etapa 04, arquitetura do Nginx na Etapa 05 e balanceamento na Etapa 06.

Os conceitos-chave

Um servidor web mínimo e o cabeçalho Server

# default.conf
server {
    listen 80;                       # a porta que o Nginx escuta
    server_name localhost;           # o nome que este bloco atende
 
    location / {                     # regra para todas as URLs que começam com "/"
        root /usr/share/nginx/html;  # a pasta onde estão os arquivos estáticos
        index index.html;            # arquivo servido quando a URL termina em "/"
    }
}

Comandos essenciais desta etapa

Mão na massa

1. Suba os dois containers: docker run -d --name nginx-lab -p 8080:80 nginx:stable e docker run -d --name apache-lab -p 8081:80 httpd:2.4.
2. Rode curl -I http://localhost:8080 e curl -I http://localhost:8081. Observe o cabeçalho Server de cada um e o 200 OK.
3. Peça um caminho que não existe (curl -I http://localhost:8080/nao-existe) e observe o 404 Not Found. Essa resposta veio do servidor web, sem nenhuma aplicação ter sido acionada.
4. Rode docker logs nginx-lab e observe as linhas de acesso com as suas requisições, inclusive a que resultou em 404.
5. Limpe: docker rm -f nginx-lab apache-lab.

Etapa 02 evolução do protocolo

HTTP e sua evolução, de 1.1 a HTTP/3

O problema

O conceito

Antes das versões, um fato estrutural: o HTTP é um protocolo sem estado (stateless). Cada requisição é tratada de forma independente, sem memória das anteriores. Isso simplifica a escala, mas exige mecanismos por cima do protocolo (cookies e sessões) para manter o contexto de um mesmo usuário.

• HTTP/1.1 (1997): introduziu conexões persistentes (keep-alive), permitindo várias requisições e respostas na mesma conexão TCP e reduzindo o custo de abrir uma conexão nova por recurso. A limitação é o head-of-line blocking: se a primeira requisição demora, as seguintes na mesma conexão esperam.
• HTTP/2 (2015): resolve o head-of-line blocking da primeira cena, na camada de aplicação. Várias requisições e respostas (streams) trafegam ao mesmo tempo pela mesma conexão TCP, sem uma bloquear a outra. Também trouxe priorização de recursos, compressão de cabeçalhos (HPACK) e o Server Push, que caiu em desuso porque os principais navegadores removeram ou restringiram o suporte, já que o ganho raramente compensava a complexidade. Na web, o HTTP/2 é usado sobre TLS, e cliente e servidor combinam a versão durante o handshake TLS (extensão ALPN).
• HTTP/3 (QUIC sobre UDP): o HTTP/2 resolveu o problema na aplicação, mas o TCP garante que os bytes cheguem em ordem estrita. Se um pacote se perde, tudo o que veio depois dele espera a retransmissão, mesmo que pertença a outro stream. O HTTP/3 troca o TCP pelo QUIC, que roda sobre UDP: cada stream é independente, e a perda de um pacote só atrasa o stream afetado. O QUIC também combina o handshake de transporte com o de TLS 1.3, o que tende a estabelecer a conexão mais rápido. O ganho é maior em redes com perda de pacotes ou latência alta, como conexões móveis.

Na prática, o cliente descobre que o servidor oferece HTTP/3 pelo cabeçalho de resposta Alt-Svc. Redes que bloqueiam UDP na porta 443 fazem o cliente voltar para HTTP/2 ou HTTP/1.1.

HTTP/2: os streams vermelho e verde dividem a mesma conexão TCP. Se um elo se perde, tudo o que vem depois dele espera a retransmissão, seja de qual stream for.

HTTP/3: no QUIC, cada stream é uma corrente independente, e a perda de um elo só atrasa a corrente em que ele estava.

Os conceitos-chave

Perguntando ao curl qual versão foi negociada

# Deixa o curl negociar livremente e mostra a versão usada (saída aproximada)
$ curl -so /dev/null -w 'Protocolo negociado: HTTP/%{http_version}\n' https://www.cloudflare.com
Protocolo negociado: HTTP/2
 
# Força HTTP/1.1, mesmo que o servidor suporte versões mais novas
$ curl --http1.1 -so /dev/null -w 'Protocolo negociado: HTTP/%{http_version}\n' https://www.cloudflare.com
Protocolo negociado: HTTP/1.1
 
# Força HTTP/3 (exige um curl compilado com suporte a QUIC)
$ curl --http3 -so /dev/null -w 'Protocolo negociado: HTTP/%{http_version}\n' https://www.cloudflare.com
Protocolo negociado: HTTP/3

Comandos essenciais desta etapa

Mão na massa

1. Escolha um domínio que suporte HTTP/2 (por exemplo, www.cloudflare.com) e rode os dois primeiros comandos do exemplo. Observe o valor de %{http_version} mudando conforme a flag.
2. Rode curl -v --http2 https://www.cloudflare.com 2>&1 | grep -i "HTTP/2" e observe a linha que confirma a versão negociada no handshake.
3. Se o seu curl tiver suporte a HTTP/3, repita com --http3 e compare -w '%{time_total}\n' nas três variantes. Não espere uma diferença grande em uma rede estável.
4. Gere o certificado, crie h2.conf e suba o h2-lab. Observe HTTP/2 na primeira chamada e HTTP/1.1 com --http1.1.
5. Apague a linha http2 on; do h2.conf local e rode docker exec h2-lab nginx -s reload. Repita o curl sem flag e observe que a versão volta a ser HTTP/1.1, porque o servidor deixou de oferecer h2 no handshake. Atenção: o arquivo é montado individualmente no container, e alguns editores e o sed -i substituem o arquivo por um novo em vez de alterar o original. Nesse caso o container continua vendo a versão antiga e o reload parece não fazer nada; rode docker restart h2-lab e repita o teste.
6. Limpe: docker rm -f h2-lab.

Etapa 03 intermediários

Forward proxy e reverse proxy

O problema

O conceito

Forward proxy, o intermediário de saída. Fica entre um cliente (geralmente em uma rede privada) e a internet, e é configurado explicitamente no lado do cliente (navegador, sistema operacional ou aplicação). O fluxo é este: o cliente envia a requisição ao proxy indicando o destino; o proxy analisa e decide se encaminha ou bloqueia; se encaminha, faz a requisição em nome do cliente; a resposta volta ao proxy, que a repassa ao cliente. Para HTTPS, o cliente pede ao proxy um túnel (método CONNECT), e o proxy só enxerga o conteúdo se fizer inspeção de TLS. Casos de uso: segurança e conformidade, controle de conteúdo, anonimato (mascarar o IP do cliente) e cache. O Squid é um exemplo de software que cumpre esse papel.

Reverse proxy, o intermediário de entrada. Fica na borda da infraestrutura, recebe as requisições da internet e as distribui para os servidores de aplicação atrás dele. É transparente para o cliente, que nem sabe que ele existe. O fluxo: o cliente envia a requisição ao IP público do proxy; com base em regras, o proxy escolhe o backend; encaminha a requisição; o backend responde ao proxy; o proxy entrega a resposta ao cliente. Funções principais: balanceamento de carga, terminação TLS centralizada (tirando essa carga dos backends), cache, uma primeira camada de segurança, compressão (Gzip ou Brotli) e roteamento entre serviços. Sobre a segurança, o proxy puro filtra certos padrões de tráfego, mas bloquear ataques como XSS normalmente exige regras de WAF (Etapa 14).

A regra prática para distinguir os dois: pergunte quem configurou o apontamento para o intermediário. Se foi o cliente, é forward proxy. Se foi a infraestrutura do servidor e o cliente não sabe, é reverse proxy.

Há uma consequência para o backend: ele só enxerga o proxy abrindo a conexão. Para saber quem fez o pedido de verdade, o proxy repassa o IP do cliente em cabeçalhos como X-Real-IP e X-Forwarded-For (não padronizados, mas amplamente usados; o cabeçalho padronizado é o Forwarded). O backend só deve confiar nesses cabeçalhos quando vierem de um proxy conhecido, porque um cliente pode enviá-los forjados.

Forward proxy: o proxy fica na rede do cliente, e é o cliente que o usa para sair. O site externo só enxerga o proxy.

Reverse proxy: o proxy fica na rede do servidor, e quem vem da internet fala só com ele, sem saber qual servidor respondeu.

Os conceitos-chave

Reverse proxy Nginx e forward proxy Squid no mesmo laboratório

# backend.py
import os
import time
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
 
NAME = os.environ.get("NAME", "backend")      # nome devolvido nas respostas
PORT = int(os.environ.get("PORT", "3000"))    # porta de escuta
DELAY = float(os.environ.get("DELAY", "0"))   # atraso artificial, em segundos
 
 
class Handler(BaseHTTPRequestHandler):
    protocol_version = "HTTP/1.1"             # permite conexões persistentes
 
    def responder(self, com_corpo):
        if self.path == "/slow":
            time.sleep(10)                    # simula um backend travado
        elif self.path != "/healthz":
            time.sleep(DELAY)                 # simula um backend lento
        if self.path.endswith("/headers"):
            linhas = [f"peer: {self.client_address[0]}"]   # quem abriu a conexão TCP
            linhas += [f"{k}: {v}" for k, v in self.headers.items()]
            corpo = "\n".join(linhas) + "\n"
        else:
            corpo = f"{NAME} recebeu {self.path}\n"
        dados = corpo.encode()
        self.send_response(200)
        self.send_header("Content-Length", str(len(dados)))
        self.end_headers()
        if com_corpo:                         # HEAD não envia corpo
            self.wfile.write(dados)
 
    def do_GET(self):
        self.responder(True)
 
    def do_HEAD(self):
        self.responder(False)
 
 
ThreadingHTTPServer(("0.0.0.0", PORT), Handler).serve_forever()

Comandos essenciais desta etapa

Mão na massa

1. Crie a pasta etapa03/ com backend.py, nginx.conf, squid.conf e compose.yaml, e rode docker compose up -d. Confirme os três serviços com docker compose ps.
2. Rode curl -s http://localhost:8080/headers e observe X-Real-IP, X-Forwarded-For e Host: localhost. Em seguida rode curl -sI http://localhost:8080/ e observe Server: nginx, mesmo com o conteúdo vindo do Python.
3. Apague a linha proxy_set_header Host $host; do nginx.conf, rode docker compose exec nginx nginx -s reload e repita o /headers. Observe Host: backend_app, o nome do upstream, em vez do domínio que o cliente pediu. Atenção: o nginx.conf é montado como arquivo único, e alguns editores e o sed -i o substituem por um arquivo novo, o que deixa o container vendo a versão antiga. Se a mudança não aparecer depois do reload, rode docker compose restart nginx.
4. Restaure a linha, apague proxy_set_header X-Real-IP $remote_addr;, recarregue e repita. Observe que X-Real-IP desaparece, mas o X-Forwarded-For continua trazendo o IP do cliente, e que peer mostra o IP do Nginx (o peer sempre foi o Nginx, porque é ele quem abre a conexão com o backend). Apague também a linha do X-Forwarded-For, recarregue e repita: sem os dois cabeçalhos, o backend só enxerga o Nginx.
5. Restaure as linhas e rode curl -s -x http://localhost:3128 http://backend:3000/headers. Observe os cabeçalhos Via e X-Forwarded-For acrescentados pelo Squid. Compare com curl -s http://backend:3000/, que falha ao resolver o nome.
6. Limpe: docker compose down.

Etapa 04 processos + threads

Apache HTTP Server e os modelos de processamento (MPMs)

O problema

O conceito

Antes dos modelos, dois termos. Um processo tem memória própria e isolada dos demais; se ele falha, os outros seguem. Uma thread vive dentro de um processo e compartilha a memória dele com as outras threads, o que a torna mais leve e mais perigosa: um erro grave em uma thread pode corromper o processo inteiro. Código que funciona corretamente quando várias threads o executam ao mesmo tempo é chamado de thread-safe.

• Prefork (sem threads): um processo filho independente atende cada conexão, completamente isolado dos demais. Vantagens: muito estável (um problema em um processo não afeta os outros), compatível com módulos não thread-safe e com software legado. Desvantagens: alto consumo de memória e pouca escalabilidade sob alta concorrência. É comum ver o Prefork com o mod_php (PHP embutido no processo do Apache, historicamente não thread-safe). A alternativa é rodar o PHP como processo separado, o PHP-FPM, com o Apache falando com ele por proxy (mod_proxy_fcgi, o mesmo conceito da Etapa 03), o que permite usar um MPM mais leve sem perder compatibilidade.
• Worker (com threads): cria vários processos filhos, cada um com várias threads, e cada thread atende uma conexão. Usa menos memória que o Prefork e suporta mais concorrência. Como as threads de um processo compartilham memória, um erro grave em uma delas pode derrubar o processo filho que a hospeda e as conexões que ele atendia; os demais filhos e o processo mestre continuam de pé. Por isso os módulos precisam ser thread-safe.
• Event (recomendado para a maioria dos deployments novos): parte do Worker, mas otimizado para o caso comum de conexões keep-alive abertas e ociosas. Uma thread dedicada consegue vigiar várias conexões que só estão esperando, sem prender uma thread de trabalho a cada conexão parada. Mantém a exigência de módulos thread-safe e é o MPM indicado para HTTP/2, que o Apache oferece pelo módulo mod_http2 (habilitado com a2enmod http2 e Protocols h2 http/1.1).

Dois pontos de leitura da comparação: o consumo de memória cresce na ordem Event, Worker, Prefork, e a concorrência suportada cresce na ordem inversa. A escolha, portanto, é sempre uma troca entre isolamento e eficiência.

Os conceitos-chave

Descobrindo e trocando o MPM ativo

# Mostra o MPM em uso (saída resumida)
$ apachectl -V | grep -i mpm
Server MPM:     event
 
# Em Debian e Ubuntu, a2query mostra o módulo MPM habilitado
$ sudo a2query -M
event
 
# Troca para o Prefork (por exemplo, para rodar um módulo legado não thread-safe)
$ sudo a2dismod mpm_event      # desabilita o MPM atual
$ sudo a2enmod mpm_prefork     # habilita o Prefork
$ sudo systemctl restart apache2
 
$ sudo a2query -M
prefork

Comandos essenciais desta etapa

Mão na massa

1. Crie a pasta etapa04/ com o Dockerfile acima, construa as duas imagens e suba os dois containers como no exemplo.
2. Confirme o MPM de cada um com docker exec <container> httpd -M | grep mpm. Observe mpm_event_module e mpm_prefork_module.
3. Em um terminal, rode ab -n 50000 -c 100 http://localhost:8082/ (Prefork). Em outro, rode várias vezes docker top apache-prefork | grep -c httpd durante o teste e observe o número de processos crescer.
4. Repita o passo 3 contra http://localhost:8081/ (Event) e apache-event. Observe que o número de processos fica pequeno, porque cada processo comporta várias threads. Compare também docker stats --no-stream apache-event apache-prefork ao fim dos testes. Os números exatos variam; o que importa é a diferença de ordem de grandeza nos processos.
5. Se você tem um Apache instalado no host (sudo apt install apache2), troque o MPM com a2dismod e a2enmod, reinicie o serviço e confirme com sudo a2query -M.
6. Limpe: docker rm -f apache-event apache-prefork. As imagens apache-event e apache-prefork continuam no computador e podem ser reaproveitadas na Etapa 05.

Etapa 05 event loop

Nginx e a arquitetura orientada a eventos

O problema

O conceito

A diferença central é a arquitetura assíncrona e orientada a eventos, em vez de um processo ou thread dedicado por conexão.

Um processo master lê a configuração e gerencia os processos worker, que são os que atendem conexões (o master não atende requisições). Cada worker roda um event loop: um laço que espera eventos (dado novo em uma conexão, resposta de um backend, escrita liberada), trata o que ficou pronto e volta ao laço. Quando uma operação de entrada e saída precisaria esperar (ler do disco, aguardar um backend), o worker não fica parado: ele registra o interesse naquele evento e passa a tratar outra conexão. Isso é I/O não bloqueante. Quando o evento fica pronto, o worker é notificado e retoma exatamente de onde parou.

No Linux, a notificação de quais conexões têm dado novo vem de um mecanismo do kernel, o epoll, que evita varrer todas as conexões a cada ciclo. O Nginx escolhe o método mais eficiente disponível sozinho, então a diretiva use epoll; costuma ser opcional no Linux.

O resultado prático é que o número de processos fica estável e pequeno (em geral um worker por núcleo de CPU), enquanto o número de conexões cresce. O limite deixa de ser "uma thread por conexão" e passa a ser CPU, memória e descritores de arquivo. Benefícios: menor consumo de memória, maior vazão, boa latência e desempenho excelente como proxy reverso e balanceador, inclusive na frente do próprio Apache. Cuidado com a conta de capacidade: worker_processes vezes worker_connections é o teto de conexões simultâneas, mas, quando o Nginx atua como proxy, cada requisição de cliente usa duas conexões (uma com o cliente e uma com o backend), então o número de clientes simultâneos é cerca de metade desse teto. Além disso, worker_connections não deve passar do limite de arquivos abertos do processo (ajustável com worker_rlimit_nofile).

Os conceitos-chave

Poucos processos, muitas conexões

# nginx.conf (trecho principal)
worker_processes auto;          # um processo worker por núcleo de CPU disponível
 
events {
    worker_connections 1024;    # cada worker aceita até 1024 conexões simultâneas
    use epoll;                  # opcional no Linux: o Nginx já escolhe o método mais eficiente
}

Comandos essenciais desta etapa

Mão na massa

1. Suba o Nginx de teste com docker run -d --name nginx-lab -p 8080:80 nginx:stable e rode docker exec nginx-lab nginx -T | grep -E 'worker_processes|worker_connections'. Observe worker_processes auto e worker_connections 1024.
2. Rode docker top nginx-lab e conte os processos worker. Compare com nproc: o número de workers costuma ser igual ou próximo ao de núcleos (o container enxerga os núcleos do host).
3. Rode ab -n 50000 -c 200 http://localhost:8080/ e, durante o teste, repita docker top nginx-lab em outro terminal. Observe que o número de processos não muda, mesmo com 200 conexões simultâneas.
4. O container apache-prefork foi apagado no fim da Etapa 04, então recrie-o com docker run -d --name apache-prefork -p 8082:80 apache-prefork (a imagem continua no computador; se você a removeu, reconstrua-a com docker build --build-arg MPM=prefork -t apache-prefork . na pasta etapa04/). Repita a carga em http://localhost:8082/ e rode docker top apache-prefork | grep -c httpd. Observe o número de processos crescer junto com a carga, ao contrário do que aconteceu com o Nginx.
5. Compare o consumo de memória com docker stats --no-stream nginx-lab apache-prefork.
6. Opcional, em um Nginx instalado no host (sudo apt install nginx): rode nginx -t e ps aux | grep '[n]ginx' e repita os passos 2 e 3 contra http://localhost/.
7. Limpe: docker rm -f nginx-lab apache-prefork.

Etapa 06 L4 + L7 + algoritmos

Balanceamento de carga: L4, L7 e algoritmos do Nginx

O problema

O conceito

Um balanceador de carga distribui as requisições entre os backends. A decisão pode usar pouca ou muita informação, e isso define a camada em que ele trabalha.

• L4 (transporte): decide com IP e porta, sobre TCP ou UDP. É rápido, serve a protocolos genéricos (bancos de dados, por exemplo), mas não consegue rotear por URL, host ou cabeçalho porque nem lê o HTTP. No Nginx, isso é feito pelo módulo stream.
• L7 (aplicação): entende HTTP e HTTPS. Pode terminar TLS, aplicar cache e compressão e rotear por host, path, cabeçalho ou cookie, com uma sobrecarga um pouco maior.

No Nginx, os algoritmos do bloco upstream são:

• Round Robin: o padrão; distribui em sequência. O parâmetro weight altera a proporção para servidores com capacidades diferentes (weight=2 recebe o dobro).
• least_conn: envia a requisição ao backend com menos conexões ativas. É adequado quando as requisições têm durações muito diferentes.
• ip_hash: o mesmo cliente tende a cair sempre no mesmo backend, a partir do endereço IPv4 (usa os três primeiros octetos) ou IPv6 (inteiro). Ajuda aplicações com estado local, mas concentra muitos usuários atrás do mesmo NAT ou VPN em um backend só.

Afinidade como a do ip_hash dificulta a redistribuição e a escalabilidade. Sempre que possível, prefira aplicações stateless: sessão em Redis ou token assinado (como JWT) permitem que qualquer backend responda a qualquer requisição. Duas diretivas completam o quadro: keepalive reaproveita conexões entre o Nginx e os backends (exige proxy_http_version 1.1 e proxy_set_header Connection ""), e os timeouts proxy_connect_timeout, proxy_send_timeout e proxy_read_timeout limitam cada fase da conversa com o upstream.

Os conceitos-chave

Um upstream com decisão explícita

 # compose.yaml
x-backend: &backend                        # molde reutilizado pelos dois backends
  image: python:3.12-alpine
  command: ["python", "/app/backend.py"]   # executa o backend didático
  volumes:
    - ./backend.py:/app/backend.py:ro      # monta o script somente leitura
 
services:
  api-1:
    <<: *backend                           # herda o molde acima
    environment:
      NAME: api-1                          # nome devolvido nas respostas
      DELAY: "${API1_DELAY:-0}"            # atraso configurável por variável de ambiente (padrão 0)
  api-2:
    <<: *backend
    environment:
      NAME: api-2
  nginx:                                   # balanceador L7 (HTTP)
    image: nginx:stable
    ports:
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - api-1
      - api-2
  nginx-l4:                                # balanceador L4 (TCP puro)
    image: nginx:stable
    ports:
      - "9090:9090"
    volumes:
      - ./nginx-l4.conf:/etc/nginx/nginx.conf:ro   # substitui o nginx.conf inteiro
    depends_on:
      - api-1
      - api-2

Comandos essenciais desta etapa

Mão na massa

1. Crie etapa06/ com backend.py, compose.yaml, nginx.conf e nginx-l4.conf, e rode docker compose up -d.
2. Com Round Robin, rode for i in $(seq 1 30); do curl -s http://localhost:8080/api/; done | sort | uniq -c. Observe uma divisão de 15 para 15.
3. Acrescente weight=2 a api-1, valide e recarregue (docker compose exec nginx nginx -t e depois nginx -s reload) e repita a contagem. Observe cerca de 20 para api-1 e 10 para api-2. Se a divisão não mudar, o container pode estar vendo a versão antiga do arquivo (editores e sed -i substituem o arquivo montado por um novo); rode docker compose restart nginx e repita a contagem.
4. Remova o peso, ative least_conn;, recarregue e rode API1_DELAY=1 docker compose up -d api-1. Recarregue o Nginx de novo (o IP de api-1 pode ter mudado) e rode seq 1 20 | xargs -P 10 -I{} curl -s http://localhost:8080/api/ | sort | uniq -c. Observe que o backend lento recebe menos trabalho novo (por exemplo, 5 contra 15; os números variam).
5. Troque least_conn; por ip_hash;, recarregue e repita a contagem. Observe que todas as respostas vêm do mesmo backend. Explique por quê: pelo mapeamento de portas do Docker, todas as requisições chegam ao Nginx com o mesmo IP de origem (o do gateway da rede). É o efeito de vários usuários atrás de um mesmo NAT.
6. Compare L4 e L7: rode curl -s http://localhost:8080/ e curl -s http://localhost:9090/. Observe que só o L7 responde sozinho por uma rota, porque só ele lê o path.
7. Meça com ab -n 1000 -c 20 -k http://localhost:8080/api/ e anote Requests per second e o tempo médio por requisição. Depois descreva em uma frase como Redis ou JWT eliminariam a necessidade do ip_hash.
8. Limpe: docker compose down.

Etapa 07 health checks + 502/504

Health checks, failover, métricas e diagnóstico

O problema

O conceito

Health checks. No Nginx Open Source, os parâmetros max_fails e fail_timeout implementam verificação passiva: falhas observadas em requisições reais retiram temporariamente o backend da rotação. Com max_fails=3 fail_timeout=10s, três falhas dentro de 10 segundos tiram o servidor da rotação por 10 segundos; depois disso o Nginx volta a tentá-lo e o recoloca se a chamada funcionar. A verificação passiva depende de tráfego real: sem requisições, não há falhas para observar. Verificações ativas (sondas periódicas independentes do tráfego, com a diretiva health_check) são recurso do Nginx Plus, a edição comercial, ou de módulos externos. Um detalhe: em um grupo com um único servidor, max_fails e fail_timeout são ignorados.

Failover e backup. Quando uma tentativa falha por erro de conexão ou timeout, o Nginx tenta o próximo servidor do grupo (comportamento padrão de proxy_next_upstream), então o cliente nem sempre percebe a falha. O parâmetro backup reserva um servidor que só recebe requisições quando todos os primários estão indisponíveis (não pode ser combinado com ip_hash, hash ou random).

Métricas. O módulo stub_status expõe conexões ativas, total de conexões e requisições aceitas, e os estados de leitura, escrita e espera. O Apache Bench (ab) gera carga controlada. Leia em conjunto requisições por segundo, latência, percentis (o p95 mostra a experiência dos mais lentos, que a média esconde), CPU e logs, para saber se o limite está no proxy, no backend ou em uma dependência.

Diagnóstico de 502 e 504. O erro 502 Bad Gateway indica que o Nginx não obteve uma resposta válida do upstream: conexão recusada, conexão encerrada ou resposta inválida. O erro 504 Gateway Timeout indica que a conexão foi feita, mas o backend não respondeu dentro do proxy_read_timeout. A investigação segue o caminho da requisição: cliente, Nginx, backend, dependências. Aumentar um timeout sem investigar pode apenas esconder lentidão.

Os conceitos-chave

Backends primários, reserva, painel de estado e erros provocados

 # compose.yaml
x-backend: &backend
  image: python:3.12-alpine
  command: ["python", "/app/backend.py"]
  volumes:
    - ./backend.py:/app/backend.py:ro
  networks: [lab]
 
services:
  api-1:
    <<: *backend
    environment: { NAME: api-1 }
  api-2:
    <<: *backend
    environment: { NAME: api-2 }
  api-backup:
    <<: *backend
    environment: { NAME: api-backup }      # só responde quando os primários caem
  nginx:
    image: nginx:stable
    ports:
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    networks: [lab]
    depends_on: [api-1, api-2, api-backup]
  tools:                                   # container só para rodar curl dentro da rede
    image: curlimages/curl
    entrypoint: ["tail", "-f", "/dev/null"]
    networks: [lab]
 
networks:
  lab:
    ipam:
      config:
        - subnet: 172.30.0.0/24            # sub-rede fixa, usada na regra allow do stub_status

Comandos essenciais desta etapa

Mão na massa

1. Crie etapa07/ com backend.py, compose.yaml e nginx.conf, e rode docker compose up -d. Confirme com for i in $(seq 1 6); do curl -s http://localhost:8080/; done que as respostas alternam entre api-1 e api-2 e nunca vêm de api-backup.
2. Rode ab -n 2000 -c 50 -k http://localhost:8080/ e anote Requests per second e a linha 95% da tabela de percentis.
3. Em um terminal, rode for i in $(seq 1 60); do curl -s -o /dev/null -w '%{http_code} ' http://localhost:8080/; sleep 0.5; done. Em outro, rode docker compose stop api-1. Observe que todos os códigos seguem 200, mas que as primeiras requisições que caírem em api-1 podem demorar alguns segundos cada (a tentativa de conexão a um IP que sumiu da rede não é recusada na hora; os tempos variam). Confirme em docker compose logs nginx --tail 30 as linhas com dois endereços de upstream (o primeiro falhou) e, depois das três falhas do max_fails, só o endereço de api-2 durante a janela de 10 segundos.
4. Rode docker compose stop api-2 e curl -s http://localhost:8080/. Observe api-backup recebeu /: com os primários fora, a reserva assume, e a primeira chamada pode demorar alguns segundos pelo mesmo motivo do passo anterior.
5. Rode docker compose start api-1 api-2, recarregue o Nginx (docker compose exec nginx nginx -s reload) e repita o laço do passo 1. Observe o retorno dos primários e o fim do uso do backup.
6. Com api-1 no ar, provoque os dois erros: curl -s -o /dev/null -w '%{http_code} em %{time_total}s\n' http://localhost:8080/quebrado e o mesmo para /lento. Observe 502 imediato e 504 em cerca de 2 segundos, e procure a causa com docker compose logs nginx | grep -E 'refused|timed out|unreachable|No route'.
7. Consulte docker compose exec tools curl -s http://nginx/nginx_status durante um ab e observe Active connections subindo.
8. Limpe: docker compose down.

Etapa 08 host + path

Ingress no Kubernetes

O problema

O conceito

O Ingress centraliza regras HTTP e HTTPS de roteamento sob um único ponto de entrada. Ele é só uma declaração: um objeto da API que diz "o host X e o caminho Y vão para o Service Z". Quem executa essas regras é o Ingress Controller (ingress-nginx, Traefik, entre outros), que observa os objetos Ingress e configura o proxy real que recebe o tráfego. Sem Controller, criar o objeto Ingress não muda o tráfego.

• Roteamento por host separa domínios (api.exemplo.com e app.exemplo.com). Roteamento por path separa caminhos no mesmo domínio (/api e /).
• pathType: Prefix aceita o caminho e seus subcaminhos; Exact exige igualdade completa; ImplementationSpecific deixa a interpretação para o Controller (é o tipo usado quando o caminho tem expressão regular no ingress-nginx).
• Annotations aplicam recursos específicos do Controller, como a reescrita de URL. Elas valem para o Ingress inteiro, e não para um path só. ingressClassName escolhe qual Controller atende a regra quando há mais de um no cluster.
• O Service de destino continua sendo um ClusterIP estável para os Pods selecionados. Se o Service não tem endpoints (Pods prontos), o Ingress não tem para onde encaminhar.

O Ingress segue estável, mas sua API está congelada (a evolução acontece na Gateway API, gateway.networking.k8s.io, que o Kubernetes recomenda para arquiteturas novas). O ingress-nginx, o Controller usado neste laboratório, foi aposentado pelo projeto Kubernetes: a aposentadoria foi anunciada em novembro de 2025 e a manutenção terminou em março de 2026. Ele continua útil para estudar o conceito no Minikube, mas, para produção, prefira um Controller mantido ou a Gateway API. Isso não se aplica ao NGINX Ingress Controller mantido pela F5, que é outro projeto.

Roteamento por path: o mesmo endereço de entrada, e o caminho da URL decide o Service. É o caso do /api deste laboratório.

Roteamento por host: o cabeçalho Host da requisição decide o Service. Nos dois casos, o Ingress é só a regra; quem a executa é o Ingress Controller.

Os conceitos-chave

Um domínio, dois Services

 # apps.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api                                # backend "api"
spec:
  replicas: 2                              # duas réplicas
  selector:
    matchLabels:
      app: api                             # seleciona os Pods pelo label
  template:
    metadata:
      labels:
        app: api                           # precisa casar com o selector
    spec:
      containers:
        - name: api
          image: python:3.12-alpine        # imagem com Python
          command: ["python", "/app/backend.py"]   # executa o backend didático
          env:
            - name: NAME
              value: api                   # nome devolvido nas respostas
          ports:
            - containerPort: 3000          # porta do backend
          readinessProbe:                  # só recebe tráfego quando responde
            httpGet:
              path: /healthz
              port: 3000
          volumeMounts:
            - name: code
              mountPath: /app              # o script aparece em /app/backend.py
      volumes:
        - name: code
          configMap:
            name: backend-py               # ConfigMap criado a partir do backend.py
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api                               # encaminha aos Pods com este label
  ports:
    - port: 80                             # porta do Service
      targetPort: 3000                     # porta do container
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web                                # mesmo molde, outro nome
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: python:3.12-alpine
          command: ["python", "/app/backend.py"]
          env:
            - name: NAME
              value: web                   # único campo que muda
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000
          volumeMounts:
            - name: code
              mountPath: /app
      volumes:
        - name: code
          configMap:
            name: backend-py
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 3000

Comandos essenciais desta etapa

Mão na massa

1. Suba o cluster e o Controller: minikube start -p lab, minikube addons enable ingress -p lab e o kubectl wait acima. Observe o Pod ingress-nginx-controller em Running e confirme com kubectl get ingressclass a classe nginx.
2. Crie o ConfigMap (kubectl create configmap backend-py --from-file=backend.py) e aplique apps.yaml e ingress.yaml. Confirme os Pods com kubectl get pods e os endpoints com kubectl get endpointslices.
3. Abra o port-forward em outro terminal (kubectl port-forward -n ingress-nginx svc/ingress-nginx-controller 8080:80, que fica em primeiro plano) e, no terminal original, rode curl -s -H 'Host: pitstop.local' http://127.0.0.1:8080/api/health e o mesmo para /. Observe api recebeu /health (o prefixo /api foi removido pelo rewrite) e web recebeu /.
4. Teste /status e /status/extra com o mesmo cabeçalho Host. Observe que Exact casa apenas o caminho exato e que o subcaminho cai na regra / do frontend.
5. Rode o kubectl exec ... cat /etc/nginx/nginx.conf | grep -n pitstop.local e observe que o Controller transformou os objetos Ingress em blocos server de um Nginx de verdade.
6. Provoque uma falha: kubectl scale deployment api --replicas=0 e repita /api/health. Observe a resposta 503 do Controller (Service sem endpoints) e restaure com --replicas=2.
7. Encerre o port-forward (Ctrl+C no outro terminal) e apague só as regras: kubectl delete -f ingress.yaml. Mantenha o perfil lab, o apps.yaml aplicado e o ConfigMap backend-py, porque a Etapa 09 usa o Service web. A limpeza completa fica no fim da Etapa 09.

Etapa 09 cert-manager

TLS e cert-manager

O problema

O conceito

O TLS oferece confidencialidade, integridade e autenticação do servidor. O cert-manager estende a API do Kubernetes com recursos declarativos para emitir, armazenar e renovar certificados automaticamente.

• Issuer emite certificados dentro de um namespace; ClusterIssuer atende o cluster inteiro. Eles definem a autoridade emissora (autoassinada, uma CA interna ou o ACME).
• Certificate declara os nomes DNS, a duração e o Secret que receberá a chave privada e o certificado.
• Com o ACME (protocolo usado pelo Let's Encrypt), um desafio HTTP-01 (publicar um token em um caminho do site) ou DNS-01 (publicar um registro TXT) prova o controle do domínio. O cert-manager acompanha a validade e renova antes do vencimento (por padrão, a duração é de 90 dias e a renovação começa quando falta um terço dela).
• O Ingress referencia o Secret TLS. Com a annotation cert-manager.io/cluster-issuer, o cert-manager cria o Certificate sozinho a partir do bloco tls do Ingress.
• Na conexão, o cliente informa o nome do site desejado logo no início do handshake (SNI), e é por isso que um mesmo Controller consegue apresentar o certificado certo para cada host.

A chave privada permanece no cluster e não deve ser gravada em manifestos nem em repositórios. Um Secret é codificado em base64, e isso não é criptografia: a proteção vem do controle de acesso (RBAC) sobre os Secrets.

O desafio ACME exige um domínio público alcançável pela autoridade, então o Let's Encrypt só pode ser praticado com um domínio real. O laboratório usa um ClusterIssuer autoassinado, que exercita o mesmo caminho (Ingress, Certificate, Secret, renovação) sem depender de internet pública. Ao usar o Let's Encrypt de verdade, comece pelo ambiente de staging para evitar os limites de emissão.

Os conceitos-chave

Ingress integrado ao cert-manager

 # clusterissuer-selfsigned.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned                         # nome citado nas annotations
spec:
  selfSigned: {}                           # emite certificados autoassinados (só para laboratório)

Comandos essenciais desta etapa

Mão na massa

1. No cluster lab, confirme que o apps.yaml e o ConfigMap backend-py da Etapa 08 continuam aplicados (kubectl get svc web). Se você os apagou, recrie com kubectl create configmap backend-py --from-file=backend.py e kubectl apply -f apps.yaml, usando os arquivos da pasta etapa08/. Instale o cert-manager com os três comandos helm do exemplo e confirme com kubectl get pods -n cert-manager os três Pods Running.
2. Aplique clusterissuer-selfsigned.yaml e ingress-tls.yaml. Rode kubectl get certificate -w e observe READY passar de False para True. Confirme o Secret com kubectl get secret pitstop-tls e observe o tipo kubernetes.io/tls.
3. Em outro terminal, abra o port-forward da porta 443 (kubectl port-forward -n ingress-nginx svc/ingress-nginx-controller 8443:443). No terminal original, rode primeiro curl -sk --resolve secure.pitstop.local:8443:127.0.0.1 https://secure.pitstop.local:8443/ e observe a resposta web recebeu /. Depois rode o mesmo comando com -v e 2>&1 | grep -iE 'subject:|issuer:' e observe que o certificado entregue já não é o Kubernetes Ingress Controller Fake Certificate do Controller (o certificado do cert-manager não define nome comum, então subject e issuer podem vir vazios; o nome do site aparece na extensão subjectAltName, que o passo 4 mostra).
4. Inspecione o certificado do Secret com o openssl do exemplo e observe a linha issuer=, o nome DNS em subjectAltName e a validade.
5. Aplique certificate-renova.yaml, espere cerca de 6 minutos e rode kubectl describe certificate renova-teste. Observe um evento de renovação e Revision: 2 no status.
6. Demonstre que base64 não é criptografia: kubectl get secret pitstop-tls -o jsonpath='{.data.tls\.key}' | base64 -d | head -n 1 mostra o início da chave privada em texto. Explique quais controles de acesso (RBAC) protegem o Secret.
7. Limpe tudo da Etapa 08 e desta: encerre o port-forward (Ctrl+C), rode kubectl delete -f ingress-tls.yaml -f certificate-renova.yaml, kubectl delete secret pitstop-tls renova-teste-tls, kubectl delete -f ../etapa08/apps.yaml, kubectl delete configmap backend-py e, por fim, minikube delete -p lab. Dois clusters ligados ao mesmo tempo pesam, e a Etapa 10 sobe um perfil novo (mesh) com 4 CPUs e 8 GB.

Etapa 10 istio + sidecars

Service Mesh e a arquitetura do Istio

O problema

O conceito

No modelo sidecar do Istio, um proxy Envoy é injetado em cada Pod, ao lado do container da aplicação, e intercepta o tráfego de entrada e de saída. A aplicação segue focada na regra de negócio.

• O Data Plane é formado pelos proxies Envoy: eles processam as requisições e aplicam roteamento, resiliência, segurança e telemetria.
• O Control Plane é o Istiod: observa serviços e recursos do Istio, traduz as regras de alto nível para a configuração do Envoy, distribui descoberta de serviços e emite as identidades (certificados) das cargas de trabalho.
• A injeção é habilitada por namespace (istio-injection=enabled) e acontece na criação do Pod: Pods já existentes só ganham o sidecar quando são recriados (por exemplo, com kubectl rollout restart).

A abstração tem custo: cada sidecar consome CPU e memória, adiciona latência por salto e a malha é uma plataforma adicional para atualizar e diagnosticar. Para poucos serviços, o benefício pode não compensar. O Istio também oferece o modo ambient, sem sidecars; este guia usa sidecars porque o caminho do tráfego fica visível.

Os conceitos-chave

Instalação, injeção e validação do sidecar

 # app.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: web                                # identidade do cliente (usada na Etapa 12)
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
      version: v1
  template:
    metadata:
      labels:
        app: api                           # label recomendado pelo Istio
        version: v1                        # versão: base dos subsets da Etapa 11
    spec:
      containers:
        - name: api
          image: python:3.12-alpine
          command: ["python", "/app/backend.py"]
          env:
            - name: NAME
              value: api-v1                # nome devolvido nas respostas
          ports:
            - containerPort: 3000
          volumeMounts:
            - name: code
              mountPath: /app
      volumes:
        - name: code
          configMap:
            name: backend-py
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api                               # seleciona todas as versões da api
  ports:
    - name: http                           # o nome http informa o protocolo à malha
      port: 80
      targetPort: 3000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      serviceAccountName: web              # o cliente chama a api com a identidade "web"
      containers:
        - name: web
          image: curlimages/curl
          command: ["sleep", "86400"]      # fica parado; usaremos kubectl exec para chamar a api

Comandos essenciais desta etapa

Mão na massa

1. Entre em etapa10/ e rode os três primeiros comandos do exemplo (download, cd istio-* && export PATH=$PWD/bin:$PATH && cd - e minikube start). Confirme com pwd que você voltou para etapa10/, instale o Istio com istioctl install --set profile=demo -y e observe Installation complete. Rode kubectl get pods -n istio-system para ver o istiod e os gateways em Running.
2. Ainda em etapa10/, crie o namespace demo, o ConfigMap e aplique app.yaml. Observe READY 1/1 nos dois Pods, sem sidecar.
3. Habilite a injeção, rode kubectl rollout restart deployment -n demo e observe READY 2/2. Rode kubectl get pod -n demo -l app=api -o jsonpath='{.items[0].spec.containers[*].name}' e observe os containers api e istio-proxy.
4. Rode istioctl proxy-status e observe os proxies de api-v1 e web em SYNCED. Rode também o comando de recursos reservados e registre o custo do proxy em CPU e memória.
5. Teste a chamada interna: kubectl exec -n demo deploy/web -c web -- curl -s http://api/. Observe api-v1 recebeu /, agora passando por dois proxies.
6. Crie o namespace legacy sem o label (kubectl create namespace legacy), copie o ConfigMap (kubectl create configmap backend-py --from-file=backend.py -n legacy) e aplique app.yaml com -n legacy. Observe READY 1/1 e explique onde as políticas da malha deixam de atuar: em Pods sem sidecar, nenhuma política do Istio é aplicada.
7. Mantenha o cluster mesh e o namespace demo para as Etapas 11 e 12. Limpe o legacy com kubectl delete namespace legacy.

Etapa 11 canary + mirror

VirtualService, DestinationRule e deploy gradual

O problema

O conceito

No Istio, duas regras trabalham juntas. A DestinationRule nomeia grupos de Pods (subsets, selecionados por labels como version: v1) e define políticas de conexão para o destino. O VirtualService decide como cada chamada percorre esses grupos: pesos, condições por header ou path, retries, timeouts, espelhamento e falhas simuladas. As regras são aplicadas pelo sidecar do cliente, então só valem para chamadas que passam por um proxy da malha.

Três formas de testar uma versão:

• Canary por peso envia uma pequena porcentagem do tráfego real para a versão nova e a amplia gradualmente. Os pesos de uma rota precisam somar 100.
• A/B testing usa características da requisição (header, cookie, path) para segmentar usuários, por exemplo enviando sempre um usuário de teste para a v2.
• Traffic mirroring duplica as chamadas para a versão nova e descarta a resposta dela: o cliente continua recebendo a v1, e a v2 recebe carga real sem risco para o usuário.

Resiliência no mesmo recurso: retries ajudam em falhas transitórias, mas multiplicam a carga se não forem limitados. attempts é o número de novas tentativas depois da primeira, perTryTimeout limita cada tentativa e o timeout da rota limita o tempo total, que precisa comportar todas as tentativas. Circuit breaking (na DestinationRule, com outlierDetection) ejeta endpoints que falham seguidamente, para evitar cascatas. A injeção de falhas (fault, com atraso ou aborto) permite testar a reação das aplicações.

Peso é o mecanismo de entrega, não o critério de sucesso: a decisão de ampliar o canário vem de taxa de erro, latência e métricas de negócio.

Os conceitos-chave

Noventa por cento v1, dez por cento v2

 # api-v2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
      version: v2
  template:
    metadata:
      labels:
        app: api                           # o Service "api" seleciona este Pod também
        version: v2                        # distingue a v2 da v1
    spec:
      containers:
        - name: api
          image: python:3.12-alpine
          command: ["python", "/app/backend.py"]
          env:
            - name: NAME
              value: api-v2
          ports:
            - containerPort: 3000
          volumeMounts:
            - name: code
              mountPath: /app
      volumes:
        - name: code
          configMap:
            name: backend-py

Comandos essenciais desta etapa

Mão na massa

1. Aplique api-v2.yaml e confirme READY 2/2 nos dois Pods api. Rode kubectl get endpointslices -n demo -l kubernetes.io/service-name=api e observe dois endpoints: o Service seleciona as duas versões.
2. Sem nenhum VirtualService, conte 100 respostas com o laço do exemplo. Observe uma divisão perto de 50 e 50, o comportamento do Service puro.
3. Aplique canary.yaml, rode istioctl analyze -n demo e conte 100 respostas de novo. Observe cerca de 90 para a v1 e 10 para a v2 (a divisão é estatística, então os números variam).
4. Envie curl -s -H 'x-usuario: teste' http://api/ pelo cliente web várias vezes. Observe api-v2 em todas as respostas, e o mesmo comando sem o header voltando à divisão 90/10.
5. Aplique mirror.yaml, envie 10 chamadas pelo cliente e observe que todas as respostas são api-v1. Em seguida rode kubectl logs -n demo deploy/api-v2 -c api --tail 12 e observe as 10 requisições chegando à v2, mesmo sem o cliente receber a resposta dela.
6. Pratique o rollback: kubectl delete virtualservice api -n demo e conte 100 respostas. Observe a volta à divisão do Service. Se algo parecer errado, rode istioctl analyze antes de atribuir o desvio ao proxy.
7. Mantenha o cluster para a Etapa 12 e deixe-o sem VirtualService, como após o rollback do passo 6. Se você reaplicar canary.yaml ou mirror.yaml, as respostas da Etapa 12 passam a vir também da v2 e os contadores lidos só no api-v1 ficam diferentes dos mostrados lá.

Etapa 12 identidade + métricas

mTLS, autorização e observabilidade na malha

O problema

O conceito

O Istio autentica as cargas de trabalho com certificados de curta duração emitidos pelo Istiod, criptografa o tráfego entre sidecars com mTLS (as duas pontas apresentam identidade) e autoriza chamadas pela identidade, que é derivada da ServiceAccount do Pod (cluster.local/ns/demo/sa/web).

• PeerAuthentication controla o mTLS. PERMISSIVE aceita tráfego com e sem mTLS e ajuda nas migrações; STRICT rejeita tráfego sem identidade da malha. A política com nome default em um namespace vale para ele todo.
• AuthorizationPolicy responde o que uma identidade autenticada pode fazer, por origem, método e path. Quando existe uma política ALLOW para uma carga de trabalho, toda requisição que não casa com nenhuma regra é negada (HTTP 403).
• Observabilidade: o Envoy registra volume, código de resposta e duração de cada chamada. O Prometheus armazena métricas, o Grafana apresenta painéis, o Jaeger reconstrói traces e o Kiali exibe a topologia, os erros e o estado do mTLS.
• Tracing distribuído: o proxy cria e lê headers de rastreamento, mas a aplicação precisa propagá-los nas chamadas seguintes (x-request-id, x-b3-traceid, x-b3-spanid, x-b3-parentspanid, x-b3-sampled, x-b3-flags, b3 e, para W3C, traceparent e tracestate). Sem propagação, o trace quebra mesmo com sidecars saudáveis. Coletar traces exige configurar um provedor de tracing na malha, o que fica fora do laboratório; aqui você verifica os headers e as métricas.

Autenticação responde quem é; autorização responde o que pode fazer. O mTLS não substitui uma política de acesso.

Os conceitos-chave

MTLS estrito, política por identidade e métricas

 # mtls-strict.yaml
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default                            # política do namespace inteiro
  namespace: demo
spec:
  mtls:
    mode: STRICT                           # rejeita tráfego sem mTLS

Comandos essenciais desta etapa

Mão na massa

1. Com o cluster mesh, crie o namespace legacy e um Pod de teste sem sidecar (comandos do exemplo). Chame a api e observe que, em PERMISSIVE, a chamada sem mTLS funciona.
2. Aplique somente a PeerAuthentication: kubectl apply -f mtls-strict.yaml. Repita a chamada do legacy e observe a recusa. Repita a chamada pelo web (que tem sidecar) e observe que continua funcionando.
3. Aplique outro.yaml (ele já declara namespace: demo) e confirme que o Pod outro tem READY 2/2. Antes de aplicar a política, faça kubectl exec -n demo deploy/outro -c outro -- curl -s -o /dev/null -w '%{http_code}\n' http://api/api/ping e observe 200, porque ainda não há regra de autorização. Aplique authz-api.yaml, rode as quatro chamadas do item 4 do exemplo e observe 200 apenas para GET /api/ping vindo do web, e 403 para outro path, outro método e outra identidade (o outro).
4. Rode a chamada ao /api/headers e observe que o proxy acrescentou X-Request-Id e X-Forwarded-Client-Cert com a identidade do chamador. Explique por que, para um trace completo, a aplicação precisa copiar esses headers para as chamadas que ela mesma fizer.
5. Rode istioctl proxy-config secret deploy/api-v1 -n demo e leia as métricas do Envoy no sidecar. Observe contadores istio_requests_total separados por código de resposta, inclusive os 403 que você provocou. Como a api-v2 também atende ao Service, repita a leitura em deploy/api-v2 e some os contadores se as chamadas tiverem ido para as duas.
6. Opcional: instale Prometheus e Kiali (samples/addons dentro da pasta istio-* em etapa10/), gere tráfego com um laço de curl e abra istioctl dashboard kiali. Observe o grafo web para api e o ícone de cadeado do mTLS.
7. Limpe tudo ao fim das Etapas 10 a 12: minikube delete -p mesh.

Etapa 13 slo + spof + vrrp

Alta disponibilidade: SLA, SLO, SPOF e redundância

O problema

O conceito

• SLA é a promessa externa ao cliente, possivelmente com penalidade. SLO é a meta interna usada pela engenharia, em geral mais rigorosa que o SLA. O orçamento de erro é o que o SLO permite de falha no período (100% menos o SLO). Uma meta de 99,9% em 30 dias permite cerca de 43 minutos de indisponibilidade.
• Um SPOF (single point of failure) é qualquer servidor, balanceador, link, banco ou local cuja falha interrompe todo o serviço. Componentes em série multiplicam as disponibilidades (dois componentes de 99,9% dão cerca de 99,8%), enquanto réplicas independentes em paralelo as melhoram (duas de 99% dão cerca de 99,99%, se as falhas forem independentes). SPOFs devem ser removidos, reduzidos ou aceitos de forma explícita.
• Ativo-passivo mantém uma instância de reserva e exige failover; simplifica a consistência. Ativo-ativo usa todos os nós ao mesmo tempo e redistribui a carga quando um falha, mas exige aplicações stateless ou sincronização correta do estado.
• Keepalived com VRRP move um IP virtual (VIP) entre dois balanceadores: o nó de maior prioridade com saúde confirmada responde pelo VIP, e se ele falhar o outro assume. A configuração dos dois nós precisa permanecer sincronizada por automação (como Ansible) ou por mecanismos declarativos. Em muitas redes de nuvem o VRRP não funciona como em uma rede local, e o provedor oferece balanceadores gerenciados ou reatribuição de IP; confira a documentação do seu provedor.
• Os health checks devem verificar a função real (por exemplo, uma resposta HTTP válida), não apenas a existência do processo.
• Chaos Engineering formula uma hipótese, injeta uma falha controlada e mede a reação, com critérios claros para abortar. Não é falha aleatória em produção.
• HA reduz interrupções locais; Disaster Recovery (DR) recupera o serviço depois de eventos amplos, como a perda de uma zona ou região. O RTO é o tempo máximo aceito para recuperar e o RPO é a perda máxima de dados aceita, medida em tempo.

Antes da falha: lb1 tem a maior prioridade e o check_nginx em dia, então responde pelo IP virtual.

Depois de nginx -s stop em lb1: duas falhas seguidas do check_nginx tiram lb1 do posto, lb2 assume o VIP, e o cliente continua usando o mesmo endereço.

Os conceitos-chave

Keepalived protegendo o balanceador

# Dockerfile
FROM nginx:stable
# keepalived faz o VRRP; curl e iproute2 servem ao check de saúde e à inspeção do IP
RUN apt-get update \
 && apt-get install -y --no-install-recommends keepalived curl iproute2 \
 && rm -rf /var/lib/apt/lists/*

Comandos essenciais desta etapa

Mão na massa

1. Desenhe em papel o caminho completo de uma requisição (cliente, DNS, balanceador, aplicação, banco) e marque cada componente sem redundância. Cada marca é um SPOF.
2. Escolha um SLO de disponibilidade para o serviço e calcule o downtime mensal permitido com o comando awk do exemplo. Calcule também a disponibilidade de dois componentes de 99,9% em série.
3. Crie etapa13/ com os arquivos do exemplo e rode docker compose up -d --build. Descubra qual nó tem o VIP e observe atendido por lb1 ao chamar o IP virtual.
4. Em um terminal, rode o laço do cliente. Em outro, pare o Nginx do lb1 com docker compose exec lb1 nginx -s stop. Observe respostas de lb1, uma ou duas falhas e depois respostas de lb2, e meça quantos segundos passaram sem resposta.
5. Rode docker compose exec lb1 nginx e observe o VIP voltar ao lb1 (prioridade maior) após os checks de saúde passarem. Registre também em docker compose logs as transições de estado.
6. Escreva uma hipótese de Chaos Engineering (por exemplo, "se o balanceador ativo cair, o cliente perde no máximo 5 segundos de resposta") com um critério de aborto (por exemplo, "se o VIP não migrar em 30 segundos, restaurar o nó e encerrar o experimento"). Compare o resultado do passo 4 com a hipótese.
7. Limpe: docker compose down.

Etapa 14 modsecurity + rate limit

WAF, rate limiting e defesa em camadas

O problema

O conceito

Firewalls de camadas 3 e 4 bloqueiam redes e portas, mas não inspecionam a camada de aplicação. Um WAF (Web Application Firewall) inspeciona o conteúdo HTTP. O ModSecurity (com a biblioteca libModSecurity e o conector para o Nginx) é o motor que aplica as regras, e o OWASP Core Rule Set (CRS) é uma base de regras mantida pela comunidade contra padrões como SQL Injection e XSS.

• O WAF avalia as regras e acumula uma pontuação de anomalia; ao passar de um limite, bloqueia (por padrão no CRS, o limite de entrada é 5). Pode apenas registrar (DetectionOnly) ou bloquear (On). Comece em modo de detecção para ajustar falsos positivos antes de interromper usuários legítimos. O CRS também tem níveis de paranoia (de 1 a 4): níveis maiores detectam mais e geram mais falsos positivos.
• TLS 1.2 ou 1.3, HSTS e headers seguros protegem o canal e o navegador. O HSTS manda o navegador usar só HTTPS para o domínio pelo tempo informado em max-age.
• Rate limiting limita as requisições por chave (em geral o IP) e ajuda contra força bruta e abuso, mas não substitui proteção contra DDoS distribuído, em que cada origem envia pouco. No Nginx, limit_req_zone define a chave, a memória e a taxa; limit_req aplica o limite em um local; burst permite rajadas e nodelay atende a rajada sem atraso. A resposta de rejeição padrão é 503; use limit_req_status 429 para devolver 429 Too Many Requests. Atrás de NAT, vários usuários compartilham o mesmo IP, e atrás de um CDN ou proxy é preciso configurar o IP real do cliente.
• Logs do Nginx e do ModSecurity precisam chegar a uma plataforma central, com alertas para aumento de bloqueios, de respostas 5xx e de latência. Segurança depende de revisão, atualização do CRS e testes repetíveis.

Um WAF não corrige a vulnerabilidade no código: reduz a exposição e compra tempo para a correção definitiva. A defesa funciona em camadas, cada uma cobrindo o que a anterior não vê.

Os conceitos-chave

Borda em camadas, com TLS, limite de taxa e WAF

 # compose.yaml
services:
  api:
    image: python:3.12-alpine
    command: ["python", "/app/backend.py"]
    environment:
      NAME: api
    volumes:
      - ./backend.py:/app/backend.py:ro
  crs:
    image: owasp/modsecurity-crs:nginx              # WAF: Nginx com ModSecurity e OWASP CRS
    environment:
      BACKEND: http://api:3000                      # para onde o WAF encaminha o tráfego aprovado
      PORT: "8080"                                  # porta de escuta do WAF dentro do container
      MODSEC_RULE_ENGINE: DetectionOnly             # só registra; troque para On para bloquear
      PARANOIA: "1"                                 # nível de paranoia do CRS (1 é o menos sensível)
    depends_on: [api]
  edge:
    image: nginx:stable                             # borda: TLS, HSTS e limite de taxa
    ports:
      - "8443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./certs:/etc/nginx/certs:ro
    depends_on: [crs]

Comandos essenciais desta etapa

Mão na massa

1. Crie etapa14/ com backend.py, compose.yaml, nginx.conf e a pasta certs/, e rode docker compose up -d. Se o edge devolver 502, confira com docker compose logs crs em que porta o WAF escuta e ajuste PORT e o proxy_pass. Se você editar o nginx.conf depois, rode docker compose exec edge nginx -s reload e, se a mudança não aparecer, docker compose restart edge.
2. Envie uma requisição normal (curl -sk https://localhost:8443/) e observe api recebeu /, passando por borda, WAF e backend.
3. Com o WAF em DetectionOnly, envie o payload XSS e o de SQL Injection do exemplo. Observe o 200 e procure no docker compose logs crs a regra acionada (um id de regra e a mensagem). Identifique a regra antes de habilitar o bloqueio.
4. Troque MODSEC_RULE_ENGINE para On, rode docker compose up -d e repita os payloads. Observe 403. Envie de novo uma requisição normal e observe que continua 200.
5. Rode as 10 chamadas seguidas ao /login e observe os 429 depois do limite. Aguarde cerca de 12 segundos e repita uma chamada para observar o limite liberando um slot.
6. Confira os headers com curl -sk -I https://localhost:8443/ e observe strict-transport-security, e a ausência da versão no cabeçalho server.
7. Monte um checklist para o seu serviço: TLS 1.2 ou 1.3, HSTS, atualização do CRS, retenção de logs, alerta de picos de bloqueio e de 5xx, e um teste repetível dos payloads.
8. Limpe: docker compose down.

Etapa 15 · revisão

Checklist de autoavaliação

Próximos passos: com todos os itens marcados, refaça os laboratórios sem consultar o guia e depois junte as peças. Em Docker, monte uma borda com dois backends atrás de um Nginx com balanceamento, servidor backup, limite de taxa e WAF, e proteja esse Nginx com um segundo nó e Keepalived. No Minikube, publique a mesma aplicação com Ingress e TLS do cert-manager e faça um canário 90/10 com o Istio, medindo a proporção real e praticando o rollback.