https://castroti.com.br/ Recent content 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/posts/kubernetes-oke-traefik-argocd/ Sun, 10 Mar 2024 00:00:00 +0000 https://castroti.com.br/posts/kubernetes-oke-traefik-argocd/ O problema Você tem um cluster OKE rodando na OCI. Quer Traefik como ingress, SSL automático via Let’s Encrypt, e ArgoCD sincronizando tudo pelo Git sem kubectl apply manual. Essa combinação não tem tutorial decente em português. Esse é ele. Pré-requisitos Cluster OKE provisionado (via Terraform ou console OCI) kubectl configurado com kubeconfig do cluster helm ≥ 3.12 Domínio com DNS apontando para o Load Balancer da OCI ArgoCD CLI (argocd) instalado localmente 1. 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/posts/postgresql-tuning-kubernetes/ Thu, 15 Feb 2024 00:00:00 +0000 https://castroti.com.br/posts/postgresql-tuning-kubernetes/ Contexto Rodar PostgreSQL no Kubernetes é possível. Fazer isso bem exige atenção em alguns pontos que a maioria dos tutoriais ignora. Esse post é o que eu gostaria de ter encontrado antes de ir pra produção. 1. Storage: não negocie com isso Use storageClassName com WaitForFirstConsumer e, se possível, local SSDs: 1 2 3 4 5 6 7 8 9 10 11 12 # storage-class.yaml — OCI Block Volume apiVersion: storage. 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/posts/observabilidade-prometheus-grafana-loki/ Sat, 20 Jan 2024 00:00:00 +0000 https://castroti.com.br/posts/observabilidade-prometheus-grafana-loki/ Por que PLG e não ELK? Simples: custo e operação. ELK (Elasticsearch + Logstash + Kibana) consome muito mais recurso e é complexo de manter. A stack PLG (Prometheus + Loki + Grafana) roda mais leve, integra nativamente com K8s e o Grafana unifica métricas, logs e traces em um único lugar. Arquitetura ┌─────────────────┐ │ Grafana │ ← única UI pra tudo └────────┬────────┘ │ ┌──────────────┼──────────────┐ │ │ │ ┌──────┴──────┐ ┌─────┴────┐ ┌─────┴─────┐ │ Prometheus │ │ Loki │ │ Tempo │ │ (métricas) │ │ (logs) │ │ (traces) │ └──────┬───────┘ └────┬─────┘ └───────────┘ │ │ ┌────────┴──────┐ ┌────┴──────┐ │ Node Exporter │ │ Promtail │ │ kube-state │ │ (agente) │ └───────────────┘ └───────────┘ 1. 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 https://castroti.com.br/about/ Mon, 01 Jan 2024 00:00:00 +0000 https://castroti.com.br/about/ Roberto Castro Analista de Infraestrutura Cloud — Rio de Janeiro, Brasil. 15 anos de estrada em infraestrutura: comecei em 2011 fazendo suporte e monitoria de servidor, hoje projeto e opero infra cloud (AWS, OCI, GCP) pra vários clientes em paralelo — de cluster Kubernetes a banco de dados em produção. Gosto de deixar tudo documentado, automatizado e sem depender de mim pra não cair. o que faço Cloud — AWS, OCI (Oracle Cloud) e Google Cloud: compute, redes, IAM, storage Kubernetes — OKE (Oracle) e EKS/ECS (AWS) em produção, GitOps com ArgoCD, provisionamento com Crossplane Automação — Ansible pra configuração e hardening, Shell Script pro resto Observabilidade — Zabbix, Prometheus + Grafana + Loki, Dynatrace, Percona PMM Bancos de dados — MongoDB (clusters HA, migração, tuning), PostgreSQL, Redis Redes & proxy — Nginx, Traefik, VPN, hardening carreira em uma linha Suporte técnico → Analista de Operações → Analista de TI → Infra Cloud Passei por provedor de internet (InfoLink), monitoria de eventos de grande porte (Mobicare — inclusive Wi-Fi de estádio na Copa de 2014), monitoria corporativa (Allied Brasil) e hoje sigo full-time na Envyron Cloud Experts cuidando de infra multi-cloud pra clientes de missão crítica. https://castroti.com.br/cv/ Mon, 01 Jan 2024 00:00:00 +0000 https://castroti.com.br/cv/ Roberto Castro Analista de Infraestrutura Cloud Rio de Janeiro, Brasil · contato@castroti.com.br · linkedin.com/in/roberto-castro · github.com/r0b3rt0c4str0 Resumo 15 anos em infraestrutura de TI, desde suporte técnico até arquitetura cloud. Hoje atuo full-time na Envyron Cloud Experts (CTO as a service, ex-InfoLink) e, em paralelo, sou sócio na Vitruvit, onde levo a consultoria de infraestrutura Migre pra Nuvem e o produto Zapgator (white-label do ClickMassa Enterprise, da VectaX). Gerencio ambientes multi-cloud (AWS, OCI, GCP), clusters Kubernetes (EKS/ECS/OKE), automação com Ansible e observabilidade ponta a ponta (Zabbix, Prometheus/Grafana/Loki, Dynatrace, Percona PMM).