DEV Community: Luis Cruz

AWS - Projeto Cloud: Implementação IAM

Luis Cruz — Tue, 02 Jun 2026 19:30:21 +0000

Neste projeto prático você vai implementar um ambiente IAM completo na AWS: criar grupos com permissões específicas, migrar usuários via script automatizado, configurar MFA obrigatório e aplicar uma política de senhas forte — tudo seguindo as boas práticas de segurança da AWS.

O projeto está dividido em duas partes:

Parte 1: Criação de grupos, preparação do CSV e automação da criação de usuários
Parte 2: Boas práticas de segurança — MFA, política de senhas e validação de acesso

Pré-requisitos

Acesso ao AWS Console com permissões de administrador
Arquivo CSV com os dados dos usuários (formato explicado abaixo)

Parte 1 — Criação e Migração de Usuários

Passo 1 — Criar os Grupos IAM

No AWS Console, acesse IAM → User groups → Create group e crie os seguintes grupos:

Grupo	Perfil
`CloudAdmin`	Administradores da conta AWS
`LinuxAdmin`	Administradores de servidores Linux
`RedesAdmin`	Administradores de rede
`DBA`	Administradores de banco de dados
`Estagiarios`	Acesso limitado para estagiários

Nomes de grupos suportam até 128 caracteres, são únicos por conta e não diferenciam maiúsculas de minúsculas.

Passo 2 — Preparar o arquivo CSV

O script espera um arquivo CSV com exatamente três colunas: usuarios, grupo e senha.

Se você tiver uma planilha Excel com os dados dos usuários, faça os seguintes ajustes antes de exportar:

Renomeie a coluna de e-mails para usuarios e remova o domínio (ex: remova @empresa.com usando Localizar e Substituir)
Renomeie a coluna de equipes para grupo e ajuste os valores para bater exatamente com os nomes dos grupos criados na AWS
Adicione a coluna senha com uma senha padrão inicial (ex: AlterarSenha@123!)
Salve como CSV separado por vírgula (UTF-8)

O arquivo final deve ter este formato:

usuarios,grupo,senha
joao.silva,LinuxAdmin,AlterarSenha@123!
maria.souza,DBA,AlterarSenha@123!
pedro.lima,Estagiarios,AlterarSenha@123!
ana.costa,RedesAdmin,AlterarSenha@123!
carlos.melo,CloudAdmin,AlterarSenha@123!

Dica: Para validar o processo, comece com 4 ou 5 usuários antes de rodar o arquivo completo.

Passo 3 — O script de criação de usuários

Salve o conteúdo abaixo como aws-iam-cria-usuario.sh:

#!/bin/bash
# Propósito:   Automatiza a criação de usuários na AWS
# Utilização:  ./aws-iam-cria-usuario.sh <arquivo.csv>
# Formato CSV: usuarios,grupo,senha
# Autor:       Luis Cruz
# ------------------------------------------

INPUT=$1
OLDIFS=$IFS
IFS=',;'

[ ! -f "$INPUT" ] && { echo "$INPUT arquivo não encontrado"; exit 99; }

command -v dos2unix >/dev/null || {
  echo "Utilitário dos2unix não encontrado. Instale com: sudo yum install dos2unix -y"
  exit 1
}

dos2unix "$INPUT"

while read -r usuario grupo senha || [ -n "$usuario" ]; do
  if [ "$usuario" != "usuarios" ]; then
    echo "──────────────────────────────────────"
    echo "Criando: $usuario | Grupo: $grupo"

    aws iam create-user --user-name "$usuario"

    aws iam create-login-profile \
      --password-reset-required \
      --user-name "$usuario" \
      --password "$senha"

    aws iam add-user-to-group \
      --group-name "$grupo" \
      --user-name "$usuario"

    echo "✓ $usuario criado com sucesso"
  fi
done < "$INPUT"

IFS=$OLDIFS
echo ""
echo "Migração concluída."

O script:

Valida se o arquivo CSV foi informado e existe
Converte o arquivo com dos2unix (necessário se criado no Windows)
Lê cada linha ignorando o cabeçalho
Cria o usuário IAM, define a senha inicial com troca obrigatória no primeiro acesso e adiciona ao grupo

Passo 4 — Executar no AWS CloudShell

O AWS CloudShell é um terminal no próprio console da AWS com AWS CLI já configurada. Acesse pelo ícone de terminal no menu superior do console.

Instalar o dos2unix:

sudo yum install dos2unix -y

Fazer upload dos arquivos via Actions → Upload file:

aws-iam-cria-usuario.sh
usuarios.csv

Preparar e executar:

# verificar os arquivos enviados
ls -la

# tornar o script executável
chmod +x aws-iam-cria-usuario.sh

# verificar o conteúdo do CSV
cat usuarios.csv

# executar
./aws-iam-cria-usuario.sh usuarios.csv

Passo 5 — Validar os usuários criados

No console, acesse IAM → Users e confirme que os usuários foram criados e estão nos grupos corretos.

Ou via CLI:

# listar todos os usuários
aws iam list-users --output table

# verificar grupos de um usuário
aws iam list-groups-for-user --user-name joao.silva

# listar usuários de um grupo
aws iam get-group --group-name DBA --output table

Passo 6 — Permitir troca de senha no primeiro acesso

Antes de testar o login com os usuários criados, anexe a política IAMUserChangePassword a todos os grupos.

Acesse IAM → User groups → [grupo] → Permissions → Add permissions → Attach policies, filtre por IAM e adicione IAMUserChangePassword.

Repita para todos os grupos.

Testando o acesso (Passo a passo)

Acesse IAM → Dashboard e copie a URL de login da conta
Abra uma aba anônima no navegador e acesse com a URL copiada
Faça login com um dos usuários criados (ex: adolfo.carlos, grupo DBA, senha AlterarSenha@123!)
Troque a senha quando solicitado
Tente acessar o DynamoDB e criar uma tabela → o acesso deve ser negado, pois o grupo DBA tem apenas AmazonRDSFullAccess

Esse teste confirma que o princípio do mínimo privilégio está funcionando corretamente.

Parte 2 — Boas Práticas de Segurança

Passo 1 — Habilitar MFA no usuário Root

O usuário root é a identidade mais poderosa da conta AWS. Proteja-o primeiro.

Acesse o console com o usuário root
Clique no nome da conta → Security Credentials
Em Multi-factor authentication (MFA) → Assign MFA device
Escolha Authenticator app (ex: Google Authenticator ou Authy)
Escaneie o QR Code com o aplicativo
Informe dois tokens consecutivos para confirmar

A partir de agora, além de usuário e senha, o login do root exigirá o token do autenticador.

Passo 2 — Criar e aplicar a política EnforceMFAPolicy

Esta política bloqueia qualquer acesso a recursos da AWS enquanto o usuário não tiver o MFA ativo.

Acesse IAM → Policies → Create policy → JSON, remova o conteúdo existente e cole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountPasswordPolicy",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice"
      ],
      "Resource": "arn:aws:iam::*:mfa/*"
    },
    {
      "Sid": "AllowManageOwnUserMFA",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Clique em Next → Next e defina o nome como EnforceMFAPolicy.

Anexar a política em todos os grupos de uma vez:

Acesse IAM → Policies → EnforceMFAPolicy → Entities attached → Attach → Filter: User groups → selecione todos os grupos → Attach policy.

Passo 3 — Configurar política de senhas da conta

Acesse IAM → Account settings → Password policy → Edit → Custom e ative:

Configuração
Letra maiúscula (A-Z)	✅
Letra minúscula (a-z)	✅
Número (0-9)	✅
Caractere especial `! @ # $ % ...`	✅
Permitir que usuários troquem a própria senha	✅
Impedir reutilização de senhas	✅

Clique em Save changes.

Passo 4 — Testar o bloqueio por MFA

Acesse IAM → Dashboard e copie a URL de login
Abra uma aba anônima e faça login com um usuário que não tem MFA configurado (ex: alda.lage, grupo CloudAdmin)
Tente acessar o IAM → o acesso será negado com erro de permissão
Isso confirma que a EnforceMFAPolicy está funcionando

Ativando o MFA como usuário:

Clique no nome do usuário no canto superior direito → Security Credentials
Em MFA device → Assign MFA device → Authenticator app
Escaneie o QR Code e informe dois tokens consecutivos
Faça Logoff → Login
Teste novamente o acesso — agora deve funcionar normalmente

Resumo do que foi implementado

Configuração	Status
Grupos IAM com permissões específicas	✅
Usuários criados via script automatizado	✅
Troca de senha obrigatória no primeiro acesso	✅
MFA habilitado no usuário root	✅
EnforceMFAPolicy aplicada em todos os grupos	✅
Política de senhas forte na conta	✅

Referências

See you later 🤘🏻

Automatizando a Migração de Usuários e o Gerenciamento de IAM na AWS

Luis Cruz — Tue, 02 Jun 2026 18:51:49 +0000

Migrar 100 usuários manualmente no console da AWS é lento, suscetível a erros e impossível de auditar com precisão. Neste artigo você vai ver como automatizar esse processo usando AWS CLI e Shell Script direto no AWS CloudShell — sem instalar nada localmente.

O resultado final: usuários criados, alocados nos grupos corretos e com MFA obrigatório, tudo em minutos.

O que é o IAM?

O AWS Identity and Access Management (IAM) é o serviço que controla quem pode acessar os recursos da sua conta AWS e o que cada pessoa ou serviço pode fazer.

Com o IAM você gerencia:

Conceito	Descrição
Usuário	Identidade individual com credenciais próprias
Grupo	Conjunto de usuários que compartilham as mesmas permissões
Política	Documento JSON que define o que é permitido ou negado
Role	Identidade temporária assumida por serviços ou usuários

A boa prática é nunca conceder permissões diretamente a um usuário — sempre use grupos.

Visão geral da solução

O fluxo é simples:

Criar os grupos IAM no console
Montar um arquivo CSV com os dados dos usuários
Rodar um shell script no CloudShell que lê o CSV e cria tudo automaticamente
Aplicar a política de MFA obrigatório nos grupos

Passo 1 — Criar os Grupos IAM

Antes de importar os usuários, os grupos precisam existir.

No AWS Console, acesse IAM → User groups → Create group e crie um grupo para cada perfil do seu ambiente. Neste exemplo usaremos:

RedesAdmin — administradores de rede
LinuxAdmin — administradores de servidores Linux
DBA — administradores de banco de dados
Estagiarios — acesso limitado para estagiários

Nomes de grupos suportam até 128 caracteres (letras, números e + = , . @ _ -), são únicos por conta e não diferenciam maiúsculas de minúsculas.

Passo 2 — Montar o arquivo CSV

Crie uma planilha com os dados dos usuários e salve como CSV separado por vírgula (UTF-8). O arquivo deve ter exatamente três colunas: Username, Group e Password.

Username,Group,Password
joao.silva,LinuxAdmin,Senha@2024!
maria.souza,DBA,Senha@2024!
pedro.lima,Estagiarios,Senha@2024!
ana.costa,RedesAdmin,Senha@2024!
carlos.melo,LinuxAdmin,Senha@2024!

Algumas observações importantes:

O valor em Group deve corresponder exatamente ao nome do grupo criado no Passo 1
Use senhas que atendam à política da conta AWS (mínimo 8 caracteres, maiúsculas, minúsculas, números e símbolos)
Se o arquivo foi criado no Excel (Windows), salve como CSV UTF-8 — o script vai precisar do dos2unix para converter os caracteres de fim de linha

Passo 3 — O script de criação de usuários

Este é o script que lê o CSV e cria cada usuário no IAM. Salve-o como criar-usuarios-iam.sh:

#!/bin/bash

# Valida se o arquivo CSV foi informado
if [ -z "$1" ]; then
  echo "Uso: $0 <arquivo.csv>"
  exit 1
fi

CSV_FILE="$1"

# Ignora o cabeçalho e lê linha por linha
tail -n +2 "$CSV_FILE" | while IFS=',' read -r USERNAME GROUP PASSWORD; do

  # Remove espaços e caracteres de retorno de carro (Windows)
  USERNAME=$(echo "$USERNAME" | tr -d '[:space:]\r')
  GROUP=$(echo "$GROUP"       | tr -d '[:space:]\r')
  PASSWORD=$(echo "$PASSWORD" | tr -d '\r')

  echo "──────────────────────────────────────"
  echo "Criando usuário: $USERNAME | Grupo: $GROUP"

  # Cria o usuário com acesso ao console
  aws iam create-user --user-name "$USERNAME"

  # Define a senha inicial e exige troca no primeiro login
  aws iam create-login-profile \
    --user-name "$USERNAME" \
    --password "$PASSWORD" \
    --password-reset-required

  # Adiciona ao grupo
  aws iam add-user-to-group \
    --user-name "$USERNAME" \
    --group-name "$GROUP"

  echo "✓ $USERNAME criado e adicionado ao grupo $GROUP"

done

echo ""
echo "Migração concluída."

Passo 4 — Executar no AWS CloudShell

O AWS CloudShell é um terminal no próprio console da AWS com AWS CLI já configurada e autenticada. Não é necessário instalar nada localmente.

4.1 Instalar o dos2unix

sudo yum install dos2unix -y

4.2 Fazer upload dos arquivos

No CloudShell, clique em Actions → Upload file e envie:

criar-usuarios-iam.sh
ListaDeUsuarios.csv

4.3 Preparar e executar

# converter o CSV (necessário se o arquivo foi criado no Windows)
dos2unix ListaDeUsuarios.csv

# tornar o script executável
chmod +x criar-usuarios-iam.sh

# executar
./criar-usuarios-iam.sh ListaDeUsuarios.csv

A saída esperada é uma linha de confirmação para cada usuário criado.

Passo 5 — Validar os usuários criados

Verifique os usuários no console em IAM → Users, ou via CLI:

# listar todos os usuários da conta
aws iam list-users --output table

# verificar os grupos de um usuário específico
aws iam list-groups-for-user --user-name joao.silva

# verificar todos os usuários de um grupo
aws iam get-group --group-name LinuxAdmin --output table

Passo 6 — Aplicar política de MFA obrigatório

Sem essa etapa, os usuários conseguem acessar recursos da AWS sem configurar autenticação multifator. A política abaixo bloqueia qualquer ação enquanto o MFA não estiver ativo.

6.1 Criar a política

Acesse IAM → Policies → Create policy → JSON e cole o conteúdo abaixo:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountPasswordPolicy",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice"
      ],
      "Resource": "arn:aws:iam::*:mfa/*"
    },
    {
      "Sid": "AllowManageOwnUserMFA",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Dê o nome EnforceMFAPolicy e salve.

6.2 Anexar as políticas aos grupos

Para cada grupo, adicione as duas políticas abaixo:

IAMUserChangePassword — permite que o usuário troque sua própria senha no primeiro acesso
EnforceMFAPolicy — bloqueia acesso a qualquer recurso enquanto o MFA não estiver configurado

Acesse IAM → User groups → [nome do grupo] → Permissions → Add permissions → Attach policies.

Para aplicar em todos os grupos de uma vez, use a política diretamente:

IAM → Policies → EnforceMFAPolicy → Entities attached → Attach → selecione todos os grupos → Attach

Boas práticas aplicadas

Mínimo privilégio — cada grupo tem apenas as permissões necessárias para sua função
MFA obrigatório — nenhum usuário acessa recursos sem segundo fator ativo
Troca de senha no primeiro acesso — o parâmetro --password-reset-required garante que o usuário defina sua própria senha
Automação auditável — o script e o CSV podem ser versionados e revisados
Nunca usar o usuário root — toda operação deve ser feita com usuários IAM com permissões adequadas

Considerações finais

O mesmo processo funciona para qualquer escala — 10 ou 10.000 usuários. Para ambientes maiores, o próximo passo natural é evoluir para AWS SSO (IAM Identity Center) com integração a um provedor de identidade como Azure AD ou Okta, eliminando a necessidade de gerenciar senhas individuais no IAM.

Referências

See you later 🤘🏻

Bicep: A Linguagem Moderna de IaC para Azure

Luis Cruz — Tue, 02 Jun 2026 17:46:37 +0000

Se você já trabalhou com ARM Templates na Azure, sabe bem o quanto pode ser frustrante: arquivos JSON verbosos, difíceis de ler e ainda mais difíceis de manter. O Bicep chegou para resolver exatamente isso, uma linguagem de domínio específico (DSL) criada pela Microsoft para declarar infraestrutura no Azure de forma limpa, simples e poderosa.

O que é o Bicep?

Bicep é uma linguagem de IaC (Infrastructure as Code) desenvolvida pela Microsoft que compila diretamente para ARM Templates. Ou seja, por baixo dos panos, a Azure ainda usa ARM, mas você escreve um código muito mais legível e produtivo.

"Bicep é o ARM Template que você sempre quis escrever."

Lançado em 2021 como GA (Generally Available), o Bicep é hoje a forma recomendada pela Microsoft para definir recursos Azure via código.

Por que usar Bicep e não ARM Templates puro?

Veja a diferença para criar um simples Storage Account:

ARM Template (JSON):

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccountName": {
      "type": "string"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2022-09-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2"
    }
  ]
}

Bicep (equivalente):

param storageAccountName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

Muito mais limpo, não é? Menos linhas, sem JSON aninhado e sem aquelas funções [parameters(...)] espalhadas por todo lado.

Bicep vs ARM vs Terraform: qual escolher?

Característica	Bicep	ARM Template	Terraform
Sintaxe	Limpa, DSL própria	JSON verboso	HCL
Multi-cloud	❌ Apenas Azure	❌ Apenas Azure	✅ Sim
Suporte a recursos Azure	✅ Primeiro dia	✅ Primeiro dia	⚠️ Depende do provider
Curva de aprendizado	Baixa	Alta	Média
State file	❌ Não precisa	❌ Não precisa	✅ Necessário
Módulos	✅ Sim	⚠️ Linked templates	✅ Sim
Integração nativa Azure DevOps/GitHub	✅ Nativa	✅ Nativa	Requer setup

Resumo prático:

Se você trabalha exclusivamente com Azure → Bicep é a melhor escolha
Se precisa de multi-cloud → Terraform
Se está migrando ARM existente → Bicep (tem conversor automático!)

Instalação

Pré-requisitos

Azure CLI instalado

Instalar o Bicep CLI

# Via Azure CLI (recomendado)
az bicep install

# Verificar versão
az bicep version

Extensão para VS Code

Instale a extensão oficial Bicep da Microsoft no VS Code. Ela oferece:

IntelliSense completo
Validação em tempo real
Autocompletar de tipos de recursos e propriedades
Visualização do diagrama de dependências

Conceitos Fundamentais

1. Parâmetros (`param`)

@description('Nome do ambiente')
@allowed(['dev', 'staging', 'prod'])
param environment string = 'dev'

@minLength(3)
@maxLength(24)
param storageAccountName string

Os decorators (@description, @allowed, @minLength) substituem as validações que no ARM eram feitas dentro do JSON.

2. Variáveis (`var`)

var location = resourceGroup().location
var tags = {
  environment: environment
  project: 'meu-projeto'
  managedBy: 'bicep'
}

3. Recursos (`resource`)

resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'plan-${environment}'
  location: location
  tags: tags
  sku: {
    name: 'B1'
    tier: 'Basic'
  }
}

4. Outputs (`output`)

output appServicePlanId string = appServicePlan.id
output storageAccountEndpoint string = storageAccount.properties.primaryEndpoints.blob

Exemplo Prático: Web App com Storage

Vamos criar um arquivo Bicep que provisiona um App Service + Storage Account completo:

// main.bicep

@description('Prefixo para os recursos')
param prefix string

@description('Ambiente de deploy')
@allowed(['dev', 'staging', 'prod'])
param environment string = 'dev'

var location = resourceGroup().location
var tags = {
  environment: environment
  managedBy: 'bicep'
}

// Storage Account
resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: '${prefix}${environment}st'
  location: location
  tags: tags
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
  }
}

// App Service Plan
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: '${prefix}-${environment}-plan'
  location: location
  tags: tags
  sku: {
    name: environment == 'prod' ? 'S1' : 'B1'
  }
}

// Web App
resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  name: '${prefix}-${environment}-app'
  location: location
  tags: tags
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
    siteConfig: {
      appSettings: [
        {
          name: 'STORAGE_CONNECTION'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.name};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
      ]
    }
  }
}

output webAppUrl string = 'https://${webApp.properties.defaultHostName}'
output storageAccountName string = storageAccount.name

Deploy

# Criar Resource Group
az group create --name rg-meu-projeto-dev --location brazilsouth

# Preview do que será criado (What-If)
az deployment group what-if \
  --resource-group rg-meu-projeto-dev \
  --template-file main.bicep \
  --parameters prefix=meuprojeto environment=dev

# Deploy
az deployment group create \
  --resource-group rg-meu-projeto-dev \
  --template-file main.bicep \
  --parameters prefix=meuprojeto environment=dev

Módulos: reutilizando código

Uma das funcionalidades mais poderosas do Bicep são os módulos, que permitem quebrar a infraestrutura em partes reutilizáveis:

// modules/storage.bicep
param name string
param location string = resourceGroup().location

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: name
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

output id string = storageAccount.id

// main.bicep — usando o módulo
module storage './modules/storage.bicep' = {
  name: 'storageDeployment'
  params: {
    name: 'mystorageaccount'
  }
}

output storageId string = storage.outputs.id

Você também pode referenciar módulos diretamente de um Bicep Registry (ACR) para compartilhar entre times:

module storage 'br:meuregistry.azurecr.io/bicep/storage:v1.0' = {
  name: 'storageDeployment'
  params: {
    name: 'mystorageaccount'
  }
}

Convertendo ARM Templates existentes para Bicep

Se você já tem ARM Templates, a migração é simples:

# Decompila ARM Template para Bicep
az bicep decompile --file template.json

# Converte Bicep de volta para ARM (útil para debug)
az bicep build --file main.bicep

Dicas e Boas Práticas

Use parâmetros com defaults para ambientes distintos (dev, staging, prod)
Adicione tags em todos os recursos para facilitar o custo e governança
Use what-if antes de todo deploy em produção
Organize em módulos desde o início evita refatorações grandes depois
Versione no Git junto ao código da aplicação (mesmo repositório)
Use o Bicep Registry (Azure Container Registry) para compartilhar módulos entre projetos e times

Próximos passos

Documentação oficial do Bicep
Bicep Playground — teste Bicep no browser
Azure Verified Modules — módulos Bicep oficiais e auditados pela Microsoft

O Bicep é, sem dúvida, a evolução natural para quem trabalha com IaC na Azure. Se você ainda usa ARM Templates puros, vale muito a pena considerar a migração, pois a curva de aprendizado é baixa e os ganhos em produtividade e manutenibilidade são imediatos.

E você, já está usando Bicep nos seus projetos? Deixa nos comentários!

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 2 e o Docker

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

Se você usa Windows e precisa trabalhar com Docker, Terraform, scripts Bash ou qualquer ferramenta nativa de Linux, o WSL 2 (Windows Subsystem for Linux) é o caminho certo. Ele roda um kernel Linux real dentro do Windows — sem dual boot, sem máquina virtual pesada — e se integra perfeitamente com o Docker.

Neste artigo você vai instalar o WSL 2 com Ubuntu e configurar o Docker, com duas opções: via Docker Desktop (mais simples) ou via Docker Engine direto no Linux (mais leve).

Pré-requisitos

Windows 11 ou Windows 10 (build 19041 ou superior)
Virtualização por hardware habilitada na BIOS/UEFI
Conexão à internet

Para verificar se a virtualização está ativa, abra o Gerenciador de Tarefas → aba Desempenho → CPU → confirme que "Virtualização: Habilitado" aparece.

1. Instalar o WSL 2

Abra o PowerShell como Administrador e execute:

wsl --install

Este comando habilita os componentes necessários, instala o WSL 2 e baixa o Ubuntu como distribuição padrão. Ao final, reinicie o computador quando solicitado.

Para instalar uma distribuição diferente, use:

# listar distribuições disponíveis
wsl --list --online

# instalar uma específica
wsl --install -d Debian

Verificar a instalação

wsl --version
wsl -l -v

A coluna VERSION deve mostrar 2 para confirmar que está usando WSL 2. Novas instalações com wsl --install já são configuradas para WSL 2 por padrão.

Para instruções detalhadas, consulte a documentação oficial da Microsoft.

2. Instalar o Docker

Você tem duas opções. Escolha a que melhor se encaixa no seu uso:

	Docker Desktop	Docker Engine no WSL
Interface gráfica	✅ Sim	❌ Não
Facilidade	Alta	Média
Consumo de recursos	Maior	Menor
Licença	Gratuito para uso pessoal	Open source
Recomendado para	Iniciantes e uso geral	Devs que preferem CLI

Opção A: Docker Desktop com integração WSL 2

Baixe o Docker Desktop para Windows
Durante a instalação, mantenha marcada a opção Use WSL 2 instead of Hyper-V
Após instalar, abra o Docker Desktop e vá em Settings → General → ative Use the WSL 2 based engine
Em Settings → Resources → WSL Integration, habilite a distro que você usa (ex: Ubuntu)
Abra o terminal do WSL — os comandos docker e docker compose já estarão disponíveis

docker --version
docker compose version

Opção B: Docker Engine dentro do Ubuntu (WSL 2)

Abra o terminal do Ubuntu no WSL e execute os passos abaixo.

Adicionar o repositório oficial do Docker:

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

Instalar o Docker Engine e o Compose:

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

Adicionar seu usuário ao grupo docker (evita usar sudo a cada comando):

sudo usermod -aG docker $USER

Reiniciar o WSL para aplicar as permissões. No PowerShell:

wsl --shutdown

Reabra o terminal do Ubuntu.

Iniciar o daemon do Docker:

sudo service docker start

Se quiser que o Docker inicie automaticamente, ative o systemd no WSL adicionando ao /etc/wsl.conf:
[boot]
systemd=true
Após salvar, execute wsl --shutdown no PowerShell e reabra o WSL.

Verificar a instalação:

docker run --rm hello-world
docker compose version

Consulte o guia oficial de instalação no Ubuntu para mais detalhes.

3. Exemplos práticos

Subir um NGINX

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

Acesse http://localhost:8080 no navegador do Windows, o Docker no WSL expõe as portas automaticamente para o host.

Usar Docker Compose

Crie um arquivo compose.yml:

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

# subir os serviços
docker compose up -d

# verificar status
docker compose ps

# ver logs em tempo real
docker compose logs -f

# encerrar e remover os containers
docker compose down

Referências

O que é Gemba? E como aplicar em times de DevOps remotos

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

Gemba (現場) é um termo japonês que significa, literalmente, "o lugar real" ou "onde as coisas acontecem". Popularizado pelo Lean Manufacturing, o conceito é simples: para entender um problema de verdade, você precisa ir até onde ele acontece, não confiar apenas em relatórios ou reuniões.

Mas o que isso tem a ver com times de DevOps, engenharia de software e ambientes remotos? Muito mais do que parece.

O que é Lean?

Antes de aprofundar no Gemba, vale contextualizar: o Lean (também chamado de Lean Thinking ou Mentalidade Enxuta) é uma filosofia de gestão originada na Toyota que busca maximizar valor e eliminar desperdícios em processos. Nos últimos anos, seus princípios migraram da manufatura para times de tecnologia — e se tornaram base de frameworks como DevOps, Agile e SRE.

O Gemba é um dos pilares práticos do Lean.

O conceito de Gemba

No contexto empresarial, o Gemba é o local onde o valor é criado:

Em uma fábrica → o chão de produção
Em uma empresa de software → onde os desenvolvedores codificam e operam sistemas
Em uma loja de varejo → o piso de atendimento ao cliente

A filosofia incentiva líderes e gestores a irem até esse local para:

Observar os processos diretamente
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, não em suposições

Gemba Walk

O conceito associado mais conhecido é o Gemba Walk — uma visita estruturada ao local de trabalho com o objetivo de:

Entender o fluxo de trabalho real
Detectar desperdícios ou gargalos
Promover a melhoria contínua (Kaizen)
Fortalecer o relacionamento entre gestão e equipe

Importante: o Gemba Walk não é uma auditoria ou fiscalização. É uma oportunidade de aprendizado mútuo — a ideia é entender, não julgar.

Princípios de uma boa prática de Gemba

Princípio	Como aplicar
Ir ao Gemba	Visite o local real com frequência, sem intermediários
Observar com propósito	Veja como o trabalho realmente é feito, não como deveria ser
Fazer perguntas	Entenda os "porquês" por trás dos processos
Ouvir os colaboradores	Eles conhecem os desafios diários melhor que qualquer relatório
Agir com respeito	A ideia é aprender, nunca expor ou pressionar
Promover melhorias	Use os insights para implementar melhorias sustentáveis

Benefícios do Gemba

Aumento da eficiência operacional
Redução de desperdícios no fluxo de trabalho
Maior engajamento e confiança da equipe
Tomada de decisão mais assertiva e baseada em fatos
Cultura de melhoria contínua enraizada no dia a dia

Como aplicar Gemba e Lean com trabalho remoto e times distribuídos

Essa é a pergunta prática: como ir ao "lugar real" quando o time está espalhado em fusos diferentes?

A resposta é que o Gemba não precisa ser físico — ele precisa ser real. Em times remotos, o Gemba é o espaço digital onde o trabalho acontece.

Redefinindo o Gemba no remoto

O "lugar real" de um time de tecnologia remoto está em:

Repositórios de código — GitHub, GitLab (onde o trabalho é registrado)
Sistemas de tickets — Jira, Linear, ServiceNow (onde o fluxo é visível)
Dashboards de observabilidade — Grafana, Prometheus, Datadog (onde os problemas aparecem)
Ferramentas de colaboração — Slack, Teams, Confluence (onde as decisões acontecem)
Pipelines de CI/CD — onde o valor chega ao cliente

Fazendo Gemba Walks digitais

Ação	Como adaptar no remoto
Observar o trabalho em tempo real	Sessões de pair programming, compartilhamento de tela, gravações de Loom
Fazer perguntas abertas	Check-ins por vídeo ou threads assíncronas no Slack/Teams
Identificar desperdícios	Analisar tempo de espera em PRs, filas de aprovação, lead time no Jira
Documentar aprendizados	Logs de Gemba Walks no Confluence ou Notion

Aplicando Lean no remoto

Mapeie o fluxo de valor digital (Value Stream Mapping)

Entenda todas as etapas entre a demanda e a entrega. Exemplo em infraestrutura:

Solicitação → Escrita do Terraform → Code Review → CI/CD → Validação → Deploy → Monitoramento

Cada etapa pode ter desperdícios escondidos — tempo de espera, retrabalho, falta de clareza.

Identifique desperdícios remotos

Espera por aprovações manuais
Retrabalho por requisitos mal definidos
Sobrecarga por excesso de reuniões
Falta de visibilidade do progresso para o time

Estimule o Kaizen remoto

Faça retrospectivas Lean curtas e frequentes (não apenas no fim do sprint)
Capture ideias de melhoria em murais colaborativos (Miro, FigJam)
Implemente pequenas melhorias rápidas e meça os resultados antes de escalar

Ferramentas para suportar Lean + Gemba em times remotos

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

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

Problema identificado	Gemba Walk digital	Ação Lean
Demora no provisionamento de VMs	Acompanhar fluxo no Terraform + GitLab CI com a equipe	Automatizar aprovações com policy as code
Incidentes frequentes em produção	Analisar logs no Grafana + entrevistar o on-call	Criar runbooks e alertas mais precisos
Backlog sem clareza	Revisitar o Jira ao vivo com o time	Definir Definition of Ready para cada ticket

Conclusão

O Gemba não é um conceito preso em fábricas japonesas dos anos 1950. É uma mentalidade que permanece relevante em qualquer contexto onde haja trabalho real acontecendo — incluindo times de DevOps, engenharia de plataforma e operações em nuvem.

A chave está em fazer a pergunta certa: onde, de fato, o trabalho acontece no nosso time? E depois ir lá — seja fisicamente ou digitalmente — para observar, ouvir e melhorar de forma contínua.

Referências

Em inglês:

Em português:

Instalando o Terraform no Debian 12 (Bookworm)

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

O Terraform é a principal ferramenta de infraestrutura como código (IaC) do mercado, desenvolvida pela HashiCorp. Com ele você descreve sua infraestrutura em arquivos .tf e aplica mudanças de forma previsível e rastreável em dezenas de providers — AWS, Azure, GCP, Docker e muito mais.

Neste artigo você vai instalar o Terraform no Debian 12 (Bookworm) a partir do repositório oficial da HashiCorp e validar a instalação com um exemplo prático: subir um container NGINX com Docker gerenciado pelo Terraform.

Segurança: sempre verifique a impressão digital (fingerprint) da chave GPG antes de adicionar repositórios externos. O passo de verificação está incluído abaixo.

Pré-requisitos

Atualize o sistema e instale as dependências necessárias:

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

gnupg e ca-certificates — verificação de assinaturas GPG
lsb-release — obtém o codinome da distribuição de forma confiável

1. Adicionar o repositório oficial da HashiCorp

Baixe e registre a chave GPG no formato esperado pelo APT:

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

Adicione o repositório usando o codinome da sua distro e a arquitetura detectadas automaticamente:

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

O lsb_release -cs é a fonte principal; o grep no /etc/os-release é o fallback caso lsb-release não esteja disponível.

2. Instalar o Terraform

sudo apt-get update
sudo apt-get install -y terraform

Confirme a versão instalada:

terraform -version

Saída esperada (versão pode variar):

Terraform v1.10.x
on linux_amd64

Para instalar uma versão específica, use sudo apt-get install -y terraform=1.9.8-1 ou baixe o binário diretamente em releases.hashicorp.com.

3. Verificar a chave GPG (fingerprint)

Confirme que a chave instalada corresponde à publicada pela HashiCorp:

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

Compare o fingerprint retornado com o valor oficial publicado em hashicorp.com/security. Se não bater, remova o keyring e refaça o processo.

4. Exemplo prático: Terraform + Docker + NGINX

Vamos provisionar um container NGINX via Terraform para validar a instalação.

Pré-requisitos do exemplo

Docker instalado e em execução
Usuário com permissão no socket Docker: sudo usermod -aG docker $USER (relogin necessário)

Estrutura do projeto

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

Crie o arquivo main.tf:

nano main.tf

Arquivo main.tf

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 3.6"
    }
  }
}

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
  }
}

Fluxo de execução

1. Inicializar — baixa o provider Docker e cria o terraform.lock.hcl:

terraform init

2. Formatar e validar — garante que o código está correto antes de aplicar:

terraform fmt
terraform validate

3. Planejar — visualize o que será criado sem aplicar nada:

terraform plan

4. Aplicar — cria os recursos. Confirme digitando yes quando solicitado:

terraform apply

Verificar

Acesse http://localhost:8000 no navegador ou via curl:

curl -s -o /dev/null -w "%{http_code}" http://localhost:8000
# esperado: 200

Liste o container criado:

docker ps --filter name=tutorial-nginx

Destruir os recursos

Quando terminar, remova tudo o que o Terraform criou:

terraform destroy

Confirme com yes. Em pipelines automatizados, use --auto-approve com cautela, nunca em produção sem controles adicionais.

Referência rápida dos comandos

Comando	O que faz
`terraform init`	Inicializa o projeto e baixa providers
`terraform fmt`	Formata os arquivos `.tf`
`terraform validate`	Valida sintaxe e configurações
`terraform plan`	Mostra o que será criado/alterado/destruído
`terraform apply`	Aplica as mudanças
`terraform destroy`	Remove todos os recursos gerenciados

Boas práticas

Trave versões: use required_version e version nos required_providers para evitar quebras por atualização automática
Commit do lock file: versione o terraform.lock.hcl para garantir builds reproduzíveis no time
Nunca suba segredos em .tf: use variáveis de ambiente, terraform.tfvars (fora do git) ou HashiCorp Vault
Planeje antes de aplicar: em produção, sempre use terraform plan -out=tfplan e revise antes de terraform apply tfplan
Verifique fingerprints GPG ao adicionar novos repositórios

Referências

Monitorando Windows com Prometheus e Windows Exporter

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

Saber o que está acontecendo nos seus servidores e máquinas Windows em tempo real é essencial para manter a saúde do ambiente. Com o Prometheus e o Windows Exporter, você coleta métricas de CPU, memória, disco, rede e muito mais, visualizando tudo em dashboards profissionais no Grafana.

Neste artigo você vai configurar toda essa stack em minutos usando Docker.

Arquitetura da solução

O Windows Exporter roda diretamente no host Windows e expõe as métricas em /metrics. O Prometheus faz o scrape dessas métricas em intervalos configuráveis. O Grafana consulta o Prometheus e exibe os dados em dashboards.

Pré-requisitos

Docker com Compose V2 instalado (docker compose version)
Acesso de administrador na máquina Windows a monitorar
Porta 9182 liberada no firewall do Windows

1. Clonar o repositório

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

2. Configurar o Prometheus

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

Atenção com a indentação: o YAML é sensível a espaços. Use sempre espaços, nunca tabs.

Adicione uma entrada para cada host Windows na seção de jobs:

scrape_configs:
  - job_name: 'windows-server-01'
    scrape_interval: 15s
    static_configs:
      - targets: ['IP-DO-HOST:9182']
        labels:
          hostname: 'windows-server-01'

  - job_name: 'windows-server-02'
    scrape_interval: 15s
    static_configs:
      - targets: ['IP-DO-HOST-2:9182']
        labels:
          hostname: 'windows-server-02'

Recomende criar uma entrada por host para facilitar a identificação nos dashboards.

3. Instalar o Windows Exporter no Host

Acesse a página de releases do Windows Exporter no GitHub e baixe a versão mais recente do arquivo .msi.

64 bits: windows_exporter-X.X.X-amd64.msi
32 bits: windows_exporter-X.X.X-386.msi

Após o download, abra o terminal como Administrador e execute (ajuste o nome do arquivo para a versão baixada):

msiexec /i windows_exporter-0.29.2-amd64.msi

O instalador registra o Windows Exporter como serviço do Windows e o inicia automaticamente na porta 9182.

Para confirmar que está funcionando, abra o navegador e acesse:

http://localhost:9182/metrics

Se você ver uma saída com centenas de linhas de métricas, está tudo certo.

Firewall: caso não consiga acessar a porta de outro host, libere a porta 9182 no Windows Defender Firewall:
netsh advfirewall firewall add rule name="Windows Exporter" protocol=TCP dir=in localport=9182 action=allow

4. Subir o ambiente com Docker

Na raiz do repositório, execute:

docker compose up -d

Aguarde o download das imagens e verifique se os containers estão saudáveis:

docker compose ps

Acesse os serviços:

Serviço	Endereço
Grafana	http://localhost:3000
Prometheus	http://localhost:9090

5. Acessar o Grafana

Abra http://localhost:3000 no navegador.

Usuário: admin
Senha:   grafana

Segurança: troque a senha imediatamente após o primeiro acesso em Profile → Change password. Nunca use as credenciais padrão em ambientes de produção ou expostos à rede.

No menu lateral, acesse Dashboards e abra o dashboard Windows Exporter for Prometheus. Você verá os dados do seu host sendo coletados em tempo real.

Principais métricas coletadas

Métrica	Descrição
`windows_cpu_time_total`	Uso de CPU por estado (idle, user, privileged)
`windows_memory_available_bytes`	Memória RAM disponível
`windows_logical_disk_free_bytes`	Espaço livre em disco por volume
`windows_net_bytes_received_total`	Tráfego de rede recebido
`windows_net_bytes_sent_total`	Tráfego de rede enviado
`windows_os_info`	Informações do SO (versão, build)
`windows_service_state`	Estado dos serviços do Windows

Troubleshooting

Prometheus não coleta métricas do host

Verifique se a porta 9182 está acessível: telnet IP-DO-HOST 9182
Confirme se o serviço windows_exporter está rodando: Get-Service windows_exporter no PowerShell
Cheque o firewall conforme o passo 3

Grafana não exibe dados

Acesse http://localhost:9090/targets no Prometheus e confirme que o target está com status UP
Verifique se o IP no prometheus.yml está correto e acessível a partir do container

Erro ao subir os containers

Certifique-se de usar o Docker Compose V2: docker compose version (sem hífen)
Verifique se as portas 3000 e 9090 não estão em uso: netstat -tulnp | grep -E '3000|9090'

Para mais informações

Dúvidas ou sugestões? Deixa nos comentários! 🤘🏻

DEV Community: Luis Cruz

AWS - Projeto Cloud: Implementação IAM

Pré-requisitos

Parte 1 — Criação e Migração de Usuários

Passo 1 — Criar os Grupos IAM

Passo 2 — Preparar o arquivo CSV

Passo 3 — O script de criação de usuários

Passo 4 — Executar no AWS CloudShell

Passo 5 — Validar os usuários criados

Passo 6 — Permitir troca de senha no primeiro acesso

Testando o acesso (Passo a passo)

Parte 2 — Boas Práticas de Segurança

Passo 1 — Habilitar MFA no usuário Root

Passo 2 — Criar e aplicar a política EnforceMFAPolicy

Passo 3 — Configurar política de senhas da conta

Passo 4 — Testar o bloqueio por MFA

Resumo do que foi implementado

Referências

Automatizando a Migração de Usuários e o Gerenciamento de IAM na AWS

O que é o IAM?

Visão geral da solução

Passo 1 — Criar os Grupos IAM

Passo 2 — Montar o arquivo CSV

Passo 3 — O script de criação de usuários

Passo 4 — Executar no AWS CloudShell

4.1 Instalar o dos2unix

4.2 Fazer upload dos arquivos

4.3 Preparar e executar

Passo 5 — Validar os usuários criados

Passo 6 — Aplicar política de MFA obrigatório

6.1 Criar a política

6.2 Anexar as políticas aos grupos

Boas práticas aplicadas

Considerações finais

Referências

Bicep: A Linguagem Moderna de IaC para Azure

O que é o Bicep?

Por que usar Bicep e não ARM Templates puro?

Bicep vs ARM vs Terraform: qual escolher?

Instalação

Pré-requisitos

Instalar o Bicep CLI

Extensão para VS Code

Conceitos Fundamentais

1. Parâmetros (param)

2. Variáveis (var)

3. Recursos (resource)

4. Outputs (output)

Exemplo Prático: Web App com Storage

Deploy

Módulos: reutilizando código

Convertendo ARM Templates existentes para Bicep

Dicas e Boas Práticas

Próximos passos

Automação GitOps com Terraform e Proxmox

Windows - Instalando o WSL 2 e o Docker

Pré-requisitos

1. Instalar o WSL 2

Verificar a instalação

2. Instalar o Docker

Opção A: Docker Desktop com integração WSL 2

Opção B: Docker Engine dentro do Ubuntu (WSL 2)

3. Exemplos práticos

Subir um NGINX

Usar Docker Compose

Referências

O que é Gemba? E como aplicar em times de DevOps remotos

O que é Lean?

O conceito de Gemba

Gemba Walk

Princípios de uma boa prática de Gemba

Benefícios do Gemba

Como aplicar Gemba e Lean com trabalho remoto e times distribuídos

Redefinindo o Gemba no remoto

Fazendo Gemba Walks digitais

Aplicando Lean no remoto

Mapeie o fluxo de valor digital (Value Stream Mapping)

Identifique desperdícios remotos

Estimule o Kaizen remoto

Ferramentas para suportar Lean + Gemba em times remotos

1. Parâmetros (`param`)

2. Variáveis (`var`)

3. Recursos (`resource`)

4. Outputs (`output`)