DEV Community: Luis Cruz

Automação GitOps com Terraform e Proxmox

Luis Cruz — Fri, 30 Jan 2026 14:45:43 +0000

Há alguns meses, adquiri um M910q Desktop (ThinkCentre) para utilizá-lo no meu homelab, permitindo que o WSL do meu Lenovo S145 tivesse um pouco de descanso.

Essa iniciativa faz parte da minha busca contínua por evolução técnica, criando ambientes de teste e homologação que me permitam experimentar novas ferramentas e abordagens com mais liberdade.

Na criação das VMs, sempre utilizei o Terraform para o provisionamento. No entanto, recentemente realizei alguns ajustes importantes, integrando o GitHub e o HCP Terraform ao fluxo de trabalho.

Após dedicar algumas horas a esse processo, concluí um projeto que mudou completamente a forma como gerencio minha infraestrutura de homelab, e decidi compartilhar essa jornada com vocês.

O problema inicial

Sempre que eu precisava criar uma VM no Proxmox, o processo se repetia: abrir a interface web, preencher formulários, configurar rede manualmente, aguardar a criação da VM, acessar via SSH e configurar o ambiente.

Além disso, era necessário torcer para lembrar exatamente quais passos haviam sido executados caso fosse preciso replicar o processo no futuro.

Não havia histórico de mudanças, automação consistente ou rastreabilidade.

Mesmo utilizando scripts ou o próprio Terraform, ainda existiam etapas manuais, tornando o processo mais demorado do que deveria e com pontos claros de melhoria.

A solução: GitOps + Terraform + GitHub Actions

Implementei um fluxo completo de GitOps, no qual toda a infraestrutura passou a ser gerenciada exclusivamente por código versionado em Git.

O resultado foi bastante expressivo.

Hoje, consigo criar, modificar ou remover VMs simplesmente realizando um commit e um push. Em cerca de dois a três minutos, a alteração é automaticamente aplicada no ambiente Proxmox.

O que aprendi no caminho

Nem tudo é simples, especialmente para quem está começando do zero.

Como já possuo uma boa experiência com essas ferramentas, configurar corretamente as permissões no Proxmox, implementar um self-hosted runner na rede local, já que o Proxmox não é acessível diretamente da nuvem, e estruturar o código de forma escalável e reutilizável não foi algo particularmente difícil.

Ainda assim, cada etapa se mostrou uma oportunidade de aprendizado e de refinamento dos processos relacionados a Infrastructure as Code, CI/CD e boas práticas de automação.

Observação: para quem nunca fez algo semelhante, deixei um passo a passo detalhado, além de uma FAQ, para facilitar a reprodução do ambiente.

Tecnologias utilizadas

A stack é 100% open source e gratuita.

Utilizei Terraform para IaC, GitHub Actions para automação, Terraform Cloud para gerenciamento remoto de estado e Proxmox como hypervisor. Tudo isso rodando em um ambiente self-hosted, garantindo controle total sobre os dados e a infraestrutura.

O impacto real

Antes: entre 15 e 20 minutos para criar cada VM, com um processo manual, sujeito a erros e sem histórico de alterações.

Agora: cerca de 30 segundos para definir a VM em código, seguido de commit e push automáticos, com rastreabilidade completa via Git.

Mais importante do que o tempo economizado foi o ganho em confiabilidade.

Cada mudança passa por revisão, fica registrada no histórico do Git e pode ser revertida facilmente com um simples git revert. Isso é especialmente valioso em ambientes de experimentação, onde a possibilidade de voltar atrás com segurança faz toda a diferença.

Lições aprendidas

Automação não é sobre eliminar o trabalho manual, mas sim reduzir tarefas repetitivas e propensas a erros.

Infrastructure as Code não é exclusiva de grandes empresas. Homelabs são ambientes ideais para experimentação.

Documentação é tão importante quanto o código. Dediquei tempo a documentar cada etapa pensando no meu “eu do futuro”.

Self-hosted runners ampliam significativamente as possibilidades de automação em ambientes locais.

Próximos passos / Melhorias

Pretendo evoluir esse projeto integrando o Ansible, já que atualmente utilizo o Semaphore UI para a configuração pós-criação das VMs, além de adicionar testes automatizados antes do deploy.

Para quem se interessou pelos detalhes técnicos da implementação, e quiser fazer a implementação, o passo a passo, incluindo troubleshooting de todos os problemas enfrentados: homelab-infrastructure-template
Public

Trabalhar com infraestrutura é uma jornada contínua de aprendizado.

Compartilhar conhecimento e aprender com a comunidade faz toda a diferença.

Windows - Instalando o WSL e o Docker

Luis Cruz — Wed, 10 Dec 2025 02:12:55 +0000

Pré-requisitos

Windows 11 ou Windows 10 com atualizações que suportem WSL 2.
Virtualização por hardware habilitada na BIOS/UEFI.
Conexão à internet para baixar distribuições, pacotes e imagens Docker.

Instalar o WSL (passo rápido)

No PowerShell em modo Administrador execute:

wsl --install

Esse comando habilitará os recursos necessários para executar o WSL e instalar a distribuição do Ubuntu do Linux. (Essa distribuição padrão pode ser alterada).

Verificar versão e distros

wsl --version

wsl -l -v

Novas instalações feitas com wsl --install são, por padrão, configuradas para WSL 2.

Para instruções oficiais e detalhes, consulte a documentação do WSL.

Opção com interface gráfica: Docker Desktop com integração WSL 2

Baixe e instale o Docker Desktop para Windows.
Em Settings > General ative Use the WSL 2 based engine.
Em Resources > WSL Integration habilite a distro que você usa.
Abra o terminal dentro do WSL: os comandos docker e docker compose estarão disponíveis.

Essa abordagem reduz conflitos e facilita para quem não tem familiaridade com CLI (interface de linha de comando). Para mais detalhes, acesse a documentação.

Alternativa: instalar Docker Engine dentro do Ubuntu (WSL 2)

Se não desejar usar Docker Desktop, siga dentro do Ubuntu:

sudo apt-get update

sudo apt-get install -y ca-certificates curl gnupg lsb-release

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

sudo apt-get install -y docker-ce docker-ce-cli containerd.io

sudo usermod -aG docker $USER

Depois faça no PowerShell e reabra a distro:

wsl --shutdown

Teste com:

docker run --rm hello-world

Consulte o guia oficial de instalação do Docker Engine para Ubuntu.

Docker Compose

O Docker Compose é distribuído como plugin (v2+). Em Linux instale docker-compose-plugin pelo repositório Docker ou siga a página oficial de instalação do Compose. Se usar Docker Desktop, o Compose já vem integrado.

docker compose version

Exemplos práticos

Rodar um Nginx simples:

docker run --name exemplo-nginx -p 8080:80 -d nginx:stable

Acesse no host: http://localhost:8080

docker-compose.yml mínimo:

services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"

Subir:

docker compose up -d

docker compose ps

docker compose logs -f

Referências e links úteis

Microsoft - Como instalar o WSL (pt-BR)

Microsoft - WSL config (wsl.conf) / systemd

Docker - Docker Desktop: WSL 2 backend / integração

Docker - Instalar Docker Engine no Ubuntu

Docker - Instalar o plugin Docker Compose

Docker - Documentação geral do Compose

O que é GEMBA?

Luis Cruz — Fri, 24 Oct 2025 19:13:53 +0000

Gemba (現場) é um termo de origem japonesa que significa, literalmente, “o lugar real” ou “o local onde as coisas acontecem”.

No contexto empresarial, especialmente em Lean Manufacturing, Lean Management e Kaizen, Gemba refere-se ao local onde o valor é criado — por exemplo:

Em uma fábrica, é o chão de produção.
Em uma empresa de software, é onde os desenvolvedores codificam.
Em uma loja de varejo, é o piso de atendimento ao cliente.

O Lean (também conhecido como Lean Thinking ou Mentalidade Enxuta) é uma filosofia de gestão originada no sistema de produção da Toyota (Toyota Production System - TPS), cujo objetivo central é maximizar valor para o cliente eliminando desperdícios nos processos.

Conceito de “Gemba” no Lean

A filosofia do Gemba incentiva líderes, gestores e profissionais a irem até o local real, para:

Observar diretamente os processos.
Identificar problemas reais, não apenas dados em relatórios.
Ouvir os colaboradores que estão na linha de frente.
Tomar decisões baseadas em fatos, e não em suposições.

Gemba Walk

Um conceito associado é o Gemba Walk (“Caminhada no Gemba”), que consiste em visitas regulares ao local onde o trabalho acontece, com o objetivo de:

Entender o fluxo de trabalho;
Detectar desperdícios ou ineficiências;
Promover a melhoria contínua (Kaizen);
Fortalecer o relacionamento entre gestão e operação.

Importante: o Gemba Walk não é uma auditoria ou fiscalização, mas sim uma oportunidade de aprendizado e colaboração.

Princípios de uma boa prática de Gemba

Ir ao Gemba – Visite o local real com frequência.
Observar com propósito – Veja como o trabalho realmente é feito.
Fazer perguntas – Entenda os “porquês” por trás dos processos.
Ouvir os colaboradores – Eles conhecem os desafios diários.
Agir com respeito – A ideia é aprender, não julgar.
Promover melhorias – Use os insights para implementar melhorias sustentáveis.

Benefícios do Gemba

Aumento da eficiência operacional.
Redução de desperdícios.
Maior engajamento da equipe.
Tomada de decisão mais assertiva e baseada em fatos.
Fomento à cultura de melhoria contínua.

Ok, mas como aplicar GEMBA e LEAN hoje com o trabalho remoto e equipes espalhadas em diversos lugares?

Aplicar os princípios de Gemba e Lean em um cenário de trabalho remoto ou distribuído é totalmente possível, mas exige adaptação. A essência continua sendo ir até onde o valor é criado, observar, ouvir e eliminar desperdícios, mesmo que esse "lugar real" agora esteja no ambiente digital.

Redefinindo o “Gemba” no remoto

No ambiente remoto, o Gemba deixa de ser físico e passa a ser o espaço digital onde o trabalho ocorre, como:

Repositórios de código (GitHub, GitLab)
Sistemas de tickets (Jira, ServiceNow, etc.)
Dashboards de observabilidade e monitoramento
Ferramentas de colaboração (Slack, Teams, Confluence)
Sistemas de CI/CD, nuvem e infraestrutura

Fazendo Gemba Walks digitais

Adapte a prática da Gemba Walk para o remoto com:

Ação	Como adaptar
Observar o trabalho em tempo real	Compartilhamento de tela, gravações de sessões, revisões de código, dashboards
Fazer perguntas abertas	Sessões de check-in por vídeo ou chat com times operacionais
Identificar desperdícios	Análise de fluxos digitais: tempo de espera em tickets, rework, incidentes repetitivos
Documentar aprendizados	Criar logs de Gemba Walks no Confluence/Notion/Trello

Ferramenta útil: Use gravações de sessões (ex: Loom, Zoom) como apoio visual e técnico para revisitar o Gemba digitalmente.

Aplicando princípios Lean no remoto

Mapeie o fluxo de valor digital (Value Stream Mapping)

Entenda todas as etapas entre a demanda do cliente e a entrega
Ex: Solicitação de infraestrutura → Provisão com Terraform → Validação → Deploy

Identifique desperdícios remotos

Espera por aprovações
Retrabalho por falta de definição
Sobrecarga por excesso de reuniões
Falta de visibilidade de progresso

Estimule o Kaizen remoto

Faça retrospectivas Lean (curtas e frequentes)
Capture ideias de melhoria via mural colaborativo (ex: Miro, Jamboard, FigJam)
Implemente pequenas melhorias rápidas e meça resultados

Ferramentas digitais para suportar Lean + Gemba

Categoria	Ferramentas
Gestão visual (Kanban)	Trello, Jira, Asana
Automação e fluxo	GitHub Actions, GitLab CI/CD, Jenkins
Observabilidade	Grafana, Prometheus, New Relic
Colaboração	Slack, Zoom, Teams
Documentação de Gemba Walks	Confluence, Notion

Engajamento e Cultura Remota

Crie rituais de escuta ativa com o time técnico
Promova a cultura do “ir ver, não apenas supor”
Incentive todos a trazer insights do Gemba digital para os encontros
Pratique o respeito e empatia, peça feedback sem julgamento.

Exemplo prático: Gemba + Lean em uma equipe de DevOps remota

Problema	Gemba Walk digital	Ação Lean
Demora no provisionamento de VMs	Acompanhar fluxo no Terraform/GitLab	Automatizar aprovações
Incidentes frequentes em uma aplicação	Analisar logs no Grafana e entrevistas com Devs	Adotar testes de caos ou revisão de deploy
Falta de clareza no backlog	Visitar o Jira com a equipe	Aplicar Kanban + Definition of Ready

Fontes e Recomendações

Gemba e Lean em inglês:

Gemba e Lean em português:

Curtiu a ideia de aplicar Lean + Gemba no remoto?

Instalando o Terraform

Luis Cruz — Tue, 27 Feb 2024 00:34:15 +0000

O Terraform é uma ferramenta de infraestrutura como código (IaC) desenvolvida pela HashiCorp. Ele permite descrever, provisionar e gerenciar recursos de infraestrutura de forma declarativa e versionada, facilitando automação, padronização e colaboração entre times de desenvolvimento e operações. Nesta série de artigos iremos demonstrar usos em ambientes cloud e on-premise; este primeiro post descreve a instalação do Terraform em Debian 12 "bookworm" e um exemplo prático usando o provider Docker para subir um contêiner NGINX.

Observação de segurança: siga as etapas de verificação da chave GPG e compare fingerprints com as fontes oficiais antes de confiar em repositórios externos.

Para mais informações, ou dúvidas consulte a documentação oficial.

Pré-requisitos

Execute os comandos abaixo para garantir que pacotes essenciais estejam instalados:

sudo apt-get update

sudo apt-get install -y gnupg ca-certificates lsb-release wget curl

gnupg e ca-certificates são necessários para verificar assinaturas.
lsb-release fornece o codinome da distribuição de forma robusta.

Instalação da chave GPG e adição do repositório oficial HashiCorp

Baixe e grave a chave em um keyring dedicado com o formato correto:

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

Este método grava a chave no formato esperado pelo APT.

Obtenha o codinome da release e a arquitetura de forma segura e adicione o repositório:

CODENAME=$(lsb_release -cs 2>/dev/null || grep -oP '(?<=VERSION_CODENAME=).*' /etc/os-release)
ARCH=$(dpkg --print-architecture)
echo "deb [arch=${ARCH} signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com ${CODENAME} main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

Esse procedimento usa lsb_release como principal fonte e faz um fallback quando necessário.

Atualize o cache APT:

sudo apt-get update

Instalação do Terraform

Após adicionar o repositório HashiCorp:

sudo apt-get install -y terraform

Verifique a versão instalada:

terraform -version

Se preferir uma versão específica, considere baixar o binário oficial ou usar o repositório de releases.

Verificação da impressão digital da chave (fingerprint)

Confirme a impressão digital do keyring recém-criado:

gpg --no-default-keyring --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg --fingerprint

Compare o valor retornado com o fingerprint publicado pela HashiCorp nas páginas oficiais de empacotamento / repositório antes de prosseguir.

Exemplo prático: Terraform + Docker + NGINX

Pré-requisitos do exemplo

Docker instalado e funcionando no host.
Usuário com permissão para acessar o socket do Docker (ex.: membro do grupo docker) ou configuração de host remoto.
Observe que o provider Docker do Terraform comunica-se com o daemon Docker via socket unix ou TCP

Estrutura do projeto

Crie o diretório de trabalho e o arquivo 'main.tf':

mkdir -p ~/learn-terraform-docker-container

cd ~/learn-terraform-docker-container

Arquivo main.tf

nano/vim main.tf

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 3.6.0"   # ajuste conforme versão estável disponível no Registry
    }
  }
}

provider "docker" {
  host = "unix:///var/run/docker.sock"
}

resource "docker_image" "nginx" {
  name         = "nginx:latest"
  keep_locally = false
}

resource "docker_container" "nginx" {
  image = docker_image.nginx.image_id
  name  = "tutorial-nginx"

  ports {
    internal = 80
    external = 8000
  }
}

Inicializar e aplicar

Siga a sequência recomendada:

terraform init

terraform fmt

terraform validate

terraform plan -out=tfplan

terraform apply tfplan

terraform apply

confirme digitando "yes" quando solicitado.

terraform init baixa providers e cria o arquivo terraform.lock.hcl. Recomenda-se commitar esse lockfile para reprodutibilidade em equipe e CI.

Verificação

Acesse http://localhost:8000 no navegador para verificar o NGINX (ou use curl).

Liste containers Docker:

docker ps -a

Destruir recursos

Para remover o contêiner:

terraform destroy

confirme com "yes" quando solicitado.

Em scripts automatizados, -auto-approve pode ser usado com cautela.

Fluxo recomendado e comandos úteis

terraform init - preparar o diretório e baixar providers.
terraform fmt - formata o HCL.
terraform validate - valida a sintaxe e configurações.
terraform plan - mostra mudanças previstas; grave o plano em CI com -out.
terraform apply - aplica mudanças.
terraform destroy - destrói recursos.

Boas práticas de versionamento, segurança e CI

Trave versões: use required_version e version nos required_providers.
Commit do terraform.lock.hcl para reprodutibilidade.
Evite inserir segredos em arquivos .tf. Use variáveis, Vault, ou mecanismos seguros de CI para secrets.
Em pipelines CI, evite -auto-approve em ambientes de produção sem controles adicionais.
Audite fingerprints de chaves GPG ao adicionar repositórios.

Referências

Guia oficial de empacotamento e instalação HashiCorp (instruções apt, GPG).
Documentação de instalação do Terraform (Downloads e instruções).
Tutorial oficial Terraform com Docker - exemplos de provider.
Registry Terraform - provider kreuzwerker/docker (verificar versão mais recente).
Repositório GitHub do provider Docker (código, releases e changelog).

Monitoramento Eficiente do Windows com Prometheus e Windows Exporter

Luis Cruz — Tue, 11 Jul 2023 01:25:41 +0000

O monitoramento de sistemas Windows com o Prometheus permite coletar métricas e dados do sistema operacional de forma eficiente e rápida. Com o Prometheus, é possível acompanhar o desempenho, identificar problemas e tomar medidas proativas para garantir a estabilidade e a segurança dos servidores Windows.

O monitoramento contínuo proporciona uma visão detalhada do ambiente, permitindo uma rápida detecção e solução de problemas, além de otimizar o desempenho geral do sistema.

No artigo, são explicados os passos para instalar o Prometheus e configurar o Windows Exporter para a coleta de métricas.

Clone o repositório:

git clone https://github.com/luiscruzcwb/prometheus-windows-exporter

Navegue até a pasta prometheus-windows-exporter

cd /prometheus-windows-exporter

Configurando o Host

Navegue até a pasta prometheus e edite o arquivo prometheus.yml.

O arquivo prometheus.yml é o arquivo de configuração principal do Prometheus, sendo usado para definir as configurações relacionadas ao comportamento do Prometheus, como os alvos de coleta de dados, regras de gravação e alertas.

Tome muito cuidado com a indentação (ou endentação) do arquivo prometheus.yml.

Inclua na sessão ## Hosts OS Windows / Windows Servers os seus Hosts de coleta, como exemplo abaixo:

  - job_name: 'hostname'
    scrape_interval: 10s
    static_configs:
      - targets: ['IP-Host:9182']

Recomendo criar uma entrada para cada Host, caso contrario, basta separa os hosts dessa forma: ['IP-Host1:9182'],['IP-Host2:9182']

Host - Downloading Windows Exporter

Para baixar o Prometheus Windows Exporter, acesse a página do GitHub da comunidade.

Faça o download da versão mais recente (v0.22.0) do Windows Exporter na seção "Releases".

Se estiver usando uma versão de 32 bits do sistema operacional Windows, clique no link windows_exporter-*-386.msi.

Se estiver usando uma versão de 64 bits do sistema operacional Windows, clique no link windows_exporter-*-amd64.msi.

Host - Instalando Windows Exporter

O Prometheus Windows Exporter possui vários coletores, cada um responsável por exportar informações específicas. Alguns coletores estarão desativados por padrão, para obter uma lista dos coletores compatíveis, ativos e desativados, visite a seção "Collectors" na página do GitHub.

Após o download, em seu Windows OS, navegue via terminal como administrador até a pasta que se encontra o arquivo, e execute o seguinte comando:

msiexec /i ./windows_exporter-0.22.0-amd64.msi

O Windows Exporter estará em execução na porta 9182 do seu computador com Windows, para verificar abra o navegador e acesse o endereço: http://localhost:9182/metrics.

Se você visualizar a saída abaixo, significa que o Windows Exporter está em funcionamento.

Subindo o ambiente e Visualizando os dados no Grafana

Execute o arquivo docker-compose.

docker-compose up -d

Em seu navegador, acesse o endereço: http://localhost:3000/.

Usuário: Admin
Senha: grafana

Esses dados de acesso podem ser alterados nas configurações do Grafana, alterando o arquivo config.monitoring em /grafana/config.monitoring

No menu Dashboard, acessando o gráfico Windows exporter for Prometheus, os seus dados já estarão sendo apresentados.