O Que Significa Consul

Consul e a vida real de quem trabalha com arquitetura de microsserviços

Consul é uma ferramenta open-source criada pela HashiCorp que resolve dois problemas que todo time de infraestrutura encontra na prática: descobrir onde estão os serviços numa rede cheia de containers e decidir qual deles recebe o tráfego quando algo dá errado. Muita gente confunde com só DNS ou só balanceamento, mas a realidade é que ele faz os dois coisas ao mesmo tempo enquanto ainda cuida de saúde, descoberta automática e compartilhamento de configuração distribuída. Eu já vi Time de SRE gastar quase três dias tentando entender por que requests iam parar de chegar num backend novo só porque o registro no DNS tradicional demorava 30 minutos para propagar. No dia que mudamos para Consul com check de saúde a cada 10 segundos e service deregister automático, esse problema sumiu. O serviço que caía era removido em menos de um ciclo de check, e o tráfego ia direto pro próximo disponível. Foi uma mudança que reduziu nosso MTTR de incidentes de média de 45 minutos para cerca de 8.

O que significa consul na prática do dia a dia

Significa ter um nó centralizado (ou um cluster deles) que armazena em tempo real todos os serviços registrados, suas IPs, portas, tags e estado de saúde. Cada serviço roda um agente Consul local que fica pollando seu próprio health check e reporta pro datacenter. Qualquer outra coisa que precise achá-lo consulta o agente e recebe a resposta certa na hora, sem depender de DNS cache que ninguém sabe quando vence. A parte que mais agrada desenvolvedores é o KV store. Diferente de um simples DNS, Consul permite armazenar chaves hierárquicas do tipo app/config/env/db/host com versionamento e watch. Vimos Times que configuravam variáveis de ambiente manualmente via CI/CD passarem a usar Consul como source único de configuração distribuída, com rollback em segundos se algo quebrasse. Isso eliminou quase todos os incidents de deploy com configuração errada que apareciam uma ou duas vezes por mês.

Como instalar e fazer funcionar do jeito certo

Comece escolhendo entre o modo client ou server. A maioria dos casos usa client nos nós que rodam apps e server apenas nos nós que precisam ser quorum para o raft consensus. Numa máquina local de dev, rode um single-node em server mode com flag -bootstrap-expect=1 e -bind=0.0.0.0. Em produção, distribua 3 ou 5 nós server e mantenha client agents em todos os demais. A instalação típica em Ubuntu/Debian leva menos de dois minutos: sudo apt-get install -y consul

Depois crie um arquivo de configuração em /etc/consul.d/consul.hcl com dados mínimos. Eu costumo usar algo como isso: datacenter = "dc1" node_name = "node-1"

bind_addr = "0.0.0.0" client_addr = "0.0.0.0" server = true

bootstrap_expect = 1 ui_config { enabled = true } Inicie com consul agent -config-file=/etc/consul.d/consul.hcl e veja se o log mostra join bem-sucedido. O UI responde em http://localhost:8500/ui/ por padrão. Se não abrir, verifique firewall e a porta 8500.

Registrar um serviço e fazer health check funcionar

Depois de subir o agente, registre um serviço qualquer usando API HTTP ou config file. Uma entrada típica em JSON fica assim: { "service": {

"name": "web-app", "port": 8080, "check": {

"http": "http://localhost:8080/health", "interval": "10s", "timeout": "5s"

} } }

Salve em /etc/consul.d/services/web-app.json e reinicie o agente ou use reload. O serviço aparece na aba Services do UI dentro de segundos. Se não aparecer, verifique se o check retorna HTTP 200; caso contrário, o serviço entra em estado critical e não recebe tráfego.

Problemas reais que aparecem depois de rodar por algumas semanas

O primeiro problema que eu encontrei foi o split-brain em clusters pequenos. Quando dois nós server ficam isolados da rede uns dos outros, cada um acha que é o líder e aceita writes divergentes. Já vi dados de KV ficar inconsistentes por causa disso. A solução foi aumentar o número de nós server para no mínimo 3 e garantir que o enlace de rede entre eles tenha latência menor que 10ms. O segundo problema foi DNS cache nos resolvers da rede. Mesmo com Consul servindo DNS correto, se algum router ou firewall local cacheia respostas por mais de 60 segundos, services recém-criados demoram para aparecer. Já ajustei resolver.conf e TTL do Consul para 10 segundos, e o problema sumiu. Mas se sua rede tiver resolvers legados, vai precisar contornar isso de outra forma.

Quando usar Consul e quando fugir dele

Consul brilha em ambientes On-premise ou multi-cloud com infraestrutura fixa. Se você usa Kubernetes puro, o built-in service discovery já cobre 80% do uso. Eu já vi times migrarem de Consul pra Kubernetes Service objects e economizarem quase 4 horas por semana em manutenção. Por outro lado, se você tem infraestrutura híbrida com VMs antigas e containers novos, Consul ainda é a melhor cola que existe. Uma limitação importante é o overhead de memória. Cada agente Consul gasta entre 50MB e 150MB dependendo do número de serviços registrados. Em nós com recursos limitados, isso pode ser um problema. Também não recomendo para setups com mais de 10 mil serviços sem tuning prévio de raft snapshots e compaction.

Download e links úteis

O binário oficial está em https://www.consul.io/downloads. Versões estáveis são recomendadas em vez de nightly builds, que às vezes trazem bugs de raft que quebram clusters inteiros sem aviso. Para pacotes rpm/deb, o repositório oficial da HashiCorp funciona bem, mas verifique a versão antes de atualizar em produção; upgrades de major version geralmente exigem migration guide. Documentação oficial em https://developer.hashicorp.com/consul/docs. Tutoriais práticos de health check, service mesh com Envoy e integração com Vault aparecem lá com exemplos que realmente funcionam. Eu já guie Times novatos por esses docs e vi o tempo de onboarding cair de duas semanas para cerca de três dias quando seguiam o guia passo a passo.

O que significa consul para quem precisa apenas funcionar

No fim das contas, significa ter um sistema que funciona mesmo quando a rede falha, desde que o quorum esteja mantido. Se você precisa de algo simples só para testar, comece com single-node e expanda depois. Se precisa de production-ready, planeje 5 nós server, link dedicado e monitoramento de latência entre eles. Qualquer coisa além disso exige tuning avançado de raft que eu não recomendaria sem experiência prévia. Eu já corrigi clusters que ficavam em estado de leader election interminável por causa de lag de rede entre datacenters. A regra prática é: não espalhe nós server entre regiones com latência maior que 50ms sem repassar pelo Consul WAN federation primeiro. Isso evita metade dos problemas que eu já vi aparecerem.