O problema

Você pede uma tarefa longa para o agente, troca de janela para fazer outra coisa e volta vinte minutos

depois. O agente trabalhou por um minuto, parou para pedir aprovação de um comando e ficou os outros

dezenove esperando você olhar para a tela.

Escrevi sobre como eu opero agentes no dia a dia, e o ponto central

lá é que o objetivo é deixar de ser a peça que dá o próximo passo. Só que existe um ponto do ciclo em que

o humano é obrigatório: aprovar uma operação destrutiva, responder uma pergunta, decidir entre dois

caminhos. Esse ponto não dá para automatizar, mas dá para encurtar. Se o agente para às 14h02 e você

descobre às 14h21, dezenove minutos foram embora por um motivo bobo: ninguém te avisou.

Este artigo é o passo a passo de como resolver isso no ambiente que eu uso, que é provavelmente o mais

comum entre quem trabalha com plataforma no Windows: Claude Code via CLI, rodando no WSL, dentro do

terminal integrado do VS Code.

O caminho nativo: preferredNotifChannel

O Claude Code tem uma configuração própria de notificação. Ela vive no settings.json e aceita estes

valores:

O detalhe que importa: auto não entrega nada no terminal integrado do VS Code. A detecção procura

iTerm2, Kitty ou Ghostty. Não achando nenhum, ela não tem para onde mandar e silenciosamente não faz nada.

Como o padrão é auto, a conclusão natural de quem roda no VS Code é que "o Claude Code não notifica",

quando na verdade ele está notificando para um canal que não existe ali.

O que funciona nesse terminal é o bell:

// ~/.claude/settings.json
{
  "preferredNotifChannel": "terminal_bell"
}

E, do lado do VS Code:

// settings.json do VS Code
{
  "terminal.integrated.enableBell": true
}

Com os dois ligados, a aba do terminal ganha um ícone de sino quando o agente pede atenção. É barato e vale

a pena ligar. Mas resolve pouco: só te ajuda se você já estiver com o VS Code na tela. Se você trocou de

janela — que é exatamente o caso do problema — um marcador dentro da janela que você não está vendo não

serve de nada.

Para isso a gente precisa de hooks.

A pegadinha do escopo: usuário ou projeto?

Antes do código, o erro que faz um hook correto nunca rodar.

O Claude Code tem dois lugares para declarar hooks: o settings.json do projeto

(.claude/settings.json no repositório) e o do usuário (~/.claude/settings.json). A diferença é

sutil e cara: o settings.json de projeto só é lido quando a sessão abre naquele diretório.

Eu tinha um hook de notificação declarado no .claude/settings.json da raiz do meu workspace. Só que eu

quase nunca abro o Claude Code na raiz: eu abro dentro de um repositório específico, um nível abaixo. E,

aberta lá, a sessão carrega as skills e rules herdadas, mas não carrega aquele bloco de hooks. Ou seja:

o hook existia, estava correto, e não rodava praticamente nunca. Nenhum erro, nenhum aviso. Só silêncio.

A regra que eu tiro disso é simples. Hook de domínio vai no projeto; hook transversal vai no usuário.

Um guardrail que valida manifesto de Kubernetes só faz sentido no repositório que tem manifesto. Já

notificação não tem nada a ver com o repositório: eu quero ser avisado em qualquer sessão, em qualquer

diretório. Então ela vai no escopo de usuário:

// ~/.claude/settings.json
{
  "preferredNotifChannel": "terminal_bell",
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash $HOME/.claude/hooks/notify-desktop.sh",
            "timeout": 10
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash $HOME/.claude/hooks/notify-desktop.sh",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

Dois detalhes desse bloco:

Aqui isso não serve: essa variável aponta para o repositório da sessão atual, que muda a cada vez. Como o

script é único e global, ele precisa de um caminho fixo.

projeto, os dois rodam. É ótimo quando são coisas diferentes: no meu caso, o Stop de usuário notifica e

o Stop do projeto imprime um resumo dos arquivos de infra tocados na sessão, e um não atrapalha o outro.

Vira problema quando é o mesmo hook nos dois lugares: aí você recebe a notificação duas vezes. Ao mover um

hook para o escopo de usuário, lembre de tirar do projeto.

O notificador: por que piscar a barra de tarefas

A escolha óbvia no Windows é o toast, aquele balão no canto inferior direito. Eu comecei por ele e ele não

resolveu, por um motivo que provavelmente vale para muita gente.

Notificações, onde só aparece se você abrir (Win+N). Como o "Não perturbe" é justamente o que a gente liga

para conseguir trabalhar, o canal que deveria te chamar é o primeiro a ser silenciado. E o som, que seria o

plano B, morre junto se o volume estiver em zero, o que num notebook em reunião é o normal.

O que sobrevive aos dois é a API mais velha da lista: FlashWindowEx, que pisca o botão da janela na

barra de tarefas. Ela não passa pelo subsistema de notificações do Windows, então "Não perturbe" não a

afeta; não emite som, então volume zero não a afeta. E, com a combinação certa de flags, ela pisca até a

janela receber foco: se você voltar dez minutos depois, o ícone ainda está laranja te esperando.

De brinde, ela se autossuprime: chamar FlashWindowEx numa janela que já está em foco não faz nada. Isso

é exatamente o comportamento que a gente quer, porque se o VS Code está em foco você já está olhando.

O script abaixo faz as duas coisas: pisca (canal principal) e dispara o toast (que serve como histórico na

Central de Notificações, mesmo entrando mudo).

# ~/.claude/hooks/notify-desktop.ps1
param(
  [string]$Title = 'Claude Code',
  [string]$Body  = 'Precisa da sua atencao'
)

$SkipWhenFocused = $true

$ErrorActionPreference = 'SilentlyContinue'

Add-Type @'
using System;
using System.Runtime.InteropServices;
public class ClaudeNotify {
  [StructLayout(LayoutKind.Sequential)]
  public struct FLASHWINFO {
    public uint cbSize; public IntPtr hwnd; public uint dwFlags; public uint uCount; public uint dwTimeout;
  }
  [DllImport("user32.dll")] static extern bool FlashWindowEx(ref FLASHWINFO pwfi);
  [DllImport("user32.dll")] public static extern IntPtr GetForegroundWindow();

  const uint FLASHW_ALL = 3;        // titulo + botao na barra de tarefas
  const uint FLASHW_TIMERNOFG = 12; // pisca ate a janela receber foco

  public static void FlashUntilFocused(IntPtr hwnd) {
    FLASHWINFO f = new FLASHWINFO();
    f.cbSize = (uint)Marshal.SizeOf(f);
    f.hwnd = hwnd;
    f.dwFlags = FLASHW_ALL | FLASHW_TIMERNOFG;
    f.uCount = 0;
    f.dwTimeout = 0;
    FlashWindowEx(ref f);
  }
}
'@

$window = Get-Process -Name Code -ErrorAction SilentlyContinue |
          Where-Object { $_.MainWindowHandle -ne 0 } |
          Select-Object -First 1

if ($window) {
  if ($SkipWhenFocused -and [ClaudeNotify]::GetForegroundWindow() -eq $window.MainWindowHandle) {
    exit 0
  }
  [ClaudeNotify]::FlashUntilFocused($window.MainWindowHandle)
}

try {
  [Windows.UI.Notifications.ToastNotificationManager, Windows.UI.Notifications, ContentType=WindowsRuntime] | Out-Null
  $template = [Windows.UI.Notifications.ToastNotificationManager]::GetTemplateContent(
    [Windows.UI.Notifications.ToastTemplateType]::ToastText02)
  $nodes = $template.GetElementsByTagName('text')
  $nodes.Item(0).AppendChild($template.CreateTextNode($Title)) | Out-Null
  $nodes.Item(1).AppendChild($template.CreateTextNode($Body))  | Out-Null
  [Windows.UI.Notifications.ToastNotificationManager]::CreateToastNotifier('Microsoft.VisualStudioCode').Show(
    [Windows.UI.Notifications.ToastNotification]::new($template))
} catch { }

exit 0

Uma observação sobre o AppId Microsoft.VisualStudioCode na chamada do toast: o Windows 11 descarta em

silêncio toasts de AppIds que não estão registrados na máquina. O AppId do PowerShell normalmente não está,

e é por isso que muito exemplo de internet "funciona" (a API retorna sucesso) sem nunca mostrar nada.

Usar o AppId de um aplicativo que já é registrado resolve, e de quebra o toast sai com o ícone dele.

Se você quiser o toast furando o "Não perturbe", dá: Configurações → Sistema → Notificações → Não perturbe

→ Definir notificações prioritárias, e adicione o Visual Studio Code. É opcional: o canal principal aqui

não depende disso.

O roteador: o que o hook recebe e como decidir

O script PowerShell sabe como avisar. Falta decidir quando avisar e o quê dizer, e isso vem do JSON

que o Claude Code entrega no stdin do hook.

O evento Notification traz message, title (opcional) e, o campo que interessa,

Já o evento Stop, que dispara no fim de cada turno, traz last_assistant_message, a última mensagem

do agente. Dá para usar a primeira linha dela como corpo da notificação, o que é bem melhor do que um

genérico "terminei": você lê o que aconteceu direto do toast, sem voltar para a janela.

Tratar esses tipos de forma diferente é o que separa uma notificação útil de um incômodo. Aprovação é

urgente; auth_success é ruído e não deveria te interromper nunca.

Antes do script, uma dependência: ele usa jq para ler o JSON, e o Ubuntu do WSL não vem com ele. Como

o script sai em silêncio quando o jq falta (é o comportamento correto para um hook, mas é indistinguível

de "não funcionou"), instale primeiro:

sudo apt install -y jq

#!/usr/bin/env bash
# ~/.claude/hooks/notify-desktop.sh
set +e

# Kill-switches: um geral (se voce ja tiver um para seus hooks) e um so da notificacao.
if [ "${HOOKS_ENABLED}" = "false" ]; then exit 0; fi
if [ "${CLAUDE_NOTIFY}" = "off" ]; then exit 0; fi
command -v powershell.exe >/dev/null 2>&1 || exit 0

raw_input="$(cat 2>/dev/null)"
[ -z "$raw_input" ] && exit 0
command -v jq >/dev/null 2>&1 || exit 0

event="$(printf '%s' "$raw_input" | jq -r '.hook_event_name // ""' 2>/dev/null)"

case "$event" in
  Notification)
    ntype="$(printf '%s' "$raw_input" | jq -r '.notification_type // ""' 2>/dev/null)"
    case "$ntype" in
      permission_prompt|agent_needs_input) body="Precisa da sua aprovacao" ;;
      idle_prompt)                         body="Esperando sua resposta" ;;
      *)                                   exit 0 ;;   # auth_success, quota: ruido
    esac
    ;;
  Stop)
    last="$(printf '%s' "$raw_input" \
      | jq -r '(.last_assistant_message // "") | split("\n")[0] | .[0:120]' 2>/dev/null)"
    if [ -n "$last" ]; then body="Terminei: ${last}"; else body="Terminei"; fi
    ;;
  *)
    exit 0
    ;;
esac

# powershell.exe nao enxerga caminho WSL; converter para o caminho Windows.
script_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
ps1_win="$(wslpath -w "${script_dir}/notify-desktop.ps1" 2>/dev/null)"
[ -z "$ps1_win" ] && exit 0

body="${body//\'/}"
body="${body//\"/}"

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "$ps1_win" \
  -Title "Claude Code" -Body "$body" >/dev/null 2>&1 &

exit 0

Três decisões nesse script que valem explicação:

Sem a conversão para o caminho Windows, ele simplesmente não acha o arquivo. Vale saber o que sai dessa

conversão, porque não é o que a gente espera: como o script mora no filesystem do WSL, o caminho é UNC

(\\wsl.localhost\Ubuntu\home\voce\...), não C:\.... Só o que está em /mnt/c/ vira letra

de unidade. Para a chamada tanto faz, o PowerShell abre os dois, mas se você for depurar à mão é bom não

estranhar.

C# em tempo de execução. O hook tem timeout, e segurar o agente por um segundo a cada notificação é um

imposto que não faz sentido pagar. Jogando para background, o hook retorna em milissegundos.

notificação nunca deve quebrar a sessão por causa de si mesmo. O preço desse desenho é o da seção anterior:

falta de dependência e funcionamento normal têm exatamente a mesma cara, então instale o jq antes de

concluir que a receita não funciona.

Testando — e por que meus dois primeiros testes não valeram nada

Essa parte é a que eu mais quero que fique, porque eu errei aqui.

Escrevi o script, rodei à mão para testar e não vi nada. Rodei de novo, nada. A primeira reação foi achar

que o script estava quebrado. Só que não estava: o teste é que era inválido.

Os dois primeiros testes rodaram com o VS Code em foco. Nessa condição, o script sai antes de piscar (é o

é uma operação que existe. Eu tinha testado, com capricho, exatamente a condição em que o comportamento

correto é não acontecer nada.

A segunda tentativa foi disparar com atraso fixo: "dispara em 12 segundos, troque de janela". Também não

valeu: aos 12 segundos eu ainda estava no VS Code, lendo a mensagem que mandava eu sair dele.

O teste que presta tira o tempo da equação. Em vez de contar segundos, ele espera o foco sair e dispara

no instante em que sai:

# espera o VS Code perder o foco e so entao dispara
$code = Get-Process -Name Code | Where-Object { $_.MainWindowHandle -ne 0 } | Select-Object -First 1
$deadline = (Get-Date).AddSeconds(90)
while ((Get-Date) -lt $deadline) {
  if ([ClaudeNotify]::GetForegroundWindow() -ne $code.MainWindowHandle) {
    [ClaudeNotify]::FlashUntilFocused($code.MainWindowHandle)
    'Disparado.'
    break
  }
  Start-Sleep -Milliseconds 800
}

E os caminhos do hook em si, com o VS Code minimizado ou em outra tela:

# pedido de aprovacao
echo '{"hook_event_name":"Notification","notification_type":"permission_prompt"}' \
  | bash ~/.claude/hooks/notify-desktop.sh

# fim de turno, com a mensagem real no corpo
echo '{"hook_event_name":"Stop","last_assistant_message":"Terminei o refactor."}' \
  | bash ~/.claude/hooks/notify-desktop.sh

# tipo de ruido: nao deve notificar nada
echo '{"hook_event_name":"Notification","notification_type":"auth_success"}' \
  | bash ~/.claude/hooks/notify-desktop.sh

A lição que sobra é maior que o script: a API retornar sucesso não é verificação. No caminho do toast,

o Windows aceitou a notificação quatro vezes seguidas e devolveu OK nas quatro, e eu não vi nenhuma

delas, porque o "Não perturbe" mandava todas, mudas, direto para a Central de Notificações. "O sistema

aceitou" e "a pessoa foi avisada" são duas afirmações diferentes, e só a segunda é o objetivo. Vale para

notificação e vale para praticamente tudo em infraestrutura: o Succeeded do control plane não prova que

a coisa funciona, prova que o pedido foi aceito.

Kill-switch e detalhes finais

Duas coisas para fechar.

derrubar os hooks de guardrail. Separar os dois interruptores importa: você nunca quer estar numa situação

em que a única forma de calar a notificação é desligar as travas de segurança junto.

sessão que já está aberta continua com a configuração antiga, o que gera aquele minuto de confusão

achando que nada funcionou.

E se um dia parar de funcionar sem motivo aparente, o suspeito é a barra de tarefas com ocultação

automática: piscar um botão que não está na tela não avisa ninguém.

No fim, o que essa configuração faz é pequeno: um ícone que pisca. Mas ela devolve os dezenove minutos do

começo do artigo, e faz isso sem depender de som, sem depender de notificação ligada e sem exigir que você

fique de olho na janela. Para um ciclo em que o humano só entra nos pontos onde ele é obrigatório, o que

importa é que esses pontos sejam curtos.

Entre setembro de 2024 e setembro de 2026 o Docker Engine saiu da série 27 e chegou na 29.8.1. No caminho teve um release que derrubou acesso a container em produção, uma troca do armazenamento de imagem por padrão, a remoção de um subsistema inteiro de assinatura e a depreciação do cgroup v1.

Fora do Engine, o período teve um anúncio de cobrança no Docker Hub que foi revertido publicamente, um catálogo de imagens endurecidas que começou pago e virou open source, e uma linha de produto inteira voltada a agentes de IA.

Este artigo é o levantamento do que mudou, com a fonte oficial de cada ponto. Não é guia de migração, é mapa: o que aconteceu, quando, e o que morde na prática.

O que sobrou de 2024: a série 27

O fim da linha 27 foi de ajuste fino, quase todo em rede. As notas completas estão nas release notes do Engine 27.

• 27.2.1 (09/09/2024): atualização do runc para a v1.1.14, corrigindo a CVE-2024-45310. Corrigiu também o docker login gravando credencial sob a chave errada.
• 27.3.0 (19/09/2024): chega a flag --feature no daemon, que passa a ser o mecanismo padrão de ligar e desligar comportamento novo sem esperar release major.
• 27.4.0 (09/12/2024): portas publicadas passam a ser acessíveis entre bridge networks diferentes quando o br_netfilter está carregado e o userland-proxy está desligado. Detecção de endereço duplicado (DAD) de IPv6 foi desabilitada no bridge.
• 27.4.1 (18/12/2024): limpeza da chain DOCKER FILTER e correção de carregamento de módulo de kernel em Docker in Docker.
• 27.5.1 (22/01/2025): aparece o DOCKER_IGNORE_BR_NETFILTER_ERROR, sintoma de que o terreno de rede já estava sendo preparado para o que viria em seguida.

Engine 28.0.0, o release que quebrou rede

Publicado em 19/02/2025, é o release mais importante da janela e o que mais gerou chamado de suporte.

Até o 27.x, em Linux com iptables, qualquer host com rota até a máquina do Docker conseguia falar direto com o IP interno de um container, mesmo em porta que nunca foi publicada. Bastava saber o endereço na rede bridge, tipicamente algo em 172.17.0.0/16. Na prática, subir um banco com docker run sem -p não deixava ele isolado da rede local, deixava ele apenas sem NAT.

O 28.0.0 fecha isso. Tráfego inbound não solicitado para o IP do container passa a ser descartado na chain DOCKER, salvo se a porta foi publicada com -p ou --publish. O anúncio oficial está em Hardening Container Networking by Default.

Três detalhes que pegam gente de surpresa:

• Vale só para Linux com iptables. Docker Desktop não é afetado.
• Passa a exigir os módulos de kernel de ipset (ip_set, ip_set_hash_net e netfilter_xt_set). Em host enxuto ou kernel customizado, o daemon reclama na subida.
• O binário docker-proxy mudou e não é compatível com dockerd antigo, então atualizar os pacotes pela metade não funciona. O rootlesskit-docker-proxy foi removido.

As saídas de emergência

Se alguma coisa no ambiente dependia do comportamento antigo, existem escapes documentados. Em ordem, do mais cirúrgico para o mais amplo:

{
  "allow-direct-routing": true
}

A recomendação prática é não começar pelo allow-direct-routing, porque ele desfaz o ganho de segurança do release inteiro. Se só um host de monitoração precisa alcançar o container, trusted_host_interfaces resolve com escopo bem menor.

O 28.0 também trouxe o modo isolated para redes internal, o gw-priority, a definição de nome de interface do container via com.docker.network.endpoint.ifname, a flag --ipv4 no docker network create e IPv6 sem precisar de fixed-cidr-v6.

O que o 28.0 removeu

• O driver de log logentries.
• Plugins externos de graph-driver.
• A flag --api-cors-header.
• A flag --time em docker stop e docker restart, que virou --timeout.
• Suporte a imagens no schema 1 legado. A variável DOCKER_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE deixou de funcionar.

A série 28 depois do 28.0

As release notes do Engine 28 trazem o resto da linha:

• 28.1.0 (17/04/2025): docker bake vira comando de topo, como alias de docker buildx bake. Entra o --use-api-socket em modo experimental.
• 28.2.0 (28/05/2025): mudança de default silenciosa e relevante, o CDI (Container Device Interface) passa a vir habilitado. Bind mount com caminho relativo passa a funcionar.
• 28.3.0 (24/06/2025): suporte a GPU AMD e uso do DOCKER_AUTH_CONFIG como credential store.
• 28.3.3 (29/07/2025): corrige a CVE-2025-54388, em que um reload do firewalld reabria portas publicadas. É o contraponto irônico do 28.0: o release que fechou a rede tinha um caminho para reabrir sozinho.
• 28.4.0 (03/09/2025): GODEBUG configurável via docker context.
• 28.5.0 (02/10/2025): anúncio da depreciação do Raspberry Pi OS 32 bits após a série 28.

Engine 29.0.0, a troca de defaults

Publicado em 10/11/2025, o 29.0.0 é menos barulhento que o 28.0 mas mexe em mais coisa de uma vez. As release notes do Engine 29 listam tudo.

• O containerd image store passa a ser o padrão em instalação nova.
• docker image ls ganha uma visão nova, em árvore colapsada, e deixa de mostrar imagem sem tag a menos que você passe --all.
• O backend experimental de firewall em nftables fica disponível via firewall-backend: nftables. Vale reforçar, porque circula informação errada sobre isso: nftables não chegou no 28.x, toda a série 28 é iptables.

• cgroup v1 depreciado. O suporte segue até maio de 2029, então não é urgência, mas é o aviso formal.
• Docker Content Trust removido do CLI. A Docker publicou depois um guia de aposentadoria e migração em 16/06/2026.
• O daemon passa a exigir API v1.44 ou superior, ou seja, cliente de Docker v25.0 para cima.
• As chains DOCKER-ISOLATION-STAGE-1 e DOCKER-ISOLATION-STAGE-2 do iptables foram removidas. Se você tem automação que escreve regra apoiada nesses nomes, ela quebra em silêncio.
• O módulo Go github.com/docker/docker foi depreciado em favor de github.com/moby/moby/client e github.com/moby/moby/api.
• Pacotes Debian armhf passam a mirar ARMv7 e os pacotes de Raspbian 32 bits foram descontinuados.

Traduzindo: o containerd image store como padrão

Historicamente o Docker guardava imagem num store próprio, baseado em graph drivers como o overlay2. O containerd image store substitui essa camada pelo mesmo mecanismo que o containerd já usa, e ser padrão a partir do 29.0 muda três coisas no dia a dia.

A migração não é automática em host que já existia. Instalação nova nasce com o store novo, host antigo continua no store anterior até a troca ser feita de forma explícita, o que é bom, porque a troca não preserva as imagens já baixadas.

Traduzindo: cgroup v1 depreciado e o rootless novo

Duas mudanças que valem checagem antes de subir para o 29.

stat -fc %T /sys/fs/cgroup/
# cgroup2fs  = v2, tudo certo
# tmpfs      = v1, entra na fila de migração

A série 29 ao longo de 2026

• 29.2.0 (26/01/2026): suporte experimental a NRI (Node Resource Interface) e campo Identity no inspect.
• 29.3.0 (05/03/2026): a versão mínima de API volta de v1.44 para v1.40, recuando parcialmente a quebra do 29.0. Entra o bind-create-src no --mount.
• 29.3.1 (25/03/2026): corrige a CVE-2026-34040, bypass de autorização em plugin AuthZ, mais três CVEs de BuildKit.
• 29.4.2 (01/05/2026): o perfil seccomp padrão passa a bloquear sockets AF_ALG e a syscall socketcall(2). O efeito colateral foi conhecido e documentado: quebra programa 32 bits e imagem i386, com workaround via perfil seccomp v0.2.1.
• 29.5.0 (14/05/2026): driver rootless novo e time namespace privado, já citados.
• 29.5.1 (18/05/2026): trio de correções no docker cp, incluindo duas TOCTOU que permitiam criar arquivo arbitrário e redirecionar bind mount para caminho arbitrário do host.
• 29.6.0 (18/06/2026): endpoint de attestations e correção do COPY --chmod sendo filtrado pelo umask do daemon.
• 29.7.0 (30/07/2026): mount type=image deixa de ser experimental, entra o embedded-containerd experimental rodando containerd dentro do processo do daemon, e o default-stop-timeout.
• 29.8.0 (03/09/2026): flag --umask no docker run e create, templates de perfil AppArmor configuráveis no daemon.
• 29.8.1 (15/09/2026): versão corrente na data deste artigo.

Docker Hub: o anúncio que foi revertido

Essa é a parte do período com mais informação errada circulando, então vale reconstituir a linha do tempo com calma.

No fim de 2024 a Docker anunciou uma revisão de planos que incluía cobrança por consumo, tanto de pull quanto de storage, com limites de pull por hora previstos para 1 de março de 2025. O anúncio está em Announcing Upgraded Docker Plans, e os planos novos entraram à venda em 10/12/2024.

Em 21/02/2025, poucos dias antes da data prevista, a empresa voltou atrás em Revisiting Docker Hub Policies:

• a cobrança por consumo de pull foi cancelada de vez;
• a cobrança por storage foi adiada por tempo indeterminado;
• o aumento de rate limit previsto não foi aplicado;
• a Docker se comprometeu a anunciar qualquer mudança futura com seis meses de antecedência.

Ou seja, os números de "10 pulls por hora para anônimo" e "40 por hora para conta Personal" que ainda aparecem em post de blog e em thread de fórum são de um plano que nunca entrou em vigor. Citar eles hoje é citar documento revogado.

Os limites que valem de fato, segundo a documentação oficial de uso do Docker Hub, são contados numa janela de seis horas, não por hora:

O detalhe do IPv4 compartilhado é o que costuma doer. Um cluster inteiro atrás de um NAT, ou um runner de CI numa faixa compartilhada, consome a cota como se fosse um único usuário. É exatamente o cenário que motiva colocar um cache de registry na frente do Hub, assunto que já tratei em ACR Artifact Cache.

Planos: o reajuste do fim de 2024

O que de fato mudou de preço na janela foi a tabela de planos, em 10/12/2024:

A contrapartida foi deixar de vender Docker Build Cloud e Testcontainers Cloud como licença por assento separada, passando a incluí-los nos planos pagos, com Docker Scout ilimitado em Team e Business.

Imagens endurecidas: DHI, o fim da Minimus e o ELS

Em 19/05/2025 a Docker lançou as Docker Hardened Images, um catálogo curado de imagens mínimas, sem shell e sem package manager, rodando como usuário não root, com base Alpine ou Debian. O argumento de venda era redução de superfície de ataque na casa de 95%. O modelo, no lançamento, era pago.

Em 17/12/2025 o modelo virou: mais de mil imagens passaram a ser gratuitas e open source sob Apache 2.0, com SBOM completo, dado de CVE transparente e proveniência SLSA Build Level 3. O pago ficou restrito ao DHI Enterprise, com SLA de remediação de CVE crítico em menos de sete dias, imagens FIPS e STIG e customização.

Em 2026 o catálogo seguiu crescendo: Hardened System Packages em 03/03/2026 e, no balanço de um ano publicado em 14/04/2026, 500 mil pulls por dia e mais de 2 mil imagens.

Se o assunto é reduzir imagem sem comprar catálogo, a abordagem de imagem mínima construída na mão está em Imagens de contêiners Python no Kubernetes com Distroless.

Build e Compose

Vale uma ressalva de precisão: o docker compose watch, da seção develop, não teve anúncio de GA nessa janela. Ele amadureceu no período, mas já existia antes.

Segurança do período

Além dos CVEs já citados por release, quatro eventos merecem registro.

A virada para agentes

Boa parte do investimento da Docker nos últimos dois anos foi para IA. Em ordem:

• Model Runner ficou GA em 18/09/2025. Roda LLM local, puxa modelo do Docker Hub em formato OCI ou do HuggingFace em GGUF, expõe API compatível com a da OpenAI e usa GPU em macOS com Apple Silicon, Windows com NVIDIA ou Qualcomm e Linux. É construído sobre o llama.cpp e é open source. Em 26/02/2026 ganhou vLLM no Apple Silicon.
• MCP Catalog e MCP Toolkit foram anunciados em 22/04/2025 e ficaram disponíveis em beta em 05/05/2025, com mais de 100 servidores MCP conteinerizados no Hub e gestão de credenciais com isolamento por container.
• MCP Gateway saiu em 09/07/2025 como projeto open source, disponível em github.com/docker/mcp-gateway. É um ponto único de enforcement entre agente e servidores MCP, com --verify-signatures, --log-calls e --block-secrets. Se MCP com Docker é o assunto, escrevi sobre o uso prático em MCP Server com Docker e Terraform.
• cagent é o runtime de agentes declarado em YAML, distribuível como artefato OCI pelo Docker Hub, apresentado em 2025 e depois integrado ao Docker Desktop, com suporte a Agent Client Protocol.
• Docker Offload entrou em beta em 10/07/2025 e ficou GA em 02/04/2026, como add-on de Docker Business. Manda build e execução para infraestrutura na nuvem da Docker, com GPU opcional.
• Gordon, o agente de IA integrado ao fluxo de container, ficou GA em 19/05/2026, gratuito em qualquer conta, com um tier Gordon Plus a 20 dólares por mês.
• Docker Sandboxes é o movimento mais recente, anunciado em 30/01/2026 e detalhado em Run Agents in YOLO Mode, Safely em 31/03/2026. Roda agente de código em microVM, cada sandbox com daemon Docker, filesystem e rede próprios, via CLI sbx. A documentação diz que o CLI é gratuito inclusive para uso comercial, e que só os recursos de governança organizacional exigem assinatura. Em 16/04/2026 a Docker explicou por que microVM e não container: o VMM é proprietário justamente para funcionar em macOS e Windows.

O fio comum é o mesmo que já discuti em Loop Engineering na prática: a pergunta deixou de ser se o agente escreve código e passou a ser onde ele executa, com qual credencial e sob qual limite.

De relance

• Docker VMM entrou em public beta em 12/08/2026, reescrito para performance.
• Verified Publisher virou self-serve em 20/08/2026.
• OIDC para GitHub Actions em organizações Docker saiu em 31/07/2026, o que elimina secret de longa duração no pipeline.
• Docker Desktop passou por 4.40 (Model Runner), 4.43 (MCP Catalog remodelado e Compose Bridge, que gera configuração de Kubernetes) e 4.50 (ferramentas de debug gratuitas).
• Não há anúncio oficial de mudança de preço ou de limite do Docker Hub em 2026. O que circula em site de terceiros sobre "allowance com overage" não tem fonte primária, então não tratei como fato.

O que eu tiro disso

Olhando os dois anos inteiros, três coisas entram na minha lista de atenção.

O resto, imagem, build, Compose e registry, continua sendo o mesmo Docker de sempre, o que é uma boa notícia sobre a estabilidade da base.

Referências

• Docker Engine release notes 27
• Docker Engine release notes 28
• Docker Engine release notes 29
• Hardening Container Networking by Default
• Docker Hub: uso e limites de pull
• Revisiting Docker Hub Policies
• Announcing Upgraded Docker Plans
• Introducing Docker Hardened Images
• Docker Hardened Images grátis e open source
• Migração da Minimus para Docker Hardened Images
• Docker ELS e o fim de vida do MinIO
• GA do Docker Bake
• Build AI Agents with Docker Compose
• GA do Docker Model Runner
• Docker MCP Catalog e Toolkit
• Docker MCP Gateway
• GA do Docker Offload
• Docker Sandboxes
• Comprometimento da supply chain do Trivy
• Aposentadoria do Docker Content Trust
• runc releases e advisories

Passei na CKA (Certified Kubernetes Administrator) em 23/12/2025. Contei como foi a preparação em Como foi minha jornada para a certificação CKA, este artigo é o capítulo seguinte: o que aconteceu com o Kubernetes depois disso.

Fui atrás, release por release, do que mudou desde então. Foram três releases do Core (v1.35, v1.36 e v1.37) em nove meses, mais uma mudança grande no ecossistema de Ingress que pesa direto no dia a dia de quem administra cluster.

Três releases: 1.35, 1.36 e 1.37

v1.35 "Timbernetes" — 17/12/2025

60 enhancements (17 stable, 19 beta, 22 alpha). O destaque prático:

• In-place Pod resource updates chega a GA, permitindo ajustar CPU e memória de um Pod sem recriá-lo. Quem já teve que reiniciar um StatefulSet inteiro para subir o limite de memória de um container sabe o tamanho disso.
• Job.spec.managedBy e supplemental groups de granularidade fina, ambos GA.
• Diretório drop-in para configuração modular do kubelet, GA.
• Em beta: certificados de identidade nativos por Pod, reconciliação de rotas via watch no Cloud Controller Manager, scheduling sensível à carga do workload, tolerations com operadores numéricos e node affinity mutável em PV.

v1.36 "Haru" — 22/04/2026

70 enhancements (18 stable, 25 beta, 25 alpha), o maior salto do período.

• User Namespaces e Mutating Admission Policies chegam a GA.
• Também GA: autorização granular da API HTTPS do kubelet, SELinux labeling em mount-time, Declarative Validation e Volume Group Snapshots.
• Em beta: toda a família nova de DRA (Partitionable Devices, Consumable Capacity, Device Taints/Tolerations), Gang Scheduling API, Memory QoS via cgroup v2 e resize vertical in-place.
• Removidos de vez: o plugin de volume gitRepo (avisado desde a 1.11), o suporte a flex-volume no kubeadm e o driver in-tree do Portworx.

v1.37 "Garhwal" — 26/08/2026

67 enhancements (16 stable, 23 beta, 27 alpha, 1 remoção). Essa saiu depois de eu começar este levantamento, então vale o registro do que de fato entrou, e não do que o sneak peek prometia.

• KYAML estável na saída do kubectl: kubectl get -o kyaml sai do feature gate e passa a vir ligado por padrão em todo comando que aceita --output. Todo arquivo KYAML continua sendo YAML válido, então nada na pipeline precisa mudar, o ganho é não depender mais de indentação sensível.
• Device taints e tolerations do DRA chegam a stable, com o objeto DeviceTaintRule. Falo disso em detalhe mais abaixo.
• Também GA: Metrics API, Storage Version Migration (ligado por padrão) e Pod Certificates + ClusterTrustBundles.
• Em beta: pod-level resource managers (recursos compartilhados entre containers de um Pod, que o sneak peek anunciava como GA e acabou ficando em beta), Memory QoS, native histograms, kubelet rootless (KubeletInUserNamespace) e HPA com scale-to-zero.

Traduzindo: Mutating Admission Policies

Se você quer alterar um objeto automaticamente no momento em que ele é criado (injetar um sidecar, forçar um label, setar um default), a forma nativa até a v1.36 era escrever e hospedar um webhook: um serviço HTTP seu que o API server chama a cada request, com toda a complexidade de TLS, disponibilidade e latência que isso implica. Se o webhook cai, dependendo do failurePolicy, o cluster para de aceitar Pod.

A v1.36 transforma essa lógica de mutação em um objeto Kubernetes declarado em CEL, sem nenhum serviço próprio no ar:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: injeta-label-de-time
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: >-
          Object{ metadata: Object.metadata{ labels: {"time": "plataforma"} } }

É o mesmo raciocínio que a ValidatingAdmissionPolicy já tinha trazido para validação, agora estendido para mutação. Na prática, onde hoje existe um webhook mutador em produção (injeção de sidecar de service mesh é o caso clássico), passa a existir uma alternativa nativa sem processo externo para manter no ar.

Traduzindo: a família DRA

A Dynamic Resource Allocation já era GA na v1.34, o mecanismo por trás de scheduling de GPU e TPU deixou de ser experimental exatamente ali. O que chegou depois foram as peças que faltavam para ela ser útil em produção de verdade.

O problema do modelo antigo de device plugin: ele trata dispositivos como inteiros opacos. O nó diz "tenho 2 GPUs disponíveis" e acabou. Não dava para pedir metade de uma GPU, nem dizer quais GPUs precisam estar conectadas entre si por NVLink, nem reagir quando uma delas apresenta falha.

• Partitionable Devices (beta na 1.36) permite fatiar um acelerador em pedaços menores que "a placa inteira".
• Consumable Capacity (beta na 1.36) modela capacidade que se consome, em vez de um contador de unidades.
• Device Taints e Tolerations (beta na 1.36, stable na 1.37) aplica em dispositivos individuais o mesmo padrão de taint/toleration que hoje só existe para nós. Um driver DRA pode marcar um device como tainted para que ele seja pulado no scheduling, e o admin pode aplicar o mesmo taint no cluster inteiro via DeviceTaintRule, sem reconfigurar driver nenhum. Pods que já usam o device podem ser despejados automaticamente, a menos que o ResourceClaim tolere o taint explicitamente.

O ganho operacional é direto: uma GPU com falha de hardware pode ser marcada NoSchedule sem tirar o nó inteiro de circulação.

Networking: o fim do Ingress NGINX

De tudo que mudou no período, essa é a que mais pesa para quem administra cluster, não porque uma regra específica mudou, mas porque o controller que praticamente todo mundo usava para praticar Ingress deixou de existir como projeto ativo.

O que foi retirado — e o que não foi

O projeto retirado é o kubernetes/ingress-nginx, mantido pela comunidade sob a SIG Network, que a estimativa oficial aponta como presente em cerca de metade de todos os clusters Kubernetes do mundo.

Duas confusões que vale desfazer:

• Não é o mesmo projeto que o NGINX Ingress Controller da F5 (nginxinc/kubernetes-ingress). Código diferente, mantenedor diferente, não afetado pela decisão.
• A API Ingress continua existindo no Kubernetes, sem plano de remoção. O que não existe mais é o controller de referência que a implementava.

Na prática, quem monta um cluster hoje já não tem mais a rota mais óbvia disponível, e a Gateway API virou a primeira opção, não mais a alternativa.

Gateway API na prática

Onde antes um único objeto Ingress concentrava regra de host, path e o nome da IngressClass, a Gateway API separa a coisa em papéis: quem administra a infraestrutura de entrada cria um Gateway (a porta de entrada, ligada a uma GatewayClass que aponta para o controller de fato); quem é dono da aplicação cria um HTTPRoute apontando para esse Gateway, sem precisar saber nada sobre o load balancer por trás.

# Antes: um Ingress só, misturando infraestrutura e regra de aplicação
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
spec:
  ingressClassName: nginx
  rules:
    - host: api.exemplo.com.br
      http:
        paths:
          - path: /v1
            pathType: Prefix
            backend:
              service:
                name: api-v1
                port:
                  number: 80

# Depois: Gateway (time de infra) e HTTPRoute (time de aplicação), separados
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs:
    - name: gateway-publico
  hostnames:
    - "api.exemplo.com.br"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api-v1
          port: 80

Essa migração eu já fiz na prática, com conversão automatizada e auditoria do que não dava para converter, está contada em De NGINX Ingress para Envoy Gateway. Aqui fica só o contexto de por que ela virou obrigatória.

Para onde o Kubernetes está indo

Quatro movimentos do período que ainda não viraram feature estável, mas dizem para onde o projeto está indo.

O que eu vou praticar

A CKA vale até 23/12/2027 e nada aqui invalida o certificado, recertificar não é necessário por causa de nenhuma dessas mudanças. Mas se o objetivo é continuar afiado, o levantamento aponta dois pontos:

• A família DRA. Device management para GPU e cargas de IA é onde o projeto está concentrando esforço de verdade. Vale montar um cenário com DeviceTaintRule e entender o ciclo de ResourceClaim.
• A migração definitiva de Ingress para Gateway API. O que mudou foi qual dos dois ainda existe como implementação de referência para praticar.

Todo o resto (troubleshooting, kubeadm, RBAC, NetworkPolicy, storage) continua exatamente como estava.

Referências

• Kubernetes v1.35: Timbernetes
• Kubernetes v1.36 released — InfoQ
• Kubernetes v1.37: Garhwal
• Kubernetes v1.37: DRA Updates
• Device Taints and Tolerations — documentação oficial
• Comunicado oficial de retirada do Ingress NGINX
• The end of an era: transitioning away from Ingress NGINX — Google Open Source Blog
• Spotlight do WG Device Management
• Anúncio do AI Gateway Working Group
• Anúncio do Checkpoint/Restore Working Group
• cncf/curriculum — PDFs oficiais do currículo da CKA

Passei na HashiCorp Certified: Terraform Associate (003) em 26/07/2025. Escrevi na época sobre a estrutura da prova e a preparação em Certificação HashiCorp Terraform Associate 003. Este artigo é a continuação: o que mudou no Terraform depois disso.

E mudou muita coisa. Em pouco mais de quatorze meses o Core saltou de v1.12 para v1.16, o provider azurerm teve uma major version com quebra real, o Stacks saiu de beta, a HashiCorp virou parte da IBM, e apareceu uma linguagem nova de governança.

Nada disso invalida o certificado, que vale até 26/07/2027. Mas é tudo conteúdo novo para quem quer continuar afiado com Terraform.

O Core, release a release

v1.13 — 20/08/2025

• O comando terraform stacks entra no CLI principal.
• A RPC interface para integradores atinge GA.
• Correções de resource identity perdida em módulos aninhados.
• init ficou mais tolerante com constraints de provider.

v1.14 — 19/11/2025

• List Resources: arquivos .tfquery.hcl e o comando terraform query, para descobrir e filtrar recursos que existem fora do código. É a base para import em lote.
• Actions block: a primeira operação fora do CRUD tradicional, via lifecycle hooks ou -invoke.
• import passa a herdar variáveis de variable sets.

# arquivo: databases.tfquery.hcl
list "azurerm_mssql_database" "encontrados" {
  provider = azurerm

  config {
    # filtro de busca, específico do provider
    resource_group_name = "rg-plataforma-prod"
  }
}

# roda com: terraform query

action "aws_lambda_invoke" "run_migration" {
  config {
    function_name = aws_lambda_function.migrate.function_name
  }
}

# dispara automaticamente quando o recurso muda
resource "aws_db_instance" "main" {
  # ...
  lifecycle {
    action_trigger {
      events  = [after_update]
      actions = [action.aws_lambda_invoke.run_migration]
    }
  }
}

v1.15 — a linha estável de 2026

• Dynamic module sources: variáveis dentro de source e version de um bloco module, com o atributo const.
• Deprecation de variables e outputs via deprecated =, encadeável entre módulos.
• Função convert() para conversão explícita de tipo, e type constraints em output.
• validate passa a validar o bloco backend. Build nativo para Windows ARM64.

module "network" {
  source  = var.usar_espelho_privado ? "git::${var.mirror_url}" : "app.terraform.io/acme/network/azurerm"
  version = var.module_version
}

variable "instance_size" {
  type       = string
  deprecated = "use 'sku_name', será removido na v3.0 do módulo"
}

v1.16 — 26/08/2026, agora GA

Quando comecei este levantamento a 1.16 ainda estava em beta. Ela saiu em 26/08/2026, com a 1.16.1 em 02/09 e a 1.16.3 como versão atual.

• terraform_data ganha um bloco store para guardar valores ephemeral ou sensitive entre plan e apply.
• graph -format passa a incluir saída Mermaid.
• workspace list -json e state show -json.
• Blocos import dentro de módulos.
• lifecycle { destroy = false }.
• Builds para Linux s390x.

Traduzindo: ephemeral values e write-only arguments

Esse é o conceito mais importante do período inteiro. A base nasceu na 1.10 e amadureceu na 1.11.

O problema: qualquer valor que passa por um resource ou output fica gravado em texto plano dentro do terraform.tfstate, inclusive senha, token e connection string. Quem tem acesso de leitura ao state lê esse valor para sempre, mesmo que a senha já tenha sido trocada depois.

Um ephemeral value é um valor que só existe durante aquele plan ou apply: nunca vai para o state, nunca vai para o arquivo de plan, e some da memória assim que a operação termina.

variable "db_password" {
  type      = string
  ephemeral = true
  sensitive = true
}

Um write-only attribute é a mesma ideia aplicada a um campo específico de um recurso: você manda a senha nova para o provider, ela é aplicada, e o Terraform nem tenta lembrar o que mandou.

resource "azurerm_mssql_server" "sql" {
  administrator_login_password_wo         = var.db_password
  administrator_login_password_wo_version = 1 # sobe para forçar rotação
}

O pulo do gato é o _wo_version. Como a senha nunca vai para o state, o Terraform precisa de outra coisa para comparar e decidir se manda a senha de novo para o Azure, e essa outra coisa é um número comum, não secreto, que fica gravado no state. Ele só reenvia a senha quando esse número muda:

O provider azurerm: a mudança que se sente todo dia

O Core é o motor. O azurerm é o que a gente escreve toda hora. Na data da minha certificação o provider estava na v4.37.0. De lá até hoje foram dezenas de minors na linha 4.x, depois a 5.0, e hoje a linha corrente é a 5.6.0 (17/09/2026).

ago/2025 a mai/2026: a preparação silenciosa

Sem quebra de versão major nesse trecho, mas é aqui que o terreno da 5.0 foi preparado, recurso por recurso:

• A onda de deprecation de storage ID começou aqui. O azurerm_storage_queue ganhou storage_account_id, depreciando storage_account_name, na v4.46.0 (25/09/2025). Blob, table e container seguiram com storage_container_id e storage_account_id na v4.77.0 (11/06/2026). É a mesma história por nove meses, e essa migração de campo é exatamente o que ficou com id malformado na subida de 4.x para 5.x.
• Actions e List Resources começaram antes do que parece. A primeira Action do azurerm foi azurerm_virtual_machine_power e os primeiros List Resources foram azurerm_storage_account e azurerm_virtual_network, todos na v4.45.0 (18/09/2025), antes mesmo do Core 1.14. Não foi um pacote fechado, foi rollout gradual por quase um ano: no total da janela, 36 novos resources, 46 novos List Resources e 6 novas Actions.
• AKS recebeu reforço incremental, sem um salto único: suporte a AzureLinux3 e Ubuntu2204 e ai_toolchain_operator_enabled na v4.47.0, integração de VNet via api_server_access_profile na v4.46.0, e a mesma linha chegando no KataVmIsolation em junho de 2026.
• Dois recursos inteiros sumiram por fim de serviço no Azure, não por decisão do provider: azurerm_mobile_network* (v4.57.0) e azurerm_spatial_anchors_account (v4.52.0).
• A migração para o go-azure-sdk é contínua, não um evento: 24 bumps de dependência em cerca de 34 releases.

Vale o registro: não houve outra major version entre a 4.0 (agosto de 2024) e a 5.0. A linha 4.x foi inteira em minors.

azurerm 5.0.0 — as cinco quebras reais

Publicado em 27/07/2026. "Major" aqui não é número de marketing: campo e recurso deprecated foram removidos de vez, não só avisados.

• Auto-registro de Resource Provider virou none por padrão. No 4.x, o provider registrava sozinho cerca de 60 Resource Providers do Azure na inicialização (resource_provider_registrations = "legacy"). No 5.0 o padrão é "none": se o RP nunca foi registrado na assinatura, o apply falha na hora de criar o recurso. Para manter o comportamento antigo, sete resource_provider_registrations = "legacy" explicitamente; para ser mais enxuto, use resource_providers_to_register listando só o que o workspace usa de fato. Isso morde forte em subscriptions novas ou pouco usadas.
• Enhanced validation desligada por padrão. A validação de location e de Resource Provider usando o cache de metadata do Azure saiu do padrão e foi para o bloco features. Sem reativar, um nome de região errado só é pego no apply, como erro da API, e não mais no plan. Reativa com features { enhanced_validation { locations = true } }.
• Preflight validation só em seis recursos: azurerm_app_service_environment_v3, azurerm_service_plan, azurerm_dashboard_grafana, azurerm_eventgrid_namespace, azurerm_managed_redis e azurerm_nginx_deployment. Todo o resto passa reto, um plan limpo deixou de ser garantia para esses tipos.
• azurerm_app_service e azurerm_function_app foram deletados. Não é deprecation, é remoção. Quem ainda usa precisa migrar para azurerm_linux_web_app/azurerm_windows_web_app e azurerm_linux_function_app/azurerm_windows_function_app, com terraform state mv para não recriar o recurso do zero.
• skip_provider_registration não existe mais no schema do provider, consequência direta do primeiro ponto.

O 5.0 também trouxe write-only nativo para o azurerm: azurerm_subnet ganhou network_security_group_id_wo e route_table_id_wo, com os respectivos _wo_version. É o mesmo padrão explicado lá em cima, agora num recurso Azure de verdade.

azuread: 3.4 para 3.9, sem major version

Andamento bem mais tranquilo. Os destaques: o novo resource azuread_flexible_federated_identity_credential (3.7), suporte a filtro em azuread_conditional_access_policy (3.9) e uma sequência de correções para eventual consistency, a Microsoft Graph API demora para propagar depois de um create, o que fazia o Terraform reportar not found num recurso recém-criado. Corrigido progressivamente entre a 3.6 e a 3.9.

Mudanças que não são só do CLI

Quatro coisas que mudaram no produto e na empresa. Nenhuma aparece em terraform --version, mas todas mudam como um time de plataforma trabalha.

Stacks saiu de beta e virou GA

# network.tfstack.hcl — a definição, uma vez só
component "network" {
  source = "./modules/network"
  inputs = {
    cidr = var.cidr
  }
}

# deployments.tfdeploy.hcl — uma entrada por ambiente
deployment "prod" {
  inputs = {
    cidr = "10.10.0.0/16"
  }
}

deployment "qa" {
  inputs = {
    cidr = "10.11.0.0/16"
  }
}

A diferença para root module com tfvars: aqui as duas deployments entram no mesmo grafo de dependência do Terraform. Dá para declarar "não aplica prod antes de qa terminar limpo" nativamente, em vez de isso morar espalhado numa pipeline por fora.

GA anunciada na HashiConf de setembro de 2025, para todos os planos de HCP Terraform baseados em RUM. O terraform-stacks-cli separado foi descontinuado, tudo entrou no CLI principal como terraform stacks. Configurações da beta pública não migram sozinhas, e o histórico de state se perde. Em 2026 ganhou suporte a monorepo e a "stack component configurations" via registry privado.

HCP Terraform e o Infragraph

O nome "Terraform Cloud" já tinha virado "HCP Terraform" antes da minha certificação. O que é novo: em setembro de 2025 entrou em preview público o HCP Terraform powered by Infragraph, um grafo de infraestrutura em tempo real dentro do HCP, a base declarada para automação agêntica, com agentes observando e agindo sobre o ciclo de vida do recurso.

A HashiCorp agora é IBM

Aquisição fechada em 27/02/2025, por US$ 6,4 bilhões. A licença continua BSL, não houve volta para open source sob MPL. Em setembro de 2025, IBM e HashiCorp anunciaram o Project Infragraph, em private beta desde dezembro de 2025, com plano de conectar Ansible, OpenShift e watsonx Orchestrate ao mesmo grafo.

tfpolicy: governança sai do Sentinel e entra no HCL

Lançado em beta público em julho de 2026, dentro do HCP Terraform, exigindo Terraform 1.16 ou superior. Resolve o mesmo problema que Sentinel e OPA sempre resolveram, barrar um plan que viola uma regra de governança, mas sem trocar de linguagem: a política é escrita em HCL, a mesma que já se usa para escrever a infraestrutura.

O que ele faz que Sentinel e OPA não faziam nativamente:

• Enxerga relação entre recursos. Por exemplo: "toda IAM role precisa ter pelo menos uma policy anexada". O Sentinel avalia um recurso isolado; o tfpolicy enxerga o grafo inteiro.
• Puxa dado externo durante a avaliação. Por exemplo: "só permite AMI aprovada", batendo num data source de verdade, e não numa lista fixa dentro da política.
• Bloqueia provider ou módulo não aprovado antes do download, barrando na origem.
• Avalia depois do deploy, contra o estado real na nuvem, pega drift e valor computado pelo provider que só existe depois do apply.

module_policy "git::github.com/acme/terraform-aws-vpc" "versao_minima" {
  enforce {
    condition     = core::semverconstraint(meta.version, ">= 2.0.0")
    error_message = "O módulo VPC oficial precisa estar na versão 2.0.0 ou superior."
    info_message  = "Versão do módulo VPC: ${meta.version}."
  }
}

Existe o mesmo padrão para resource_policy, aplicado a um tipo de recurso específico, e para provider_policy, ambos com o mesmo bloco enforce, e os atributos do recurso acessados pelo prefixo attrs. (por exemplo attrs.tags.environment). Se você já trabalha com policy as code, vale comparar com a abordagem que descrevi em Platform Engineering e Policy as Code.

Duas coisas novas que vale entender

Além de ephemeral values e write-only arguments, dois outros conceitos ganharam peso no período:

variable "storage_tier" {
  type = string

  validation {
    condition     = contains(["Hot", "Cool", "Cold"], var.storage_tier)
    error_message = "storage_tier precisa ser Hot, Cool ou Cold, não '${var.storage_tier}'"
  }
}

De relance

• terraform test amadureceu. -junit-xml virou GA na 1.11, -parallelism na 1.12, state_key e override_during na 1.11. Um test cleanup experimental apareceu no ciclo da 1.16 e 1.17 para lidar com state órfão de teste que falhou.
• State encryption continua exclusivo do OpenTofu. Vale a distinção: um Azure Storage Account com SSE criptografa o arquivo do state em repouso, mas quem tem Storage Blob Data Reader naquele container abre o JSON e lê tudo em texto plano, senha incluída. É exatamente por isso que ephemeral values e write-only existem. "State encryption" é outra coisa: criptografa o conteúdo do state com uma chave separada (KMS, Key Vault, OpenBao), de modo que nem quem tem acesso de leitura ao blob lê nada sem a chave. Isso segue sendo do OpenTofu, desde a v1.7 dele. Se isso importa para o seu time, é o maior motivo concreto para olhar o fork.

O que eu tiro disso

O esqueleto do Terraform que eu estudei continua de pé, mas três coisas mudaram o suficiente para entrar na minha lista de prática:

• Ephemeral values e write-only arguments, porque mudam como segredo trafega.
• Stacks e tfpolicy, que juntos cobrem o espaço que hoje é preenchido por wrapper e por linguagem de política separada.

O resto (backend, módulo, state, import, workspace) é o mesmo Terraform que eu estudei.

Referências

• Terraform 1.11: ephemeral values e write-only arguments — HashiCorp
• Novidades do Terraform 1.15 — HashiCorp
• Releases do hashicorp/terraform no GitHub
• Terraform Stacks: atualização de GA — HashiCorp Developer
• Introducing tfpolicy — HashiCorp
• Referência de política do tfpolicy — HashiCorp Developer
• Guia de upgrade do azurerm 5.0 — Terraform Registry
• CHANGELOG-v4.md do terraform-provider-azurerm
• Histórico de versões do azurerm — Microsoft Learn
• Releases do terraform-provider-azuread no GitHub
• Conteúdo oficial do exame 004 — HashiCorp Developer
• IBM conclui a aquisição da HashiCorp — TechCrunch

Quase todo texto sobre trocar de ingress controller fala da arquitetura de destino: por que Gateway API, por que Envoy, como fica o novo modelo de recursos. Esse aqui fala de outra coisa, menos explorada: como a migração foi de fato executada, com um agente de IA operando num loop estruturado em vez de uma pessoa dirigindo cada passo na mão.

Resumo rápido

• Plataforma Kubernetes multi-tenant sob NDA. Nada de nome de empresa, cluster, tenant ou repositório. O que generaliza é o formato do problema.
• Existe um controller próprio que converte continuamente Ingress de classe nginx em HTTPRoute, GRPCRoute e TLSRoute ligados a um Envoy Gateway compartilhado.
• A decisão mais importante veio antes do código: para toda annotation nginx em uso, o time decidiu o que aconteceria com ela, convertida, redundante, sem efeito, ou marcada para trabalho manual, nunca deixada para trás em silêncio.
• Snippet de nginx é traduzido em regime tudo ou nada. Tradução parcial é modo de falha pior que tradução nenhuma.
• O achado que salvou o dia 1 não tem nada a ver com Envoy: dezenas de serviços montavam URL de redirect de OAuth a partir de um header não-padrão que nunca existiu naquele ambiente.
• O mecanismo do loop em si, hooks, skills, subagentes verificadores, escada de verificação, eu já detalhei em Loop Engineering na prática. Aqui ele aparece em recap curto, e só desce ao detalhe onde a aplicação é específica desta migração.

O problema da migração

O ambiente é uma plataforma Kubernetes multi-tenant sob NDA. O que interessa e generaliza para qualquer time fazendo essa migração é a forma do problema, não os nomes.

Existe um controller que converte, de forma contínua, Ingress de classe nginx em recursos de Gateway API ligados a um Envoy Gateway compartilhado. Ele envolve o projeto open source kubernetes-sigs/ingress2gateway e acrescenta quatro camadas em cima:

• Rebind de parentRef, para que a rota gerada aponte para o Gateway compartilhado certo em vez do que a conversão padrão inferiria.
• Parsing de snippet nginx, o config livre embutido em annotation.
• Derivação de policy, quando o comportamento não cabe na rota e precisa virar objeto de política no nível do Gateway. É a mesma ideia que eu defendi em Platform Engineering e Policy-as-Code que aceleram times, só que aqui a política não é escrita à mão, ela é derivada de uma annotation legada.
• Cobertura total de annotation, que é o assunto da próxima seção e a decisão mais importante do projeto inteiro.

Vale dizer o óbvio que às vezes se perde: a conversão não é um script que roda uma vez. É um controller em reconciliação, porque os times donos das aplicações continuam criando e editando Ingress nginx enquanto a migração acontece. Migração de verdade não tem freeze.

O primeiro passo: um assessment da frota inteira

Antes de desenhar qualquer contrato, tinha uma pergunta mais básica: o que a frota realmente usa? Não a lista de annotations que a documentação do nginx descreve, a lista real, encontrada em produção, com toda variação que cada time introduziu ao longo do tempo.

Foi o primeiro passo do projeto, e não teve nada de manual nele. Um agente varreu todos os Ingress de todos os workloads da frota, um a um, e extraiu cada annotation encontrada, onde ela aparecia, em qual workload, em qual namespace. O resultado saiu num .csv, não num documento, porque o próximo passo era justamente decidir, entrada por entrada, para onde cada annotation ia na tradução para Gateway API.

Esse .csv é o que faz o contrato da próxima seção ser honesto. Sem ele, a lista de annotations a cobrir teria sido "as que a gente lembrou", montada de memória por quem já trabalhou com o ambiente. Com ele, é "as que existem de verdade", incluindo a annotation rara que um time usou uma vez, dois anos atrás, e que ninguém mais tinha em mente. É o mesmo problema, na escala do assessment inteiro, que o contrato resolve annotation por annotation: o que não é visto, desaparece calado.

O contrato de cobertura: cinco categorias e nada fora delas

Antes de escrever qualquer código de conversão, a pergunta que precisava de resposta era: o que acontece com uma annotation que o conversor não conhece?

A resposta preguiçosa é ignorar e seguir. É também a resposta que faz a migração parecer um sucesso até alguém descobrir, três semanas depois, que o rate limit sumiu.

A saída foi fechar essa lacuna antes de escrever código: para toda annotation nginx.ingress.kubernetes.io/*, o time definiu de antemão qual das cinco categorias abaixo ela ocupa, sempre uma, nunca zero.

A quinta categoria é o que faz o contrato valer. Sem uma categoria explícita para "isso não dá", tudo que não dá vira silêncio. Unconvertible não é derrota, é o mecanismo que transforma um desconhecido em item de trabalho com nome.

O ganho prático de escrever isso antes: o agente não tem espaço para inventar uma quarta via. A instrução não é "converta o que der", é "coloque cada entrada numa categoria e não sobre nada". Objetivo verificável em vez de objetivo simpático.

Snippet é tudo ou nada

Snippet de nginx é o caso mais desagradável, porque não é uma annotation com valor conhecido, é um pedaço de configuração livre embutido numa string.

A regra que vale a pena copiar: um snippet só é traduzido quando todos os diretivos dentro dele são reconhecidos. Nunca nove décimos.

O motivo é o modo de falha, não a pureza. Um snippet traduzido pela metade parece funcionar, e continua parecendo funcionar até o dia em que o diretivo que ninguém portou se revela a checagem de autenticação. Um snippet não traduzido, marcado Unconvertible, é um problema visível numa lista. É a diferença entre uma pendência e uma armadilha.

A mesma lógica vale para regra de rewrite e qualquer coisa baseada em diretivo. Tradução parcial é modo de falha pior que tradução nenhuma, porque destrói o sinal que te avisaria.

O que o loop virou neste projeto

O hook que protege o RBAC gerado

O hook genérico eu já expliquei no artigo anterior. O que muda aqui é o alvo: o RBAC do operator é gerado a partir de marcadores +kubebuilder:rbac no código, e editar o arquivo gerado à mão é trabalho que o gerador apaga em silêncio na próxima execução.

#!/usr/bin/env bash
# PostToolUse — pega edição manual num arquivo de RBAC gerado, antes que ele seja sobrescrito.
set +e
payload="$(cat)"; [ -z "$payload" ] && exit 0
file="$(printf '%s' "$payload" | jq -r '.tool_input.file_path // empty')"
case "$file" in *config/rbac/role.yaml) ;; *) echo '{"continue":true}'; exit 0 ;; esac

if git diff --quiet -- "$file" 2>/dev/null; then
  echo '{"continue":true}'; exit 0
fi

printf 'Guardrail: %s e gerado a partir dos marcadores +kubebuilder:rbac.\n' "$file" >&2
printf 'Rode `make manifests` em vez de editar a mao, o gerador sobrescreve isso na proxima execucao.\n' >&2
exit 2   # o stderr volta para o contexto do agente

Duas coisas que só a prática ensina, e que valem para qualquer hook desse tipo. Primeira: ele estreita o escopo antes de opinar, dispara num arquivo só, não em todo YAML do repositório. Segunda: a mensagem diz o que fazer, não só o que está errado. Feedback acionável fecha o loop numa iteração; feedback vago gasta três.

A skill do converter: "isto NÃO é um operator genérico"

A skill deste projeto tem uma linha que eu considero a mais valiosa dela, e não é um passo de procedimento, é uma negação:

---
name: ingress-converter-operator
description: >
  Convenções de trabalho do conversor nginx para Gateway API: regras de git,
  build/test/deploy, e decisões de arquitetura já resolvidas por investigação
  anterior. Use ao editar internal/converter/* ou internal/controller/*.
  Este NÃO é um operator de CRD genérico feito com kubebuilder,
  não use `kubebuilder create api` aqui.
---

## Quando usar
## Build e teste
## Limitações conhecidas (leia antes de reinvestigar)

Sem a linha de desambiguação, o agente alcança o padrão genérico de scaffolding de Kubebuilder num projeto que deliberadamente arrancou tudo aquilo fora. Ele não está errado por burrice, está errado porque o padrão mais provável do mundo, dado o formato do repositório, é exatamente o que este projeto não é. Dizer o que a coisa não é custa uma linha e economiza um dia.

E a última seção importa tanto quanto o procedimento. "Limitações conhecidas" existe para o agente não reinvestigar "será que dá pra consertar?" em algo que uma sessão anterior já resolveu que não dá. Sem ela, cada sessão nova paga de novo o custo da mesma investigação, e chega na mesma conclusão, e não deixa registro. O agente esquece, o repositório não.

Onde a escada encosta na realidade: o degrau que precisa de data plane

Os cinco degraus da escada de verificação estão no artigo anterior. O que esta migração acrescenta é o motivo de o degrau 4 existir, e ele é bem concreto.

O envtest sobe um kube-apiserver e um etcd de verdade, com os CRDs de Gateway API e de Envoy Gateway vendorizados, não com mocks. Isso prova que a lógica de reconciliação funciona. E não prova absolutamente nada sobre tráfego, porque o envtest não sobe o data plane do Envoy. Ele não move pacote.

Ou seja: tudo que depende de como um header é de fato reescrito passa no envtest e falha no mundo. É o tipo de verde que dá confiança errada.

A correção é um degrau a mais, e o detalhe que faz ele valer é chato de propósito: Envoy Gateway instalado localmente, no Kubernetes que vem no Docker Desktop, com exatamente os mesmos values de Helm do módulo que provisiona o ambiente real. Não é o chart com defaults, não é um cluster de brinquedo. É o ambiente de destino em miniatura, porque o que você está testando é justamente a configuração, não o Envoy.

Ao lado dele, um backend que só ecoa os headers que recebeu, e um curl. É assim que se confirma que um request HTTP simples atravessando o Envoy chega do outro lado com X-Forwarded-Proto: https. Não por leitura de código, não por asserção de unidade. Por observação.

Esse mesmo cluster local também roda o Gateway API (os CRDs), não só o Envoy. Motivo: simular o Envoy sozinho prova o rewrite de header, mas não prova que o operator chega até lá do jeito que chegaria em produção. O cluster local simula o operator rodando, não só existindo.

Isso é o ponto que vale enfatizar: quanto mais o ambiente local imita o real, Helm values, Gateway API incluído, menos surpresa sobra para o cluster de produção. Teste local que só sobe a aplicação não testa o caminho pelo qual a aplicação chega lá, e esse caminho tem tanta chance de esconder bug quanto o código em si.

Vale registrar também que a imagem do operator não faz parte do ciclo de iteração. Editar arquivo, reiniciar o pod com a árvore de código montada por hostPath, ver o efeito em segundos. A imagem é construída pelo serviço de build do registry, depois que o comportamento já está validado. A imagem é o resultado do loop, não uma etapa dentro dele.

A virada de tráfego é uma operação destrutiva

Remover ou rebaixar um Ingress nginx antigo depois que o equivalente em Gateway API está saudável é, tecnicamente, apagar um recurso de produção. Então ela passa pela mesma trava que qualquer outra operação destrutiva do meu setup: para, pede autorização explícita, e não importa o modo de automação em que eu esteja.

Não repito aqui como a trava é construída, está detalhada no artigo anterior, incluindo a brecha do modo sem prompt que quase me custou caro. O ponto específico da migração é outro: a palavra que importa é "sempre".

Um cutover é exatamente o momento em que a confiança anda mais rápido que a verificação. O loop vem funcionando bem há semanas, as rotas vêm saindo certas, e a tentação de aprovar no piloto automático é máxima justo quando o custo de errar também é. Esse guardrail não protege contra o agente errar, protege contra o operador aprovando rápido demais. Falso positivo aí é preço, não defeito.

O que a auditoria em fan-out achou antes da virada

Rodar a descoberta com agentes em vez de na mão teve um efeito colateral que sozinho pagou o esforço.

A sweep foi em fan-out, um agente por área da frota, seguida de uma segunda rodada com a instrução invertida: não confirme o que já foi achado, tente refutar. E o resultado foi desconfortável.

Dezenas de serviços montavam a URL de redirect de OAuth a partir do header não-padrão X-Forwarded-Scheme, com fallback para X-Scheme, em vez do padrão X-Forwarded-Proto.

Repare no que isso significa. Nem o nginx nem a borda anterior mandavam esses headers. Ou seja, aquelas aplicações vinham confiando num header ausente e caindo no default http na URL entregue ao provedor de identidade. Funcionava porque nada dependia do valor até o momento em que dependeria.

Mover o tráfego para o Envoy sem tocar nisso teria produzido uma onda de callbacks de OAuth quebrados no dia 1, com root cause que não tem nada a ver com Envoy, num dia em que todo mundo estaria olhando para o Envoy. É o pior formato possível de incidente: sintoma novo, causa velha.

O fix, uma vez achado, foi pequeno: o controller injeta os dois headers não-padrão, add-if-absent, na mesma camada onde já reescreve outros headers de request. Add-if-absent importa, porque quem já manda o header certo não pode ser sobrescrito por compatibilidade retroativa.

O que o processo não pegou: ReferenceGrant no namespace errado

No interesse de não vender o peixe maior do que ele é: o processo pega classes de falha, ele não é infalível. E o caso que escapou é instrutivo justamente porque os testes ficaram verdes o tempo todo.

Backend cross-namespace precisa de um objeto ReferenceGrant no namespace de destino para autorizar a rota. O teste de unidade provava, corretamente, que o conversor calculava o namespace de destino certo. E isso não prova que o controller aplica o objeto lá.

Um passo de carimbo de namespace em outro ponto do loop de reconciliação sobrescrevia aquele destino em um caso específico, deixando o objeto de autorização válido e inútil, no namespace errado. Unidade verde, comportamento quebrado.

A correção é um teste de integração cobrindo conversor e controller juntos, que é exatamente o degrau que a suíte original pulava. Ela está escrita na seção de limitações conhecidas da skill, com nome, não esquecida numa conversa. Um loop com agente é tão honesto quanto o backlog que ele deixa para trás.

Para quem vai fazer essa migração

As recomendações genéricas de loop estão no outro artigo. Estas são específicas desta migração:

• Escreva o contrato de cobertura de annotations antes do primeiro código de conversão. Decida de antemão o que acontece com cada entrada possível, para que nada que você não previu desapareça em silêncio. E tenha uma categoria explícita para "não dá".
• Trate feature baseada em diretivo como tradução tudo ou nada. Snippet, rewrite, qualquer config livre. Meia tradução é pior que nenhuma, porque parece que funcionou.
• Verificação local precisa de data plane de verdade. Uma API do Kubernetes falsa prova sua lógica de reconciliação; só um cluster rodando a mesma implementação de Gateway com os mesmos values de Helm da produção prova que seu rewrite de header acontece.
• Audite os headers que suas aplicações consomem antes de virar a borda. Não os que a documentação delas diz que elas consomem, os que o código realmente lê. E rode uma passada adversarial em cima do resultado, porque a primeira volta sempre parece completa demais.
• Diga na skill o que o projeto NÃO é. Se o formato do repositório sugere um padrão comum que não se aplica, escrever a negação custa uma linha e evita que o agente reconstrua o que você arrancou fora de propósito.
• Trate o cutover como operação destrutiva com autorização explícita. É o momento em que a confiança está mais alta e o custo de errar também.

Conclusão

O que me deixou confortável nessa migração não foi a velocidade da conversão. Foi que os pontos onde ela poderia ter falhado em silêncio, annotation ignorada, snippet meio traduzido, header ausente, autorização no namespace errado, viraram itens com nome, seja numa categoria, seja numa lista de limitações conhecidas, seja num teste que ainda falta escrever.

O agente acelerou o trabalho. O que decidiu se ele foi confiável foi o contrato escrito antes dele começar, e a disciplina de tratar todo verde não observado como suspeito.

No dia 22 de agosto de 2026, ao lado de Jéssica Mello (LowOps Consultoria), palestrei no DevOpsDays Curitiba, um dos eventos mais tradicionais da comunidade DevOps no Brasil, realizado no Auditório Eny Caldeira do Campus Rebouças da UFPR.

Agenda

Um estudo de caso sobre como usei IA generativa para criar meu portfólio pessoal do zero, com Terraform, GitHub Actions e boas práticas de DevOps garantiram que o deploy em produção, fosse feito com controle humano.

A Jornada: Do Prompt ao Deploy

O Problema

Meu portfólio pessoal (orafaelferreira.com) estava desatualizado. Eu precisava de um site moderno, minimalista e rápido, mas sem tempo para desenhar e codar tudo do zero.

Tudo Começou com um Prompt

Estruturei um prompt detalhado, seções para Home, Sobre, Blog, Palestras, Mentoria e Contato, guidelines de estilo (tema escuro, tipografia moderna, ícones lineares) e requisitos técnicos (SEO, performance, Markdown), e usei o Lovable para gerar 100% via IA generativa a primeira versão.

O resultado: um site one-page, com design moderno e performance ótima. Só que sair de uma one-page para um blog completo era o próximo desafio.

Quando a "Vibe" Encontra a Produção

A modularização começou com refinamento contínuo, via prompts refinados e edição manual estratégica, transformando o one-page em páginas de fato (Home, Sobre, Blog, Palestras, Recomendações).

Mas dois problemas clássicos apareceram: vendor lock-in (dependência total da plataforma que gerou o código) e custos de hospedagem.

Assumindo o Controle: Do Prompt ao Repositório

A solução: exportar o código do Lovable, versionar no GitHub, refatorar com GitHub Copilot e adotar GitFlow e versionamento profissional.

Hospedagem e Migração para Azure

Com o código sob controle, migrei a hospedagem para a Microsoft Azure: escrevo o código → GitHub guarda e testa (CI/CD) → publica no Azure → o domínio (www.orafaelferreira.com) responde. Isso envolveu migração de conteúdo (posts, palestras, projetos), adaptação estratégica de layout e configuração de DNS com downtime mínimo.

Infraestrutura como Código com Terraform

Toda a infraestrutura é provisionada 100% via código com Terraform: criação do Azure Static Web App, configuração automatizada de DNS e domínio, e execução automatizada via GitHub Actions, garantindo consistência e replicabilidade, no lugar do clássico ClickOps manual e propenso a erros.

A arquitetura final: um Resource Group (rg-site) com Azure Blob Storage guardando o state do Terraform, um Azure Static Web App (free tier, eastus2) e um domínio customizado (www.orafaelferreira.com) com TLS automático e validação DNS via TXT record.

O Motor de Entrega: GitHub Actions

O pipeline de CI/CD roda em push to main: build → test → deploy to Azure, com autenticação via Service Principal (secrets nunca hardcoded). Zero intervenção manual, 100% automatizado, incluindo validação de infraestrutura (tflint, trivy, checkov) antes de qualquer terraform apply.

A Base do Frontend Moderno

No frontend: TypeScript, React, Vite, TailwindCSS e shadcn/ui, com arquitetura orientada a componentes, cobertura completa de testes (unit com Vitest, componentes com React Testing Library, E2E com Playwright), suporte a i18n (PT-BR/EN) e foco em acessibilidade e SEO.

GEO: A Evolução da Busca

Também trouxe um recorte sobre Generative Engine Optimization (GEO), a evolução do SEO tradicional (palavras-chave, cliques, backlinks) para um mundo onde o foco está em intenção e contexto, citações por LLMs e dados estruturados e semânticos.

Lições Aprendidas

1. Um prompt bem estruturado vale mais que 100 tentativas aleatórias.

2. Unir IA, automação e cloud não é o futuro, é o presente, mas exige profissionais em "T": generalistas na velocidade (vibe coding, prototipagem rápida) e especialistas em profundidade (DevOps, Terraform, Azure, Security).

3. UX é tão importante quanto o produto.

4. A inteligência artificial acelera exponencialmente, mas o poder humano de decisão, a criatividade e o objetivo continuam sendo intangíveis.

> "A IA é o Acelerador. Você é o Piloto." A IA não vai roubar seu emprego, ela vai impulsionar quem sabe usá-la.

E um recado final, direto: você não é pago pra escrever código, você é pago pra resolver problemas. Se você não está gostando do seu trabalho atual, ou você não está usando a IA do jeito certo, ou você está no emprego errado.

Slides da Apresentação

Repositórios

• Repositório do Site, código-fonte, Terraform e pipeline completa.

Obrigado ao DevOpsDays Curitiba pela oportunidade e a todos que estiveram na sessão!

No dia 22 de agosto de 2026, palestrei no MVP Conf Regional Curitiba 2026, realizado na PUC PR, com a sessão "Platform Engineering na Prática - Construindo Plataformas Serverless Self-Service".

Uma imersão prática em Platform Engineering:qu o que é um Internal Developer Platform (IDP) de verdade, e como construí, com Terraform, GitHub Actions e uma arquitetura em três pilares, uma plataforma serverless self-service na Azure.

O Anti-Padrão do Shadow Ops

A promessa "you build it, you run it" quebrou sob o peso da complexidade cloud-native. Exigir que desenvolvedores dominem toda a stack de infraestrutura (Kubernetes, Helm, Terraform, RBAC, CI/CD, networking) atrasa entregas e gera configurações inconsistentes, o chamado Shadow Ops. 44% das organizações de baixo desempenho sofrem com desenvolvedores assumindo tarefas de infraestrutura e desviando o foco do produto.

O Que É Platform Engineering?

Platform Engineering é construir uma plataforma interna que simplifica, padroniza e acelera o trabalho dos times de desenvolvimento. Não é uma ferramenta. É um produto.

• O core da plataforma: infraestrutura padronizada, pipelines automatizados e governança clara, processos que os devs realmente querem usar. O objetivo é tornar o caminho certo o caminho mais fácil.
• Reduz carga cognitiva: devs conseguem provisionar, deployar e monitorar sem precisar ser especialistas em cloud, Kubernetes ou networking. A plataforma "esconde" complexidade sem esconder poder.
• Resultado: velocity aumenta, erros humanos caem drasticamente e ciclos de release passam de meses para dias.

DevOps Tradicional vs. Engenharia de Plataforma

O mercado reconhece essa mudança: Platform Engineers ganham, em média, até 20% a mais do que profissionais de DevOps tradicionais.

A Anatomia de um IDP: os 5 Planos

Um Internal Developer Platform (IDP) de verdade se organiza em cinco planos:

1. Developer Control Plane, a interface de entrada (portais, CLI, API, workload specifications). Onde o desenvolvedor interage.

2. Integration & Delivery Plane, o motor lógico (CI/CD, orquestradores de plataforma). Cria configurações dinamicamente a cada git push.

3. Resource Plane, os recursos reais subjacentes (compute, DNS, bancos de dados, nuvem).

4. Security Plane, governança contínua (gerenciamento de segredos, políticas de acesso).

5. Observability Plane, visibilidade padronizada (logs, APM, métricas).

O Perfil do Engenheiro de Plataforma

Um bom engenheiro de plataforma vive na intersecção de três habilidades: habilidades técnicas profundas (Cloud Native, Kubernetes, CI/CD, GitOps, Infraestrutura como Código), mentalidade de produto (visão de ciclo de vida, foco no cliente/dev, MVPs e métricas de uso) e comunicação e empatia (vender a solução pra liderança técnica e ouvir criticamente o desenvolvedor).

Erros Fatais ao Adotar Platform Engineering

1. Mudança apenas de nome, renomear a equipe de SysAdmins para "Plataforma", mas continuar afogado em Ticket Ops.

2. Foco em Ops, não em Devs, construir ferramentas baseadas no que os operadores acham importante, ignorando a experiência do usuário (dev).

3. Sem mentalidade de produto, atender requisições ad-hoc de todos os times sem construir fluxos de trabalho escaláveis.

4. Tecnologia pela tecnologia, trocar ferramentas sem um motivo estratégico atrelado à produtividade.

O Valor Real: A Experiência do Desenvolvedor (DevEx)

O objetivo final é resumir meses de configuração de infraestrutura a parâmetros essenciais. Da visão do desenvolvedor, o esforço é imagem = 'meu-app:v1'. Por trás, a engenharia oculta cuida de tudo: Container Apps Environment configurado, rede spoke /27 delegada, Managed Identity vinculada nativamente, comunicação criptografada com o Azure Container Registry, e logs fluindo automaticamente pra Application Insights.

Como Construí: Uma Arquitetura em Três Pilares

Na prática, estruturei o ecossistema em três repositórios que se conectam:

1. Pipeline-as-a-Service, centraliza validação e segurança, valida o código.

2. TFse Modules-as-a-Service, blocos de construção reutilizáveis (ex: um módulo de Azure Container Registry já com RBAC embutido). Fornece as peças.

3. Platform-as-a-Service, o produto final: ambientes completos via feature flags, monta a solução.

Módulos não criam apenas o recurso, eles encapsulam governança, monitoramento e acesso, escondendo a complexidade do consumidor.

Pipeline-as-a-Service: Um Reusable Workflow

Um único reusable workflow de GitHub Actions elimina mais de 70 linhas de código de validação duplicadas por projeto entre os três repositórios. Atualizações são feitas em um único lugar e se propagam pra todos os consumidores.

O fluxo sequencial de validação de infraestrutura roda em cinco etapas (com continue-on-error: true, executando todas as checagens mesmo se uma falhar):

Feature Flags e Matriz de Dependências

A plataforma final é montada por feature flags que respeitam uma matriz de dependências, por exemplo, enable_container_apps = true dispara automaticamente enable_observability, enable_managed_identity (o hub central de RBAC que conecta Storage, Service Bus, SQL e ACR) e enable_key_vault, que por sua vez depende do enable_sql pra gerenciar senhas.

A arquitetura final segue quatro camadas, com dependência obrigatória de baixo pra cima: Base (Resource Group, Virtual Network) → Fundação (Managed Identity, Key Vault) → Serviços (Storage, Service Bus, SQL, ACR) → Workloads (Azure Container Apps Environment).

Slides da Apresentação

Repositórios da apresentação

• Platform Stack:

• Pipeline Stack:

• TF Modules Stack:

Obrigado ao MVP Conf Regional Curitiba pela oportunidade e a todos que estiveram na sessão!

Quero deixar o registro com vocês um novo post onde destaco minhas participações em publicações, escrevendo sobre DevOps, Cloud e Platform Engineering. Espero que este post possa inspirar outros a buscar desenvolvimento profissional contínuo. Bora lá!

Minhas Participações

Accelerate Teams with Platform Engineering and Policy-as-Code

How I Use AI — Loop Engineering: Building Safer AI Agent Workflows for High-Stakes Infrastructure

Resumo rápido

• Loop Engineering é técnica de o sistema que dá o prompt no agente, em vez de você dar o prompt a cada passo. O termo foi sistematizado em junho de 2026.
• O conceito original de um loop de verdade tem cinco peças: objetivo, verificador, caminho de feedback, regra de parada e teto de iteração/custo. Sem verificador, não é loop, é um gerador de texto com autoconfiança.
• Meu setup implementa quatro dos cinco componentes canônicos. O quinto, worktree, eu tirei de propósito, e explico por quê.
• A peça mais útil do meu loop não é uma IA: é um hook em shell que sai com código 2. É assim que a correção volta para o contexto do modelo.
• A divisão que faz o resto funcionar: hook aplica, skill instrui, MCP executa. Nenhuma das três invade o papel da outra.
• Trabalho com plataforma sob NDA, então aqui não tem nome de empresa, cluster, tenant ou repositório. O que interessa é o mecanismo, e o mecanismo é público.

De prompt para loop

Nos últimos dois anos a alavanca foi migrando para fora. Primeiro era a palavra que você digita, prompt engineering. Depois virou a informação que o modelo vê, context engineering. Depois o ambiente em que ele roda, harness engineering. Agora é o ciclo que dirige tudo isso.

O Peter Steinberger resumiu de um jeito que provoca: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Isso provoca, porque é verdade. Se o seu trabalho com agente ainda é abrir o terminal, descrever a tarefa, ler a resposta, corrigir, repetir, você é o loop. Você é a peça que não escala.

Eu passei os últimos meses construindo o meu, num contexto que é bem menos glamouroso que os exemplos de blog: infraestrutura multi-tenant, Terraform, AKS, pipelines. Domínio onde o custo de errar não é um teste vermelho, é um ambiente fora do ar. E foi justamente esse contexto que me fez questionar e estudar cada vez mais para não usar a receita padrão.

O que é Loop Engineering

Vamos ao que o povão está dizendo

O termo foi sistematizado pelo Addy Osmani em junho de 2026, no artigo que virou referência (também publicado no O'Reilly Radar). A definição dele é direta: "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."

A IBM descreve como a prática de projetar, especificar e manter loops agênticos, sistemas que se auto-instruem e avaliam o próprio trabalho até atingir um objetivo declarado. O Augment Code detalha a anatomia: um loop pareia um agente de código com um verificador, um caminho de feedback, uma condição de saída, um teto de iterações e um teto de orçamento, para que ele possa rodar sem supervisão sob regras de parada explícitas.

Repare no que essa lista tem de mais importante: quatro dos cinco itens são freios. Só um é acelerador.

Os cinco componentes

O Osmani lista cinco peças que transformam execução avulsa em loop:

• Automations, "Automations are what make a loop an actual loop and not just one run you did once." Tarefas agendadas que descobrem trabalho sozinhas.
• Worktrees, diretórios de trabalho isolados, para vários agentes mexerem no mesmo repo sem colidir.
• Skills, conhecimento de projeto codificado em arquivos SKILL.md: convenções, passos de build, o contexto que você reexplicaria a cada sessão.
• Plugins e connectors, integrações via MCP, para o loop alcançar sistemas reais e não só o filesystem.
• Subagents, separar quem escreve de quem confere. Nas palavras dele: "The most useful structural thing in a loop, by far, is splitting the one who writes from the one who checks."

E uma sexta peça, que na verdade é a fundação: estado externo. O modelo esquece tudo entre execuções, então a memória tem que viver fora dele. O jeito mais curto de dizer isso: o agente esquece, o repo não.

A tensão que ninguém resolveu

Existe um problema estrutural no meio disso, e vale nomear antes de qualquer entusiasmo: a capacidade de gerar ultrapassou a capacidade de verificar. Agentes produzem código rápido; checagens confiáveis continuam sendo artefato escasso, feito por gente.

Daí vêm as falhas clássicas, todas documentadas: reward hacking (o agente reescreve o teste em vez de consertar o código), tool-call hacking (ele chuta a saída em vez de usar o resultado da ferramenta), o exit "parece pronto" (declara conclusão sem evidência) e a iteração infinita (loop sem condição de parada).

Um paper de julho deste ano no arXiv argumenta na mesma direção: o problema não é o modelo ser fraco, é o loop ser mal projetado. E a própria Anthropic, na engenharia de agentes eficazes, coloca o requisito de forma seca, o agente precisa obter ground truth do ambiente a cada passo. Não da própria opinião. Do ambiente.

Os quatro pontos onde meu loop é diferente

Eu implemento quatro dos cinco componentes acima. São decisões que o eu determinei.

1. Loop sem worktree

O worktree é um dos cinco componentes canônicos. Eu tirei o meu, e tenho uma regra explícita proibindo o agente de criar um por iniciativa própria.

O raciocínio é este: em repositório de infraestrutura, o isolamento que importa não é de arquivo, é de estado. O que colide de verdade quando dois agentes trabalham em paralelo não é o diretório, é o state remoto do Terraform, é o lock de um apply em andamento, é o contexto de cluster ativo no kubectl, é o registro de um recurso que só existe uma vez na nuvem. Worktree não resolve nenhum desses. Ele te dá dois checkouts que disputam exatamente o mesmo recurso, com a sensação agradável de que estão isolados.

Então eu troco por outra coisa: branch, e o PR como gate. O isolamento vem do branch. A verificação vem da revisão. E o PR ainda me dá o que worktree nenhum dá, trilha de auditoria com diff, comentário e aprovação nominal. Em infra, "quem aprovou isso" é uma pergunta que aparece.

2. Guardrail antes da geração, não depois

O padrão da literatura é gerar e depois verificar. Meu loop inverte parte disso. As rules carregam antes de qualquer código existir, e várias delas são proibições: validar versão de provider e schema do recurso via MCP antes de escrever a primeira linha; nunca escrever segredo em arquivo; nunca abrir endpoint público em serviço de dados de produção; menor privilégio por padrão.

A ideia é simples e pouco glamourosa: o verificador mais barato do mundo é a regra que impede o erro de existir. Um teste que pega credencial hardcoded é bom. Uma regra que faz o agente nunca escrever uma é melhor, porque custa zero iteração.

É o mesmo raciocínio que eu já defendi em Platform Engineering e Policy-as-Code que aceleram times, só deslocado uma camada para trás. Lá a política barra o recurso errado na hora de admitir; aqui a regra impede o agente de escrever o recurso errado. Política é guardrail para o que já existe; rule é guardrail para o que ainda vai nascer.

3. Em infra, o verificador não é a suíte de testes

Aquela tensão de gerar-versus-verificar é ruim em desenvolvimento de aplicação. Em plataforma é pior, por um motivo bobo: verificar custa tocar em ambiente.

Não existe npm test que me diga se uma regra de rede vai funcionar. O verificador honesto é outro conjunto de coisas, e elas têm preços muito diferentes:

A regra que eu sigo é ordenar do mais barato ao mais caro, e nunca deixar o agente pular etapa. O Augment recomenda a mesma ordenação de forma genérica, portas determinísticas primeiro, raciocínio depois, teste dinâmico por último. Em infra isso não é otimização de custo, é gestão de blast radius.

E o corolário desconfortável: o último gate da minha lista não é automatizável hoje. "O ambiente está saudável" envolve olhar coisa que só existe depois de aplicar. É exatamente por isso que a próxima tese existe.

4. O outer loop é meu

O Osmani tem uma frase: "Delegating the inner loop is leverage; delegating the outer loop is abdication."

Delegar o inner loop, escrever, rodar o gate, corrigir, rodar de novo, é alavancagem pura. É trabalho que eu não quero fazer à mão.

Delegar o outer loop, decidir o que é o objetivo, julgar se o resultado presta, assumir o resultado, é abdicação. Não é uma questão de confiança no modelo. É que a responsabilidade não é transferível: quando algo cai, ninguém aceita "o agente decidiu".

No meu setup isso está codificado, não é boa intenção:

• O objetivo vem de um card do Jira.
• O ID da tarefa vive no nome da branch, não na conversa. Qualquer sessão nova recupera o objetivo com um comando de git.
• O fim do ciclo é um PR, com um comentário de volta no card. Não um deploy.
• O estado persiste fora do modelo, em memória entre sessões e no próprio histórico do repo.
• O merge é meu. O agente nunca faz merge. Nenhuma exceção.

Repare que só o primeiro e o último item são sobre mim. Os três do meio são automação, e é justamente por serem automatizados que eu consigo manter as pontas na mão sem virar gargalo. Autonomia no meio, autoridade nas bordas.

Isso torna meu loop menos autônomo do que os exemplos que circulam por aí. É de propósito. Autonomia é meio, não é métrica.

Como o loop está montado

Agora a mecânica. A tese organizadora, e o que eu levaria para qualquer outro setup: hook aplica, skill instrui, MCP executa.

Três camadas, três papéis, e a disciplina de nenhuma invadir a outra. Hook é determinístico , ele detecta e aplica. Skill é procedimento versionado, ela ensina. MCP é quem busca atualidade na internet. Quando eu misturei os papéis, quebrou. Quando separei, ficou previsível.

exit 2 é a primitiva do loop

Se eu pudesse levar uma coisa só deste artigo, seria esta.

Leia de novo. Isso significa que um script de shell de trinta linhas consegue injetar correção no loop. Não é sugestão em documentação que o modelo talvez leia. É feedback que chega no momento exato do erro, com o texto que eu escrevi.

Esse é o caminho de feedback da definição de loop, implementado em bash. Cinco hooks meus usam isso: três para o modelo se autocorrigir, um para entregar uma tarefa de follow-up, um para travar de verdade.

Um exemplo genérico, que é a forma de todos eles:

#!/usr/bin/env bash
# PostToolUse — avisa quando um manifesto sai sem limite de recurso.
set +e
[ -t 0 ] && exit 0                    # sem stdin, nada a fazer
payload="$(cat)"; [ -z "$payload" ] && exit 0

file="$(printf '%s' "$payload" | jq -r '.tool_input.file_path // empty')"
case "$file" in *.yaml|*.yml) ;; *) echo '{"continue":true}'; exit 0 ;; esac

# só olha workload de verdade, não Application/CRD/kustomization
grep -qE "^kind: (Deployment|StatefulSet|DaemonSet|Job|CronJob|Pod)$" "$file" || {
  echo '{"continue":true}'; exit 0; }

if ! grep -q 'resources:' "$file"; then
  printf 'Guardrail: %s define workload sem resources/limits. Adicione requests e limits antes de seguir.\n' "$file" >&2
  exit 2                              # <- stderr volta para o contexto do modelo
fi
echo '{"continue":true}'

Note duas coisas que aprendi na prática. Primeira: o hook estreita o escopo antes de opinar, se ele disparasse em todo YAML, ia gritar em manifesto de GitOps que legitimamente não tem resources, e guardrail que grita errado é guardrail que a gente desliga. Segunda: a mensagem diz o que fazer, não só o que está errado. Feedback acionável fecha o loop numa iteração; feedback vago gasta três.

O card é o objetivo, e o loop começa nele

Um loop precisa de objetivo que o modelo não inventou. No meu setup ele vem de um card do Jira, e o ciclo toca o card em três momentos: descobrir qual é, criar a branch e comentar de volta no fim.

project = <PROJ> AND assignee = currentUser() AND status = "In Progress"
ORDER BY updated DESC

E aqui está a decisão de design IRADA que decidi criar: ele pega o primeiro resultado e não pergunta. Diz em uma linha qual card assumiu, "usando o card X, tal resumo", e segue trabalhando. Se estiver errado, eu corrijo na mensagem seguinte.

Um loop que para para perguntar "qual desses três cards?" não é um loop, é um formulário. Pergunta bloqueante no início de toda tarefa é exatamente o atrito de humano-no-meio que Loop Engineering existe para remover. O padrão certo é default otimista com correção barata: escolha o mais provável, diga em voz alta o que escolheu, continue. Errar custa uma mensagem; perguntar custa todas as vezes.

As saídas de emergência são explícitas, e isso importa mais que a regra: se eu já dei a chave na mensagem, não busca nada. Se a busca voltar vazia, ela avisa e pede a chave, nunca inventa uma. Se eu citar outro projeto, usa aquele. Loop bom tem default; loop confiável tem default e as três exceções escritas.

E tem um detalhe de arquitetura aí que eu considero mais importante que a convenção: a sequência do git não está na skill. Dar pull na base, sair dela para uma branch nova, nunca commitar na base, isso vive numa rule, e a skill do Jira diz explicitamente para não repetir esses passos. É a disciplina anti-duplicação. Se eu copiar a sequência do git em toda skill que mexe com git, mudar a sequência significa editar cinco arquivos e esquecer dois.

Tem também um ritual de limpeza antes de começar a próxima tarefa: voltar para a base, git pull --prune para derrubar as referências de rastreamento que já morreram no remoto, e apagar a branch local que já virou PR. Parece detalhe bobo, mas um loop que cria uma branch por tarefa e nunca limpa te deixa com quarenta branches órfãs em três meses.

git branch --show-current | grep -oE 'feature/[A-Z][A-Z0-9_]+-[0-9]+'

O ciclo que se fecha sozinho

O melhor exemplo de loop no meu setup é o que fecha esse ciclo: liga o PR de volta ao card. Ele mostra as três camadas trabalhando sem se atropelar.

O hook roda em PostToolUse, casando tanto com o comando de CLI que abre PR quanto com a tool MCP equivalente. E aí vem a parte que eu errei na primeira versão: ele confirma que uma URL de PR realmente voltou na resposta antes de fazer qualquer coisa. Sem isso, ele disparava quando o comando falhava ou era negado, anunciando um PR que não existia.

pr_url="$(printf '%s' "$response_blob" \
  | grep -oE 'https://github\.com/[^"[:space:]]+/pull/[0-9]+' | head -1)"
[ -z "$pr_url" ] && { echo '{"continue":true}'; exit 0; }

E o passo decisivo: o hook não escreve no rastreador. Ele não tem credencial, não conhece a API, não sabe formatar o comentário. Ele sai com código 2 e devolve ao modelo um ponteiro, vá na seção tal da skill tal, extraia a chave da branch atual, resuma o que foi feito, comente no card com o link.

A skill é quem sabe o procedimento, e ela é específica de um jeito que só a prática ensina: o resumo sai em inglês mesmo quando a conversa é em português, porque o card é lido por outros times; o link do PR vai como link markdown com texto descritivo, nunca URL crua, porque URL crua vira uma string gigante que arrebenta a leitura do parágrafo; e se a branch não seguir o padrão esperado, não faz nada e fica calado, não todo PR está ligado a um card.

O MCP tem o token e escreve o comentário.

Trigger determinístico, procedimento versionado, efetor autenticado. Nenhuma das camadas sabe fazer o trabalho da outra, e é por isso que dá para mexer numa sem quebrar as demais.

Minha trava preferida: nada é destruído sem eu olhar

De tudo que eu construí nesse setup, esse é o hook de que eu mais gosto, e é o que eu recomendaria escrever primeiro se alguém me perguntasse por onde começar. A regra dele é uma frase: toda operação destrutiva para e pede autorização, sempre, independente do modo em que eu esteja.

Ele roda em PreToolUse, antes de qualquer coisa acontecer, e a cobertura é deliberadamente ampla. São dez regras rotuladas, testadas em ordem, e o rótulo importa porque é ele que vai para o log:

• Remoção de arquivo, rm, rmdir, unlink, shred, del, com ou sem sudo, inclusive quando aparecem depois de um ;, de um && ou dentro de um subshell.
• Subcomando destrutivo depois de uma CLI conhecida, a rede mais larga de todas: delete, destroy, uninstall, purge, prune, remove, drop precedidos de az, kubectl, helm, docker, terraform, tofu, gh, argocd, flux, aws, gcloud, npm, apt e companhia.
• terraform destroy, e também o apply disfarçado com a flag de destruição, que é o jeito silencioso de fazer a mesma coisa.
• Git destrutivo, push --force, reset --hard, clean -f, branch -D, tag -d, stash drop e stash clear. Perder trabalho local não é menos grave que perder recurso na nuvem, é só mais silencioso.
• Docker, system prune, volume rm, network rm, e o compose down -v que leva os volumes junto.
• Kubernetes, kubectl delete e kubectl drain, helm uninstall.
• find com -delete ou -exec rm, que é como um comando de busca se transforma em remoção em massa.
• SQL, DROP TABLE, DROP DATABASE, DELETE FROM, TRUNCATE.
• Verbo destrutivo genérico, a rede de segurança para o que eu não previ: pega uma tool de MCP chamada delete_algumacoisa ou um campo "destroy" no payload.

E tem um detalhe de escopo que faz esse último item funcionar. O hook não olha só linha de comando: quando a ferramenta não é o shell, ele varre o tool_input inteiro. Isso é o que faz uma tool de MCP que apaga recurso na nuvem cair na mesma rede que um rm -rf. Ferramentas que não destroem nada (ler, escrever, buscar arquivo) saem na primeira linha, sem custo.

Repare no que isso significa: é o único guardrail meu que não confia em mim. Os outros protegem contra o agente errar. Esse protege contra eu estar no automático e aprovar sem ler, que é o modo de falha mais provável depois que o loop começa a funcionar bem. É o freio contra a rendição cognitiva, escrito em shell.

Ele também é o único que ignora o kill-switch global. Todos os meus outros hooks respeitam uma variável de ambiente que os desliga de uma vez; esse não olha para ela. Guardrail que desliga junto com o resto não é guardrail, é enfeite.

{ "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "ask",
    "permissionDecisionReason": "Operação destrutiva, confirme antes de seguir." } }

Só que existe um modo de permissão em que os prompts estão desligados. Nele, pedir confirmação é pedir para o vazio, a decisão é simplesmente ignorada e o comando passa. Descobri isso do pior jeito possível: o guardrail existia, parecia certo, e não protegia nada exatamente no modo em que eu mais precisava dele.

A correção é ser consciente do modo:

case "$perm_mode" in
  bypassPermissions) printf 'BLOQUEADO: %s\n' "$reason" >&2; exit 2 ;;
  *) jq -n --arg r "$reason" '{"hookSpecificOutput":{
       "hookEventName":"PreToolUse","permissionDecision":"ask",
       "permissionDecisionReason":$r}}' ;;
esac

Onde tem prompt, pede. Onde não tem, usa exit 2, que é o único mecanismo que bloqueia em qualquer modo, e a mensagem diz para sair do modo bypass e reexecutar se a intenção era real. Isso fecha a única brecha que restava.

E o log de auditoria é escrito antes da decisão, nunca depois. Se eu aprovar no automático, quero pelo menos ter o registro de que fui eu que aprovei, com data, sessão, regra e o comando inteiro. Auditoria que só grava o que foi bloqueado conta metade da história.

Verificador separado, com dentes

O componente que o Osmani chama de mais útil é separar quem escreve de quem confere. Subagentes são o mecanismo.

O que eu acrescentaria é: separe por restrição de ferramenta, não por instrução. Dizer no prompt "você é read-only" é pedir cortesia. Não entregar as ferramentas de escrita é garantir.

Meus dois verificadores, um que planeja antes de mexer, um que revisa depois, não têm Edit nem Write. Também não têm a ferramenta de spawnar outros agentes, então são folhas da árvore: não conseguem delegar o próprio julgamento para um terceiro que teria escrita. O agente que implementa tem escrita, e não é o mesmo que aprova.

E tem um teto explícito no orquestrador: se a revisão não convergir em três rodadas, ele para e me reporta em vez de continuar tentando. Escrevi isso meses antes de ler qualquer coisa sobre Loop Engineering, por um motivo prosaico, vi um ciclo revisar e reescrever a mesma coisa sem convergir. É o "iteration cap" da literatura, aprendido na marra.

Um detalhe que economiza contexto: meus verificadores têm formato de saída fixo, e uma das seções obrigatórias é "obstáculos encontrados", problema de ambiente, comando que precisou de flag especial, dependência que atrapalhou. Isso impede que quem chamou redescubra o mesmo tropeço. É estado externo em escala de subagente.

A escada de verificação, na prática: escrevendo um operator

A tese 3 disse que em infra o verificador não é a suíte de testes. Mas isso não significa que não exista suíte. Significa que ela é um degrau, não o topo. O caso onde eu montei essa escada por inteiro foi escrevendo um operator Kubernetes em Go, com Kubebuilder, e a ordem importa mais que cada peça.

E aqui está a regra que eu considero a mais valiosa deste artigo depois do exit 2, porque é a defesa direta contra reward hacking:

Isso é mutation testing manual, e resolve o problema central do loop autônomo. O agente é ótimo em escrever teste que passa. Pedir "escreva um teste", não. Digite "escreva um teste e me prove que ele pega o bug". É a diferença entre verificar e parecer que verificou.

Essa é uma falha de loop clássica e vale nomear: erro de ambiente que se disfarça de erro de código. O agente lê o stack trace, acredita nele, e começa a consertar a coisa errada com muita confiança. O antídoto é o mesmo do resto: registrar o obstáculo por escrito na primeira vez que ele aparece, para a próxima sessão não repetir o diagnóstico.

Então existe um degrau a mais: o Kubernetes que vem no Docker Desktop, rodando na minha máquina, configurado com os mesmos valores de Helm do módulo que provisiona o ambiente real. Não é um cluster de brinquedo com o default do chart; é o ambiente de produção em miniatura, e é isso que faz o teste valer. Ao lado dele, um backend que só ecoa os headers que recebeu, e um curl. Aí eu vejo o que realmente chegou.

Esse degrau também é onde mora um dos meus guardrails favoritos, e ele é de permissão, não de código: os clusters reais são read-only para o agente, só get, list, watch, logs e events, mais nada. O cluster local é a única exceção com acesso de escrita. A assimetria é o guardrail. O agente pode quebrar o quanto quiser onde quebrar é grátis, e não alcança onde não é.

E uma armadilha bem específica de quem roda WSL com Docker Desktop, que me custou um bom tempo: rodar o operator com go run no WSL e tentar alcançá-lo do cluster via host.docker.internal não funciona. WSL e a VM do Kubernetes do Docker Desktop são máquinas virtuais separadas. O DNS resolve, o que faz parecer que está tudo certo, e a conexão TCP simplesmente não completa. Diagnóstico enganoso do início ao fim.

Tem um sexto verificador nessa história que eu gosto de citar porque é um teste guardando consistência entre duas fontes de verdade, não comportamento. O RBAC do operator existe em dois lugares: um arquivo gerado a partir de marcadores no código, que não pode ser editado à mão, porque o gerador sobrescreve silenciosamente na próxima execução, e uma cópia de referência no manifesto. Um teste falha o build se os dois divergirem. Sem ele, alguém edita o gerado à mão, o gerador apaga na semana seguinte, e o operator perde permissão em produção sem ninguém ter tocado em permissão.

Quando o CI é o verificador: ler a pipeline de volta

Os cinco degraus acima rodam antes do push. Depois do push existe outro verificador, que é o único que enxerga o ambiente de CI de verdade: a pipeline.

E é aqui que o loop se fecha de um jeito que eu não esperava que funcionasse tão bem. O agente não precisa que eu traduza o erro do CI para ele. Ele lê direto, pelo gh CLI ou pela tool de MCP do GitHub, pega o log do que falhou, corrige e empurra de novo.

O detalhe de eficiência que faz diferença é pedir só o que falhou:

gh run list --branch "$(git branch --show-current)" --limit 1
gh run view <run-id> --log-failed

Isso é ground truth do ambiente, no sentido exato que a Anthropic descreve, o agente não está julgando o próprio trabalho, está lendo o veredito de um sistema que ele não controla. Que é a definição de verificador honesto.

Skills: a descrição é o que decide

O que mais gente entende errado, e eu entendi errado por um bom tempo: a description do frontmatter não é documentação, é o mecanismo de roteamento. É por ela que o modelo decide carregar a skill ou não. Descrição vaga é skill que nunca dispara.

---
name: minha-skill
description: "O que faz + QUANDO usar, com as palavras que aparecem no pedido real. Diga também o que NÃO é, se existir skill vizinha que confunde."
---

## Quando usar
## Passos
## Guardrails

Duas coisas que a prática ensinou. Desambiguação explícita vale ouro: eu tenho duas skills sobre Kubernetes que fazem coisas diferentes, e cada descrição termina dizendo "isto é X, não Y, para Y use a outra". Sem isso, disparava a errada metade das vezes.

Rules com escopo: disciplina de token

Um CLAUDE.md carrega em toda requisição. Isso é uma faca de dois lados: o que está lá é sempre verdade, e você paga por isso sempre.

Então eu separei. O arquivo raiz ficou deliberadamente curto, contexto, modelo de nomenclatura, os não-negociáveis, e a regra de roteamento. Profundidade de domínio foi para arquivos que carregam só quando um arquivo daquele tipo é editado, via glob de caminho.

A lição de escopo veio de um erro que dói de lembrar. Minha regra de manifestos casava com /.yaml, extensão nua. Resultado: disparava em pipeline, em config de linter, em qualquer YAML do mundo, injetando guardrail de Kubernetes onde não tinha Kubernetes. Trocar para escopo por convenção de diretório* resolveu. Regra que dispara errado treina você a ignorar regra.

MCP no Docker: um gateway, muitos servidores

Já escrevi um artigo inteiro sobre esse caminho, MCP Server com Docker e Terraform: discovery, troubleshooting e produtividade, com a montagem passo a passo. Aqui o recorte é outro: o papel que ele cumpre dentro do loop.

Sem ele, cada servidor MCP é um processo com runtime próprio, dependência própria e credencial largada em algum .env. Com o MCP Toolkit e o Catalog, você habilita servidores pela interface do Docker Desktop e o MCP Gateway agrega todos eles atrás de uma única entrada de configuração. Cada servidor roda em container, com limite de CPU e memória e no-new-privileges. E, o ponto que mais me importa, as credenciais ficam no store cifrado do Docker, não em arquivo no repo.

São 331 ferramentas em 11 servidores, mais as nativas do próprio gateway, o que fecha as ~339 que aparecem no handshake. Um único container por servidor, uma única entrada de configuração no cliente.

Agora olhe essa tabela como orçamento em vez de catálogo. Três servidores concentram 207 das 331 ferramentas, quase dois terços. Eu não uso 77 operações de Jira: uso quatro ou cinco. Esse é o custo escondido do "habilita que é fácil", e é a causa do problema de timeout logo abaixo, não só um detalhe de contexto.

Eu publiquei o meu:

# publicar o profile local em um registry
docker mcp profile push profile rafaferreira011/public:latest

# do outro lado, instalar tudo de uma vez
docker mcp profile pull rafaferreira011/public:latest

O artefato está público no Docker Hub. Repare que não é uma imagem executável: são ~170 kB de JSON com artifactType application/vnd.docker.mcp.profile.v1+json, a relação de servidores com as imagens fixadas por digest. Ninguém roda esse artefato, o Toolkit lê e reconstrói a configuração.

Duas coisas que valem dizer, porque são exatamente as perguntas que eu faria:

E fechando o argumento do orçamento de ferramentas lá de cima, existe a régua fina, que eu deveria ter começado a usar antes:

docker mcp profile tools <profile-id> --disable atlassian.jira_delete_issue
docker mcp profile tools <profile-id> --disable-all playwright

Dá para habilitar e desabilitar ferramenta a ferramenta, não só servidor inteiro. É a resposta certa para "77 operações de Jira das quais eu uso cinco": em vez de desligar o servidor e perder o que presta, corta a cauda e fica com o que você chama de verdade.

A configuração no lado do cliente é uma entrada só:

{
  "mcpServers": {
    "MCP_DOCKER": {
      "type": "stdio",
      "command": "docker",
      "args": ["mcp", "gateway", "run"]
    }
  }
}

Tem caminho ainda mais curto: no Docker Desktop, em MCP Toolkit → Clients, existe um botão que conecta o cliente e escreve esse arquivo por você. Pela CLI, o equivalente é docker mcp client connect claude-code. Segredo entra com docker mcp secret set, nunca no JSON. Depois é só rodar /mcp no cliente para conferir que conectou. O blog oficial do Docker tem o passo a passo, e existe um tutorial em vídeo do próprio Docker cobrindo a mesma sequência. Para diagnóstico, o Docker publica um plugin oficial que adiciona comandos de status e debug do gateway.

Agora as duas armadilhas que eu paguei, e que não estão em tutorial nenhum.

A correção é aumentar o teto nas configurações do cliente:

{ "env": { "MCP_TIMEOUT": "120000", "MCP_TOOL_TIMEOUT": "180000" } }

Estado externo

O modelo esquece entre execuções. Então tem que existir memória fora dele, e ela opera em duas escalas no meu setup.

O loop que melhora o loop

Voltando ao primeiro componente do Osmani: automations são o que fazem um loop ser loop. É a peça que eu demorei mais para colocar, e a que mais mudou as coisas.

Tenho uma rotina semanal agendada que lê os transcripts da própria semana e mede o que aconteceu: quais ferramentas foram mais chamadas, quais skills dispararam, quais subagentes foram acionados. Aí ela cruza isso com o que já existe no meu setup e propõe: aqui houve repetição que merece uma skill nova; aqui uma skill existente ficou vaga e precisa de descrição melhor.

A barra de aceitação é explícita, porque sem ela a rotina cria skill para tudo: precisa ser repetível e não-óbvio, ter aparecido em duas sessões com a mesma forma, ou ter custado iteração pesada uma vez, ou ser uma correção minha que ainda não estava escrita em lugar nenhum, do tipo "nesse repositório não crie nada", "sempre use tal comando".

E o detalhe que faz funcionar: ela registra o que foi rejeitado. Sem isso, a rodada seguinte propõe a mesma coisa de novo, e você passa a ignorar o relatório inteiro.

Tem uma segunda camada: uma skill de governança que define como escrever artefato nesse setup, quando é regra e quando é skill, limite de tamanho, e a obrigação de procurar sobreposição antes de criar coisa nova. Cada regra dela rastreia para uma falha concreta que eu vivi.

O loop tem meta-loop. E é aí que ele para de ser configuração e começa a ser sistema.

Como eu montei essa rotina

O objetivo era fácil de enunciar: toda semana, ler as minhas próprias sessões de trabalho e transformar o que se repetiu em skill, nova quando não existe nada cobrindo, melhoria na que já existe quando existe. Nada de inventar processo: a fonte é o que eu de fato fiz na semana, com o agente, no ambiente real.

A primeira decisão apareceu antes de qualquer código: onde vive o insumo. E a resposta elimina de saída a opção mais confortável. Os transcripts das minhas sessões só existem na minha máquina, então um agendador na nuvem, que rodaria com o computador desligado, sem eu precisar lembrar de nada, veria commit e PR, e é exatamente isso que não interessa. Commit conta o que ficou de pé; transcript conta o que eu pedi, quantas tentativas custou e qual suposição estava errada. O valor está no atrito, e o atrito só fica registrado localmente. Sobrou tarefa agendada no sistema operacional chamando o cliente em modo headless: menos elegante, e a única com acesso ao que importa.

A segunda decisão foi de divisão de trabalho, e é a mesma tese do resto do artigo: o que é determinístico não vai para o agente. Destilar a semana é trabalho de shell, varrer os transcripts, contar chamada de ferramenta, extrair os prompts reais separando-os do ruído de plumbing, cruzar com o histórico de commits, listar o inventário de skills que já existe. Dezenas de megabytes viram um digest de umas seiscentas linhas em menos de um minuto, sem gastar um token. O agente entra depois, com o digest pronto na mão, para fazer só a parte que exige julgamento: isso é rotina ou foi acidente? já existe skill que cobre? melhora a que existe ou cria nova?

Aí vieram as paredes. Três, e todas se parecem exatamente igual do lado de fora, o agente diz que precisa de aprovação e para, sem pista de qual delas é:

• O agente não escreve na própria camada de configuração. O diretório de customização é caminho sensível: em modo não-interativo a escrita é recusada, com ou sem regra de permissão liberando explicitamente aquele caminho. E é proteção correta, rotina que pode reescrever as próprias permissões não é rotina, é risco. A saída foi inverter o fluxo: o agente escreve a proposta num diretório de staging, e um script de shell promove só o que casa um padrão estreito, arquivo .md dentro de skills//, nunca configuração, nunca hook, nunca executável, guardando backup do que for sobrescrito. O que o script recusa, ele registra.
• Liberar o caminho não libera criar arquivo. Regra de permissão com escopo de caminho não limpa a aprovação de criação de arquivo novo, e a execução trava pedindo uma confirmação que, em headless, ninguém pode dar. Precisa combinar com o modo de permissão que aceita edição. Bônus: diretório oculto, começando com ponto, simplesmente não casa com o glob da regra, perdi um ciclo inteiro procurando bug antes de renomear o diretório e ver funcionar.
• Comando composto não casa allow-list. Eu havia liberado o script coletor por caminho; o agente rodou mkdir -p ... && ./coletor e a regra não casou. Isso virou princípio, e é o que consolidou a divisão acima: passo determinístico roda no wrapper, não dentro do agente.

O que a primeira execução real entregou: uma skill nova, um procedimento de virada de ingress que atravessa duas camadas de infraestrutura e que nenhuma skill existente cobria; duas melhoradas, uma delas ganhou a descoberta que mais me custou na semana, a de que o dry-run do cliente de linha de comando valida schema mas não avalia lógica de política de admissão, então "passou no dry-run" não significa nada ali; e quatro rejeitadas, cada uma com o motivo escrito, três delas por duplicarem skill existente.

Mas o item que me convenceu de que a coisa tinha valor foi outro: ela corrigiu uma memória minha que estava errada. Eu tinha um fato registrado dizendo que um certo repositório seguia meu fluxo padrão de branch e PR. Durante a semana eu havia dito o contrário, duas vezes, em sessões diferentes. A rotina leu isso nos transcripts, viu a contradição com o que estava escrito, e reescreveu o registro. O loop consertando o estado externo do próprio loop.

E uma honestidade sobre o alcance: o passe agendado é rede de segurança, não o evento principal. Rodando sem supervisão, o agente não pode me perguntar "isso vai repetir?", e essa resposta é justamente o critério que separa skill útil de entulho. Quando eu rodo o mesmo procedimento à mão, numa sessão normal, sai skill melhor. O agendamento existe porque o insumo é perecível e disciplina humana não é confiável; o refino continua sendo meu. Outer loop, de novo.

A verificação que me deixou tranquilo não foi ela ter criado skill, foi rodar duas vezes na mesma janela. Na segunda, reconheceu que a semana já tinha sido processada, reconferiu as rejeições anteriores e não escreveu nada. Zero arquivos promovidos. Automação que reescreve o que já existe a cada execução não é automação, é ruído com agenda.

A automação que eu não escrevi

Outra automação que pensei: uma rotina para apagar as sessões antigas, com mais de uma semana. A motivação é menos glamourosa que a da anterior e mais séria. Transcript é texto puro, e tudo que passa por uma ferramenta é gravado nele, conteúdo de arquivo, saída de comando, o que eu colei no prompt. Em ambiente de plataforma isso significa detalhe de infraestrutura acumulando em texto claro no meu diretório de usuário, protegido só por permissão de arquivo do sistema. E o bom que o próprio claude code ja tem um mecanismo de limpeza: o client já varre por idade na inicialização, e o período é uma chave no arquivo de configuração do usuário, ~/.claude/settings.json:

{ "cleanupPeriodDays": 8 }

O default são 30 dias, o mínimo é 1. Baixar para 8 foi uma escolha minha.

Um inventário inteiro, do zero até virar sistema

O exemplo mais completo de tudo isso trabalhando junto não veio da rotina agendada, veio de um pedido pontual: mapear todas as tecnologias em uso num ambiente de plataforma com dezenas de repositórios. Sem inventário prévio. Era descobrir do zero, e o resultado ia decidir o que precisava virar skill.

A primeira rodada foi fan-out puro: um agente por área, infraestrutura como código, pipelines, orquestração de containers, linguagens, todos em paralelo, cada um devolvendo o que achou. Saiu organizado, sem furo visível. Foi exatamente essa perfeição que me fez desconfiar: levantamento bom demais de um ambiente que eu sei que é bagunçado é sinal de cobertura rasa, não de sorte. Pedi mais uma passada, recortando por um repositório específico que eu sabia ser denso, e a lista de tecnologias daquele recorte sozinho quase dobrou o total. O primeiro fan-out tinha visitado cada área uma vez e chamado isso de completo.

Fechei a segunda rodada com o mesmo princípio de sempre: quem escreve não confere. Nova leva de agentes, mas com a instrução invertida, não confirme o que já está escrito, tente refutar. Cada um recebeu um pedaço do levantamento e a ordem explícita de achar erro, não validar acerto. Valeu a rodada: achou um item que não existia (um agente anterior tinha inventado um detalhe plausível que não batia com o ambiente real), achou outro atribuído ao lugar errado, e um terceiro marcado como "desativado" quando na verdade estava ativo em produção. Nenhum dos três ia aparecer se eu tivesse pedido para o mesmo agente reler o próprio trabalho, ele ia confirmar o que já acreditava.

Com o levantamento fechado, o passo seguinte foi virar aquilo em conhecimento operacional, não documento pra ler uma vez, skill que o sistema carrega quando alguém pedir ajuda com uma daquelas tecnologias. E aqui entrou a decisão que o resto do artigo já defende, aplicada em escala: nem tudo virou skill. Duas coisas viraram hook, porque a regra era "isso tem que acontecer sempre, sem depender do modelo lembrar", um aviso de dependência de terceiro que tinha acabado de ser descontinuada e um checador de configuração que falha calado em vez de dar erro. Nada virou agente novo, porque agente é persona isolada com escopo de ferramenta próprio, e cada tecnologia daquelas era conhecimento de referência, não um papel a interpretar. Artefato errado custa tanto quanto artefato nenhum, essa parte do julgamento não terceirizo.

Pra não terminar com dezenas de skills competindo pela mesma descrição, agrupei por domínio operacional, um SKILL.md raiz por área, arquivo de referência por tecnologia dentro dele, carregado só quando aquela tecnologia específica entra na conversa. Antes de escrever a primeira linha, consultei a documentação oficial do próprio formato de skill via MCP: a intuição de "menor é melhor" tem limite, e o padrão oficial recomenda exatamente esse agrupamento com disclosure progressivo, pra não competir por trigger nem custar contexto à toa quando ninguém precisa daquele arquivo.

O último passo foi replicar tudo numa segunda camada de customização, que outra ferramenta usa nesse mesmo ambiente. A motivação não foi capricho de organização: é redundância de verdade. Se o Claude Code sair do ar, tiver uma degradação, ou eu simplesmente precisar trocar de ferramenta num dia ruim, o conhecimento não desaparece junto, ele já existe traduzido, pronto para outro agente carregar. Skill, hook e regra viraram ativo do time, não vendor lock-in de configuração. Eu esperava find-and-replace de caminho. Não foi. A documentação oficial da outra ferramenta, puxada via MCP na hora, corrigiu duas suposições de uma vez: a numeração das regras "inegociáveis" era diferente entre as duas camadas, citar por número mantendo só o nome do arquivo teria virado referência errada, e o formato de skill que eu vinha usando já era, na prática, um padrão aberto que a outra ferramenta também suporta nativamente, pasta de recurso e tudo. MCP não é só pra puxar doc de infraestrutura. É pra puxar doc de qualquer coisa que eu não deveria assumir de memória, incluindo o próprio formato que eu uso pra ensinar o agente.

Conclusão

O que eu levaria daqui, na ordem em que eu faria de novo:

• Comece pelo verificador, não pelo agente. Sem gate honesto, aumentar autonomia só aumenta a velocidade com que você acumula problema. Um loop com verificador ruim é pior que nenhum loop, porque parece estar funcionando.
• Escreva o freio antes do acelerador. Teto de iteração, regra de parada, guardrail que dispara antes da geração. Quatro dos cinco itens da anatomia de um loop são freios; essa proporção não é acidente.
• Separe quem escreve de quem confere, por ferramenta, não por instrução. Read-only de verdade é não ter a ferramenta de escrita.
• Um hook que sai com código 2 é feedback de loop de verdade. É a peça mais barata e mais eficaz do meu setup, e não tem nada de IA nela.
• Escreva primeiro a trava de remoção, e faça ela desconfiar de você. Toda operação destrutiva para e pede autorização, inclusive no modo que liberou o resto, inclusive quando o pedido veio de uma ferramenta e não do shell. É o único guardrail que protege contra o operador no automático, e não contra o agente. Falso positivo nessa checagem é preço, não defeito.
• Exija que o teste de regressão prove que pega o bug. Se ele passa igual com e sem a correção, não testa nada. Não pedir "escreva um teste". Use "reverta a correção e me mostre o teste falhando" é a defesa mais barata que existe contra reward hacking.
• Ordene os gates por custo e nunca deixe pular degrau. Compilar, unidade, integração com API real, cluster local espelhando o ambiente de verdade, e só então a imagem. A imagem é o resultado do loop, não uma etapa dele.
• Deixe o agente ler o CI sozinho, mas só a parte que falhou. Ele não precisa que você traduza o erro. Precisa de acesso ao veredito e de disciplina para não arrastar o log inteiro para o contexto.
• Default otimista, correção barata. Onde o loop precisaria perguntar, faça ele escolher o mais provável, declarar em voz alta o que escolheu e continuar. Pergunta bloqueante no começo de toda tarefa transforma o loop em formulário. Só não esqueça de escrever as exceções: se a busca voltar vazia, pede, nunca inventa.
• Guarde o estado do ciclo onde qualquer sessão acha. A chave da tarefa no nome da branch faz o objetivo sobreviver a compactação, a sessão nova e a subagente. Estado externo não precisa de banco; às vezes precisa só de uma convenção de nome respeitada.
• Deixe a descrição fazer o roteamento. Skill boa com descrição ruim não dispara. Escope regra por convenção de diretório, nunca por extensão nua.
• Automation é o que separa configuração de sistema. Sem rotina agendada, você tem um setup bonito. Com ela, você tem um loop.
• Discorde do padrão quando o seu domínio pedir. Eu tirei worktree porque em infra o isolamento que importa é de estado, não de arquivo.

E o mais importante: o outer loop continua sendo seu. Delegar o ciclo interno é alavancagem; delegar o julgamento é abdicação. A frase com que o Osmani fecha o artigo dele é a melhor síntese que eu achei disso, e serve de régua: "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."

No dia 23 de julho de 2026, junto com Jéssica Mello (LowOps Consultoria), palestrei na Trilha Software Security do TDC Florianópolis, um dos maiores eventos de tecnologia do Brasil, realizado no CentroSul, em Florianópolis - SC.

A trilha abordou um tema central: "Construindo software seguro do design à produção em tempos de IA", explorando como a IA generativa acelera o desenvolvimento, mas também expande riscos e responsabilidades.

Agenda

• Rafael Ferreira (Senior Azure Platform Engineer, Stefanini North America, Microsoft MVP)
• Jéssica Mello (LowOps Consultoria)

Um estudo de caso sobre os limites e riscos do "vibe coding" quando confrontado com exigências reais de produção, e como DevSecOps resolve isso.

Programação da Trilha Software Security

O dia foi repleto de conteúdo técnico de altíssimo nível:

• 10:30–11:05 | Mobile 2026: O custo da compatibilidade e a nova era de exploits com IA — Michel Anderson Lütz Teixeira (AI/R Company)
• 11:15–11:50 | SecOps Autônomo: Automatizando Bumps de Dependência e Resolução de CVEs com IA em Pipelines Zero Trust — Felipe Faria (Mindera)
• 11:55–12:30 | Desenvolvimento seguro com IA: planejamento, revisão e Cross-Agent na prática — Marcelo Martins (Unicred)
• 14:10–14:45 | Vibe Coding com DevSecOps: a IA gerou o site, mas a segurança do deploy foi MINHA — Rafael Ferreira & Jéssica Mello
• 14:50–15:25 | Prompt Injection: um problema de segurança em LLMs — Guilherme Luiz Maia Pinto (Fortress OS)
• 15:30–16:30 | Painel: Da AppSec à AgentSec: quem garante a segurança quando a IA escreve, corrige, opera e decide? — Georgia Maria Ferro Benetti, Rodrigo Diehl, Kalita da Silva, Gabriel Ferreira Ramos da Conceição
• 17:10–17:45 | Eficiência em AppSec: Utilizando a IA para escalar Segurança em Aplicações — Thiago Lotufo (Globo)
• 17:50–18:25 | IA em produção é risco: como governar decisões automatizadas com segurança — Wesley Souza (AdviceHealth)

A Jornada: IA Escreve, Você Responde

O Problema

Meu portfólio pessoal (orafaelferreira.com) estava obsoleto. Precisava modernizá-lo rápido, com estilo contemporâneo, mantendo foco em conteúdo (artigos, palestras, certificações). Tempo era um luxo que não tinha.

O Prompt & o Lovable

Estruturei um prompt detalhado (estilo visual, seções esperadas como blog, palestras e sobre, stack preferido em React e tom de voz) e usei o Lovable para gerar 100% via IA generativa uma primeira versão.

O resultado foi perfeito para um protótipo: um site one-page bonito, responsivo, rodando em produção em horas.

Mas aí vem o problema.

A Crise do Vibe Coding em Produção

Quando saí do "protótipo legal" pra "arquitetura profissional", os clássicos apareceram:

• Vendor lock-in: o Lovable gerou código otimizado pra sua plataforma, não pra ser exportado e sustentado.
• Custo insustentável: hospedagem on-demand sendo cobrada por requisição.
• Arquitetura monolítica: one-page, tudo bundled junto, sem code-splitting, sem preocupação com assets.
• Falta de padrão: sem versionamento Git, sem pipeline, sem testes, sem "agora meu site quebrou em produção, e aí?".

Ficou claro: a IA é excelente em acelerar, mas não entende responsabilidade.

Retomando o Controle

Exportei o código do Lovable pro GitHub, e daí começou o trabalho real.

Refatorei com GitHub Copilot (que também gera código, mas agora meu, meu repositório, minhas decisões), adotei GitFlow completo, versionamento semântico, e transformei o "site bonito" em "sistema profissional":

• Separei conteúdo (TypeScript data files, não CMS) de apresentação.
• Estruturei componentes reutilizáveis.
• Implementei i18n (português + inglês).

DevSecOps de Verdade

Agora veio a camada que diferencia um hobby de um sistema em produção:

• Azure Static Web App (distribuição global, HTTPS nativo, hosting seguro).
• DNS automatizado (apex + www) com validação de domínio.
• Tudo versionado, revisível, auditável.

• tflint — análise estática do Terraform.
• trivy — scanning de vulnerabilidades em imagens e artefatos.
• checkov — compliance & policy as code.
• Rodam tanto no terraform plan quanto no apply, sem passar, não deploya.

• Service Principal do Azure com mínimos privilégios.
• Secrets armazenados no GitHub (criptografados, nunca em logs de build).
• Rotação automática de credenciais.

Stack Final & Qualidade

A evolução não parou em infraestrutura:

• Frontend: React 19 + TypeScript + Vite + TailwindCSS + shadcn/ui (design system moderno, acessível).
• Testes: pirâmide completa, unit/integration com Vitest & React Testing Library, E2E com Playwright.
• SEO tradicional + GEO: structured data, meta tags, sitemaps, RSS, mas também otimizado pra "Generative Engine Optimization" (como LLMs descobrem conteúdo).

Tudo isso não seria possível se eu tivesse confiado 100% no "vibe coding" inicial.

Os 4 C's do Cloud Native Security (Aplicados Aqui)

A estrutura clássica de segurança em cloud funciona em camadas:

1. Cloud: políticas de acesso, roles, networking (tudo Terraform, nada clicável em portal).

2. Cluster/Infra: Azure Static Web App é gerenciada, mas o Terraform valida config & compliance.

3. Container: Trivy verifica imagens; Checkov valida policies.

4. Code: GitHub Copilot ajuda, mas os testes garantem que o código faz o que deve.

Nenhuma camada é ignorada. Nenhuma depende só da IA.

De "Prompt Engineer" a "Harness Engineer"

Quando você usa IA pra gerar código, a evolução natural é:

• Fase 1: Prompt Engineer, "escrever bons prompts" é o skill.
• Fase 2: Harness Engineer, "estruturar o loop IA + automação + feedback" é o skill.

Um harness engineer não só escreve prompts bons; ele:

• Define pipeline, testes, validações que a IA passa por.
• Entende quando a IA pode ir sozinha e quando não.
• Desenha feedback loops (errar, aprender, melhorar).
• Não confia na IA sozinha, a IA é aceleradora, não substituta.

Essa jornada do site foi aprender a ser um harness engineer, não só um prompt engineer.

Checklist Prático: Do "Funcionando" ao "Seguro em Produção"

Aqui está o que você não pode ignorar depois que a IA gera algo funcional:

• Segredos: nunca hardcode. Use vaults, env vars, managed secrets.
• Infraestrutura: IaC (Terraform, CloudFormation, ARM), nada de cliques em portal.
• Testes: unit, integration, E2E, a IA gera código, mas testes garantem que funciona seu caso de uso.
• Scanning: SAST (código), DAST (rodando), dependency checks, container scanning.
• Logs & Monitoramento: quem vai investigar incidente às 3 da manhã? Você. Logo, precisa de visibilidade.
• Documentação: a IA gera código rápido, mas documentação arquitetural é coisa de humano.
• Código review: até a IA merece code review.
• Backup & Disaster Recovery: quando der merda (e vai dar), você precisa de plano B.

Lições da Jornada

1. Um prompt bem estruturado bate tentativa e erro, qualidade da entrada determina qualidade da saída.

2. Unir IA + automação + cloud não é o futuro; é o presente, mas exige T-shaped skills (rápido em amplitude, profundo em especialização).

3. UX importa tanto quanto o produto, design é decisão, não accident.

4. A IA é o acelerador; você é o piloto, profissional generalista (velocidade, vibe coding) precisa ser também especialista em T (DevOps, Terraform, Cloud, Security) pra sustentar o que a IA acelera.

E um thought final, polêmico: se você não está gostando do seu trabalho, ou não está usando IA do jeito certo, ou está no emprego errado.

Slides da Apresentação

Repositórios

• Repositório do Site — código-fonte, Terraform, pipeline completa.

Se você está mergulhando em vibe coding, generative AI, ou IA no deploy, as lições dessa jornada valem ouro.

Resumo rápido

• MCP cria um padrão para clientes de IA se conectarem a ferramentas e dados externos.
• Terraform MCP Server é uma forma prática de trazer contexto de providers, módulos, runs e plans para um workflow mais previsível.
• Agentes de codificação trabalham em um loop de execução (análise, ação e observação), e dá para guiar esse loop com engenharia.
• MCP e skills se completam: o MCP conecta o agente a dados atuais e as skills carregam as boas práticas para orientar cada passo.

O Model Context Protocol (MCP) cria um formato padrão para um cliente consultar ferramentas e dados sem ficar adivinhando formato ou fazendo scraping de texto.

O protocolo foi inicialmente desenvolvido pela Anthropic e hoje evolui como padrão aberto no ecossistema.

E o Terraform MCP Server coloca isso no mundo Terraform.

MCP é tipo um "USB da internet"

Uma analogia que ajuda muito: MCP funciona como um "USB-C" para apps de IA.

No mundo físico, você conecta mouse, teclado, webcam no mesmo padrão. No mundo de IA, você conecta servidores MCP de docs, cloud, banco, ticket, observabilidade e automação no mesmo protocolo.

Isso permite trocar informações sem reescrever tudo e diminui acoplamento entre cliente e integrações.

Exemplos simples:

• um agente conecta no MCP do Terraform para ler módulos e providers
• o mesmo agente conecta no MCP de observabilidade para investigar incidente
• depois conecta no MCP de wiki interna para buscar padrões do time

Como o agente de IA realmente trabalha: o loop de execução

Antes de plugar qualquer MCP, vale entender como um agente de codificação (Claude Code, GitHub Copilot, Codex e afins) executa uma tarefa. Ele não resolve tudo de uma vez: trabalha em um loop de execução.

O ciclo se repete mais ou menos assim:

• Análise — o agente lê a tarefa (ou a especificação) e decide o próximo passo
• Ação — chama uma ferramenta: ler um arquivo, rodar um comando ou consultar um MCP
• Observação — lê o resultado daquela ação
• Repetição — volta para a análise e segue até concluir a tarefa

Quando você fica trocando prompt atrás de prompt no chat, corrigindo na tentativa e erro, o agente decide sozinho cada passo, sem trilho. É o famoso "vibe coding": até funciona, mas rende pouco e erra bastante.

A alternativa é aplicar engenharia a esse ciclo, guiar o loop em vez de só reagir a ele. Para isso existem dois controles complementares: skills (direção) e MCPs (ferramentas).

Skills vs MCPs: dois controles que se completam

É fácil confundir os dois, mas cada um resolve um problema diferente:

• MCP é o encanamento. Dá ao agente acesso a ferramentas e dados externos, aqui, a documentação viva de providers e módulos do Terraform. Responde a "o que o agente consegue alcançar?".
• Skill é o livro-texto. Empacota conhecimento e boas práticas que o agente carrega sob demanda: workflows, convenções e guardrails. Responde a "como o agente deve trabalhar?".

A própria HashiCorp resume bem: o MCP é o "cano" que conecta dados à IA, enquanto as Agent Skills são os "livros-texto" de conhecimento, e o melhor resultado vem de usar os dois juntos.

Na prática, com Terraform:

• só com MCP: o agente consulta a versão atual do provider e evita gerar código preso a uma versão antiga do treinamento
• só com skill: o agente segue o style guide, escreve testes e revisa segurança, mas sem dados atualizados
• com os dois: dados atuais e boas práticas dentro do mesmo loop

Skills são um formato aberto criado pela Anthropic: cada uma é uma pasta com um arquivo SKILL.md que descreve, em linguagem natural, quando e como o agente deve agir. Diferente de um prompt pontual, a skill é reutilizável e só entra em contexto quando é relevante.

No dia a dia

Sem MCP, o fluxo costuma ser:

1. pesquisar manualmente provider/módulo

2. abrir várias abas para comparar versões

3. cruzar informação de workspace, run e plan na mão

4. responder o time com base em contexto parcial

Com MCP, um cliente compatível consegue consultar essas informações de forma estruturada.

Em vez de prompt genérico, você chama uma tool específica e recebe dados previsíveis. Isso reduz erros, acelera decisões e melhora rastreabilidade.

No dia a dia, os ganhos mais claros são:

• discovery mais rápido: buscar providers e módulos sem navegar em 10 páginas
• menos erro de versão: consultar versões recentes de forma objetiva

Exemplos de tools disponíveis:

• search_providers e get_provider_details
• search_modules e get_module_details
• get_latest_provider_version e get_latest_module_version
• list_workspaces e get_workspace_details
• get_plan_json_output e get_run_details

Onde encontrar MCPs oficiais na internet

Se você quer fontes confiáveis para descobrir servidores MCP:

• Site oficial do MCP (oficial: conceitos, spec e guias)
• Organização oficial no GitHub (oficial)
• Lista de servidores do ecossistema MCP (comunidade/ecossistema)
• Registry MCP da comunidade (comunidade)

Para ecossistemas grandes, vale acompanhar registries e catálogos de vendors:

• Docker MCP Registry (oficial Docker)

• Microsoft MCP Registry (oficial Microsoft)

Skills oficiais de Terraform da HashiCorp

Além do MCP Server, a HashiCorp publicou uma biblioteca aberta de skills: o HashiCorp Agent Skills, disponível no repositório hashicorp/agent-skills.

As skills de Terraform ajudam o agente a:

• gerar código no style guide oficial da HashiCorp, em vez de convenções aleatórias encontradas na internet
• escrever e rodar testes com o framework nativo de testes do Terraform
• orquestrar com Terraform Stacks cenários multi-ambiente e multi-região
• desenvolver e manter providers seguindo o plugin framework (schema, ciclo de vida e breaking changes)
• refatorar módulos, quebrando configurações monolíticas em módulos reutilizáveis

Instalar é rápido. Para todas as skills, via npx:

npx skills add hashicorp/agent-skills

Ou uma skill específica:

npx skills add hashicorp/agent-skills/terraform/code-generation/skills/terraform-style-guide

No Claude Code, dá para instalar como plugin:

claude plugin marketplace add hashicorp/agent-skills
claude plugin install terraform-code-generation@hashicorp

O ganho reforça o tema deste artigo: a skill entrega as boas práticas e o MCP entrega os dados atuais. Juntos, reduzem alucinação e mantêm o código dentro do padrão.

Onde o Docker entra de verdade

Reduzir variação de ambiente. Com Docker, você empacota o servidor MCP de forma reproduzível para:

• notebook local
• ambiente de desenvolvimento
• CI/CD
• máquina de quem entrou no time ontem

Isso corta o clássico "na minha máquina funciona" e ajuda a manter o mesmo comportamento entre ambientes.

Setup mínimo para começar

Primeiro, confirme o Terraform no ambiente:

terraform version

Depois, rode o servidor MCP com Docker (exemplo; ajuste conforme a documentação oficial e versão mais recente):

docker run --rm -it   --name terraform-mcp   -e TF_IN_AUTOMATION=true   -e TF_LOG=INFO   -v "${PWD}:/workspace"   -w /workspace   hashicorp/terraform-mcp-server:1.0.0

Primeira chamada real (hands-on)

Depois de subir o servidor MCP, o fluxo mínimo no cliente costuma ser:

1. listar as tools disponíveis

2. chamar uma tool de discovery (ex.: search_providers)

3. validar estrutura de resposta antes de automatizar

Exemplo de resposta esperada (resumida). Os campos exatos podem variar conforme a tool e o cliente MCP:

{
  "providers": [
    {
      "name": "azurerm",
      "namespace": "hashicorp",
      "latest_version": "x.y.z"
    }
  ]
}

Com isso, você já valida conectividade, autenticação e formato dos dados.

Como instalar e rodar MCP com Node.js (o mínimo necessário)

Se você quiser criar ou testar um MCP sem Docker, normalmente precisa de:

• Node.js LTS (18+ ou 20+)
• npm, pnpm ou yarn
• um cliente MCP (editor, agente, CLI, ou o Inspector)

Exemplo de bootstrap rapido com Node:

mkdir meu-mcp-node && cd meu-mcp-node
npm init -y
npm install @modelcontextprotocol/xxxx

Estrutura mínima comum:

• package.json
• server.ts

Exemplo mínimo de servidor (conceitual):

import { Server } from "@modelcontextprotocol/sdk/server/index.js";

const server = new Server(
  { name: "meu-mcp", version: "0.1.0" },
  { capabilities: { tools: {} } }
);

// Registrar tools aqui (status, healthcheck, consultas etc.)

Execução típica em desenvolvimento:

npx tsx server.ts

No cliente MCP, configure esse servidor para rodar via stdio.

• criar um servidor MCP em TypeScript/JavaScript
• expor tools (ex.: consultar status, buscar docs, executar validações)
• rodar por stdio para o cliente consumir

Para testar localmente, muita gente usa o MCP Inspector.

Se a equipe usa Docker em tudo, a abordagem mais estável é empacotar também o MCP Node em container para padronizar runtime.

Troubleshooting rápido

Quando estou com erro, normalmente eu peço ajuda para o agent corrigir mesmo.

Exemplo de configuracao MCP (Terraform MCP Server via Docker/stdio):

"io.github.hashicorp/terraform-mcp-server": {
  "type": "stdio",
  "command": "docker",
  "args": [
    "run",
    "-i",
    "--rm",
    "-e",
    "TFE_ADDRESS",
    "-e",
    "TFE_TOKEN",
    "-e",
    "ENABLE_TF_OPERATIONS",
    "hashicorp/terraform-mcp-server:1.0.0"
  ],
  "env": {
    "TFE_ADDRESS": "${input:TFE_ADDRESS}",
    "TFE_TOKEN": "${input:TFE_TOKEN}",
    "ENABLE_TF_OPERATIONS": "${input:ENABLE_TF_OPERATIONS}"
  },
  "gallery": "https://api.mcp.github.com",
  "version": "1.0.0"
}

Fluxo prático

1. subir o servidor MCP em container

2. conectar o cliente MCP (editor, agente ou automação)

3. validar uma consulta de discovery (provider/módulo)

4. validar uma consulta operacional (workspace/run/plan)

Guardrails que você não deve ignorar

Se o servidor tiver acesso a ambientes reais, trate como componente crítico:

• use credenciais com privilégio mínimo
• evite segredo em variável solta no container
• defina limites claros para operações permitidas
• habilite logs suficientes para auditoria e troubleshooting
• separe bem o que é dev, homolog e prod

MCP acelera muito, mas sem guardrail ele também acelera o caos!

Se quiser aprofundar, estes dois cursos da Anthropic são ótimos pontos de partida:

• Introduction to Model Context Protocol
• Model Context Protocol Advanced Topics

Resumo:

• Terraform continua sendo o motor declarativo
• MCP organiza como ferramentas e agentes consomem contexto atualizado
• Skills carregam as boas práticas que guiam o agente no loop de execução
• Docker entrega repetibilidade para rodar isso sem drama

Se a meta é reduzir erros operacionais e ganhar velocidade com controle, combinar Terraform MCP Server, skills e Docker é um passo bastante útil.

Salve, galera. Quero compartilhar com vocês que recentemente gravei o curso Computação em Nuvem: práticas e governança com Azure na Alura e ele já está no ar.

Caso não seja ainda aluno da Alura, você pode se inscrever com o link: Link amigo

Por que esse curso existe

Há alguns anos, aprender cloud significava assistir horas de vídeo e, no final, criar uma máquina virtual. Hoje isso já não é suficiente.

Quem trabalha com Azure precisa entender arquitetura, segurança, governança, FinOps, Infrastructure as Code, automação e, agora, como utilizar IA para acelerar tudo isso.

A proposta não é criar mais um curso mostrando onde clicar no portal da Azure.

Quis construir um material que aproxima o estudante do que realmente acontece no mercado, com uma abordagem prática e conectada aos desafios de quem atua com infraestrutura e plataforma.

O que o curso cobre

Ao longo de mais de 20 horas de conteúdo, passamos por temas como:

• Fundamentos de Cloud Computing
• Azure na prática
• Arquitetura de soluções em nuvem
• Segurança, identidade e governança
• FinOps e otimização de custos
• Redes e conectividade
• Infrastructure as Code com Terraform
• Como utilizar IA para acelerar o provisionamento de infraestrutura
• CI/CD, automação e boas práticas
• Well-Architected Framework e estratégias de migração

Para quem o curso foi pensado

Esse conteúdo foi pensado para profissionais de infraestrutura, engenheiros de plataforma, arquitetos de soluções, profissionais de DevOps e estudantes de tecnologia que querem aprender práticas aplicáveis em Azure e conceitos multi-cloud para projetar, governar e operar ambientes em nuvem.

• entender modelos de serviço como IaaS, PaaS e SaaS
• projetar arquiteturas resilientes e escaláveis
• orquestrar e versionar infraestrutura com IaC
• gerenciar redes, conectividade e políticas
• aplicar governança, controle de acesso e otimização de custos
• automatizar pipelines e monitorar aplicações com foco em disponibilidade

O que tem de prática

• laboratórios de rede, compute e storage
• App Services, Functions e bancos gerenciados
• governança e permissão com usuários, grupos, políticas e identidade
• IA para engenharia de cloud
• zonas de disponibilidade
• Well-Architected Framework
• estratégias de migração

Foi um projeto enorme, com muito planejamento e muito cuidado para transformar experiência de mercado em aprendizado aplicável.

Se você já é aluno, depois me conta o que achou. Seu feedback ajuda bastante e me dá ainda mais direção para os próximos conteúdos.

Se você quer aprender cloud indo além do básico, tenho certeza que esse curso vai te ajudar BASTANTE.

No dia 20 de junho de 2026, realizamos o Microsoft Build //localhost: Florianópolis em Florianópolis e apresentei uma talk que conectou uma ideia simples com impacto direto no dia a dia: agentes de IA não servem só para escrever código, eles também podem ajudar a investigar, medir e validar software com mais contexto.

O evento reuniu pessoas interessadas em IA, cloud, DevOps e desenvolvimento moderno. A proposta da palestra foi mostrar, na prática, como o GitHub Copilot no VSCode pode atuar como um parceiro de trabalho quando o fluxo exige análise, repetição e rapidez.

Evento organizado por mim e Vinicius Deschamps, representando a comunidade Azure User Groups Brasil, com o objetivo de aproximar a comunidade de cenários reais de uso do GitHub Copilot no dia a dia de quem constrói software.

Agentes bem configurados encurtam esse ciclo sem substituir a habilidade crítica do desenvolvedor. Eles ajudam a chegar mais rápido no ponto certo da investigação.

Na prática, o maior ganho aparece quando o agente ajuda a organizar o problema.

Em vez de abrir dezenas de arquivos sem direção, a conversa pode começar com contexto, hipóteses e sinais observáveis. Isso ajuda a:

• identificar a parte mais provável do bug
• sugerir arquivos e símbolos relacionados
• resumir o comportamento esperado versus o comportamento real

O resultado é menos tempo procurando e mais tempo corrigindo.

Harness com agentes

Um agente pode ajudar a interpretar sinais de uso de CPU, latência, alocação e dependências, principalmente quando o problema está espalhado por mais de uma camada do sistema.

O ponto não é automatizar o diagnóstico inteiro. O ponto é chegar mais rápido nas perguntas certas:

• onde a aplicação passa mais tempo?
• qual etapa está repetindo trabalho desnecessário?
• qual caminho vale instrumentar primeiro?

Testing com agentes

Testes são um dos melhores usos para esse tipo de fluxo. Agentes ajudam a transformar um cenário solto em um conjunto de casos reproduzíveis, o que facilita validar correções e evitar regressões. Isso vale especialmente quando o comportamento envolve dependências, interfaces ou estados difíceis de reproduzir manualmente.

A mensagem principal foi que agentes funcionam melhor quando entram no fluxo certo:

• com contexto
• com objetivo claro
• com validação humana no final

Quando isso acontece, o desenvolvedor ganha velocidade sem perder controle técnico.

Confira os conteúdos que tivemos no evento:

From CLI to PR: Automating the Path to Merged Code

🔹 Vinicius Deschamps

Nesta demonstracao pratica, mostramos como utilizar GitHub Copilot CLI e agentes para automatizar desde o planejamento ate a revisao de Pull Requests, explorando gerenciamento de contexto, automacao e fluxos modernos de desenvolvimento.

GitHub Copilot no Visual Studio: Agents That Debug, Profile and Test

🔹 Rafael Ferreira

Nesta sessão, exploramos como os agentes do GitHub Copilot podem ajudar a investigar problemas, identificar gargalos de performance, analisar infraestrutura como codigo, entender comportamentos complexos de aplicacoes e acelerar troubleshooting em ambientes reais.

Menos tempo procurando a causa do problema.

Mais tempo resolvendo o problema.

From Zero to Deployed on Azure with AI Agents

🔹 Claudio Raposo

Um laboratorio pratico para quem quer colocar a mao na massa. Partindo de um terminal vazio, os participantes construiram e publicaram uma aplicacao no Azure utilizando GitHub Copilot CLI e agentes de IA para provisionamento de recursos, desenvolvimento, debugging e deployment.

Slides

• Build 2026 - GitHub Copilot in VSCode

• LinkedIn Post Divulgação evento

Conecte-se com a comunidade

Se você quiser acompanhar os próximos encontros e participar da comunidade:

• Site oficial
• Linktree
• Grupo no WhatsApp
• YouTube
• LinkedIn
• Meetup

Evento organizado por mim e Vinicius Deschamps, representando a comunidade Azure User Groups Brasil, com o objetivo de aproximar a comunidade de cenários reais de uso do GitHub Copilot no dia a dia de quem constrói software.

A proposta foi reunir desenvolvedores, engenheiros de cloud e pessoas de comunidade para discutir o que muda quando agentes de IA entram no fluxo de trabalho.

Mais do que falar de tendência, queríamos mostrar:

• como agentes ajudam a acelerar investigação, validação e entrega
• como manter critério técnico mesmo usando IA
• como conectar criação, troubleshooting e automação em um fluxo prático

O evento em Florianópolis

O encontro aconteceu em Florianópolis e fez parte da série Microsoft Build //localhost, com uma pegada local e muito próxima da realidade de quem está construindo software em produção.

• Página oficial do evento
• LinkedIn Post Divulgação evento

A programação foi desenhada para conectar IA e prática de engenharia.

Os temas giraram em torno de:

• GitHub Copilot no fluxo de desenvolvimento
• uso de agentes para debugging, profiling e testes
• automação com foco em entrega e governança

Confira os conteúdos que tivemos no evento:

From CLI to PR: Automating the Path to Merged Code

🔹 Vinicius Deschamps

Nesta demonstracao pratica, mostramos como utilizar GitHub Copilot CLI e agentes para automatizar desde o planejamento ate a revisao de Pull Requests, explorando gerenciamento de contexto, automacao e fluxos modernos de desenvolvimento.

GitHub Copilot no Visual Studio: Agents That Debug, Profile and Test

🔹 Rafael Ferreira

Nesta sessão, exploramos como os agentes do GitHub Copilot podem ajudar a investigar problemas, identificar gargalos de performance, analisar infraestrutura como codigo, entender comportamentos complexos de aplicacoes e acelerar troubleshooting em ambientes reais.

Menos tempo procurando a causa do problema.

Mais tempo resolvendo o problema.

From Zero to Deployed on Azure with AI Agents

🔹 Claudio Raposo

Um laboratorio pratico para quem quer colocar a mao na massa. Partindo de um terminal vazio, os participantes construiram e publicaram uma aplicacao no Azure utilizando GitHub Copilot CLI e agentes de IA para provisionamento de recursos, desenvolvimento, debugging e deployment.

Esse tipo de evento só acontece porque existe comunidade por trás.

Se você participou, obrigado pela presença. Se não conseguiu ir, este post fica como registro da organização e do propósito da edição.

Conecte-se com a comunidade

Se você quiser acompanhar os próximos encontros e participar da comunidade:

• Site oficial
• Linktree
• Grupo no WhatsApp
• YouTube
• LinkedIn
• Meetup

Visão Geral

No artigo anterior, eu mostrei a base da construção do blog com Terraform, Azure Static Web Apps e GitHub Actions. Esse texto é o passo seguinte: o que eu evoluí depois que a primeira versão já estava no ar. A ideia aqui não é repetir o conteúdo anterior, é mostrar como a infraestrutura evoluiu depois dessa decisão.

A maior mudança dessa fase foi trazer o meu domínio orafaelferreira.com para dentro do Azure. Ele estava registrado e com o DNS na GoDaddy, e eu migrei a zona para o Azure DNS, assim me possibilitando gerenciar o domínio como código, junto com o resto da infraestrutura.

Com o domínio dentro do Azure, eu passo a:

• Centralização dos recursos no provider Azure
• controlar a zona DNS via Terraform, no mesmo fluxo de IaC do site
• reaproveitar o mesmo domínio em outros projetos e subdomínios
• versionar e auditar cada mudança de registro como faço com qualquer outro recurso

Algumas features:

• Terraform como infraestrutura como código (IaC)
• domínio orafaelferreira.com migrado da GoDaddy para o Azure DNS
• subscriptions separadas para site e DNS
• DNS-as-Code com CNAME, A e TXT gerenciados no próprio Terraform
• azapi para cobrir o que o provider não resolve e manter tudo em IaC

1. Tirando o domínio da GoDaddy

Antes, o orafaelferreira.com vivia inteiro na GoDaddy: registro e DNS no mesmo lugar, tudo editado na mão pelo painel. Funcionava, mas me prendia a cliques e deixava o DNS fora do meu fluxo de IaC.

A migração foi direta: criei a zona no Azure DNS, recriei os registros que já existiam e apontei os name servers do domínio na GoDaddy para os name servers do Azure. A partir daí, a autoridade do DNS passou a ser o Azure.

Isso me abre espaço para reusar o orafaelferreira.com em outros laboratórios e projetos sem repetir configuração manual.

2. Duas subscriptions

Aqui vou mostrar como trabalhar com duas subscriptions usando aliases de provider no Terraform. Em vez de depender de um único contexto, eu passo a indicar explicitamente onde cada recurso vive. Coisas que acontecem no dia a dia real, com ambientes de produção, que decidi espelhar e colocar em prática aqui.

provider "azurerm" {
  features {}
}

provider "azurerm" {
  alias           = "site"
  features        {}
  subscription_id = var.site_subscription_id != "" ? var.site_subscription_id : null
}

provider "azurerm" {
  alias           = "dns"
  features        {}
  subscription_id = var.dns_subscription_id != "" ? var.dns_subscription_id : null
}

provider "azapi" {
  alias           = "dns"
  subscription_id = var.dns_subscription_id != "" ? var.dns_subscription_id : null
}

Visualmente, a arquitetura ficou assim:

3. DNS com IAC

Essa foi a parte que mais evoluiu em relação ao artigo anterior. Antes, a ideia era basicamente “subir o SWA e validar o domínio”. Agora o DNS também virou parte do código declarativo.

data "azurerm_dns_zone" "this" {
  provider            = azurerm.dns
  name                = "orafaelferreira.com"
  resource_group_name = data.azurerm_resource_group.dns_rg.name
}

resource "azurerm_dns_cname_record" "www" {
  provider            = azurerm.dns
  name                = "www"
  zone_name           = data.azurerm_dns_zone.this.name
  resource_group_name = data.azurerm_dns_zone.this.resource_group_name
  ttl                 = 3600
  record              = azurerm_static_web_app.this.default_host_name
}

resource "azurerm_static_web_app_custom_domain" "www" {
  provider          = azurerm.site
  static_web_app_id = azurerm_static_web_app.this.id
  domain_name       = "www.orafaelferreira.com"
  validation_type   = "cname-delegation"
}

• o www aponta diretamente para o host do SWA
• a validação passa a refletir o estado real do DNS

O que é Apex?

O apex (ou naked domain) é o domínio raiz, sem nenhum prefixo. No caso do meu site, "orafaelferreira.com" é o apex, enquanto "www.orafaelferreira.com" é um subdomínio. O apex é importante porque é a forma "limpa" e mais comum de acessar um site: quando alguém digita só "orafaelferreira.com", está acessando o apex.

O apex também ganhou tratamento próprio. Em vez de esconder isso atrás de configuração manual, eu explicitei o caminho do registro A e a validação por TXT.

locals {
  apex_txt_values = distinct(concat(
    var.apex_base_txt_records,
    [azurerm_static_web_app_custom_domain.apex.validation_token]
  ))
}

resource "azurerm_dns_a_record" "apex" {
  provider            = azurerm.dns
  name                = "@"
  zone_name           = data.azurerm_dns_zone.this.name
  resource_group_name = data.azurerm_dns_zone.this.resource_group_name
  ttl                 = 3600
  target_resource_id  = azurerm_static_web_app.this.id
}

O detalhe importante está no distinct(concat(...)). Ele preserva os TXT base do domínio, como SPF, e adiciona o token de validação do Azure sem sobrescrever o que já existe.

Esse tipo de cuidado evita uma classe de erro chata: mudar o domínio para validar o SWA e quebrar outros usos do TXT sem perceber.

4. Por que usei azapi

Nem tudo o que eu precisava encaixou bem no provider padrão do AzureRM. No caso do TXT do apex, eu usei azapi para garantir o controle do record set.

resource "azapi_resource" "apex_validation_txt" {
  provider  = azapi.dns
  type      = "Microsoft.Network/dnsZones/TXT@2018-05-01"
  name      = "@"
  parent_id = data.azurerm_dns_zone.this.id

  body = {
    properties = {
      TTL = 3600
      TXTRecords = [for value in local.apex_txt_values : {
        value = [value]
      }]
    }
  }
}

Esse é um bom exemplo de onde o Terraform brilha: você não precisa forçar a solução para caber numa única ferramenta. Usa a melhor peça disponível para cada responsabilidade.

5. O site continua simples, mas a operação ficou melhor

Mesmo com essa evolução, eu não quis transformar o blog numa plataforma altamente complexa.

O SWA continua sendo a base do hosting, e isso me ajuda porque ele entrega o suficiente sem exigir engenharia excessiva para um site pessoal.

6. Quando esse nível de estrutura faz sentido

Nem todo projeto precisa começar assim. Se você está montando um site simples e isolado, talvez uma subscription só e um conjunto mínimo de recursos já resolvam. Mas quando o projeto vira laboratório vivo, quando você quer experimentar, evoluir e manter tudo auditável, esse tipo de arquitetura começa a fazer sentido.

No meu caso, o blog é também um espaço para testar ideias que depois podem virar conteúdo, palestra ou prática de trabalho. Então vale a pena investir tempo e esforço nessa base.

Conclusão

Tirar o orafaelferreira.com da GoDaddy e trazer o domínio para o Azure foi o que destravou tudo: o DNS deixou de ser um painel manual e isolado e passou a fazer parte do mesmo código que descreve o site para criar os registros DNS. Com isso, a infraestrutura saiu de uma migração funcional para um desenho em que o site e o domínio ficam melhor organizados. De quebra, o domínio fica pronto para ser reaproveitado em outros projetos, sempre via IaC. Isso me ajuda no meu vibe coding, compartilhando o troubleshooting com a IA.

Visão geral do Build 2026

O Microsoft Build é a conferência anual da Microsoft voltada para desenvolvedores, onde a empresa apresenta os principais lançamentos e atualizações da sua plataforma, de Azure e ferramentas de desenvolvimento a IA, dados e segurança.

Azure Cobalt 200

O early access preview do Azure Cobalt 200 traz a segunda geração de VMs Arm-based da Microsoft, desenhada do zero para workloads cloud-native, escaláveis e baseadas em Linux, com foco explícito em agentic AI.

• até 50% mais performance de CPU por geração sobre o Cobalt 100
• até 128 vCPUs por VM, com 3 MB de cache L2 por core e 192 MB de cache L3 no nível de sistema
• criptografia de memória habilitada por padrão, com impacto de performance desprezível
• ganhos reais expressivos: até 135% em banco de dados, 80% em caching e 45% em criptografia de comunicação

Segurança para código, agentes e modelos

Com agentes assumindo decisões antes feitas por código determinístico, a segurança muda de figura. A Microsoft trouxe anúncios focados em proteger código, agentes e modelos ao longo de todo o ciclo de desenvolvimento.

• auditabilidade das atividades dos agentes e RBAC para controlar acesso
• circuit breakers e guardrails independentes do próprio agente
• detecção de comportamento anômalo com possibilidade de intervenção humana a qualquer momento

Microsoft Marketplace para apps e agentes

O Microsoft Marketplace ganhou destaque como canal para construir, escalar e monetizar aplicações e agentes.

• caminho unificado para publicar e distribuir apps e agentes
• foco em ajudar desenvolvedores e ISVs a alcançar clientes e gerar receita

Azure HorizonDB

O Azure HorizonDB (preview) é um serviço de banco totalmente gerenciado, cloud-native e construído sobre PostgreSQL, pensado para workloads tier-1 e aplicações de IA.

• arquitetura de compute e storage desacoplados com design de database-as-a-log para performance previsível e alta disponibilidade
• compatibilidade total com PostgreSQL, drivers, ORMs e SQL existentes migram com pouca ou nenhuma mudança de código
• dois endpoints: um de leitura/escrita (primário) e um reader que faz load-balance entre réplicas HA (hoje até 4, com plano de chegar a 8)
• pronto para IA: vector search, embeddings, hybrid search, reranking semântico e pipelines de IA, servindo como camada de memória e recuperação de conhecimento para agentes

Azure Linux 4.0

O Azure Linux 4.0 (public preview) é a distribuição Linux open-source mantida pela própria Microsoft, construída para Azure, com footprint pequeno e postura de segurança endurecida.

• base no ecossistema Fedora, com a familiaridade dos pacotes RPM
• kernel 6.18 LTS otimizado para Azure, com drivers Hyper-V e tuning específico
• segurança forte: kernel lockdown, dm-verity para boot verificado, SELinux e FIPS 140-3
• pipeline de CVE com scan duas vezes por dia contra a NVD; ainda não indicado para produção

Azure Container Linux (ACL)

O Azure Container Linux (ACL) é um sistema operacional imutável e container-optimized para node pools do AKS, derivado do projeto Flatcar Container Linux e já em GA a partir do AKS 1.34.

• diretório /usr read-only protegido por dm-verity, validando hash assinado em boot e runtime
• superfície de ataque mínima e atualizações automáticas semanais baseadas em imagem
• SELinux em enforcing por padrão e Trusted Launch com Secure Boot e vTPM obrigatórios
• criação direta com az aks create --os-sku AzureContainerLinux; atenção às limitações (sem Pod Sandboxing, Artifact Streaming e Confidential VMs)

Novidades do AKS

O AKS recebeu um conjunto de anúncios no Build 2026 que ampliam o controle em toda a stack, da operação do cluster até treino e inferência de IA rodando em cima dele.

• Managed system node pools no AKS Automatic (GA): o Azure passa a cuidar do ciclo de vida dos nós de sistema (capacidade, patching, escala), evitando que os componentes do cluster disputem recursos com suas cargas, importante sobretudo em nós com GPU
• AKS on bare metal (preview): roda o AKS em máquinas dedicadas sem hypervisor, com acesso direto a NVLink, RDMA e rede de alta performance, ideal para treino grande, inferência sensível a latência e pipelines de alto throughput
• Fleet Manager para clusters Arc-enabled (GA): aplica updates, políticas e posicionamento de cargas em clusters dentro e fora do Azure a partir de um único control plane, com rollout progressivo e RBAC consistente
• Anyscale on Azure (preview): traz o Ray gerenciado ao AKS para coordenar execução distribuída (GPUs e CPUs juntas, alocação fracionada de GPU), rodando dentro da sua subscription com Entra ID
• AI Runway + KAITO para servir modelos de forma Kubernetes-native: você escolhe o modelo, valida o ajuste à memória de GPU disponível e faz o deploy; o KAITO provisiona nós e sobe runtimes otimizados como vLLM

Gestão de file shares mais simples e escalável (GA)

O Azure Files ganhou um novo modelo de gerenciamento para file shares premium SSD (NFS), agora em disponibilidade geral, em que cada share é criado, protegido, escalado e cobrado de forma independente, sem ficar amarrado à storage account.

• Cada share é um recurso próprio, com performance, segurança e billing isolados (modelo provisioned v2), alinhando os limites aos limites reais da aplicação ou do tenant
• Escala maior e provisionamento mais rápido: até 10.000 file shares por subscription por região e time-to-first-share 2,5x mais rápido que os shares clássicos
• Isolamento por share: restrições de rede, RBAC, política, snapshots e criptografia em trânsito definidos individualmente, ideal para cenários multi-tenant de SaaS
• Infraestrutura como código e visibilidade de custo: define naming, capacidade, IOPS, rede e tags em Bicep/ARM, com meters de billing por share para chargeback preciso

Outros destaques

Project Solara

• Plataforma chip-to-cloud (codinome) criada do zero para experiências agent-first e para uma nova geração de dispositivos moldados ao redor de agentes, não de apps
• Aposta em just-in-time UI: a interface do agente se adapta a diferentes telas e modalidades (voz, visão, toque) sem o desenvolvedor redesenhar para cada formato
• Nasce enterprise-ready, com identidade (Entra ID), gestão (Intune), segurança e privacidade como fundação, além de ser extensível para você trazer seus próprios agentes
• Primeiros conceitos de hardware incluem um dispositivo de crachá (portátil) e um dispositivo de mesa, com silício de MediaTek e Qualcomm

Microsoft Scout

• Agente pessoal always-on, pensado para acompanhar o usuário de forma contínua
• Conecta-se ao Microsoft 365 para agir sobre contexto real de trabalho, não só responder perguntas isoladas

Modernização agentic

• GitHub Copilot modernization agent chega à disponibilidade geral: operado pela CLI, atua como orquestrador que avalia prontidão de várias aplicações ao mesmo tempo, planeja jornadas específicas e automatiza upgrades de Java e .NET
• Integra-se ao fluxo nativo do GitHub criando issues, pull requests e relatórios de avaliação por aplicação, com coordenação assíncrona via coding agent e trilha de auditoria no Agent HQ
• Faz par com o Azure Copilot migration agent (preview), que cobre o planejamento em escala de estate, descoberta, mapeamento de dependências, análise de ROI e wave planning, reduzindo meses de análise a minutos
• Custom skills (GA): o time codifica padrões, bibliotecas e boas práticas em arquivos skill.md (formato aberto) e reaproveita em todo o portfólio
• Resultado relatado pela Microsoft: modernização até 4x mais rápida em centenas de milhares de apps legados .NET e Java

Microsoft Web IQ

• Inteligência de busca para a web, trazendo dados e contexto atualizados para aplicações e agentes
• Pensado para alimentar experiências de IA com informação fresca da web em vez de conhecimento estático

Azure Functions no Build 2026

No serverless, a mensagem reforça uma direção clara: o Flex Consumption é onde as novidades chegam primeiro.

• cold starts menores com instâncias always-ready e integração com rede virtual
• per-function scaling e scale-out de até 1.000 instâncias (contra 200 do Consumption)
• mounts de Azure Files para binários grandes e modelos de ML sem empacotar no deploy

Demos do Build 2026

Para ver na prática, seguem demos selecionadas do canal Microsoft Developer, todas gravadas no Build 2026. Cada uma é curta e vai direto ao ponto:

OpenClaw + Windows

• Mostra o OpenClaw rodando em conjunto com o Windows, no contexto da plataforma de desenvolvimento
• Boa amostra de como ferramentas de agente se integram ao ambiente nativo do sistema
• Teve a participação especial do fundador da Open Cloud, comentando um pouco de como ele está animado com o que está por vir

Developer Experience on Windows

• Um tour pela experiência de desenvolvimento no Windows, alinhada aos anúncios de ferramentas para devs (Coreutils, WSL, configurações otimizadas)
• Útil para quem quer entender o caminho que a Microsoft está traçando para o fluxo de trabalho no Windows

GitHub App + Rayfin

• Integração de um GitHub App com o Rayfin, ilustrando fluxos de automação e produtividade
• Mostra na prática como conectar repositórios a automações de ponta a ponta

Microsoft Discovery

• Demonstração do Microsoft Discovery aplicado a cenários de pesquisa e descoberta acelerada por IA
• Dá uma ideia de como a IA encurta o tempo entre uma pergunta e uma resposta acionável

MDASH

• MDASH é o codinome do sistema de varredura de segurança agêntica multimodelo da Microsoft Security, criado pela equipe de Segurança de Código Autônomo
• Diferente de abordagens de modelo único, orquestra mais de 100 agentes de IA especializados (modelos de fronteira e destilados) para descobrir, debater e comprovar bugs exploráveis de ponta a ponta
• Na prática, ajudou a encontrar 16 novas vulnerabilidades na pilha de redes e autenticação do Windows, incluindo 4 falhas críticas de execução remota de código

Resumo brabo do que vem por ai: tudo aponta para agentes

Este artigo faz parte da série sobre Docker e containers, agora com foco em Azure Container Registry (ACR) Artifact Cache.

Se você trabalha com AKS, App Service, Functions, Container Apps ou pipelines de CI/CD, provavelmente já enfrentou pelo menos um destes problemas:

• limite de pull em registries públicos
• latência e instabilidade para baixar imagens em horário de pico
• dependência direta de registry externo em ambiente de produção
• excesso de credenciais espalhadas para autenticação entre registries

O Artifact Cache do ACR resolve esse conjunto com uma abordagem de pull-through cache: você continua puxando imagem com o nome do seu ACR, e a plataforma busca e armazena o conteúdo do upstream no primeiro pull.

Onde a Docker entra diretamente neste desenho

Mesmo sendo um recurso do ACR, a operação do dia a dia passa por componentes do ecossistema Docker:

• Docker Engine no host de build ou no workstation
• Docker CLI para validar e executar comandos como pull, tags e comportamento do cache
• Docker Hub como upstream comum para imagens base e imagens de runtime
• Formato OCI de imagens — o mais comum no ecossistema Docker e runtimes cloud-native, mas não o único.

Na prática, boa parte do valor aparece quando você tira dependência direta de pull no Docker Hub em momentos de pico e passa a concentrar distribuição via ACR com cache local.

O que é Artifact Cache, na prática

Pense no Artifact Cache como uma camada de distribuição local para imagens:

1. Seu runtime (AKS, por exemplo) faz pull em meuacr.azurecr.io/time/api:1.0.0.

2. Se a imagem ainda não estiver no cache, o ACR busca no upstream definido na regra.

3. O cliente recebe a imagem e, em paralelo, o ACR persiste o conteúdo de forma assíncrona.

4. Nos próximos pulls, a entrega sai do próprio ACR.

Esse comportamento reduz dependência de internet no caminho crítico, melhora previsibilidade de pull e permite aplicar controle de rede/segurança dentro do seu perímetro Azure.

Quando esse recurso brilha

1. Escala em cluster

Quando muitos nós sobem ao mesmo tempo (rolling update, autoscale, node replacement), o cache reduz pressão no upstream e no egress externo.

2. Promoção de imagens entre ambientes

Você pode manter repositórios separados por ambiente (dev, staging e prod) e usar o cache para padronizar o consumo de imagens no destino.

3. Ambientes restritos por rede

Com Private Link bem configurado, você evita expor pipeline e runtime diretamente ao registry externo.

Upstreams suportados (resumo)

O que é um upstream?

No contexto do Artifact Cache, upstream é o registry de origem de onde o ACR vai buscar a imagem quando ela não estiver em cache. É o registry "de fora", pode ser Docker Hub, GHCR, Quay ou até outro ACR.

Quando você configura uma cache rule, você define:

• source-repo: o caminho no upstream (ex.: docker.io/library/nginx)
• target-repo: o caminho dentro do seu ACR onde o conteúdo ficará espelhado (ex.: mirror/library/nginx)

Na prática, o upstream só é acessado no primeiro pull de uma tag. Depois, o ACR serve o conteúdo localmente. Se o upstream ficar indisponível, imagens já em cache continuam acessíveis, esse é o ganho de resiliência do padrão.

De acordo com a documentação oficial, o Artifact Cache suporta vários registries upstream, com diferenças de autenticação por fonte. Alguns exemplos:

• Docker Hub (somente autenticado)
• Azure Container Registry (somente autenticado)
• GHCR (autenticado e não autenticado)
• Quay (autenticado e não autenticado)
• registry.k8s.io (CLI)
• Microsoft Artifact Registry (não autenticado)

Exemplo com Docker Hub como upstream

Um padrão comum é cachear imagens oficiais usadas como base de aplicações:

az acr cache create \
  --registry "acrpocprod" \
  --name "dockerhub-nginx" \
  --source-repo "docker.io/library/nginx" \
  --target-repo "mirror/library/nginx" \
  --cred-set "DockerHubCredSet"

Depois, em vez de puxar direto do Docker Hub, seu ambiente passa a consumir:

docker pull acrpocprod.azurecr.io/mirror/library/nginx:stable

Limites e comportamento que você precisa saber

Esses pontos costumam gerar dúvida em troubleshooting:

1. O cache não é prefetch automático de novas tags. A tag só entra quando alguém puxa.

2. Limite de até 1.000 cache rules por registry.

3. Regras não podem sobrepor namespace/caminho.

4. O primeiro pull pode sofrer latência maior; os seguintes tendem a ser mais estáveis.

5. Em cenários com upstream privado, o upstream exige autenticação.

Matriz de decisão rápida

Troubleshooting objetivo

Erro de autorização no cache rule

• Confirme se a identidade foi anexada ao ACR downstream.
• Confirme o role assignment no upstream com escopo correto.
• Verifique se a autenticação configurada na cache rule está correta.

Primeiro pull funciona, mas desempenho não melhora

• Lembre que a cópia é assíncrona.
• Aguarde alguns instantes e repita pull para validar efeito de cache.
• Confira eventos/logs e permissão de leitura no upstream.

Regra não cria por conflito

• Regras de cache não podem se sobrepor.
• Revise namespace de target-repo e caminhos de source-repo.

Ambientes com rede restrita

• Verifique regras de firewall/private endpoint do upstream.
• Quando aplicável, habilite Trusted Services no source.

Boas práticas para ambiente real

1. Padronize naming de cache rule por domínio/time/produto.

2. Separe namespace de cache por ambiente (ex.: promoted/, quarantine/).

3. Use tags imutáveis para promoção crítica (ou controle rigoroso de retag).

4. Evite escopo amplo de permissão quando ABAC estiver habilitado.

5. Adicione validação em pipeline para garantir que a regra de cache existe antes do deploy.

6. Monitore latência de pull e falhas de autenticação como indicadores de saúde.

Exemplo de fluxo de promoção com governança

1. Build publica imagem em devregistry.azurecr.io/team-a/api:1.4.0.

2. Pipeline de qualidade executa scan e testes.

3. Aprovado, o pipeline dispara pull no destino:

docker pull prodregistry.azurecr.io/promoted/team-a/api:1.4.0

4. Esse pull alimenta o cache no prod.

5. Clusters de produção consomem do ACR de produção.

Esse padrão simplifica governança e reduz scripts customizados de import, sem abrir mão de rastreabilidade.

Boas práticas

1. Mantenha imagens base oficiais e versionadas (evite depender sempre de latest).

2. Use tags imutáveis para promover release entre ambientes.

3. Reduza pulls diretos em registry público durante janela crítica de deploy.

4. Centralize auditoria de consumo de imagem no registry corporativo.

Conclusão

O Azure Container Registry Artifact Cache não é apenas um recurso de conveniência. Em plataformas com muitos deploys e múltiplos ambientes, ele vira uma camada de resiliência operacional.

Combinando:

• pull-through cache
• identidade gerenciada
• RBAC/ABAC bem definido
• segmentação de namespace por ambiente

Você constrói uma estratégia mais segura, previsível e escalável para distribuição de imagens.

Para quem já está nessa pegada de Docker + Kubernetes + Azure, o Artifact Cache é um passo natural para maturidade de supply chain de containers.

Referências

• Microsoft Learn: Optimize image pulls with artifact cache in Azure Container Registry
• Azure CLI: az acr cache
• Docker Docs: Docker Hub usage and limits
• Docker Docs: docker pull reference

No dia 16 de maio de 2026, rolou o Code Island Ctrl Z na UniCesusc, em Florianópolis/SC – um evento presencial focado em cases reais, erros honestos e aprendizados práticos de quem já "derrubou produção" e sobreviveu para contar a história.

Sobre o evento

O Ctrl Z nasceu para mostrar que todo mundo erra – até quem está no palco. Foram 14 palestrantes, 150 vagas, 8 horas de conteúdo e muita troca sobre DEV, DATA, DEVOPS e CLOUD.

Meu case: O Dia em que Derrubei Produção em Plena Sexta-Feira e o log tava com meu nome

> Sim, eu derrubei a produção. E sim, meu nome estava no log.

O ambiente era crítico, o impacto foi imediato e o culpado tinha nome e sobrenome gravados no log do sistema. Mas o mais importante não foi o erro técnico – foi o que veio depois:

• Como manter a calma quando o negócio está perdendo dinheiro?
• Como comunicar o problema sem perder a confiança do time?
• O que fazer para o erro não se repetir?

Aprendizados que compartilhei

• Todo mundo vai errar – o que diferencia é como você reage
• Transparência e comunicação são mais importantes que buscar culpados
• Ter processo de rollback e monitoramento salva seu emprego
• Cultura de blameless postmortem: aprender, não punir

Local e estrutura

O UniCesusc fica na SC-401, fácil acesso de carro, Uber, ônibus. Estacionamento disponível, acessibilidade garantida, e toda a estrutura para receber a galera tech de Floripa e região.

Links e materiais

• Slides da Apresentação
• Post divulgação do evento

Quer participar dos próximos?

Fique ligado nas redes da Code Island e acompanhe os próximos eventos!

No dia 18 de abril de 2026, aconteceu o Global Azure User Group Floripa 2026 no Colégio Alpha, em São José/SC, com temas sobre Azure, carreira internacional, segurança, arquitetura cloud native e DevOps.

O evento reuniu profissionais, estudantes e entusiastas para discutir tendências e casos práticos sobre Microsoft Azure, IA e DevOps.

Se você perdeu essa edição, este post reúne o panorama oficial do evento, com agenda, palestras e registros dos palestrantes.

Organizadores

• Rafael Martin Alves Ferreira
• Vinicius Deschamps

Sobre o evento

• Nome: Global Azure Floripa 2026
• Cidade: São José
• Local: Colégio Alpha
• Endereço: Rua Vereador Walter Borges, 424, São José - SC

Sobre o Global Azure

O Global Azure é uma iniciativa mundial em que comunidades locais realizam eventos para compartilhar conhecimento sobre Microsoft Azure e acelerar a evolução técnica de quem está na linha de frente.

Agenda oficial

Manhã

• 09:00 - 10:00

Arquitetura Celular na Era Cloud Native: Estratégias Modernas com Microsoft Azure

Palestrante: Claudio Raposo

• 10:00 - 11:00

Azure Virtual Desktop: como acelerar seu negócio em minutos

Palestrante: Leonardo Souza

• 11:00 - 12:00

Carreira internacional: como ganhar XP e se dar bem nas fases do jogo

Palestrante: Lore Locks Coelho

Almoço

• 12:00 - 13:30

Almoço

Tarde

• 13:30 - 14:30

Reactive DDD na prática: Modelagem event-first e integração reativa em alta escala

Palestrante: Antonio Falcao Jr

• 14:30 - 15:30

Segurança sem gambiarra: usando HSM para proteger o que realmente importa

Palestrante: Vinicius Deschamps

• 15:30 - 16:30

Vibe Coding com DevOps: usei IA pra criar meu site no Azure, mas quem fez o deploy fui EU

Palestrante: Rafael Ferreira

Comunidade presente

Links oficiais

• Agenda e detalhes no Sessionize

Apoio local

Esta edição contou com apoio da Alpha Educação.

Conecte-se com a comunidade

Se você quiser acompanhar os próximos encontros e participar da comunidade:

• Site oficial
• Linktree
• Grupo no WhatsApp
• YouTube
• LinkedIn
• Meetup

Obrigado a todos que participaram presencialmente e ajudaram a fortalecer o ecossistema cloud em Santa Catarina e no Brasil.

No dia 18 de abril de 2026, aconteceu o Global Azure User Group Floripa 2026 no Colégio Alpha, em São José/SC, com temas sobre Azure, carreira internacional, segurança, arquitetura cloud native e DevOps.

Evento organizado por mim e Vinicius Deschamps, representando a comunidade Azure User Groups Brasil.

Sobre o Global Azure

O Global Azure é uma iniciativa mundial em que comunidades locais realizam eventos para compartilhar conhecimento sobre Microsoft Azure e acelerar a evolução técnica de quem está na linha de frente.

Agenda oficial

Manhã

Almoço

Tarde

Minha palestra

Nessa edição, apresentei a sessão sozinho, trazendo um case prático sobre como usar IA para acelerar desenvolvimento sem abrir mão de engenharia.

Tema da sessão:

Abordei principalmente:

• como usar IA para aumentar produtividade sem terceirizar pensamento técnico
• limites de código gerado sem processo de qualidade
• papel de CI/CD, validações e ownership técnico no deploy
• porque "entregar" não é só subir código, e garantir confiabilidade

Comunidade Azure User Groups Brasil

Se você quiser participar da comunidade:

• WhatsApp
• YouTube
• LinkedIn

Conteúdos da sessão

Os slides da minha sessão estão disponíveis:

• Slides da Apresentação

• Repositório do Site

Vamos explorar estratégias multi-stage build com imagens de contêiner distroless para workloads Python no Kubernetes, criando soluções da vida real.

O que é distroless

Imagens distroless contêm apenas o runtime da linguagem e suas dependências mínimas. Não incluem:

• Shell (bash, sh): não é possível abrir um terminal no container para debug
• Package managers (apt, yum, pip)
• Utilitários do sistema (curl, wget, vi, ls, cat)
• Usuário root (na variante -nonroot, roda como UID 65534). ALTO RISCO DE SEGURANÇA.

Exemplo de família de imagens distroless (valores anonimizados para referência arquitetural):

mcr.microsoft.com/azurelinux/distroless/python:3.12          # root
mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot  # non-root (recomendado)
mcr.microsoft.com/azurelinux/distroless/debug/python:3.12    # com shell (debug only)

Criei uma solução e botei para rodar no Kubernetes, um script básico em Python para consumir uma API REST e disparar notificações, rodando menos de 5 segundos, uma vez por dia.

Durante a jornada, fiz um benchmark de imagens base para comparar seus tamanho, segurança e operação. A implementação final do workload foi feita com mcr.microsoft.com/azurelinux/base/python:3.12 no estágio de build e mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot no runtime.

Comparação das imagens consultadas

O "problema"

Mesmo imagens otimizadas para runtime geral ainda podem incluir componentes que não são necessários para workloads curtos, por exemplo Jobs/CronJobs:

• Shell (bash, sh)
• Package manager (apt, dpkg)
• Utilitários como curl, wget e find
• Usuário root por padrão

Obviamente quando estamos criando, precisamos de certas ferramentas para desenvolvimento e depuração. Finalizado o desenvolvimento e testes, podemos e devemos enxugar a imagem. Para um container que executa um script e termina, nada disso é necessário. Cada binário extra também amplia a superfície de possíveis ataques.

A engenharia entrando em ação: multi-stage build + distroless

A estratégia de separar build e runtime em dois estágios:

# Stage 1: Build - instala dependências
FROM mcr.microsoft.com/azurelinux/base/python:3.12 AS build

WORKDIR /aplicativos
COPY requirements-ex.txt .
RUN pip install --no-cache-dir --target=/aplicativos/deps -r requirements-ex.txt

# Stage 2: Runtime - distroless (sem shell, sem package manager, non-root)
FROM mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot

WORKDIR /aplicativos
COPY --from=build /aplicativos/deps /aplicativos/deps
COPY worker_alertas.py .

ENV PYTHONPATH=/aplicativos/deps
ENTRYPOINT ["python3", "exemplo.py"]

O --target=/aplicativos/deps instala dependências em um diretório isolado, que é copiado para o segundo estágio. O PYTHONPATH aponta para esse diretório.

Pontos de atenção na hora de desenvolver uma solução distroless do zero!

1. Logs

Falando de código e testes, sem stream=sys.stdout no logging.basicConfig(), os logs iam para stderr e, em alguns cenários de CronJob, não apareciam no kubectl logs:

# Logs podem não aparecer
logging.basicConfig(level=logging.INFO)

# Garante stdout
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
    stream=sys.stdout,
)

2. Erros em variáveis de ambiente

Sem shell e sem processo de init, se uma variável estivesse faltando, o container podia falhar rápido demais e dificultar a observabilidade:

REQUIRED_ENV_VARS = ["API_URL", "API_KEY", "RECIPIENTS"]

def load_config() -> dict:
    missing = [v for v in REQUIRED_ENV_VARS if v not in os.environ]
    if missing:
        logger.error("Missing env vars: %s", ", ".join(missing))
        sys.exit(1)
    # ...

3. Debug sem shell

Com distroless, kubectl exec -it -- /bin/sh não funciona. Para troubleshooting, a estratégia é trocar temporariamente para a imagem de debug:

# Temporário: apenas para troubleshooting
FROM mcr.microsoft.com/azurelinux/distroless/debug/python:3.12

Isso adiciona ~15-20MB, mas habilita shell busybox. Depois do diagnóstico, o ideal é voltar para a variante -nonroot.

4. ENTRYPOINT, não CMD

Em imagens distroless sem shell, o formato exec é obrigatório:

# Shell form: exige /bin/sh (que não existe)
# CMD python3 exemplo.py

# Exec form: obrigatório para distroless
ENTRYPOINT ["python3", "exemplo.py"]

Na implementação final deste workload:

• Build stage: mcr.microsoft.com/azurelinux/base/python:3.12
• Runtime stage: mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot

Essa combinação manteve o workload simples para instalação de dependências no build e conseguimos entregar um runtime enxuto, sem shell e sem package manager em produção.

Benefícios de segurança

1. Sem shell: reduz execução arbitrária de comandos

2. Sem package manager: impede instalação de ferramentas de exploração em runtime

3. Non-root: UID 65534, reduzindo risco de escalonamento trivial

4. Superfície mínima: tende a reduzir CVEs reportadas por scanners (como Trivy)

5. Imutabilidade operacional: menos formas de alterar o container em execução

Quando usar (e quando não usar)

Use distroless quando

• Scripts/workers que rodam e terminam (CronJobs, Functions)
• Microsserviços que não exigem debug interativo frequente
• Workloads de produção onde segurança é prioridade

Evite distroless quando

• O ciclo de desenvolvimento depende fortemente de debug interativo
• A aplicação depende de binários de sistema (ffmpeg, imagemagick etc.)
• O time ainda não está pronto para um workflow de troubleshooting sem shell

Template para CronJobs Python

# Stage 1: Build

FROM mcr.microsoft.com/azurelinux/base/python:3.12 AS build
WORKDIR /aplicativos
COPY requirements-ex.txt .
RUN pip install --no-cache-dir --target=/aplicativos/deps -r requirements-ex.txt

# Stage 2: Runtime (distroless)
# Para debug temporário, troque por:
# FROM mcr.microsoft.com/azurelinux/distroless/debug/python:3.12

FROM mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot
WORKDIR /aplicativos
COPY --from=build /aplicativos/deps /aplicativos/deps
COPY exemplo.py .
ENV PYTHONPATH=/aplicativos/deps
ENTRYPOINT ["python3", "exemplo.py"]

E no Python, comece com:

import logging
import sys

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
    stream=sys.stdout,
)

A adoção de distroless non-root removeu shell, package manager e root do runtime. Os principais desafios encontrados foram logs em stdout, validação de variáveis e troubleshooting sem shell, que são contornáveis com práticas simples.

Para workloads Python executados como Jobs no Kubernetes, distroless é uma escolha sólida.

No dia 11 de abril de 2026, participei como palestrante no SQL Saturday Joinville 2026, realizado na Univille, em Joinville/SC, organizado pela comunidade Comunidado

O SQL Saturday é um dos eventos mais tradicionais da comunidade de dados, reunindo profissionais de SQL Server, Azure, analytics e Inteligência Artificial para compartilhar experiências reais de mercado.

Cronograma do evento

Centro de Convenções

Auditório da Reitoria

Anfiteatro I

Anfiteatro II

Minha palestra

Apresentei novamente com a Jéssica Mello a sessão:

A ideia foi mostrar como acelerar construção com IA sem abrir mão de fundamentos de engenharia, pipeline, governança e ownership técnico no deploy.

Falamos sobre:

• produtividade com IA aplicada ao desenvolvimento
• limites e riscos de gerar código sem processo
• importância de CI/CD e validações automáticas
• responsabilidade técnica no momento de publicar em produção

Participar do SQL Saturday Joinville 2026 como palestrante foi uma experiência excelente. O evento apenas reforça a força da comunidade técnica em Santa Catarina e como dados + IA + cloud estão cada vez mais conectados na prática.

Se você trabalha com dados, engenharia, analytics ou arquitetura em nuvem, esse é o tipo de evento que acelera aprendizado e eleva a qualidade das decisões no trabalho real.

Slides

Os slides estão disponíveis aqui:

• Slides da Apresentação:

Repositórios da apresentação

• Repositório do Site:

[](https://github.com/orafaelferreiraa/orafaelferreira-com)

No dia 08 de abril de 2026, participei como palestrante no Sem Servidor Conf 2026 - Edição Floripa, realizado no Faial Prime Suites, em Florianópolis.

Foi um evento presencial com foco total em cloud, serverless-first e arquitetura moderna, trazendo discussões práticas para o dia a dia de quem toma decisões técnicas.

Grade de palestras

13:00 Credenciamento

14:00 - Abertura - Evandro Pires @ Sem Servidor

14:15 - Durable Functions vs Step functions... quem leva? - Giovana Armani @ AWS

14:55 - O mistério dos pacotes perdidos, MTU quebrando sua Lambda - Jorge Kohn @ Senior Sistemas

15:35 - Integrações com APIs terceiras e serviços AWS - Um jeito simples usando Appsync - Marcelo Andrade @ sls.guru

16:15 - Netbuilding + Coffee - -

17:00 - Serverless além do Tech (Case Buzios Divers) - Filipe Barretto @ Buzios Divers / AWS Hero

17:40 - Platform Engineering: Construindo uma Plataforma Serverless Self-Service - Rafael Ferreira @ Stefanini North América

18:20 - Removendo a tecnologia das suas decisões de tecnologia - Fernando Sapata @ Select / tnkr

19:00 - Encerramento - Evandro Pires @ Sem Servidor

Apresentei a talk Platform Engineering: Construindo uma Plataforma Serverless Self-Service.

A proposta foi mostrar como aplicar conceitos de platform engineering para acelerar entregas padronizadas, com automação e autonomia para os times, sem abrir mão da governança.

Falei sobre desafios de escalar, padronização de ambientes e como transformar boas práticas em produtos internos reutilizáveis.

Um evento com conteúdo aplicável

Rolou palestras técnicas sobre AWS, integrações, arquitetura e tomadas de decisão em tecnologia. O mais legal foi como as palestras se conectaram em torno de um mesmo objetivo: ajudar times a fazer escolhas melhores em cloud.

E o diferencial como sempre, foi o networking durante os intervalos. Reunindo profissionais de diferentes contextos e empresas para trocar experiência de forma direta e sem filtro.

Comunidade

Eventos como o Sem Servidor reforçam como a comunidade técnica no Brasil está madura e cada vez mais orientada a conteúdo prático.

Se você trabalha com cloud e arquitetura moderna, esse tipo de encontro acelera muito o aprendizado e melhora a qualidade das decisões no trabalho real.

Slides

Os slides estão disponíveis aqui:

• Slides da Apresentação:

Repositórios da apresentação

• Platform Stack:

• Pipeline Stack:

• TF Modules Stack:

O Platform Engineering surge como resposta à crescente complexidade das aplicações em nuvem. Criamos plataformas internas que automatizam infraestrutura e governança. A plataforma é tratada como um produto: o desenvolvedor é o cliente interno e deve encontrar o “caminho dourado” (golden path). Uma boa definição de Platform Engineering resume seu propósito: “melhorar a segurança, conformidade, custos e tempo de entrega de valor dos times de desenvolvimento por meio de experiências de desenvolvedor aprimoradas e self-service num ambiente seguro e governado”. Ao padronizar processos e oferecer automações prontas, as plataformas eliminam etapas repetitivas e reduzem drasticamente a carga cognitiva dos desenvolvedores.

Sem essa governança integrada, temos riscos de custos excessivos, falhas de segurança e não-conformidades. Equipes podem criar recursos em regiões caras ou não vigiadas, esquecer tags obrigatórias, expor APIs inadvertidamente etc. O Platform Engineering garante o complience disso criando guardrails automatizados: cada “guardrail” adiciona automaticamente práticas recomendadas. Isso reforça a segurança e compliance de modo invisível e natural ao desenvolvedor, acelerando entregas em vez de bloqueá-las.

O que é Policy-as-Code (PaC)

Quando implementamos PaC, mudamos do modelo "fazer e auditar depois" para "validar antes de implantar". Como destaca a comunidade de engenharia de plataforma, chamada "CAPOC" (Compliance At Point Of Change) – comprimir o ciclo de feedback de dias para segundos. Por exemplo, se um desenvolvedor tentar subir um container vulnerável, um engine de política (OPA ou Kyverno) a rejeita imediatamente, retornando erros legíveis. Assim, equipes de segurança se mantem centralizada, mas sem serem gargalo, cada time segue com autonomia porque políticas automatizadas garantem que só configurações aprovadas irão ver a luz do dia. Além disso, todo evento acaba criando trilhas de auditoria nativas que facilitam evidências de compliance.

Ecossistema de ferramentas de políticas

O universo de PaC é amplo e, em geral, independente da nuvem. Várias ferramentas permitem implementar políticas em diferentes camadas:

OPA (Open Policy Agent)

Kyverno

Conftest

Azure Policy

Hoje minha especialidade é cloud Azure, onde me sinto mais confortável. Recentemente criamos um projeto interno de Policy-as-Code com Terraform: colocamos as policies (arquivos .json) em uma pasta no repositório e o Terraform aplica essas definições automaticamente para toda a organização. Esse fluxo garante consistência, versionamento e a possibilidade de aplicar politicas de forma centralizada e garante governança em escala sem depender de processos manuais.

Um exemplo de Azure Policy

Um exemplo prático de Azure Policy que implementei em ambientes de produção foi: "Azure Backup should be enabled for Virtual Machines" (ID: 013e242c-8828-4970-87b3-ab247555486d) para auditar VMs sem item de backup associado a um Recovery Services Vault. Para passo a passo e opções de remediação (Portal, Azure Policy), veja: Azure Backup para Máquinas Virtuais.

Fluxo DevEx com governança integrada

Para não atrapalhar a experiência do desenvolvedor (DevEx), as verificações de política devem ocorrer em todas as etapas do fluxo:

• IDE/Local: extensões (VSCode, IntelliJ) validam IaC e alertam sobre violações antes do commit (ex.: região proibida, tag ausente).
• CI/CD (pré-merge): um job dedicado (policy-test) roda Conftest/OPA/Azure CLI Policy e barra PRs não conformes com mensagens claras.
• Admission Controllers (Kubernetes): Gatekeeper ou Kyverno negam deploys inválidos (imagem não autorizada, portas indevidas) e podem mutar recursos para corrigir padrões.
• Runtime Cloud: Azure Policy, AWS Config, etc., auditam continuamente; painéis de compliance mostram o status e facilitam remediação rápida.

Boas práticas FinOps

De acordo com a FinOps Foundation, as boas práticas incluem (confira também meu artigo sobre fundação sólida em FinOps):

• Tags obrigatórias: owner, costCenter e environment, que são a base para alocação de custos e responsabilização.
• Controle de SKUs/limites por ambiente: restrinja tipos de VMs e SKUs (evita surpresas em dev/staging).
• Desligamento automático: pare recursos de dev/sandbox fora do horário (Azure Automation/Runbooks/Stop schedules).
• Orçamentos e alertas: defina budgets (ex.: 80% do previsto) e acople alertas ao pipeline; falhe deploys quando limites forem excedidos.
• Visibilidade e análises: exporte custos para Analytics/Power BI; use Azure Cost Management/AWS Cost Explorer para dashboards de FinOps.

Exemplo: uma Azure Landing Zone já vem com tagging obrigatório e orçamentos como parte da fundação.

Estratégia de implantação de políticas

Ao adotar PaC e políticas de governança, faça um rollout gradual e iterativo:

Conclusão

Integrar Policy-as-Code à engenharia de plataforma transforma a governança numa aliada, não num gargalo. Quando as políticas de segurança, compliance e custo são incorporadas no dia a dia de forma automatizada, elas se tornam invisíveis ao usuário – o time só vê as “regras do jogo” funcionando nos bastidores. Como resultado, equipes entregam mais rápido e com menor risco: não há mais um “time do não” bloqueando solicitações, mas sim orientações automáticas que guiam o desenvolvimento.

Referências

• Platform Engineering
• Policy-as-Code
• Martin Fowler – Platform Engineering
• Open Policy Agent
• Kyverno
• Conftest
• Azure Policy Overview
• Azure Cloud Adoption Framework - Landing Zones
• FinOps Foundation
• Azure Policy na prática
• Fundação sólida em FinOps
• Azure Backup para Máquinas Virtuais

Muita gente me pergunta: "como eu pratico?", "como eu estudo pra certificação?", "como eu monto um laboratório de verdade?". A resposta é simples: implementando. Não adianta só assistir vídeo ou ler documentação se você nunca subiu a arquitetura com as próprias mãos.

A arquitetura que vamos implementar é baseada nas referências oficiais do Centro de Arquitetura do Azure, onde a Microsoft publica padrões, práticas recomendadas e arquiteturas de referência para cargas de trabalho reais.

Arquitetura final:

Com serviços de apoio privados:

• Key Vault
• Storage Account
• Azure SQL

O que vamos criar

• Resource Group único para o laboratório
• Domínio público delegado para Azure DNS
• VNet segmentada com subnets dedicadas
• Private DNS Zones para resolução interna de Private Link
• App Service com acesso público desabilitado
• Application Gateway WAF v2 com IP público
• Certificado TLS no Key Vault com Managed Identity
• Validações finais de ponta a ponta

Troque os nomes abaixo para o seu ambiente, mantendo o padrão:

• Resource Group: rg-app-baseline-lab
• Região: Brazil South
• Domínio: seudominio.com.br
• App público: app.seudominio.com.br
• VNet: vnet-app-baseline

ETAPA 1 - Criar Resource Group

Crie o grupo de recursos:

• Nome: rg-app-baseline-lab
• Região: Brazil South (ou outra com suporte a zonas)

Tudo do laboratório fica aqui dentro. O RG serve como uma pasta, onde você organizar seus arquivos. E na Azure, é onde fica o seus recursos, você deletando o RG você deleta tudo que tem dentro.

ETAPA 2 - Utilizar domínio

Compre ou utilize o domínio público (exemplo: seudominio.com.br) no registrador da sua preferência.

ETAPA 3 - Criar zona DNS pública no Azure

No Azure, crie uma DNS Zone pública:

• Nome: seudominio.com.br
• Tipo: Público

Depois de criada:

• Copie os 4 name servers da zona
• No registrador, substitua os DNS atuais pelos name servers do Azure

Quando a delegação propagar, o Azure DNS vira autoridade oficial do domínio e assim poderemos seguir com as alterações tudo dentro de um portal.

ETAPA 4 - Criar VNet e subnets

Crie a VNet:

• Nome: vnet-app-baseline
• Address space: 10.0.0.0/16
• Região: mesma do Resource Group

Crie as subnets:

snet-appGateway       10.0.1.0/24
snet-appService       10.0.0.0/24
snet-privateEndpoints 10.0.2.0/27

Configuração obrigatória:

• Em snet-appService, habilite delegation para Microsoft.Web/serverFarms
• A subnet do Application Gateway deve ser dedicada (não compartilhe com PE, VM ou NIC)

Nota prática importante: GatewaySubnet é reservada para VPN Gateway e ExpressRoute. Para Application Gateway, crie uma subnet dedicada com outro nome, por exemplo SubnetAppGateway, agw-subnet ou snet-appgw. O nome não é obrigatório, mas a exclusividade da subnet é obrigatória.

NSG (Network Security Group) obrigatório na subnet do Application Gateway

Conforme a documentação da Microsoft, a subnet do Application Gateway v2 exige NSG com regras específicas. Sem essas regras, o gateway não funciona.

Crie um NSG e associe a snet-appGateway com as seguintes regras:

A regra GatewayManager nas portas 65200-65535 é obrigatória para o control plane do Application Gateway v2. Sem ela, o backend health não funciona.

DDoS Protection

A Microsoft recomenda habilitar DDoS Protection na VNet que contém a subnet do Application Gateway com IP público. No portal:

• VNet -> DDoS Protection -> Enable

ETAPA 5 - Criar Private DNS Zones

Crie estas zonas privadas:

• privatelink.azurewebsites.net
• privatelink.database.windows.net
• privatelink.vaultcore.azure.net
• privatelink.blob.core.windows.net

Depois, crie o Virtual Network Link de cada zona para vnet-app-baseline.

Sem esse passo, Private Endpoint costuma quebrar por falha de resolução DNS.

ETAPA 6 - Criar Key Vault (privado)

Crie o Key Vault:

• Nome: kv-app-baseline
• Public network access: Disabled
• Authorization model: Azure RBAC

Depois crie o Private Endpoint do Key Vault:

• Subnet: snet-privateEndpoints
• Private DNS Zone: privatelink.vaultcore.azure.net

ETAPA 7 - Criar Storage Account (privado)

Crie a Storage Account:

• Nome único (exemplo): stappbaseline123
• Redundância: ZRS
• Public network access: Disabled

Crie o Private Endpoint para Blob:

• Subresource: blob
• Subnet: snet-privateEndpoints
• Private DNS Zone: privatelink.blob.core.windows.net

ETAPA 8 - Criar Azure SQL (privado)

Ordem recomendada no portal para evitar retrabalho:

1. Criar o SQL Server

2. Criar o SQL Database

3. Criar o Private Endpoint para o SQL

Crie o SQL Server:

• Public network access: Disabled

Crie o banco de dados no servidor criado:

• Camada: General Purpose
• Zone redundancy: habilitado

Depois crie o Private Endpoint do SQL:

• Subnet: snet-privateEndpoints
• Private DNS Zone: privatelink.database.windows.net

ETAPA 9 - Criar App Service Plan

Configuração recomendada para baseline:

• Tier: Premium v3/v4
• Zone redundancy: habilitado
• Instance count inicial: 3

A Microsoft recomenda no mínimo 3 instâncias para o App Service Plan com zone redundancy. Se uma zona falhar, as outras 2 mantêm a disponibilidade sem esperar o startup de novas instâncias.

ETAPA 10 - Criar Web App

Crie o Web App (Node, .NET ou container) usando o plano da etapa anterior.

Depois configure:

• Networking -> VNet Integration -> snet-appService
• Public Network Access -> Disabled
• Health Check -> / (ou endpoint de health da sua app)

O Health Check permite que o App Service detecte instâncias com problema e redirecione tráfego automaticamente para instâncias saudáveis. Requer no mínimo 2 instâncias no plano.

ETAPA 11 - Criar Private Endpoint do Web App

No Web App:

• Networking -> Private Endpoint -> Add
• Subnet: snet-privateEndpoints
• Subresource: sites
• Private DNS Zone: privatelink.azurewebsites.net

Resultado esperado: o App Service fica acessível apenas internamente.

ETAPA 12 - Criar Application Gateway + WAF

Primeiro, crie um Public IP:

• SKU: Standard
• Zone-redundant

Depois crie o Application Gateway:

• SKU: WAF_v2
• Autoscaling: habilitado
• Min instances: 3 (Microsoft recomenda no mínimo 3 para evitar downtime de 6-7 min no startup de nova instância)
• Subnet: snet-appGateway (ou a subnet dedicada definida para o gateway)

Depois de criar o Application Gateway, crie uma WAF Policy:

• Pesquise Web Application Firewall policies -> Create
• Mode: Prevention
• Ruleset: Microsoft Default Rule Set (DRS) 2.1 ou mais recente
• Associe ao Application Gateway criado

Sem a WAF Policy em Prevention, o WAF não bloqueia ataques como SQL injection e XSS.

Configuração inicial (HTTP temporário para validar fluxo):

1. Listener HTTP:

• Protocolo: HTTP
• Porta: 80

2. Backend Pool:

• Target: FQDN
• Valor: nomedoapp.azurewebsites.net

3. HTTP Settings:

• Protocolo: HTTPS
• Porta: 443
• Override host name: nomedoapp.azurewebsites.net
• SNI: habilitado

4. Health Probe customizada:

• Host: nomedoapp.azurewebsites.net
• Path: / (ou endpoint de health da sua app)

5. Rule:

• Associe Listener -> Backend Pool -> HTTP Settings

Se backend ficar Unhealthy, o problema costuma ser DNS privado não vinculado corretamente ou host/probe incorretos.

ETAPA 13 - Criar registro DNS público

Na zona DNS pública seudominio.com.br, crie:

• Tipo: A
• Nome: app
• IP: IP público do Application Gateway

Resultado:

ETAPA 14 - Configurar HTTPS real com certificado

Emita certificado para:

Pode ser Let's Encrypt, ZeroSSL ou certificado comercial.

Tutorial rápido - certificado gratuito com ZeroSSL

Para este lab, use o fluxo por validação DNS no ZeroSSL.

1. Acesse o ZeroSSL e inicie emissão para app.seudominio.com.br.

2. Escolha validação por CNAME.

3. O ZeroSSL vai fornecer um registro parecido com este:

Name
_xxxx.app.seudominio.com.br

Target
xxxx.comodoca.com

4. Na zona seudominio.com.br no Azure DNS, crie o CNAME com os valores informados.

5. Aguarde propagação e valide:

nslookup -type=CNAME _xxxx.app.seudominio.com.br

6. Conclua a validação no portal do ZeroSSL e baixe os arquivos:

certificate.crt
ca_bundle.crt
private.key

7. Converta para PFX:

openssl pkcs12 -export \
  -out app-seudominio.pfx \
  -inkey private.key \
  -in certificate.crt \
  -certfile ca_bundle.crt

Importe o certificado no Key Vault.

Passo obrigatório - criar User Assigned Managed Identity

Conforme a documentação, a integração Application Gateway + Key Vault exige 3 passos:

1. Criar uma User Assigned Managed Identity

2. Delegar acesso dessa identidade ao Key Vault

3. Associar a identidade e o certificado no Application Gateway via CLI ou PowerShell

Importante: com Azure RBAC no Key Vault (como configuramos na ETAPA 6), o vínculo da identidade e do certificado no Application Gateway não é suportado pelo portal. Use PowerShell ou CLI.

Passo 1 - Criar a identidade

No portal:

• Pesquise Managed Identities -> Create
• Nome: mi-agw-kv-reader
• Resource Group: rg-app-baseline-lab
• Região: mesma do lab

Passo 2 - Conceder permissão no Key Vault

No Key Vault -> IAM:

• Role: Key Vault Secrets User
• Principal: mi-agw-kv-reader

Nota: como o Key Vault tem Private Endpoint habilitado (ETAPA 6), o Application Gateway já consegue acessar via IP privado desde que a zona privatelink.vaultcore.azure.net esteja linkada a VNet (ETAPA 5).

Passo 3 - Associar identidade e certificado no Application Gateway (PowerShell)

# Obter o Application Gateway
$appgw = Get-AzApplicationGateway -Name agw-app-baseline -ResourceGroupName rg-app-baseline-lab

# Associar a User Assigned Managed Identity
Set-AzApplicationGatewayIdentity -ApplicationGateway $appgw \
  -UserAssignedIdentityId "/subscriptions/<subscription-id>/resourceGroups/rg-app-baseline-lab/providers/Microsoft.ManagedIdentity/userAssignedIdentities/mi-agw-kv-reader"

# Obter o secret ID do certificado no Key Vault (sem versão para auto-rotação)
$secret = Get-AzKeyVaultSecret -VaultName "kv-app-baseline" -Name "<nome-do-certificado>"
$secretId = $secret.Id.Replace($secret.Version, "")

# Adicionar o certificado SSL ao Application Gateway
Add-AzApplicationGatewaySslCertificate -KeyVaultSecretId $secretId -ApplicationGateway $appgw -Name $secret.Name

# Aplicar as alterações
Set-AzApplicationGateway -ApplicationGateway $appgw

Passo 4 - Criar Listener HTTPS no portal

Agora sim, no portal:

• Application Gateway -> Listeners -> Add Listener
• Protocol: HTTPS
• Porta: 443
• Host name: app.seudominio.com.br
• Certificate: selecione o certificado adicionado no passo anterior
• Save

Passo 5 - Redirect HTTP para HTTPS

No Application Gateway, crie uma regra de redirecionamento:

• Application Gateway -> Rules -> selecione a regra do Listener HTTP (porta 80)
• Backend targets: troque para Redirection
• Target type: Listener
• Target listener: o listener HTTPS criado no passo anterior
• Redirect type: Permanent (301)

Isso garante que todo acesso HTTP seja redirecionado automaticamente para HTTPS.

ETAPA 15 - Testes finais (checklist de aceite)

Teste 1:

https://app.seudominio.com.br

Esperado: carregar normalmente via Application Gateway.

Teste 2:

https://nomedoapp.azurewebsites.net

Esperado: falhar (acesso público do App Service desabilitado).

Teste 3:

nslookup app.seudominio.com.br

Esperado: retornar o IP público do Application Gateway.

Se os 3 testes passarem, sua baseline esta pronta com:

• DNS público no Azure
• WAF na borda
• Private Link no backend
• Isolamento de rede
• TLS ponta a ponta

Troubleshooting rápido

Backend Unhealthy no Application Gateway

• Verifique se as Private DNS Zones estão linkadas a VNet
• Confirme host da probe e path de health
• Valide se o Web App responde 200 no endpoint usado na probe

Erro de certificado no listener HTTPS

• Confirme Managed Identity ativa no Application Gateway
• Confirme role Key Vault Secrets User no Key Vault
• Aguarde propagação de permissões RBAC (pode levar alguns minutos)

Erro de host header

• Confirme que o domínio público foi adicionado no App Service (Custom Domains), quando exigido pelo seu fluxo

Exportar como Infrastructure as Code (IaC)

Para quem não conhece, o Azure permite exportar todos os recursos de um Resource Group como código. Você pode gerar templates em ARM (JSON), Bicep ou Terraform direto pelo portal ou CLI.

No portal: Resource Group -> Export template.

Isso é útil para versionar a infraestrutura, replicar o ambiente em outra subscription ou usar como base para automação em pipelines de CI/CD.

Neste laboratório, exportei o Resource Group inteiro no formato Terraform. O arquivo ficou com mais de 2 mil linhas, então não incluí aqui no artigo. Publiquei no meu repositório do GitHub como referência:

Importante: esse export não foi testado como implementação real com terraform apply. O Azure gera o código a partir do estado atual dos recursos, mas nem sempre o resultado é aplicável sem ajustes. Use como ponto de partida e referência, não como código pronto para produção.

Visualização da arquitetura no portal

O Azure oferece uma funcionalidade de visualização gráfica direto pelo Resource Group. No portal, acesse Resource Group -> Resource visualizer. Lá você consegue ver todos os recursos e suas conexões em um diagrama interativo, e exportar a imagem.

Este é o resultado final do nosso laboratório:

Conclusão

Esse roteiro evita o ciclo comum de "cria recurso, testa, quebra DNS, volta tudo".

Seguindo essa ordem, você implementa a arquitetura baseline completa de forma previsível: primeiro identidade e rede, depois Private Link, em seguida borda WAF e por fim DNS/TLS público com validação final.

No dia 25 de fevereiro de 2026, rolou o Codecon Meetup #15 em Florianópolis. O encontro aconteceu no Impact Hub Bewiki, no centro da cidade, um espaço de coworking focado em inovação e conexões entre profissionais de tecnologia.

Foram cerca de 3 horas de troca técnica, networking e conversas sobre como a IA e o ensino estão mudando a forma de construir software.

Abri a noite junto com a Jéssica Mello com a talk:

A proposta foi mostrar um case real: a construção do meu site pessoal usando IA generativa + engenharia de software + DevOps.

A história começou com um prompt simples, pedindo um site profissional, moderno e responsivo. A primeira versão saiu toda com IA e virou um one-page rápido de colocar no ar, mas aquilo era só o começo.

Do prompt ao código

Depois da primeira versão gerada por IA, o próximo passo foi assumir o controle do projeto. O site saiu da ferramenta de geração e foi para um repositório com versionamento profissional, refatoração e organização de código.

Foi ali que o projeto deixou de ser só um experimento de IA e virou um produto de verdade: separação em múltiplas páginas, melhorias de UX, ajustes de SEO e evolução contínua.

A IA ajudou muito a acelerar, mas engenharia ainda manda no resultado final.

Colocando em produção

Toda a infraestrutura foi provisionada usando Infrastructure as Code (Terraform), garantindo imutabilidade e consistência. O deploy ficou totalmente automatizado com pipeline CI/CD.

Push no repositório, testes rodando, deploy automático. No ClickOps.

Também falamos sobre o lado que pouca gente comenta quando o assunto é IA. Dependência de plataforma, custos e vendor lock-in são alguns riscos. IA acelera muito, mas em produção exige controle. Essa foi uma das mensagens centrais da talk.

Mas uma coisa continua igual: deploy ainda é responsabilidade do engenheiro.

E ainda bem.

Tecnologia como ponte

Na sequência, a Maiza Louise trouxe a talk: Tecnologia como ponte para educação de qualidade

Uma visão bem diferente e complementar, mostrando como tecnologia pode gerar impacto real fora do mundo corporativo. Esse tipo de assunto deixa o meetup muito mais rico.

Fechamento

Eu e a Maisa estavamos representando a Alura, que estava presente apoiando o evento. Tivemos um sorteio de um ano de licença da plataforma.

E essa é a foto com o ganhador:

Slides

Os slides estão disponíveis aqui:

• Slides da Apresentação:

No dia 31 de janeiro de 2026, rolou o 92º Python Floripa, dessa vez dentro do QG da HostGator, em Florianópolis. E olha… competimos com a praia num sábado de sol em pleno verão e ganhamos. Isso diz muita coisa sobre a força da comunidade.

Casa cheia, energia lá em cima e um clima muito claro: sem hype, mais prática. Menos buzzword, mais ideia de como construir software hoje.

Uma tarde FOD@

As talks se conectaram, nada fora do contexto. Como desenvolver software com mais consciência, estratégia e visão de longo prazo.

Abri a tarde junto com a Jéssica Mello, puxando uma conversa bem direta sobre Vibe Coding com DevOps. IA ajuda, acelera, mas não substitui humano, processo e muito menos o engenheiro/a. E sim, DevOps continua sendo peça-chave quando o assunto é colocar aplicação no ar com segurança, controle e previsibilidade.

IA no dia a dia de quem constrói

Na sequência, a Evelyn Cid aprofundou exatamente esse ponto: como a IA já está impactando a rotina do desenvolvedor agora, do código à tomada de decisão. Menos palco, mais bastidor. Menos promessa, mais uso consciente por quem está no teclado todos os dias.

Fechando o evento, a Ana Paula Mendes trouxe um tema que deveria ser obrigatório em qualquer carreira tech: brag document.

Comunidade sendo comunidade

As lightning talks deram aquele tempero clássico do Python Floripa: projetos pessoais, ideias em construção, dicas práticas e muita troca honesta. Gente aprendendo, gente ensinando e todo mundo no mesmo nível.

E claro, o coffee break fez jus à fama. Muita conversa e networking

Agradecimento

Fica aqui um agradecimento gigante à Comunidade Python Floripa, que fortalecem demais a cena tech em Floripa.

As talks estão disponíveis no YouTube pra quem quiser assistir ou reassistir. E se a quiser participar do próximo, já se organiza e acompanha as novidades no nosso calendário.

• Slides da Apresentação: Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU

No artigo anterior, mostrei como estruturei a infraestrutura do blog com Terraform e GitHub Actions. Agora vamos seguir em frente e fazer um deep dive no GitHub Actions (Pipelines CI/CD).

Vou compartilhar estratégias de deploy, pull requests, conceitos de engenharia de platforma aplicadas na prática, otimizações de performance e práticas de segurança que apliquei.

O que vamos ver:

• Arquitetura de Workflows: Overview das 3 pipelines (infra-plan, infra-deploy, deploy-app)
• Estratégias de Branching: trunk-based development aplicado na prática
• Pirâmide de Testes: unitários, componentes e E2E
• Otimização de Performance: caching de dependências e providers Terraform
• Segurança em Pipelines: tflint, tfsec, Checkov e gestão de secrets Azure
• Job Summaries: informações dos outputs após as execuções

1. Arquitetura de Workflows

1.1 Organização e Nomenclatura

Uma das primeiras decisões que tomei foi: como organizar as workflows. Em projetos menores, tudo pode ficar em um único arquivo. Em projetos maiores, com a separação fica mais a manutenção e sua usabilidade.

.github/
  workflows/
    infra-plan.yml        # PR → Terraform plan + validações
    infra-apply.yml       # main → Terraform apply + docs
    deploy-app.yml        # main → build + testes + deploy

1.2 Path Filters: Execute Apenas o Necessário

Uma otimização simples mas poderosa: não rode workflows quando não há mudanças relevantes.

on:
  pull_request:
    branches: [ main ]
    paths:
      - 'infra/**'
      - '.github/workflows/infra-plan.yml'

on:
  push:
    branches: [ main ]
    paths:
      - 'src/**'
      - 'e2e/**'
      - 'public/**'
      - 'index.html'
      - 'package.json'
      - 'package-lock.json'
      - 'bun.lockb'
      - 'tsconfig*.json'
      - 'vite.config.ts'
      - 'tailwind.config.ts'
      - 'postcss.config.js'
      - 'eslint.config.js'
      - '.github/workflows/deploy-app.yml'

Se você só mexer no README, nenhum workflow roda.

1.3 Workflow Chaining: Infra → App

O deploy-app.yml tem um trigger com uma condition: aguarda a workflow infra-apply terminar com sucesso:

on:
  workflow_run:
    workflows: ["infra-apply"]
    types:
      - completed
    branches: [ main ]

jobs:
  build_and_deploy:
    if: github.event.workflow_run.conclusion == 'success'

Se eu alterar algo na infraestrutura (Terraform) e o código do site ao mesmo tempo, a infra deve ser provisionada antes do deploy da app.

2. Estratégias de Branching e CI/CD

A estratégia de branching influencia diretamente como seus workflows se comportam.

2.1 Trunk-Based Development na Prática

main (produção)
  ↑
feature branches ou commits diretos

on:
  pull_request:
    branches: [ main ]
    paths:
      - 'infra/**'
      - '.github/workflows/infra-plan.yml'
  workflow_dispatch:

jobs:
  terraform-plan:
    # Executa plan, validações, scans
    # Adiciona comentário do plan no PR

on:
  push:
    branches: [ main ]
    paths:
      - 'infra/**'
      - '.github/workflows/infra-apply.yml'
  workflow_dispatch:

jobs:
  terraform:         # infra-apply
  build_and_deploy:  # deploy-app

if: github.actor != 'github-actions[bot]'

2.2 Concurrency Control

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true  # Cancela deploys anteriores

Para infraestrutura (Terraform):

concurrency:
  group: infra-${{ github.head_ref || github.ref }}
  cancel-in-progress: true  # Cancela runs anteriores

3. Pirâmide de Testes

        /\
       /  \
      / E2E\          ← Poucos, críticos
     /------\
    /  API   \        ← Médios, contratos
   /----------\
  / Unit Tests \       ← Base sólida
 /--------------\

 

3.1 Testes Unitários (Base)

- name: Unit tests
  run: npm run test:ci

// package.json
{
  "scripts": {
    "test": "vitest",
    "test:ci": "vitest run --coverage --reporter=verbose"
  }
}

// vitest.config.ts
export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: './src/setupTests.ts',
    coverage: {
      provider: 'v8',
      reporter: ['text', 'lcov', 'html'],
      exclude: [
        'node_modules/',
        'src/setupTests.ts',
        '**/*.d.ts',
        '**/*.config.*',
        '**/mockData',
      ],
      thresholds: {
        lines: 80,
        functions: 75,
        branches: 70,
        statements: 80,
      },
    },
  },
});

• Output no job summary
• Falha se abaixo dos thresholds

3.2 Testes de Componente

- name: Component tests
  run: npm run test:components:ci

// src/components/ui/button.test.tsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { Button } from './button';

describe('Button', () => {
  it('executa onClick quando clicado', async () => {
    const handleClick = vi.fn();
    render(<Button onClick={handleClick}>Click me</Button>);
    
    await userEvent.click(screen.getByRole('button'));
    
    expect(handleClick).toHaveBeenCalledTimes(1);
  });
  
  it('renderiza variantes corretamente', () => {
    const { container } = render(<Button variant="destructive">Delete</Button>);
    expect(container.firstChild).toHaveClass('bg-destructive');
  });
});

// vitest.config.components.ts
export default defineConfig({
  test: {
    include: ['src/components/**/*.test.tsx'],
    environment: 'jsdom',
    setupFiles: './src/setupTests.ts',
  },
});

3.3 Testes E2E

- name: Get Playwright version
  id: playwright-version
  run: echo "version=$(npm list @playwright/test --depth=0 --json 2>/dev/null | jq -r '.dependencies["@playwright/test"].version // empty')" >> $GITHUB_OUTPUT
  
- name: Cache Playwright browsers
  uses: actions/cache@v4
  with:
    path: ~/.cache/ms-playwright
    key: playwright-${{ runner.os }}-${{ steps.playwright-version.outputs.version }}

- name: Install Playwright browsers
   if: steps.playwright-cache.outputs.cache-hit != 'true'
   run: npx playwright install --with-deps

- name: E2E smoke tests
   run: npm run test:e2e:ci

// e2e/smoke.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Smoke Tests', () => {
  test('deve carregar a página inicial', async ({ page }) => {
    await page.goto('/');
    await expect(page).toHaveTitle(/Rafael Ferreira/);
    await expect(page.locator('h1')).toBeVisible();
  });
  
  test('deve navegar para artigo e renderizar conteúdo', async ({ page }) => {
    await page.goto('/');
    await page.click('text=Blog');
    await page.click('a:has-text("Terraform")').first();
    
    await expect(page).toHaveURL(/artigo-terraform/);
    await expect(page.locator('article')).toBeVisible();
  });
  
  test('deve alternar idioma', async ({ page }) => {
    await page.goto('/');
    const initialLang = await page.locator('html').getAttribute('lang');
    
    await page.click('[data-testid="language-toggle"]');
    
    const newLang = await page.locator('html').getAttribute('lang');
    expect(newLang).not.toBe(initialLang);
  });
});

// playwright.config.ts
export default defineConfig({
  testDir: './e2e',
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 1 : undefined,
  reporter: process.env.CI ? 'github' : 'html',
  use: {
    baseURL: 'http://localhost:5173',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },
  webServer: {
    command: 'npm run preview',
    port: 5173,
    reuseExistingServer: !process.env.CI,
  },
});

3.4 Paralelização de Testes

test:
  runs-on: ubuntu-latest
  strategy:
    matrix:
      shard: [1, 2, 3, 4]
  steps:
    - name: Run tests
      run: npm run test:ci -- --shard=${{ matrix.shard }}/4

e2e:
  runs-on: ubuntu-latest
  strategy:
    fail-fast: false
    matrix:
      shardIndex: [1, 2, 3, 4]
      shardTotal: [4]
  steps:
    - name: Run E2E
      run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}

4. Otimização de Performance

4.1 Estratégias de Cache Avançadas

- name: Cache dependencies
  uses: actions/cache@v4
  with:
    path: |
      ~/.npm
      node_modules
      ~/.cache/ms-playwright
    key: ${{ runner.os }}-deps-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('**/playwright.config.ts') }}
    restore-keys: |
      ${{ runner.os }}-deps-${{ hashFiles('**/package-lock.json') }}-
      ${{ runner.os }}-deps-

- name: Cache build output
  uses: actions/cache@v4
  with:
    path: |
      .next/cache
      dist/
      .vite/
    key: build-${{ runner.os }}-${{ github.sha }}
    restore-keys: |
      build-${{ runner.os }}-

- name: Cache Terraform
  uses: actions/cache@v4
  with:
    path: |
      infra/.terraform
      ~/.terraform.d/plugin-cache
    key: terraform-${{ runner.os }}-${{ hashFiles('infra/.terraform.lock.hcl') }}

4.2 Artifacts Estratégicos

build:
  steps:
    - name: Build
      run: npm run build
    
    - name: Upload build
      uses: actions/upload-artifact@v4
      with:
        name: dist-${{ github.sha }}
        path: dist/
        retention-days: 7
        if-no-files-found: error

deploy:
  needs: build
  steps:
    - name: Download build
      uses: actions/download-artifact@v4
      with:
        name: dist-${{ github.sha }}
        path: dist/

4.3 Job Conditionals Inteligentes

deploy-docs:
  if: |
    github.event_name == 'push' &&
    github.ref == 'refs/heads/main' &&
    contains(github.event.head_commit.message, '[docs]')

on:
  push:
    paths:
      - 'src/**'
      - 'package.json'
      - '!**/*.md'

- name: Check for relevant changes
  id: changes
  run: |
    FILES=$(gh pr view ${{ github.event.pull_request.number }} \
      --json files --jq '.files[].path')
    if echo "$FILES" | grep -E '^src/'; then
      echo "has-src-changes=true" >> $GITHUB_OUTPUT
    fi

- name: Run tests
  if: steps.changes.outputs.has-src-changes == 'true'
  run: npm test

5. Segurança nas Pipelines

5.1 A Pirâmide de Segurança em IaC

Assim como aplicações (unit → component → E2E), infraestrutura também precisa de validações em camadas:

5.2 Implementação

- name: Setup TFLint
  uses: terraform-linters/setup-tflint@v4

- name: Cache TFLint plugins
  uses: actions/cache@v4
  with:
    path: ~/.tflint.d/plugins
    key: ${{ runner.os }}-tflint-${{ hashFiles('infra/.tflint.hcl') }}

- name: Run TFLint
  run: tflint --init && tflint -f compact

- name: tfsec scan
  uses: aquasecurity/tfsec-action@v1.0.3
  with:
    working_directory: infra
    soft_fail: false

- name: Checkov scan
  uses: bridgecrewio/checkov-action@v12
  with:
    directory: infra
    soft_fail: false

5.3 Gestão de Secrets

jobs:
  terraform:
    env:
      ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
      ARM_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
      ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      ARM_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

deploy:
  steps:
    - name: Deploy to Azure Static Web Apps
      uses: Azure/static-web-apps-deploy@v1
      with:
        azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}

6. Job Summaries: Visibilidade Pós-Execução

6.1 Job Summary no deploy-app.yml

- name: Job summary
  if: always()
  run: |
    {
      echo "## 🚀 App Deploy Summary"
      echo ""
      echo "| Item | Value |"
      echo "|------|-------|"
      echo "| Event | \`${{ github.event_name }}\` |"
      echo "| Branch | \`${{ github.ref_name }}\` |"
      echo "| Actor | \`${{ github.actor }}\` |"
      echo "| Commit | \`$(git rev-parse --short HEAD)\` |"
      echo ""
      echo "### 📦 Build Info"
      echo ""
      echo "| Metric | Value |"
      echo "|--------|-------|"
      echo "| Output | \`dist/\` |"
      echo "| Files | $(find dist -type f | wc -l) |"
      echo "| Size | $(du -sh dist | cut -f1) |"
      echo ""
      echo "### ✅ Deploy Status"
      echo ""
      echo "Application deployed to **Azure Static Web Apps**"
      echo ""
      echo "🌐 [View Application](https://www.orafaelferreira.com)"
    } >> "$GITHUB_STEP_SUMMARY"

• Roda mesmo se steps anteriores falharem
• Sempre tenho visibilidade do que aconteceu

6.2 Job Summary no infra-apply.yml

- name: Job summary
  if: always()
  run: |
    {
      echo "## Terraform Apply Summary";
      echo "";
      echo "| Item | Value |";
      echo "|------|-------|";
      echo "| Branch | \`${{ github.ref_name }}\` |";
      echo "| Actor | \`${{ github.actor }}\` |";
      echo "| Backend | \`stostateorafael/statetf/infra.terraform.tfstate\` |";
      echo "| Status | ✅ Applied |";
    } >> "$GITHUB_STEP_SUMMARY"

7. Deploy: Azure Static Web Apps

7.1 Deploy Direto para Produção

O deploy-app.yml faz um deploy simples e direto para o Azure Static Web Apps:

- name: Deploy to Azure Static Web Apps
  uses: Azure/static-web-apps-deploy@v1
  with:
    azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
    action: 'upload'
    app_location: 'dist'
    skip_app_build: true  # Já fizemos build antes

• O build já foi executado antes (npm run build)
• Testes já rodaram (unitários e componentes)
• Apenas fazemos upload do dist/ pronto

7.2 Fluxo Completo do Deploy

1. Install deps (npm install)
   ↓
2. Unit tests (Vitest)
   ↓
3. Component tests (React Testing Library)
   ↓
4. Type check (tsc)
   ↓
5. Build (Vite)
   ↓
6. Deploy to Azure SWA
   ↓
7. Job Summary (métricas)

8. Custos

8.1 Custo Zero para Repositórios Públicos

• Public repos: minutos ilimitados ✅
• Private repos: 2000 min/mês (free), depois $0.008/min

Como o blog é público, os custos são zero. Mas ainda assim está otimizado.

8.2 Timeouts: Proteção Contra Runs Travados

Todas as pipelines têm timeout configurado:

# infra-plan.yml
timeout-minutes: 25

# infra-apply.yml
timeout-minutes: 30

# deploy-app.yml
timeout-minutes: 20

• Evita workflows travados consumindo hardware
• Falha rápida em caso de problemas em loop infinito

9. Workflow Dispatch: Triggers Manuais

9.1 Trigger Manual nas 3 Pipelines

Todas as 3 workflows suportam trigger manual via workflow_dispatch, permitindo execução sob demanda sem precisar fazer commits:

on:
  workflow_dispatch:

1. Vá para GitHub Actions

2. Selecione o workflow desejado

3. Clique em "Run workflow"

4. Confirme a execução

Caso queira dar uma olhada em detalhes: Workflows

Conclusão

• Arquitetura: 3 workflows com responsabilidades segregadas
• Path filters: executa apenas quando necessário
• Concurrency control: evita race conditions
• Testes: pirâmide com unitários + componentes
• Cache: dependências npm, providers Terraform e plugins TFLint
• Segurança: TFLint + tfsec + Checkov validam código Terraform
• Documentação: terraform-docs auto-gera docs no README
• Deploy: direto para Azure SWA após validações
• Job summaries: métricas claras em cada execução
• Workflow dispatch: todas as 3 pipelines podem ser executadas manualmente

Não comecei com tudo isso, fui evoluindo conforme fui aprendendo coisas novas e implementando em um case real.

Faça o mesmo, crie algum projeto pequeno pessoal, quebre, teste, aprenda, evolua!

No ecossistema de nuvem, a eficiência financeira é tão importante quanto a eficiência técnica. O uso de Azure Spot Node Pools no AKS permite economizar até 90% em comparação com instâncias regulares. Contudo, essa economia exige uma configuração rigorosa de Taints para evitar que sua aplicação sofra interrupções inesperadas.

1. O que são Spot Node Pools?

Características Principais

• Efemeridade: Os nós podem ser removidos a qualquer momento.
• Custo: Drasticamente reduzido.
• Casos de Uso: Processamento em lote, ambientes de teste, CI/CD, cargas de trabalho stateless resilientes, ambientes de desenvolvimento.
• Limitação: Não podem ser o pool de sistema (System Node Pool) padrão do cluster.

> Documentação Oficial: Para mais detalhes sobre a implementação de Spot Node Pools no AKS, consulte a documentação completa da Microsoft.

2. O Conceito Vital: Taints e Tolerations

Um Taint é um atributo aplicado a um nó que "repele" pods. Para que um pod seja agendado em um nó com Taint, ele deve possuir uma Toleration (tolerância) correspondente.

No contexto de instâncias Spot, o Taint é a sua principal ferramenta de segurança para garantir que apenas pods preparados para interrupções sejam alocados nesses nós.

Efeitos de Taint no AKS

3. Implementação com Terraform

Para criar um pool de nós Spot com as proteções adequadas, utilizamos o recurso azurerm_kubernetes_cluster_node_pool. O exemplo abaixo demonstra a configuração ideal:

resource "azurerm_kubernetes_cluster_node_pool" "spot" {
  name                  = "spotpool01"
  kubernetes_cluster_id = azurerm_kubernetes_cluster.main.id
  vm_size               = "Standard_DS2_v2"
  
  # Ativação do modo Spot
  priority              = "Spot"
  eviction_policy       = "Delete" # Deleta a VM após o despejo
  spot_max_price        = -1       # Paga até o preço de uma instância regular

  # Configuração do Taint (Crítico!)
  node_taints = [
    "kubernetes.azure.com/scalesetpriority=spot:NoSchedule"
  ]

  # Labels para seleção de nós via Affinity
  node_labels = {
    "kubernetes.azure.com/scalesetpriority" = "spot"
    "node-type"                             = "preemptible"
  }

  # Autoscaling é altamente recomendado para Spot
  enable_auto_scaling = true
  min_count           = 1
  max_count           = 5
}

4. Taints de Inicialização (Node Initialization Taints)

Uma funcionalidade avançada mencionada na documentação oficial do AKS é o Node Initialization Taint. Eles são usados para marcar nós no momento da inicialização, garantindo que o tráfego só chegue ao nó após a execução de scripts de configuração ou instalação de agentes de segurança (como o Prisma Cloud ou Cilium).

• Uso: Temporário, durante o boot do nó.
• Terraform: Pode ser configurado para garantir que o nó esteja "pronto" antes de receber qualquer carga.

5. Agendando Pods no Pool Spot

Para que sua aplicação utilize os nós criados, você deve configurar o manifesto do Kubernetes com a Toleration correta. Caso contrário, o scheduler ignorará o pool Spot e sua aplicação não rodará (ou rodará no pool regular mais caro).

Exemplo de Manifesto (YAML)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-batch-process
spec:
  template:
    spec:
      containers:
      - name: worker
        image: my-repo/worker:latest
      
      # 1. Permite entrar no nó Spot
      tolerations:
      - key: "kubernetes.azure.com/scalesetpriority"
        operator: "Equal"
        value: "spot"
        effect: "NoSchedule"
      
      # 2. Força a preferência pelo nó Spot
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: "kubernetes.azure.com/scalesetpriority"
                operator: In
                values:
                - "spot"

6. Checklist de Atenção

Ao utilizar Terraform para gerenciar AKS Spot, observe estes pontos críticos:

• Eviction Policy: Use Delete para evitar custos de disco orfãos e problemas de cota de vCPU no Azure.
• Cluster Autoscaler: Sem ele, se todos os nós Spot forem removidos, o pool pode ficar com 0 nós permanentemente até uma intervenção manual.
• Upgrade: Pools Spot não suportam surge upgrade da mesma forma que pools regulares. O nó é simplesmente substituído.
• SLA: Lembre-se que instâncias Spot não possuem SLA de disponibilidade.

7. FinOps: A Importância da Gestão Financeira em Nuvem

Quando falamos de otimização de custos no Azure, especialmente em ambientes enterprise e de larga escala, FinOps (Financial Operations) se torna algo vital. Em infraestruturas complexas, os custos podem escalar rapidamente, tornando essencial uma abordagem estruturada para monitoramento, análise e otimização contínua de gastos.

FinOps não é apenas sobre reduzir custos, mas sim sobre maximizar o valor do investimento em nuvem. Isso envolve:

• Visibilidade de Custos: Entender onde e como os recursos estão sendo consumidos
• Otimização Contínua: Identificar oportunidades de economia, como o uso de Spot Instances
• Cultura de Responsabilidade: Engajar equipes de engenharia, operações e finanças na gestão de custos
• Decisões Baseadas em Dados: Usar métricas para tomar decisões informadas sobre arquitetura e recursos

A utilização de Spot Node Pools, como demonstrado neste artigo, é um exemplo prático de como FinOps pode gerar economias significativas (até 90%) sem comprometer a qualidade das aplicações resilientes.

Conclusão

O uso de AKS Spot via Terraform é uma estratégia brilhante para reduzir a fatura do Azure, mas exige um entendimento profundo do agendador do Kubernetes. Os Taints são sua barreira de proteção: eles garantem que sua aplicação crítica não seja agendada por engano em um nó que pode desaparecer em 30 segundos.

Em 6 de dezembro de 2025, o auditório do Centro Universitário Cesusc (UNICESUSC) virou ponto de encontro da comunidade DevOps para um dia inteiro de talks, open-spaces e reencontros.

📍 Local: SC-401, 9301 - Santo Antonio de Lisboa, Florianópolis - SC, 88050-001

🌐 Site oficial: DevOpsDays Florianópolis 2025

📲 Linktree: Redes e novidades

O dia em ordem cronológica

• 08:00 - 09:00 — Credenciamento
• 09:00 - 09:30 — Abertura oficial.
• 09:30 - 10:05 — Eduardo Munari Crossplane: Habilitando Engenharia de Plataforma na sua Infraestrutura.
• 10:05 - 10:45 — Coffee break. Sim, eu estava lá disputando os salgadinhos. 😋
• 10:45 - 11:20 — Alison Duarte — Construindo uma Plataforma Self-Service: Criação de Projetos utilizando um Catálogo de Serviços.
• 11:20 - 11:55 — Jonatas (jojo) Baldin — Escrevendo seu Primeiro Operador de Kubernetes.
• 11:55 - 12:30 — Ruan Oliveira — Banalizamos a migração entre clouds com Kubernetes.
• 12:30 - 13:40 — Almoço para recarregar as energias.
• 13:40 - 13:55 — Retorno
• 13:55 - 14:30 — Rafael Mateus — Backstage na Prática: É Hora de Subir uma Plataforma de DEx na sua Firma.
• 14:30 - 15:05 — Camila Maia — Keynote — O Hack das Oportunidades.
• 15:05 - 15:40 — Lightning Talks
• 15:40 - 16:15 — Coffee break parte 2
• 16:15 - 16:50 — Luis Pontes — Lambda Pinball: Simplificando a Orquestração Serverless.
• 16:50 - 17:25 — Dri Cardoso, João Brito — Cérebro e Código: saúde mental e performance cognitiva na tecnologia.
• 17:25 - 18:00 — Sorteios

Patrocinadores

• Platinum: grafana, Elastic
• Gold: Software.com.br
• Community: UNICESUSC

Organização local

Lanusse Morais • Rafael Ferreira • Patrick Machado • Gislaine Luciane • Julio Fontes • Stefani Dal Puppo • Leandro Venâncio • Henrique Pereira Zimermann

Código de conduta

Nosso evento segue o Código de Conduta do DevOpsDays. Ajude a manter um ambiente seguro e acolhedor para todos.

Nos vemos na próxima edição do DevOpsDays Floripa! 🚀

Há 3 meses decidi tirar a certificação CKA (Certified Kubernetes Administrator). Para acelerar os estudos, segui a trilha da KodeKloud, que é referência absoluta no mercado.

Minha base já contava com o conhecimento dos cursos do DevOpsPro e da LinuxTips, além da experiência prática que tenho no trabalho. No entanto, para a prova, eu precisava de velocidade e precisão.

Utilizei exaustivamente o curso Ultimate Certified Kubernetes Administrator (CKA) Mock Exam Series. Os exercícios reproduzem a pressão do exame real e me ajudaram a automatizar a resolução de problemas complexos em cenários de cluster real. Documentei abaixo o que funcionou para chegar pronto no dia da prova.

Certificados dos Cursos de Preparação

🏆 Resultado da Prova CKA

> Exam Results

> - Status: Pass ✅

> - Your Score: 75%

> - Score Needed: 66%

🎖️ Certificação Oficial

Topicos Abordados na Prova CKA 2025

1. Arquitetura do Cluster e Conceitos Core

A base de tudo é entender a separação entre o Control Plane e os Worker Nodes.

• ETCD: O banco de dados chave-valor que armazena todo o estado do cluster. Backup e restauração aqui são críticos.
• Kube-API Server: O único componente que fala com o ETCD. Tudo passa por ele.
• Kube-Scheduler: Decide em qual nó o seu Pod vai morar, baseando-se em recursos disponíveis.
• Kubelet: O agente que roda nos nós e garante que os containers estejam rodando conforme o esperado.
• Kube-Proxy: Gerencia as regras de rede (IPtables/IPVS) para permitir a comunicação.

2. Gerenciamento do Ciclo de Vida da Aplicação

Administrar aplicações envolve estratégias de atualização e resiliência:

• ConfigMaps e Secrets: Separam a configuração e dados sensíveis do código da imagem.
• Escalonamento: O uso de HPA (Horizontal Pod Autoscaler) e VPA (Vertical Pod Autoscaler) para ajustar a infraestrutura à demanda.

3. Agendamento e Escalabilidade Avançada

Não basta rodar o Pod; é preciso saber onde ele deve rodar:

• Taints and Tolerations: Impedem que Pods sejam colocados em nós específicos, a menos que tenham uma permissão explícita.
• Node Affinity: Atrai Pods para nós específicos.
• Resource Quotas & Limits: Essenciais para evitar que um único Pod utilize todos os recursos do nó.

4. Rede e Conectividade

A parte MAIS desafiadora do exame.

• Serviços: ClusterIP (interno), NodePort (exposição básica) e LoadBalancer (integração com nuvem).
• Ingress vs. Gateway API: Enquanto o Ingress é o padrão clássico, a Gateway API (foco nas atualizações de 2025) oferece um modelo mais expressivo.

5. Armazenamento (Storage)

A persistência de dados em um ambiente efêmero:

• PV (Persistent Volume): O recurso de armazenamento real no cluster.
• PVC (Persistent Volume Claim): O "ticket" ou pedido de um usuário por armazenamento.
• Storage Classes: Permitem o provisionamento automático e dinâmico de discos.

6. Segurança e Manutenção

Garantir a integridade e a atualização do cluster:

• RBAC (Role-Based Access Control): Definir QUEM pode fazer O QUÊ e em QUAL Namespace.
• TLS Certificates: O Kubernetes usa certificados para todas as comunicações. Saber expirar, renovar e aprovar CSRs é vital.
• Upgrade do Cluster: O processo de usar o kubeadm para atualizar o Control Plane e os Nodes de forma segura.

7. Resolução de Problemas (Troubleshooting)

No exame CKA, você passará a maior parte do tempo consertando coisas quebradas.

• Logs e Describe: kubectl logs e kubectl describe são seus melhores amigos.
• Componentes de Sistema: Se o cluster cair, verifique o status do serviço no SO com journalctl -u kubelet.

Dica de ouro

Pratique exaustivamente os Imperative Commands (kubectl run, kubectl create) para ganhar tempo e evitar erros de sintaxe em arquivos YAML.

Considerações sobre a Prova

A prova CKA 2025 é 100% prática e exige velocidade e precisão. Você terá 2 horas para resolver entre 15 e 20 questões em ambientes reais de cluster Kubernetes. Não existe múltipla escolha, apenas você, o terminal e a documentação oficial.

Questões que Caíram

Durante a prova, encontrei questões que abordavam os seguintes tópicos:

• Instalar o Calico v3.28.2 via tigera-operator
• Configurar CRDs e verificar NetworkPolicies funcionais

• Criar PersistentVolumeClaims e recuperar dados de volumes existentes
• Configurar StorageClass com volumeBindingMode: WaitForFirstConsumer
• Definir StorageClass padrão do cluster

• Corrigir configurações de kube-apiserver após migração (etcd endpoints incorretos)
• Identificar componentes quebrados e reiniciar serviços
• Ajustar certificados e paths de arquivos após mudança de máquina

• Calcular e aplicar resource requests para Pods (dividindo recursos do nó igualmente)
• Configurar sidecard e containers com os mesmos valores de request

• Instalar Argo CD via Helm (versão 7.7.3) sem reinstalar CRDs
• Gerar templates Helm e salvar manifestos
• Usar --set crds.install=false para evitar conflitos

• Criar recursos Ingress com TLS
• Migrar de Ingress para Gateway API (novidade 2025)
• Configurar HTTPRoute e Gateway com hostname específico

• Criar HPA com target de 50% CPU
• Configurar downscaleStabilizationWindow para 30 segundos
• Instalar e configurar metrics-server quando necessário

• Adicionar container sidecar para streaming de logs
• Usar volumes compartilhados (emptyDir)
• Comando: tail -n+1 -f /var/log/app.log

• Reconfigurar Deployment para expor porta 80/tcp
• Criar Service tipo NodePort usando comandos imperativos
• Entender a diferença entre containerPort e Service port

• Criar PriorityClass com valor específico
• Fazer patch em Deployment existente para usar a nova priority
• Observar eviction de Pods de menor prioridade

• Atualizar ConfigMap para permitir TLSv1.2 e TLSv1.3 em NGINX
• Recriar Pods para aplicar mudanças de configuração
• Testar com curl --tls-max 1.2 (deve falhar)

• Listar CRDs do cert-manager
• Extrair documentação com kubectl explain (ex: certificate.spec.subject)
• Salvar outputs em arquivos específicos

• Instalar e configurar cri-dockerd via dpkg
• Configurar parâmetros sysctl para Kubernetes
• Habilitar e startar serviços do systemd

• Expor Deployment via NodePort
• Considerar overhead de 10% e limites adequados

Distribuição de Pontos

As questões não valem o mesmo. Questões de troubleshooting e setup completo tendem a valer mais (8-12% cada), enquanto tarefas simples como criar um Service valem menos (2-4%). Por isso, é estratégico focar primeiro nas questões que você domina completamente.

Recursos Recomendados para Preparação

Além do curso da KodeKloud, aqui estão alguns recursos que podem acelerar significativamente sua preparação:

Repositórios no GitHub

• CKA-PREP-2025-v2
• CKA2025

Esses repositórios contêm questões similares às que caem na prova e são excelentes para praticar cenários hands-on.

Playlists no YouTube

• Playlist 1 — Kubernetes CKA Full Course
• Playlist 2 — CKA Crash Course
• Playlist 3 — Kubernetes Administrator Series

Assista às playlists enquanto pratica os labs. A combinação de teoria + prática é fundamental para fixar os conceitos.

Conclusão

A combinação de prática diária, simulados fez toda a diferença. Se você está começando agora, foque em repetir os labs até que os comandos se tornem automáticos.

Algumas semanas atrás eu decidi migrar meu blog para uma versão mais moderna, simples de operar e fácil de evoluir. O plano:

Terraform para declarar infraestrutura, GitHub Actions para orquestrar e Azure Static Web Apps para hospedar. Neste artigo, irei contar um pouco dessa jornada:

Vamos passar por tudo o que sustenta o blog hoje:

• Organização dos arquivos Terraform (providers, backend, variáveis e recursos)
• Estratégia de state remoto em Azure Storage
• Provisionamento do SWA e domínio customizado
• Padrões de execução local com Service Principal
• Pipelines CI/CD no GitHub Actions para "plan" (PRs) e "apply" (push em main)
• Segurança, lint e scans: TFLint, tfsec, Checkov (era preciso tudo isso? claro que não! meu site se tornou meu projeto pessoal de estudos)
• Automatização de documentação com terraform-docs
• Integração com o deploy do app (build + upload da pasta "dist")

Ao final, você terá uma visão ponta a ponta do que acontece desde um "git push" até o site atualizado em produção.

Estrutura Terraform

Dentro da pasta infra/ temos os principais arquivos que definem a infraestrutura:

• providers.tf: versão do Terraform, provider azurerm e suas capabilities.
• backend.tf: configuração do backend remoto do state no Azure Storage.
• variables.tf: variáveis para vincular o repositório ao SWA (URL, branch e token).
• main.tf: recursos da solução (Static Web App + domínio customizado) e o resource group consumido como data source.

providers.tf

O arquivo fixa as versões para garantir reprodutibilidade e compatibilidade:

terraform {
  required_version = "1.13.4"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "4.50.0"
    }
  }
}

provider "azurerm" {
  features {}
}

• Terraform: versão 1.13.4, versão mais atual de quando fiz o projeto
• Provider azurerm: versão 4.50.0, versão mais atual de quando fiz o projeto

backend.tf

Quando migrei, uma das primeiras decisões foi nunca manter state local.

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-site"
    storage_account_name = "stostateorafael"
    container_name       = "statetf"
    key                  = "infra.terraform.tfstate"
    use_azuread_auth     = true
  }
}

• RG/Storage/Container: isolam o state em um bucket dedicado.

variables.tf

Variáveis me ajudaram a controlar comportamentos por ambiente: no apply em main, os valores reais chegam via secrets. Isso mantém o fluxo seguro com segurança.

variable "repository_url" {
  description = "GitHub repository URL para SWA (vazio em PR)"
  type        = string
  default     = ""
}

variable "repository_branch" {
  description = "Branch do repositório para SWA (vazio em PR)"
  type        = string
  default     = ""
}

variable "repository_token" {
  description = "GitHub PAT para linkage CI (omitido em PR)"
  type        = string
  sensitive   = true
  default     = ""
}

• Em apply, os valores reais chegam via secrets do GitHub Actions.

main.tf

Aqui fica a cereja do bolo: o Azure Static Web Apps na camada gratuita com domínio customizado. Eu queria um hosting estável, com HTTPS automático e integração perfeita com GitHub. O SWA entrega isso sem dor de cabeça.

# Recurso de RG existente (fora do TF)
data "azurerm_resource_group" "rg" {
  name = "rg-site"
}

# Static Web Apps (SWA)
resource "azurerm_static_web_app" "this" {
  name                = "swa-site-orafael"
  resource_group_name = data.azurerm_resource_group.rg.name
  location            = "eastus2"
  sku_tier = "Free"
  sku_size = "Free"
  repository_url    = var.repository_url
  repository_branch = var.repository_branch
  repository_token  = var.repository_token
}

# Domínio customizado (validação DNS via TXT)
resource "azurerm_static_web_app_custom_domain" "txt-value" {
  static_web_app_id = azurerm_static_web_app.this.id
  domain_name       = "www.orafaelferreira.com"
  validation_type   = "dns-txt-token"
}

• O RG é um data source (mantido fora do Terraform), já que é onde fica o storage account para manter o state remoto.
• O SWA tem linkage com este repositório, então o deploy do blog é natural ao meu fluxo de commits.
• O domínio www.orafaelferreira.com usa validação por DNS TXT; depois da propagação, o Azure cuida dos certificados.

Service Principal

Para validação das pipelines podem fazer o deploy na cloud, estou utilizando Service Principal (SP).

Exemplo de export das credenciais (Linux) e execução:

export ARM_CLIENT_ID=<appId-do-SP>
export ARM_CLIENT_SECRET=<clientSecret-do-SP>
export ARM_TENANT_ID=<tenantId>
export ARM_SUBSCRIPTION_ID=<subscriptionId>
export SWA_REPOSITORY_TOKEN=<github-PAT>

cd infra
terraform init
terraform plan
terraform apply -auto-approve   -var "repository_url=https://github.com/<owner>/<repo>"   -var "repository_branch=main"   -var "repository_token=${SWA_REPOSITORY_TOKEN}"
cd -

> Em ambientes Windows PowerShell, adapte com $Env:VAR=valor.

Pipelines CI/CD no GitHub Actions

Se a infraestrutura é o esqueleto, os pipelines que bota pra rodar. Cada commit tem revisão, aplicação e publicação.

A automação está dividida em três workflows principais.

1) infra-plan.yml (PRs)

Dispara em pull requests que alteram infra/ ou o próprio workflow. Objetivo: validações e geração do plan.

Passos:

• actions/checkout@v4
• hashicorp/setup-terraform@v3 (Terraform 1.13.4)
• Cache dos providers Terraform e plugins do TFLint
• terraform init
• terraform fmt -check -recursive (não quebra o build em PR)
• terraform validate
• tflint --init && tflint -f compact
• tfsec e Checkov com soft_fail: false (quebram em achados críticos)
• terraform plan -out=tfplan com variáveis placeholder
• Upload do artifact tfplan
• Comentário no PR com o plan já expandido (sem tabela de status). Eu quis reduzir cliques e atrito: abrir o PR e já ver o que muda.

2) infra-apply.yml (push em main)

Dispara em push que altera infra/ ou o próprio workflow, e também pode ser manual via workflow_dispatch.

Passos de segurança e qualidade:

• terraform init, fmt, validate, tflint, tfsec, Checkov (mesma base do plan)
• terraform apply -auto-approve com repository_url, repository_branch, repository_token vindos de secrets
• terraform-docs: injeta documentação do módulo no README.md e commita automaticamente (quando houver alteração)
• Job Summary: resumo simples (branch/actor/backend/status), sem seção de outputs para evitar ruído quando não definidos. Na migração eu removi a seção de outputs do summary para evitar alertas desnecessários.

3) deploy-app.yml (build + upload da SPA)

Dispara em push de arquivos do app, manual (workflow_dispatch) e após conclusão bem-sucedida do infra-apply via workflow_run.

Pipeline do app:

• Node 20 + cache npm
• npm install
• Testes: unitário (Vitest), componentes (RTL) e E2E smoke (Playwright)
• npm run typecheck e npm run build
• Cache de browsers do Playwright (otimiza tempo e custo)
• Deploy com Azure/static-web-apps-deploy@v1 usando action: upload e skip_app_build: true (fazemos o build antes). Essa foi uma escolha de performance e previsibilidade no build.

Proteção contra loops:

• Condição no job: (github.event_name == 'push' && github.actor != 'github-actions[bot]')…
• Isso evita que commits automatizados (ex.: terraform-docs) disparem deploys do app desnecessariamente, um ajuste que nasceu de um incidente: o bot fazia commit e o app queria redeploy sem mudanças reais.

Segurança e Qualidade

• TFLint: enforce de boas práticas e estilo nos .tf.
• tfsec: análise de segurança estática específica para Terraform (Azure incluído).
• Checkov: políticas de segurança e conformidade (CSPM) adicionais.
• actions/cache@v4: acelera builds mantendo providers e plugins.
• Sem outputs no summary: evita confusão quando não há output definido no módulo.

> Observação: caso sejam necessários outputs (ex.: hostname, IDs), basta adicionar blocos output em infra/ e consumir no resumo/pipelines. Por ora, optei por manter o módulo minimalista.

Documentação Automatizada

Durante a migração, quis que a documentação acompanhasse o código sem esforço humano. O infra-apply.yml roda terraform-docs e injeta a referência do módulo no README.md. Se não houver mudanças, nenhum commit é feito, é documentação viva, sem burocracia.

Fluxo de Trabalho: do PR ao Deploy

1. PR em infra/ → roda infra-plan.yml: valida, escaneia segurança e gera o plan.

2. Merge em main → roda infra-apply.yml: aplica mudanças, atualiza docs.

3. Push do app (ou workflow_run de infra) → roda deploy-app.yml: builda e publica a pasta dist/ no SWA. Esse foi o momento mais satisfatório da migração: ver o blog ir ao ar segundos depois do merge.

Tudo isso com proteção contra loops de commits do bot e com caches para acelerar o ciclo.

Caso queira dar uma olhada em detalhes: Workflows

Conclusão

A combinação de Terraform + GitHub Actions entrega uma infraestrutura escalável, auditável e automatizada.

Com state remoto seguro, validações de segurança e documentação contínua, o resultado é um pipeline confiável que leva alterações de infraestrutura e aplicação ao Azure de forma robusta.

No dia 29 de novembro de 2025, estive presente no DevOpsDays Porto Alegre, O DevOpsDays é conhecido mundialmente para quem ama infraestrutura ágil, e a edição de POA manteve a tradição: conteúdo de altíssimo nível.

Minha palestra

Como aplicar Segurança em Camadas na sua arquitetura Cloud Native com Open Source

Fui aceito para apresentar a palestra "Como aplicar Segurança em Camadas na sua arquitetura Cloud Native com Open Source".

Durante a sessão, explorei a estratégia de Defesa em Profundidade (Defense in Depth), saindo da teoria para a prática com ferramentas do ecossistema CNCF. A defesa deve ser contínua e integrada em cada camada.

Destaques do Evento

A programação técnica foi excelente, especialmente a parte da tarde! Após minha apresentação, tive a oportunidade de acompanhar grandes colegas da comunidade que trouxeram temas extremamente relevantes para o nosso dia a dia:

• João Brito com a palestra As quatro dimensões de segurança em Kubernetes, um excelente complemento ao meu tema.

• Daniel Rodrigues falando sobre Chaos Mesh: Engenharia do caos para Kubernetes, explorando como injetar falhas de forma controlada.

• Vinicius Campitelli sobre Criando esteiras de CI/CD performáticas e seguras, um tema vital para a cultura DevOps.

• Cristiano Diedrich abordando o DevFinOps - Além das tags, mostrando a evolução da mentalidade de custos e eficiência.

• O tradicional Coffee Break, um momento perfeito para recarregar as energias e fazer um networking de qualidade.

É massa demais ver tanta gente nova interessada em aprender e tantos profissionais experientes dispostos a compartilhar.

> Segurança TEM que começar na fundação.

> Não existe "bala de prata", existe defesa em camadas.

• Slides da Apresentação: Defesa em Camadas com Open Source

Durante a (1ª Semana Acadêmica de ADS do IFSC), eu e o meu parceiro Vinícius Deschamps tivemos a honra de fechar a noite do dia 06/11 com uma conversa que muita gente sempre quis ouvir, mas poucos realmente contam: como é trabalhar para o exterior na vida real.

Nada de glamour de LinkedIn, nada de “ficar rico em 3 passos”, nada de frase de efeito.

Foi papo reto, experiência de campo e aquelas histórias que normalmente ficam só no café da firma.

O evento aconteceu no IFSC São José, reunindo estudantes, profissionais e curiosos querendo entender como funciona a vida tech além das fronteiras brasileiras. E, sinceramente, foi incrível ver tanta gente interessada em construir uma carreira internacional com planejamento e consciência.

Sobre a Palestra

O que a gente trouxe pra galera

A gente sabe que o assunto “trabalhar pra fora” virou moda, mas também virou uma terra de muita promessa vazia. Então fizemos o oposto.

Falamos sobre:

• O que realmente muda quando você trabalha com times internacionais
• Como lidar com cultura, comunicação e expectativas totalmente diferentes
• Realidades do fuso, das reuniões e do inglês de verdade (não aquele decorado em curso)
• O impacto na vida pessoal: rotina, saúde, relacionamentos e até grana
• Estratégias que realmente funcionam pra conquistar oportunidades lá fora
• E claro… os perrengues. Porque sempre tem perrengue.

A ideia não foi mostrar um “mundo perfeito”.

A ideia foi preparar a galera para o que é de fato.

Por que esse assunto importa??

Porque a comunidade técnica precisa falar sobre carreira e escolhas reais.

Trabalhar para o exterior pode abrir portas absurdas, mas também exige maturidade, adaptação e clareza sobre o que você quer da sua vida.

Achar que trabalhar pra fora é só “ganhar em dólar e ser feliz” é receita pra frustração.

Mas entender como se preparar, como se posicionar e como navegar esses ambientes… aí sim muda o jogo.

E se a nossa conversa ajudou pelo menos uma pessoa a tomar uma decisão mais consciente, já valeu o rolê.

Alguns momentos da noite

Aqui você pode inserir as fotos do evento:

🧾 Links de Indicação Úteis pra Quem Quer Trabalhar pra Fora

Se você está começando sua jornada internacional, aqui vão dois serviços que uso pessoalmente e recomendo:

💼 Abrir ou manter seu CNPJ com a Contabilizei

Simplifique sua vida como PJ, sem dor de cabeça com impostos e obrigações contábeis:

👉 Abra sua conta na Contabilizei com meu link de indicação

💸 Receber em dólar com ótimas taxas usando a TechFX

Pra quem recebe moeda de fora (dólar, euro, libra...) direto na conta PJ, TechFX ajuda a economizar nas taxas e ganhar agilidade:

👉 Crie sua conta TechFX com meu link e comece a receber melhor

Gratidão pelo convite

Fica meu agradecimento ao IFSC, ao pessoal da organização da Semana Acadêmica e a todo mundo que ficou até o final da noite com a gente.

A troca foi forte e verdadeira.

E que venham mais conversas que vão além do código.

• Slides da Apresentação: GreenOps e Cloud Sustentável no MVP Conf 2025

Nos dias 24 e 25 de outubro de 2025, estive presente no MVP Conf Brasil, realizado na UNIP Campus Paraíso/Vergueiro, em São Paulo - SP.

O evento reuniu mais de 500 especialistas Microsoft de todo o país, dois dias intensos de aprendizado, networking e compartilhamento de conhecimento técnico de alto nível.

Minha palestra

GreenOps e Cloud Sustentável: o equilíbrio entre performance, custo e meio ambiente

Fui convidado para compartilhar a palestra "GreenOps e Cloud Sustentável", onde explorei estratégias práticas para adotar uma operação de nuvem mais eficiente, econômica e ambientalmente responsável.

Durante a sessão, mergulhamos em tópicos como:

• O papel do GreenOps dentro da governança de nuvem corporativa
• Como medir e reduzir o carbon footprint em ambientes Azure
• A união entre FinOps, Cloud Efficiency e automação
• Arquiteturas verdes, resilientes e escaláveis
• Casos reais de sustentabilidade digital aplicada ao dia a dia corporativo

A ideia foi mostrar que dá pra fazer mais com menos impacto, sem comprometer a performance, e ainda gerando economia real.

Porque, convenhamos, eficiência e sustentabilidade podem (e devem) andar juntas.

Um evento com propósito

O MVP Conf vai muito além de tecnologia.

Todo o valor arrecadado com os ingressos é 100% destinado a instituições sociais, como a Casa do Zezinho, Associação Prato Cheio e Associação Fênix.

É inspirador ver uma comunidade tão técnica e diversa unida por um propósito tão nobre: usar o conhecimento pra gerar impacto real.

Um encontro de gigantes

Foi uma honra dividir o palco com tanta gente incrível e poder representar a comunidade de arquitetura cloud e sustentabilidade dentro desse ecossistema.

Networking e reencontros

O MVP Conf é aquele tipo de evento que você chega pra assistir uma palestra e sai com dez novas conexões no LinkedIn.

O ambiente colaborativo e cheio de energia positiva.

Reencontrei amigos de comunidade, troquei ideias com profissionais de diferentes regiões e claro, renderam boas conversas sobre café, cloud e caos controlado.

Participar do MVP Conf Brasil 2025 foi uma experiência única.

Um evento feito por especialistas para a comunidade, com propósito social, conteúdo técnico de peso e um clima de colaboração genuína.

> Sustentabilidade não é tendência, é responsabilidade.

> E quando unimos tecnologia e propósito, o impacto é exponencial.

• Slides da Apresentação: GreenOps e Cloud Sustentável no MVP Conf 2025

No dia 02 de outubro de 2025, participei como palestrante na 8ª edição da whiteStone_dev, realizada no INAITEC – Pedra Branca, em Palhoça (SC).

Uma noite dedicada à Cultura DevOps, onde a comunidade se reuniu para discutir o que realmente faz essa mentalidade transformar times e organizações.

O evento

A whiteStone_dev chegou à sua 8ª edição com uma proposta diferente:

falar menos sobre ferramentas e mais sobre pessoas, princípios e práticas que tornam o DevOps algo vivo dentro das empresas.

O evento contou com apoio do INAITEC (que sediou o encontro) e patrocínio educacional da FIAP, reunindo profissionais, estudantes e entusiastas de tecnologia da região metropolitana de Florianópolis.

📍 Local: INAITEC – Pedra Branca, Palhoça – SC

📅 Data: 02 de outubro de 2025

🕖 Horário: A partir das 19h

Minha palestra

Antes de Estudar Ferramentas, Entenda a Cultura DevOps

Na minha sessão, falei sobre o que vem antes das ferramentas, a mentalidade e os valores que sustentam o verdadeiro DevOps.

Abordei temas como colaboração, aprendizado contínuo e o impacto cultural que transforma a forma como entregamos software no dia a dia.

Toquei em pontos como:

• O que realmente significa Cultura DevOps
• Por que a transformação começa nas pessoas, não nas ferramentas
• Exemplos reais de times que aplicam princípios DevOps com propósito
• Como a empatia e a colaboração se traduzem em entregas melhores
• Práticas para criar times autônomos e de alta performance

Programação da Noite

A 8ª edição da whiteStone_dev foi marcada por talks inspiradoras e uma energia de comunidade contagiante:

• 19:00 — Abertura e Check-in

• 19:10 — Rafael Ferreira — Antes de Estudar Ferramentas, Entenda a Cultura DevOps

• 20:00 — Julio Santos — Da Entropia ao Equilíbrio: Lições de Arquitetura de Software Sustentável

• 21:00 — Eduardo P. Gutkoski - AppSync Event API – AWS User Group Floripa

• 21:50 — Networking & Encerramento

Galeria de Fotos

Encontro com a Comunidade

Além das palestras, o evento foi uma grande oportunidade pra reencontrar amigos, conhecer novas pessoas e fortalecer os laços entre comunidades, especialmente com a presença do AWS User Group Floripa e parceiros locais.

Conclusão

Participar do whiteStone_dev 8ª Edição | Cultura DevOps foi uma experiência incrível.

Ver a comunidade reunida para discutir cultura, arquitetura e colaboração é o que mantém viva a essência do movimento DevOps.

Agradecimento especial à organização do whiteStone_dev, aos palestrante Julio Santos e equipe do AWS User Group Floripa, e a todos que participaram dessa noite memorável.

> DevOps não é sobre ferramentas, é sobre pessoas, cultura e propósito.

• Slides da Apresentação: Antes de Estudar Ferramentas, Entenda a Cultura DevOps

Um evento incrível que serviu como prévia do maior encontro de especialistas Microsoft do Brasil: o MVPConf.

O evento

Curitiba foi o palco da última edição do Esquenta MVPConf, reunindo profissionais, estudantes e entusiastas de tecnologia para um dia inteiro de palestras técnicas de altíssimo nível.

A cidade, reconhecida como uma das mais inteligentes e inovadoras do Brasil, recebeu especialistas premiados com o título de Microsoft MVP (Most Valuable Professional), compartilhando conhecimento e experiências reais do dia a dia.

📍 Local: Auditório Principal da UTFPR

📅 Data: 27 de setembro de 2025

🕘 Horário: 09h00 às 18h00

Minha palestra

DevOps Além da Hype: Pessoas, Cultura e Prática

Durante a minha sessão, falei sobre o que realmente sustenta o DevOps além das ferramentas, as pessoas, a cultura e as práticas reais.

Abordei como o movimento nasceu, como evoluiu, e por que as empresas que prosperam em DevOps entendem que colaboração e empatia vêm antes do código.

Toquei em pontos como:

• O nascimento do movimento DevOps e o Agile Infrastructure
• Os Three Ways, do The Phoenix Project
• As 4 métricas do livro Accelerate
• O framework CALMS e como aplicá-lo na prática
• Como criar um ambiente onde a cultura habilita a entrega contínua

Programação do evento

O dia foi repleto de palestras inspiradoras e muito conteúdo técnico:

• 09:00 - 09:10 — Abertura do evento
• 09:10 - 09:50 — Keynote - Task TI
• 10:00 - 10:50 — Felipe Augusto — Testes de unidade e integração em .NET com xUnit, Bogus, ReportGenerator e TestContainers

• 11:00 - 11:50 — Rafael Ferreira — DevOps além da hype: Pessoas, cultura e prática

• 12:00 - 14:00 — Almoço e Networking

• 14:00 - 14:50 — Bruno Brito — Do 1º usuário ao 1 milhão: Como escalar sua aplicação

• 15:00 - 15:50 — Carlos dos Santos — Criando e publicando uma aplicação com Containers e Azure

• 16:00 - 16:50 — Walter Coan — Monitoramento de equipamentos industriais com Azure IoT Operations e OPC UA

• 17:00 - 17:50 — Johnson — Proteção na era da IA com o Microsoft Security Copilot

Estrutura e Experiência

O evento contou com uma estrutura impecável, com estandes, recepção organizada e um público engajado.

Além das palestras, rolou aquele networking maroto nos intervalos, com troca de ideias e reencontros com amigos da comunidade.

Poder compartilhar com a comunidade aprendizados sobre Cultura DevOps em um evento com tantos profissionais talentosos reforça o propósito de continuar disseminando conhecimento.

Agradeço à organização, aos palestrantes, aos patrocinadores e a todos que fizeram parte desse dia memorável.

• Slides da Apresentação: DevOps Além da Hype: Pessoas, Cultura e Prática

Se você está querendo se aventurar no mundo das redes em nuvem, a certificação AZ-700 é o passaporte para provar que domina como projetar e implementar soluções de rede dentro do Microsoft Azure.

Depois de concluir o curso AZ-700 - Projetar e Implementar Soluções de Rede do Azure do Higor Barbosa, compilei aqui os principais aprendizados e boas práticas que realmente fazem diferença, tanto para quem administra ambientes corporativos quanto para quem busca aprofundar o domínio técnico em Azure Networking.

1. Planejamento de Endereçamento IP

Tudo começa com as redes.

Planeje suas VNets e subnets com cuidado: o Azure reserva sempre cinco endereços por subnet (do primeiro ao quarto e o último).

2. Resolução de Nomes (DNS Público e Privado)

• Azure DNS: gerencia domínios públicos com redundância global e desempenho via anycast.
• Azure Private DNS: resolve nomes internamente entre VNets privadas, integrando automaticamente registros das VMs.
• Private DNS Resolver: resolve consultas entre ambientes on-premises e Azure sem precisar expor tráfego para a internet.

3. Conectividade e Roteamento de VNets

1. VNet Peering – comunicação direta, rápida e segura.

2. VPN Gateway – conecta VNets entre regiões ou com ambiente local.

3. UDR (User Defined Routes) – define rotas personalizadas entre sub-redes.

Organize o ambiente para que o hub concentre segurança e conectividade. As spokes hospedam workloads isolados, conectados via peering ou WAN Virtual.

4. NAT Gateway

Quando suas VMs precisam de saída de internet com IP fixo, use o Azure NAT Gateway.

Ele evita exaustão de portas SNAT e garante previsibilidade em cenários de egress controlado.

5. Monitoramento e Diagnóstico

• Connection Monitor
• IP Flow Verify
• Packet Capture
• NSG Flow Logs

Combine com Azure Monitor e Log Analytics para construir uma visão completa da rede, detectar gargalos e ativar alertas automáticos.

6. VPN Site-to-Site e Ponto-a-Site

• Conecta datacenters e VNets.
• Use gateways route-based e é possível, configuração ativa-ativa com BGP.

• Conexões individuais de dispositivos.
• Suporte a SSTP, IKEv2 e OpenVPN.
• Pode autenticar via certificados, RADIUS ou Entra ID (AAD).

Essas opções permitem criar conectividade híbrida estável e segura entre diferentes ambientes.

7. ExpressRoute e WAN Virtual

Quando o assunto é conectividade privada e de alta performance:

• ExpressRoute conecta seu ambiente local diretamente ao backbone do Azure.
• Azure Virtual WAN centraliza e automatiza o roteamento global, integrando S2S, P2S, ER e VNets.

8. Balanceadores de Carga e Entrega de Aplicações

Camada 4 → Azure Load Balancer

Camada 7 → Application Gateway (AppGW)

Gerenciamento Global → Traffic Manager e Azure Front Door

Cada serviço tem seu lugar:

• LB: ideal para backend interno.
• AppGW: faz roteamento baseado em URL e HTTPS com WAF embutido.
• Front Door: CDN global + balanceamento inteligente entre regiões.
• Traffic Manager: DNS-based routing (latência, prioridade, geográfico).

9. Acesso Privado a Serviços PaaS

Duas opções dominam:

1. Service Endpoints: protegem o acesso a serviços PaaS via backbone, mas mantêm o recurso com IP público.

2. Private Endpoints: criam uma interface privada na sua VNet, isolando o tráfego totalmente.

Hoje, o padrão corporativo é sempre Private Endpoint, mais seguro, mais fácil de auditar e compatível com políticas de compliance.

10. Segurança de Rede no Azure

Os blocos de segurança que mais fazem diferença no dia a dia:

11. Conclusão

Entender endereçamento, conectividade, segurança e entrega de aplicações te coloca em outro nível, não só tecnicamente, mas na forma de pensar na infraestrutura com sua resiliência e escalabilidade de rede.

---

Referências oficiais

• Microsoft Learn — AZ-700: Design and Implement Azure Network Solutions
• Microsoft Docs — Virtual Network Overview
• Azure Architecture Center — Hub-and-Spoke Network Topology

• 2025-06 - AZ-700 - Projetar e Implementar Soluções de Rede do Azure

No dia 17 de setembro de 2025, participei como palestrante da Trilha de Arquitetura Cloud no TDC São Paulo, um dos maiores eventos de tecnologia do Brasil, realizado no ProMagno, em São Paulo - SP.

Foram 8 horas de muito conteúdo, inovação, networking e tecnologia reunindo profissionais, comunidades e empresas de todo o país.

Minha palestra

GreenOps na Cloud: Arquitetando um Futuro Sustentável

Na minha sessão, falei sobre como adotar práticas sustentáveis na nuvem pode gerar impacto positivo tanto para o planeta quanto para o negócio.

Exploramos estratégias que combinam FinOps, automação e arquitetura verde, mostrando que é possível reduzir custos e emissões sem comprometer performance.

Toquei em temas como:

• O papel do GreenOps na governança de nuvem corporativa
• Como usar métricas ambientais (carbon footprint) dentro do Azure
• Boas práticas de FinOps + Cloud Efficiency
• A importância de arquiteturas sustentáveis e automatizadas
• Casos reais e aprendizados práticos em ambientes globais

Programação da Trilha Arquitetura Cloud

O dia foi intenso e repleto de conteúdo técnico de altíssimo nível, participi de algumas palestras:

• Thiago Silva (Bosch) — Construindo o futuro na nuvem: Benefícios da Redundância e paz de espírito com Recuperação de Desastres

• Renan Oliveira (CTO - Hypetech) e André Bassi (Platform Engineer - Hypetech) — Arquitetura Multi-cloud na Prática: Escalabilidade Sem Fronteiras

• Marcello Ozzetti (Accenture) e Victor Muniz (Accenture) — DevOps como Serviço: Templates Padronizados para Multi-Frameworks e Multi-Cloud

• Camila Macedo (Red Hat) — Descomplicando o Operator Pattern: estenda a API do Kubernetes

Encontro com os Alura Stars

Durante o evento, também rolou um momento especial com o grupo dos Alura Stars que estavam presentes no TDC.

Foi ótimo encontrar tanta gente que compartilha a mesma paixão por tecnologia, aprendizado e comunidade.

Espaço de Fotos e Networking

O hall de entrada do ProMagno estava com uma estrutura incrível, e o evento ainda contou com um espaço dedicado para fotos profissionais.

Com um fotógrafo no local, os participantes puderam atualizar a foto do perfil do LinkedIn e registrar o momento com qualidade.

Galeria de Fotos

Certificado de Participação

Participar do TDC São Paulo foi uma experiência incrível, energia contagiante, público engajado e discussões profundas sobre o futuro da arquitetura em nuvem e sustentabilidade digital.

> Pense grande, pense verde.

• Slides da Apresentação: GreenOps na Cloud: Arquitetando um Futuro Sustentável

No dia 03 de setembro de 2025, participei como palestrante no Encontro das comunidades AWS User Group Floripa + DevOps Floripa, realizado no Auditório da ACATE - Passeio Primavera (SC-401).

Um evento colaborativo que uniu duas comunidades vibrantes para discutir computação em nuvem, cultura DevOps, inovação e muito networking.

Minha palestra

Explorando a Cultura DevOps: Por que tanto se fala de cultura por trás da entrega contínua?

Na minha sessão, trouxe reflexões sobre como a cultura é o principal motor por trás das práticas DevOps.

Mais do que ferramentas, DevOps é sobre mentalidade, colaboração e propósito.

Toquei em pontos como:

• Por que falar de cultura importa tanto quanto falar de tecnologia
• O impacto da empatia e colaboração em times distribuídos
• Como práticas reais transformam entregas contínuas em valor para o negócio
• Casos práticos de pipelines e times que adotaram a mudança cultural antes da técnica

Programação do evento'

O encontro teve uma programação muito rica e diversa:

• 18h45 - 19h20 — Recepção + Introdução às comunidades

• 19h20 - 19h30 — Apresentação da empresa Zallpy (patrocinadora do evento)

• 19h30 - 20h — Do Qubit à Aritmética: Como calcular a + b usando computadores quânticos? — Ruan Luiz (Grupo de Computação Quântica da UFSC)

• 20h - 20h30 — Coffee + Networking ☕

• 20h45 - 21h15 — Explorando a Cultura DevOps — Rafael Ferreira (Senior Platform Engineer)

• 21h15 - 21h45 — Logs não são o suficiente — Marcelo Scheidt (Principal Engineer, e-Hub da Zallpy)

• 21h45 — Encerramento

Destaques da minha sessão

• Cultura DevOps é sobre pessoas e interações
• Ferramentas só têm valor quando aplicadas com propósito claro
• A entrega contínua depende de confiança e alinhamento cultural
• Exemplos práticos de mudanças que deram certo (e outras que ensinaram muito)

Galeria de Fotos

Conclusão

O encontro foi uma irado cheio de aprendizado e conexão com as comunidade AWS User Group Floripa, DevOps Floripa aos patrocinadores e todos que participaram dessa noite.

> DevOps é sobre cultura, não sobre ferramentas.

• Slides da Apresentação: Explorando a cultura DevOps: Por que tanto se fala de cultura por trás da entrega contínua?

No dia 30 de agosto de 2025, tive o prazer de participar do DevOpsDays Curitiba, um dos principais eventos da comunidade DevOps no Brasil. O evento aconteceu no Centro Politécnico da UFPR, reunindo profissionais apaixonados por tecnologia, inovação e cultura DevOps.

Minha palestra

DevOps Além da Hype: Pessoas, Cultura e Prática

Falar sobre DevOps vai muito além de falar sobre ferramentas. Na minha sessão, foquei na transformação cultural, no papel das pessoas e em práticas reais que impactam a entrega de software de forma mais rápida, contínua e confiável.

Toquei em pontos como:

• O nascimento do movimento DevOps, desde o Agile Infrastructure em 2008
• Os Three Ways, do The Phoenix Project
• As 4 métricas do livro Accelerate
• A importância das topologias de times (Team Topologies)
• O framework CALMS e os pilares para sustentar o DevOps na prática

Programação do evento

O evento contou com nomes de peso e temas de altíssimo nível, como:

• Vinicius Moraes — Usando Infraestrutura como Código para Criar um Sistema de Detecção de Intrusões

• Ederson do Nascimento — SRE na Prática

• Bruno Lopes — Otimizando Clusters Kubernetes com Karpenter

• João Brito — 15 Dicas em 30 Minutos

• Lucas Ribeiro da Mata — MLOps na prática

• Gabriel Bazzotti — Policy as Code e Segurança em Clusters!

• Igor Estevan Jasinski — Machine Learning e Séries Temporais com Prometheus

Destaques da minha sessão

• 🧠 Cultura DevOps ≠ Ferramentas
• 🛠️ Integração de ferramentas com propósito (CI/CD, IAC, observabilidade)
• 🚀 Transformação real de pipelines com Kubernetes
• 📊 Métricas de sucesso para times de alta performance
• 👥 Colaboração e empatia como base de qualquer transformação

Galeria de Fotos

Conclusão

Agradeço à organização, aos palestrantes, e a toda galera que colou na minha sessão.

> DevOps não é um destino. É uma jornada contínua.

• Slides da Apresentação: DevOps Além da Hype: Pessoas, Cultura e Prática

No último dia 16 de agosto de 2025, rolou em Florianópolis o HNWD (Hacking na Web Day), um dos eventos mais autênticos e relevantes da cena de hacking e segurança cibernética no Brasil. Essa edição aconteceu no Castelmar Hotel, reunindo especialistas, entusiastas e comunidades apaixonadas por segurança da informação.

O HNWD nasceu como um encontro feito da comunidade para a comunidade, e já virou referência nacional. Em 2025, a tour passou por seis cidades brasileiras, trazendo conteúdo de altíssimo nível, com palestras práticas, CTFs presenciais, além de muito networking e trocas intensas de experiência.

Minha palestra: blindagem DevOps em ambientes cloud

Tive a honra de palestrar no Auditório 2, ao meio-dia, com o tema:

Resumo da Talk

Na palestra Cloud Moderna ANTI Ataque: Blindagem DevOps Essencial, apresentei duas frentes principais de segurança:

Parte 1 — Defesa em Camadas

Mostrei como proteger ambientes cloud com uma arquitetura em múltiplas camadas, utilizando os principais recursos nativos das clouds:

• Identidade & Acesso: IAM, RBAC, Zero Trust, MFA.
• Perímetro: WAF, CDN, VPN, Bastion, proteção DDoS.
• Rede & Segmentação: VNet/SG/NACL, isolamento de workloads.
• Compute & Containers: Defender, Inspector, OS Config, AKS/EKS/GKE.
• Aplicações: API Management, App Services, Gateways, Key Vault/Secrets.
• Dados: Criptografia, KMS, controle de chaves.
• Monitoramento & Resposta: SIEM (Sentinel, Security Hub, Chronicle), logs centralizados, automação de incidentes.

Parte 2 — Os 4Cs da Cloud Native Security

Conectando com o modelo da CNCF, mostrei como aplicar defesa de forma Cloud Native:

• Cloud → Governança, Policy, Defender for Cloud, Config, SCC.
• Cluster → Segurança em Kubernetes (RBAC, hardening, runtime visibility).
• Container → Scan de imagens, assinatura, execução não-root, OPA/Kyverno.
• Código → Shift Left, SAST/DAST, SCA, secret scanning, IaC seguro.

O evento foi cheio de aprendizado. Tivemos palestras sobre IA adversarial, XSS avançado, Kubernetes hacking, deepfakes, AWS hardening e muito mais. Além disso, o espaço de comunidades e patrocinadores trouxe aquela vibe que só a cena de segurança brasileira tem: colaboração acima da competição.

Quero agradecer a todos que participaram da minha palestra e trocaram ideias comigo durante o evento. Foi uma experiência incrível poder compartilhar práticas de blindagem em nuvem com tanta gente interessada em levar segurança a sério no dia a dia.

E claro: parabéns à organização do HNWD e a todos os apoiadores que tornam esse evento possível. É nítido que o hacking no Brasil está cada vez mais forte, maduro e conectado.

Nos vemos na próxima!

• Slides da Apresentação: Cloud Moderna ANTI Ataque: blindagem DevOps que você PRECISA conhecer

Introdução

Fala galera! Tudo bom? Recentemente passei no exame HashiCorp Certified: Terraform Associate (003) e quero compartilhar com vocês um pouco sobre como foi a experiência, desde a estrutura da prova até as minhas dicas de estudo. Se você é um profissional de DevOps querendo se certificar em Terraform, este artigo é pra você!

Para quem não conhece, essa certificação Terraform Associate basicamente valida seus conhecimentos fundamentais sobre o Terraform e conceitos de Infraestrutura como Código (IaC).

Sobre o Exame Terraform Associate

O Terraform Associate (versão 003) é uma certificação de nível "fundamental" da HashiCorp voltada para Terraform. É recomendada para engenheiros de infraestrutura/DevOps que atuam em operações, TI ou desenvolvimento e já conhecem os conceitos básicos do Terraform.

• Online, com supervisão (proctored)
• 57 questões de múltipla escolha
• Tempo: 1 hora (60 minutos)
• Idioma: Inglês
• Custo: cerca de US$70
• Validade: 2 anos

Tópicos Principais do Exame

• Infraestrutura como Código (IaC): Saber o que é IaC e por que é vantajosa, destacando a consistência, automação e versionamento de infraestrutura.
• Exercício prático: 1-UnderstandInfrastructureasCode(IaC)concepts-BuildingVMconcepts-BuildingVM)

• Propósito do Terraform em relação a outras ferramentas: Entender os benefícios de ser multi-cloud e agnóstico ao provedor e o papel do arquivo de estado.
• Exercício prático: 2-UnderstandTerraformbasics
• Fundamentos do Terraform: Dominar sintaxe HCL, blocos de recursos e dados, providers, variáveis e outputs.
• Uso do Terraform além do fluxo básico: Conhecer comandos como terraform import para importar recursos, terraform state para inspecionar o estado e como habilitar logs de depuração.
• Módulos: Saber encontrar módulos no registro público, usar módulos locais e remotos, versionar e entender o escopo de variáveis.
• Exercício prático: 5-InteractwithTerraformmodules1
• Exercício prático: 5-InteractwithTerraformmodules2
• Fluxo de trabalho: Gravar a sequência write → plan → apply (CAI NA PROVA) e também validate, fmt e destroy.
• Estado: Entender backends locais e remotos, locking de estado, drifts e comandos como terraform state mv, bem como segredos no tfstate.
• Ler e modificar configurações: Utilizar variáveis e outputs corretamente, proteger segredos, trabalhar com tipos complexos e funções HCL.
• Exercício prático: 8-Read,generate,ModifyConfiguration-Collections
• Exercício prático: 8-Read,generate,ModifyConfiguration-Functions
• Exercício prático: 8-Read,generate,ModifyConfiguration-Secrets
• Conhecer o Terraform Cloud/Enterprise: Ter noções das funcionalidades da oferta SaaS (state remoto, integração com VCS, políticas e colaboração).
• Workspaces: Embora não apareça explicitamente no blueprint, várias questões NA PROVA abordam Workspaces. Saiba criar, listar, selecionar e remover workspaces e as diferenças em relação a usar backends distintos.

Minha Preparação e Materiais de Estudo

• Curso TFTEC: 100% prático, com labs e simulado final. Acesse aqui
• Labs próprios: Pratiquei com cloud Azure.
• GitHub pessoal: Criei um repositório com todos os projetos que fiz nos labs.
• Curso Udemy – Terraform Associate Practice Exam (em inglês): Excelente para testar conhecimentos com simulado realista. Acesse aqui

Dicas para o Exame

• Domine IaC na teoria: O exame cobra definições e vantagens da IaC. Saiba explicar por que versionar infraestrutura como código aumenta a confiabilidade e como se diferencia de ferramentas de gerenciamento de configuração.
• Pratique todos os comandos: Não fique só no trio init/plan/apply. Experimente fmt, import, state list/show/mv, workspace, login/logout e assim por diante.
• Estude o arquivo de estado: Saiba que o tfstate é salvo localmente por padrão e pode ser movido para backends remotos. Entenda como funciona o locking, como lidar com drifts e quando usar terraform state rm.
• Módulos são fundamentais: Crie e utilize módulos para entender entradas e saídas, escopo de variáveis, versionamento e fontes (local, registro ou repositório Git).
• Aprenda sobre Workspaces: Domine os comandos workspace new/list/select/show e compreenda que cada workspace tem seu próprio arquivo de estado.
• Conheça o Terraform Cloud: Mesmo que nunca tenha usado a versão SaaS, leia sobre suas vantagens: state remoto com bloqueio automático, integrações com Git, execução em equipe e políticas de governança.
• Gerencie o tempo na prova: Sessenta minutos para 57 perguntas dá cerca de um minuto por questão. Marque a melhor opção e volte depois se necessário.
• Mantenha a calma: Revise as opções com atenção, pois muitas vezes a diferença está em uma palavra (e em inglês). Antes de submeter, revise tudo.
• Transfira o aprendizado para o trabalho: Refatore códigos reais com boas práticas. Aplicar o conteúdo no dia a dia reforça o aprendizado.

Conclusão

Fazer a certificação Terraform Associate foi uma experiência valiosa. Além de receber o badge, consolidei conceitos essenciais de IaC e do Terraform que aplico diariamente. A prova reflete demandas do mundo real: ao estudar para ela, você aprimora seu domínio da ferramenta e se prepara melhor para projetos de nuvem e automação.

Recomendo a certificação para quem já utiliza Terraform. Ela formaliza o conhecimento e pode abrir portas, muitas vagas pedem familiaridade com Terraform, e ter a certificação ajuda a comprovar essa habilidade. Para quem pretende avançar, a HashiCorp oferece também o nível Professional, então a Associate pode ser só o começo.

• HashiCorp Terraform Associate

Introdução

O Azure User Groups Brasil nasceu para conectar comunidades regionais, incentivar novas branches e ampliar o acesso a conteúdo de qualidade sobre Microsoft Azure e tecnologias cloud em todo o país.

Além de fortalecer a troca entre organizadores, palestrantes e participantes, a iniciativa cria um ponto de encontro nacional para quem quer aprender, compartilhar experiências reais e evoluir na carreira.

Se você curte comunidade, cloud e colaboração, esse grupo é para você.

Azure User Groups Brasil

• 🌐 Site oficial
• 🔗 Linktree oficial
• 🗂️ Branches
• 📅 Eventos
• 🧭 Nova Branch
• 👥 Grupo WhatsApp
• ▶️ YouTube
• 💼 LinkedIn
• 🤝 Meetup
• 📸 Instagram
• 🔗 Acessar o Linktree do Azure User Groups Brasil

Nossas Branches

Comunidades regionais ativas em todo o Brasil, organizando meetups, workshops e eventos técnicos sobre Azure.

Quer levar o Azure User Groups Brasil para a sua cidade? A comunidade mantém uma página dedicada para abertura de novas branches, reunindo pessoas que queiram organizar encontros locais e expandir o alcance da iniciativa.

• 🚀 Quero abrir uma branch
• ℹ️ Saiba mais sobre a comunidade

Atuação local: Azure User Group Florianópolis

Além da frente nacional, também faço parte do Azure User Group Florianópolis, branch local da comunidade em Santa Catarina.

O grupo conecta desenvolvedores, arquitetos e profissionais de TI interessados em tecnologias Microsoft Azure, promovendo meetups, workshops e eventos para fortalecer o ecossistema tech da Ilha da Magia.

• 📍 Página da branch Florianópolis

Como participar

Se você quer acompanhar eventos, conhecer a branch mais próxima ou entrar em contato com a organização nacional, estes são os principais canais:

• 👥 Entrar no grupo do WhatsApp

O Azure User Groups Brasil consolida um movimento nacional de comunidades locais sobre Azure. No meu caso, essa atuação acontece em duas frentes complementares: no nível nacional, apoiando a expansão da comunidade, e no nível local, ajudando a fortalecer o Azure User Group Florianópolis.

Se fizer sentido para você, participe da branch mais próxima ou ajude a abrir a próxima.

No último dia 26 de abril de 2025, Blumenau foi palco de um grande evento tech do sul do Brasil: o Esquenta MVP Conf, uma amostra da energia e do conteúdo de alto nível que teremos na próxima edição do MVP Conf em São Paulo. A FURB (Fundação Universidade Regional de Blumenau) recebeu MVPs da Microsoft e rolou muita troca de ideia.

Minha palestra

Os 6Rs que Você Precisa Conhecer para Migrar para a Cloud

Falar sobre migração pode parecer batido, mas muita gente ainda se perde na hora de escolher a estratégia certa. Na minha sessão eu trouxe o framework dos 6Rs (Rehost, Replatform, Rearchitect, Rebuild, Replace e Retire), mostrei quando usar cada um e acrescentei algumas piadas para manter a sanidade da galera.

Palestrantes e temas

• Henrique Mauri — Desenvolvendo aplicações modernas com .NET e Azure
• Vinicius Deschamps — “Olha mãe, sem usar senhas”: como utilizar Managed Identity no Azure
• Rodrigo Dornel — Análise de Dados com Power BI & Copilot

• Walter Coan — Evolução da plataforma Azure IoT: do IoT Hub até o IoT Operations

• Claudio Rapôso — Revolucione Suas Aplicações: o segredo contra falhas em FaaS com JavaScript que ninguém te contou!

• Felipe Augusto — Event-Driven no Azure: como utilizar o Azure Service Bus para escalabilidade e resiliência

• Rafael Ferreira — Os 6Rs que Você Precisa Conhecer para Migrar para a Cloud; o sétimo R é de Rivotril?!

• Johnson de Souza — Preparar a segurança e a conformidade para dar suporte ao Microsoft 365 Copilot
• Bruno Leires — O futuro da administração do 365 com Copilot: o que esperar?

Destaques da Palestra

• 🚀 Cloud Foundation: por que não adianta colocar o telhado antes da base
• 🧱 Landing Zones: seu ponto de partida estruturado
• 🛠️ Ferramentas como Azure Migrate e Database Migration Service
• 💰 FinOps e GreenOps: migrar sem estourar o orçamento

Galeria de Fotos

Durante o Global Azure 2025 – Edição Azure Floripa, tive o prazer de abrir o evento ao lado do grande amigo e profissional Vinicius Deschamps com uma palestra que foge um pouco do tradicional técnico, mas que é um divisor de águas "Trabalhando para o Exterior: Realidade, Desafios e Oportunidades".

Falamos sobre como é atuar em uma empresa internacional, os bastidores que, os impactos na vida pessoal e profissional, e claro, compartilhamos nossas experiências reais no mercado global.

🎙️ Sobre a Palestra

💬 O que abordamos?

• Diferenças culturais e adaptação no trabalho remoto com times globais
• Estratégias para se destacar em entrevistas internacionais
• Dicas montar um perfil atrativo para o mercado global
• Dicas práticas de quem vive isso no dia a dia
• E o mais importante: falamos a real!

📸 Momentos que Valem o Registro

Confira algumas fotos da nossa palestra:

🧾 Links de Indicação Úteis pra Quem Quer Trabalhar pra Fora

Se você está começando sua jornada internacional, aqui vão dois serviços que uso pessoalmente e recomendo:

💼 Abrir ou manter seu CNPJ com a Contabilizei

Simplifique sua vida como PJ, sem dor de cabeça com impostos e obrigações contábeis:

👉 Abra sua conta na Contabilizei com meu link de indicação

💸 Receber em dólar com ótimas taxas usando a TechFX

Pra quem recebe moeda de fora (dólar, euro, libra...) direto na conta PJ, TechFX ajuda a economizar nas taxas e ganhar agilidade:

👉 Crie sua conta TechFX com meu link e comece a receber melhor

💙 Por que falamos disso?

Porque a comunidade técnica precisa falar sobre carreira, escolhas conscientes e qualidade de vida, não só sobre código. E se pudermos ajudar alguém a conquistar uma oportunidade internacional com mais preparo e menos ilusões, já valeu a pena!

#GlobalAzure #AzureFloripa #TrabalhoInternacional #CarreiraTI #ComunidadeTech #Azure

Mais um ano, mais uma edição do Global Azure 2025 – Edição Azure Floripa! E sim, o Azure Floripa colou junto mais uma vez pra fazer história com a comunidade técnica brasileira. Foram 2 dias intensos, com conteúdo de qualidade, e muito aprendizado!

Se você perdeu, relaxa, a gente fez esse post cheio de links pra você maratonar as talks.

Organizadores

• Rafael Martin Alves Ferreira
• Vinicius Deschamps

Palestras e Sessões em Destaque

Fazendo Backup de VMs no Azure Utilizando o Azure Backup

Migrando sua infraestrutura para Nuvem - Projeto Real

BCDR - Business Continuity and Disaster Recovery

Desenvolvendo Agentes Inteligentes com Semantic Kernel e LLM

Azure App Service e Docker: Trabalhando com Aplicações Contêinerizadas

Azure IoT Operations

Arquitetando Agentics e Aplicações Multiagentes

Your Gateway to the World of Artificial Intelligence

Do Código à Nuvem: IaC e Conteinerização no Ecossistema Azure

Facilite sua vida com Azure Blobs

Impulsione seus estudos com a Cloud: Explorando o poder do Azure para aprender na prática!

Bora se conectar?

Se você quer participar, contribuir ou só ficar por dentro dos próximos eventos da comunidade Azure Floripa, se liga aqui:

• WhatsApp
• YouTube
• Visite nosso site

Saiba mais: Global Azure

No dia 10 de maio de 2025, rolou a edição presencial do Global Azure 2025 – Edição Azure Floripa em Florianópolis, e que evento, meus amigos! Recebemos a comunidade na sede da Neoway, com uma programação intensa, conteúdo técnico de qualidade e aquele clima de parceria e aprendizado que só quem vive comunidade entende.

Com palestras inspiradoras, demos na prática e muito networking com profissionais incríveis, essa edição mostrou a força da comunidade Azure em Santa Catarina.

📍 Onde foi?

🗓️ Programação Completa

📸 Quer ver como foi?

Se liga nas fotos e reveja os melhores momentos:

👏 Agradecimentos

Um evento como esse não acontece sozinho. Nosso muito obrigado aos palestrantes, patrocinadores, parceiros.

Em especial, agradecemos à Neoway, que gentilmente cedeu o espaço para o evento, e à Softensity, que apoiou com um coffee break.

E claro, nosso reconhecimento à comunidade, que marcou presença em peso e mostrou, mais uma vez, que conhecimento se constrói junto.

💙 Participe da Comunidade Azure Floripa!

Não deixe a energia acabar aqui. Cola com a gente nas redes, participe dos meetups e fique por dentro dos próximos eventos!

• WhatsApp
• YouTube
• Visite nosso site

---

#GlobalAzure #AzureFloripa #MicrosoftAzure #EventoPresencial #ComunidadeTech #AzureBrasil

O SQL Saturday é conhecido mundialmente por ser um evento referência para a comunidade de dados, e esta edição em Joinville não deixou nada a desejar. Contou com uma programação rica, oferecendo palestras simultâneas com conteúdos altamente relevantes e ministradas por grandes nomes do mercado brasileiro de tecnologia.

Sobre Minha Palestra

Na minha palestra intitulada "Pipelines com Azure DevOps: Automatizando o Provisionamento Seguro da sua Infraestrutura na Nuvem", abordei pontos essenciais para implementar pipelines eficientes utilizando Azure DevOps, garantindo agilidade, segurança e qualidade na entrega da infraestrutura.

Conversamos bastante sobre como DevOps deixou de ser uma simples tendência e se tornou uma cultura fundamental nas empresas modernas. Também mostrei na prática o funcionamento das pipelines de Integração Contínua e Entrega Contínua (CI/CD) e como essa automação facilita significativamente o processo de deploy em ambientes cloud, utilizando ferramentas como Terraform para provisionamento de infraestrutura.

Alguns tópicos detalhados que abordei durante a palestra foram:

• Fundamentos e Cultura DevOps: Expliquei como o DevOps está transformando as empresas, melhorando significativamente a comunicação, colaboração e produtividade dos times de desenvolvimento e operações.

• Azure DevOps Overview: Discuti brevemente sobre a história e as funcionalidades principais do Azure DevOps, destacando as diferenças e vantagens entre Azure DevOps Services (SaaS) e Azure DevOps Server (IaaS).

• Estruturando Pipelines CI/CD: Apresentei passo a passo a criação e execução de pipelines usando Azure DevOps, mostrando como é possível automatizar testes, builds e deploys, garantindo entregas rápidas e seguras.

• Casos Práticos: Compartilhei exemplos reais e cenários práticos em que utilizei o Azure DevOps com Terraform e Bicep, evidenciando a importância da automação para lidar com infraestruturas complexas.

Networking e Troca de Experiências

Um grande diferencial de eventos é o networking, e SQL Saturday Joinville não foi diferente.

Quero deixar aqui um agradecimento especial ao Comunidado e a toda equipe organizadora que tornou esse evento possível, proporcionando uma experiência incrível para todos os envolvidos.

Até o próximo evento!

---

Como parte do meu aprendizado e desejo de retribuir à comunidade, decidi participar do projeto de tradução da documentação do Kubernetes para o português brasileiro. Este esforço é importante para tornar a tecnologia mais acessível ao público da língua portuguesa.

Contribuições Recentes

1. Windows no Kubernetes

• Issue:
• Pull Request:
• Página traduzida:

2. Guia para executar contêineres do Windows no Kubernetes

• Issue:
• Pull Request:
• Página traduzida:

3. Containers Windows no Kubernetes

• Issue:
• Pull Request:
• Página traduzida:

Importância da Tradução

A tradução da documentação do Kubernetes para o português brasileiro é fundamental por várias razões:

1. Acessibilidade: Permite que desenvolvedores e profissionais de TI brasileiros acessem informações cruciais em sua língua nativa.

2. Adoção: Facilita a adoção do Kubernetes por empresas e organizações no Brasil.

3. Comunidade: Fortalece a comunidade brasileira de Kubernetes, incentivando mais pessoas a contribuírem e participarem.

4. Educação: Auxilia no aprendizado e na formação de novos profissionais especializados em Kubernetes.

Como Contribuir

Se você também deseja contribuir para a tradução do Kubernetes, aqui estão algumas etapas para começar:

1. Familiarize-se com o processo de contribuição do Kubernetes.

2. Junte-se ao canal Slack #kubernetes-docs-pt da comunidade Kubernetes.

3. Verifique as páginas pendentes de tradução.

4. Escolha uma página para traduzir e crie uma issue no repositório kubernetes/website.

5. Faça um fork do repositório, crie uma branch e realize a tradução.

6. Submeta um Pull Request com sua tradução para revisão.

Contribuir para a tradução do Kubernetes é uma excelente maneira de aprender mais sobre a tecnologia enquanto ajuda a comunidade. Junte-se a nós neste esforço importante!

O Azure Policy é um recurso da Microsoft Azure que ajuda organizações a implementar governança e compliance de forma automatizada e em larga escala. Ele garante que os recursos na nuvem estejam em conformidade com as diretrizes corporativas, padrões de segurança e requisitos regulatórios.

Imagine que, toda vez que você vê uma placa, seja no shopping ou no trânsito, ela funciona como uma policy (política). A placa tem a função de te alertar sobre regras e comportamentos esperados. Caso você não siga essas orientações e um segurança perceba a irregularidade, ele pode te abordar, corrigir sua ação ou até mesmo te impedir de continuar no local.

O que o Azure Policy Faz?

O Azure Policy avalia continuamente os recursos e as ações no Azure com base em definições de política. Essas definições, escritas em formato JSON, descrevem regras que determinam se os recursos estão ou não em conformidade com os padrões estabelecidos.

Principais Benefícios e Casos de Uso:

• Conformidade em Larga Escala: Avalia recursos e toma ações automáticas para garantir conformidade.
• Automação e Consistência: Implementa políticas de maneira consistente em todas as suas assinaturas e grupos de recursos.
• Segurança e Gerenciamento: Reforça políticas de segurança, como restringir SKUs de VMs, impor criptografia e definir regiões específicas para implantação de recursos.
• Conformidade Regulatória: Auxilia no cumprimento de normas como GDPR, ISO 27001 e SOC 2.

Como o Azure Policy Funciona?

O Azure Policy funciona criando e aplicando definições de política e iniciativas para controlar como os recursos são implantados e gerenciados. Esses componentes incluem:

Definições de Política

Uma definição de política é uma regra individual que descreve um critério para conformidade, como:

• Permitir a criação de recursos apenas em uma região específica.
• Garantir que todas as VMs utilizem discos criptografados.

Exemplo de definição de política em JSON:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "field": "location",
      "notIn": ["eastus", "westus"]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Iniciativas

Uma iniciativa é uma coleção de múltiplas definições de políticas agrupadas com um propósito comum, como:

• Garantir conformidade regulatória (por exemplo: GDPR, ISO 27001).
• Padronizar a segurança de uma aplicação.

Atribuições

Uma atribuição de política aplica uma definição ou iniciativa a um escopo específico, como:

• Assinatura Azure.
• Grupo de Recursos.
• Recurso Individual.

Efeitos das Políticas

As políticas podem ter diferentes efeitos, como:

• Deny: Impede a criação ou modificação de recursos não conformes.
• Audit: Apenas registra a não conformidade sem bloquear a ação.
• Modify: Faz modificações automáticas nos recursos para garantir conformidade.
• DeployIfNotExists: Implanta recursos adicionais para garantir conformidade.

Imagine a Situação: Ser Bloqueado por uma Política do Azure

Imagine que você está tentando implantar uma nova máquina virtual no Azure para testar uma aplicação. Você escolhe uma região aleatória, digamos South India, porque parece conveniente no momento. No entanto, ao tentar concluir a criação da VM, você recebe um erro:

O que aconteceu? Você foi impedido por uma Azure Policy aplicada em sua organização! Essa política foi configurada pelo time de governança de TI para garantir que todos os recursos sejam criados apenas em regiões específicas, como East US e West Europe, por razões de conformidade e segurança.

Frustração? Sim. Mas por uma Boa Razão.

Parece frustrante ser bloqueado quando você só queria testar uma VM, certo? No entanto, o propósito dessa regra não é atrapalhar seu trabalho, mas sim proteger o ambiente da empresa e manter padrões consistentes. Veja o porquê:

• ✅ Conformidade Legal: Algumas empresas precisam armazenar dados apenas em regiões específicas por leis como a LGPD (Lei Geral de Proteção de Dados).
• ✅ Otimização de Custos: Restringir o uso de regiões mais caras pode reduzir significativamente os gastos.

Como Resolver?

Se você precisar de uma exceção para essa política, você pode:

1. Solicitar uma Isenção (Exemption): Um administrador pode criar uma isenção temporária para um recurso específico.

2. Testar em um Sandbox: Se for um teste, você pode pedir acesso a um ambiente separado sem restrições.

3. Propor uma Revisão da Política: Se a necessidade for frequente, pode ser o caso de revisar a política e flexibilizar as regiões permitidas.

Essa experiência mostra como o Azure Policy ajuda a manter o controle e a segurança, mesmo quando parece um bloqueio.

Azure Policy vs Azure RBAC (Controle de Acesso Baseado em Função)

Embora ambos estejam relacionados à governança e controle no Azure, eles têm propósitos diferentes: