https://castroti.com.br/portfolio/ Recent content in portfolio on Castro Hugo -- gohugo.io pt-br Sat, 15 Jun 2024 00:00:00 +0000 https://castroti.com.br/portfolio/n8n-self-hosted-observabilidade/ Sat, 15 Jun 2024 00:00:00 +0000 https://castroti.com.br/portfolio/n8n-self-hosted-observabilidade/ Contexto n8n rodando em n8n.castroti.com.br — infraestrutura própria em vez de depender do plano cloud deles. É onde ficam as automações que sustentam outros projetos meus, incluindo parte da orquestração do pipeline de Leads Migre. Arquitetura Traefik (TLS + rate limit) │ ▼ n8n (editor/API) ──┐ │ │ n8n-worker (fila) │ │ │ Postgres Redis (fila) Modo fila (EXECUTIONS_MODE=queue) — worker separado do processo principal, escala independente Postgres — persistência de workflows e execuções Redis — fila de jobs (Bull) Traefik — TLS automático, rate limit (10 req/s, burst 20) na frente do editor/webhooks Observabilidade Prometheus — métricas do n8n (N8N_METRICS=true, incluindo métricas de fila) e do host (node-exporter) cAdvisor — métricas de container Loki + Promtail — centralização de logs de todos os containers Grafana — dashboards unificando tudo, atrás do próprio Traefik com TLS Por que montar em vez de usar o n8n Cloud Dados dos workflows (inclusive credenciais de automações de clientes) ficam no meu servidor, não em terceiro Observabilidade integrada com o resto da minha stack (mesmo padrão Prometheus/Loki/Grafana usado em outros projetos) Sem limite de execução por plano — modo fila escala conforme a demanda real Tecnologias n8n · Docker Compose · PostgreSQL · Redis · Traefik · Prometheus · Loki · Grafana · cAdvisor https://castroti.com.br/portfolio/zapgator-whitelabel-clickmassa/ Sat, 01 Jun 2024 00:00:00 +0000 https://castroti.com.br/portfolio/zapgator-whitelabel-clickmassa/ Contexto Zapgator (zapgator.com, migrando para zapgateway.com.br nas próximas semanas) é um white-label do ClickMassa Enterprise, produto da VectaX — levado ao mercado pela Vitruvit, empresa que fundei com meu sócio. Estou no projeto desde o dia zero. Meu papel Como sócio técnico, cuido da parte de infraestrutura e implantação — a mesma frente que já toco pra VectaX como cliente da Migre pra Nuvem, só que aqui do lado de dentro do produto que estamos revendendo. https://castroti.com.br/portfolio/leads-migre-prospeccao/ Wed, 01 May 2024 00:00:00 +0000 https://castroti.com.br/portfolio/leads-migre-prospeccao/ Contexto Projeto pessoal de prospecção — uso interno pra abordar negócios locais. Nasceu de uma dor simples: lista de leads manual não escala e fica desatualizada rápido. A solução virou um pipeline completo, do scraping até a publicação. Pipeline scraper (Google Maps, GuiaMais, Vivareal, Doctoralia) │ ▼ cruzamento com CNPJ da Receita Federal (filtro por município/bairro) │ ▼ confirmação de WhatsApp/Instagram/Facebook via site do próprio negócio │ ▼ build_release.py → dataset cumulativo (nunca perde cidade antiga, upsert por nome+cidade) │ ▼ release estática nova → symlink atômico → Docker (Caddy) serve, sem downtime Decisões de arquitetura Estático, sem banco de dados — cada publicação gera uma release nova e imutável; rollback é só reapontar o symlink Deploy atômico — a troca de release não tem downtime nem estado inconsistente Superfície de ataque mínima — a imagem Docker publicada não contém Python nem os scripts, só os arquivos estáticos já gerados Basic Auth sempre ativo — dado de contato de negócio não fica aberto publicamente 100% no servidor — coleta e publicação não dependem de nenhuma máquina local ligada Score de qualificação Cada lead é pontuado (0–27) considerando telefone, WhatsApp (por formato e confirmado via site), email, site próprio, Instagram, Facebook, avaliações/nota no Google e CNPJ ativo — pra priorizar quem vale a pena abordar primeiro. https://castroti.com.br/portfolio/mongodb-cluster-ha-superfrete/ Mon, 01 Apr 2024 00:00:00 +0000 https://castroti.com.br/portfolio/mongodb-cluster-ha-superfrete/ Contexto Infraestrutura cloud em AWS e Google Cloud, com o banco de dados (MongoDB) como peça central: precisava suportar crescimento acelerado de usuários e transações sem virar gargalo nem ponto único de falha. O que entrou Cluster MongoDB HA — projetado, implementado e operado do zero (réplicas, failover, monitoria, tuning) Backup/restore — rotina testada de verdade, não só configurada e esquecida Compute — EC2 (AWS) e Cloud Functions (GCP) dando suporte à aplicação Segurança — IAM/roles, hardening, VPN e conectividade entre os dois ambientes cloud Observabilidade — métricas, logs e alertas cobrindo banco e aplicação Continuidade — testes de restore e procedimentos de disaster recovery (DR) documentados Por que dois clouds AWS e GCP não foi escolha por modismo — cada ambiente hospeda uma parte específica da stack, com conectividade (VPN) desenhada pra que a aplicação não perceba a fronteira entre os dois. https://castroti.com.br/portfolio/migracao-multicloud-hibrida-aws/ Fri, 01 Mar 2024 00:00:00 +0000 https://castroti.com.br/portfolio/migracao-multicloud-hibrida-aws/ Problema Infraestrutura híbrida — parte em OVH, parte em Vercel — sem padrão único, dificultando escalar e diagnosticar problema ponta a ponta. Precisava virar uma arquitetura só, na AWS, sem downtime pra quem já estava em produção. Arquitetura de destino ALB (Application Load Balancer) │ Auto Scaling Group (EC2) │ ┌────────────┼────────────┐ │ │ │ Amazon RDS ElastiCache Microsserviços (Redis) ALB + Auto Scaling Groups (EC2) — ambiente escalável e altamente disponível Amazon RDS — banco relacional gerenciado ElastiCache (Redis) — cache em memória VPC/IAM — segmentação de rede e controle de acesso desenhados desde a migração Papel na migração Atuei como ponto focal de infraestrutura junto ao time de desenvolvimento — viabilizando microsserviços, diagnosticando erros complexos (rede, latência, timeouts) que só apareciam em produção, e otimizando performance ponta a ponta durante a transição. https://castroti.com.br/portfolio/gitops-argocd-multicluster/ Thu, 01 Feb 2024 00:00:00 +0000 https://castroti.com.br/portfolio/gitops-argocd-multicluster/ Contexto Grupo VectaX (produtos ClickMassa, ChipSMS, Start) — infraestrutura implantada do zero e operada em conjunto com o time desde 2022. O core roda hoje na OCI (Oracle Cloud), em migração progressiva pra Kubernetes (OKE). Desafio real: migrar sem quebrar quem já está em produção no VPS legado. Nada de big-bang — cliente por cliente, ambiente por ambiente. Abordagem OKE em staging/homologação primeiro — padronizado e validado antes de qualquer cliente entrar Suporte simultâneo ao ambiente legado (VPS) e ao K8s durante a transição GitOps com ArgoCD — todo o estado do cluster declarado em Git, sync automático Provisionamento com Crossplane — recursos de infra (não só workloads) também viram manifesto Kubernetes Ingress com Traefik/Nginx, Docker como runtime Stack de suporte Observabilidade: Prometheus, Grafana, Loki Bancos: PostgreSQL, MongoDB, Redis Integrações: Supabase, n8n Automação complementar: Ansible, CI O que ficou pra trás Deploy manual — vira PR → review → sync automático via ArgoCD Ambiente diferente por cliente — padronizado via Crossplane + overlays Troubleshooting às cegas — engenharia com acesso direto a métricas/logs/ingress pra depurar microsserviços Tecnologias ArgoCD · Crossplane · OKE · Traefik · Docker · Prometheus · Grafana · Loki · Ansible https://castroti.com.br/portfolio/observabilidade-stack-plg/ Wed, 10 Jan 2024 00:00:00 +0000 https://castroti.com.br/portfolio/observabilidade-stack-plg/ Contexto Trabalho de infraestrutura cloud onde eu era o ponto focal entre infra e o time de desenvolvimento — precisava diagnosticar problema de rede, latência e timeout em produção rápido, sem depender de “acho que é o banco” ou “acho que é a rede”. Solução: cada camada com sua ferramenta certa, tudo correlacionável. Camadas Zabbix — saúde da infraestrutura (servidores, rede) Grafana + Telegraf — dashboards em tempo real de aplicação Loki — centralização de logs Percona PMM — análise profunda de banco de dados (queries lentas, locks, índices) Onde isso importou de verdade Migração do MongoDB Atlas para solução autogerenciada em EC2 — decisão baseada em dados reais de custo e performance coletados pelo PMM, não achismo Ambiente escalável na AWS (ALB, Auto Scaling Groups, RDS, ElastiCache) — desenhado e operado com visibilidade completa do que cada componente consumia Segurança e confiabilidade — VPC/IAM, backups e revisão de incidentes apoiados pelos mesmos dashboards Resultado Diagnóstico de problema de rede/latência deixou de ser “abrir 4 ferramentas diferentes” pra ser um fluxo único Migração de banco decidida com dado, não com medo Colaboração contínua com o time de Dev/Ops em vez de infra isolada apagando incêndio Tecnologias Zabbix · Grafana · Telegraf · Loki · Percona PMM · AWS (ALB, ASG, RDS, ElastiCache) · MongoDB