DEV Community: Marcos Vilela

Shared Workflows: minha experiência definindo pipelines reutilizáveis

Marcos Vilela — Tue, 03 Mar 2026 19:53:52 +0000

Nos últimos meses trabalhei na definição de um modelo padrão de shared workflows para projetos de backend Node.js e recursos de infraestruturas implantados na AWS. Neste artigo descrevo a motivação, decisões de arquitetura, trechos de código e aprendizados que considero úteis para quem quer adotar um modelo similar.

Problema e motivação

Em organizações com múltiplos times e repositórios, cada projeto costuma inventar seu pipeline (lint, test, build, deploy). Isso gera retrabalho, inconsistências de segurança e custo de manutenção alto. Minha meta foi criar um conjunto de workflows reutilizáveis — fáceis de configurar por repositórios consumidores — que reduzissem duplicação e padronizassem boas práticas.

Abordagem

Optei por usar reusable workflows do GitHub Actions (on: workflow_call) e separar claramente responsabilidades, exemplo:

CI: lint, install, cache, unit/integration tests, security scan (yarn audit).
Infra CI: Terraform fmt/init/plan (shared-terraform-ci).
CD: build/push para ECR, deploy blue/green em ECS (shared-backend-deploy-ecs).
Release: criação automática de branch de release e PR para main (shared-release-workflow).

Essa separação facilita reaproveitamento: um repositório pode chamar apenas o CI shared, ou o deploy shared, ou ambos através de wrappers.

Trechos de consumo (exemplos)

Consumo do shared CI num projeto:

jobs:
  ci:
    uses: ./.github/workflows/shared-backend-ci.yml
    with:
      working_directory: app
      node_version: '20'
      enable_security_scan: true
    secrets:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Wrapper que executa deploy em staging e, em seguida, chama o workflow de release se o deploy teve sucesso:

jobs:
  deploy:
    uses: ./.github/workflows/shared-backend-deploy-ecs.yml
    with:
      environment: staging
      tf_backend_bucket: my-staging-state
      tf_var_file: envs/staging/variables.tfvars
    secrets:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  promote:
    needs: deploy
    if: ${{ needs.deploy.result == 'success' }}
    uses: ./.github/workflows/shared-release.yml
    secrets:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Decisões arquiteturais chave

Reusable workflows via workflow_call favorecem versão e rollback centralizado. Consumidores apontam para uma tag (@v1) no repositório de shared workflows.
Segreguei permissões por job (princípio de menor privilégio): jobs de lint/test usam contents: read; jobs de release/deploy recebem permissões mais elevadas apenas quando estritamente necessário.

Aprendizados e recomendações

Parametrização é essencial. Trabalhei com working_directory, app_path, image_tag e outros inputs para permitir que projetos com monorepos ou estruturas diferentes reutilizem os mesmos workflows.
Teste local e validação estática. Ferramentas como actionlint, shellcheck e checkov evitaram regressões e problemas de segurança antes do merge.
Documente uso e exemplos. Consumidores adotam shared workflows muito mais rápido quando encontram exemplos práticos e um README conciso com nomes de secrets esperados.
Tenha um piloto. Validar o modelo em um projeto piloto permitiu ajustar inputs e detectar diferenças (por exemplo, onde o monorepo precisava de um working_directory diferente).

Riscos & mitigação

Diferenças entre repositórios: mitigação com inputs configuráveis e exemplos detalhados.
Permissões excessivas: mitigação com revisão de permissões por job e uso de roles para operações AWS.
Dependência central: documentar SLA de alterações e versionar via tags semânticas para evitar breaking changes.

Conclusão

Criar um modelo de shared workflows traz retorno rápido em escala: menos esforço duplicado, pipelines padronizados e melhorias de segurança centralizadas. A chave do sucesso foi manter o design simples, parametrizável e bem documentado, além de validar por meio de um piloto real.

Se você estiver começando, recomendo iniciar pelo shared CI (lint/test) e, em seguida, evoluir para um shared deploy com validações de infraestrutura (Terraform) e deploys controlados.

[Boost]

Marcos Vilela — Tue, 03 Mar 2026 19:53:00 +0000

Reestudando sua infraestrutura

Marcos Vilela ・ Jan 27

#security #iac #vulnerabilityanalysis #devops

Template de testes de API com K6

Marcos Vilela — Tue, 24 Feb 2026 12:18:31 +0000

Escrevi um template para servir de modelo para escrita de testes de performance para testar APIs REST com k6, integrando Prometheus e Grafana localmente e adicionando utilitários reutilizáveis para autenticação, checks, thresholds e geração de relatórios. A seguir descrevo as decisões que tomei, exemplos de código e como rodar localmente e no CI.

Por que escolhi o k6

Escolhi o k6 por ser leve, confiável e por permitir escrever testes em JavaScript com boa legibilidade. Ele integra bem com observability (Prometheus/Grafana) e funciona tanto via CLI quanto em container — ideal para rodar localmente ou em pipelines de CI.

Estrutura do projeto

Organizei o repositório com foco em reutilização e clareza:

tests/ — scripts organizados por tipo (smoke, load, stress, soak).
lib/ — utilitários e helpers:
- lib/common/ — auth.js, checks.js, generators.js, thresholds.js
- lib/config/loader.js — carregador de configurações (.env, env vars e arquivos JSON)
- lib/utils/ — logger.js, reporter.js
docker-compose.yml — stack local com k6, prometheus e grafana
.env.example — exemplo mínimo de variáveis locais

Essa divisão mantém os testes pequenos e delega lógica compartilhada para lib/.

Configuração e precedência de variáveis

Implementei uma lógica simples de carregamento de configuração em lib/config/loader.js:

Variáveis passadas via CLI/CI (__ENV) têm prioridade;
Em seguida, eu leio o .env local;
Por fim, valores padrões vindos de config/staging.json ou config/production.json.

Trecho simplificado:

// lib/config/loader.js (trecho)
const currentEnv = __ENV.ENVIRONMENT || dotEnv.ENVIRONMENT || 'staging';
const configFile = JSON.parse(open(`../../config/${currentEnv}.json`));

const config = Object.assign({}, configFile, {
  BASE_URL: __ENV.BASE_URL || dotEnv.BASE_URL || configFile.BASE_URL,
  USERNAME: __ENV.USERNAME || dotEnv.USERNAME || configFile.USERNAME,
  PASSWORD: __ENV.PASSWORD || dotEnv.PASSWORD || configFile.PASSWORD,
  AUTH_TOKEN: __ENV.AUTH_TOKEN || dotEnv.AUTH_TOKEN || configFile.AUTH_TOKEN,
});

Nota: __ENV é a forma padrão do k6 para acessar variáveis de ambiente passadas na execução.

Autenticação reutilizável

Para endpoints protegidos criei lib/common/auth.js. A função authenticate() tenta:

Retornar AUTH_TOKEN se presente (útil para debug);
Caso contrário, fazer login com USERNAME/PASSWORD e retornar o token.

Uso típico em um teste:

import { authenticate } from '../../lib/common/auth.js';

export function setup() {
  const token = authenticate();
  return { token };
}

A função valida a resposta (checks) e chama fail() em caso de erro para interromper o teste quando a autenticação falha.

Checks e thresholds

Criei helpers para checks (lib/common/checks.js) e thresholds (lib/common/thresholds.js) para padronizar asserts e SLOs:

// Exemplo de test (smoke)
import http from 'k6/http';
import config from '../../lib/config/loader.js';
import { standardChecks } from '../../lib/common/checks.js';

export const options = {
  vus: 1,
  duration: '10s',
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const res = http.get(`${config.BASE_URL}/health`);
  standardChecks.is200(res);
}

Os thresholds possibilitam que o job do CI falhe automaticamente quando os SLOs não são atendidos.

Relatórios

Integrei o k6-reporter para gerar summary.html e summary.json. No lib/utils/reporter.js exporto handleSummary:

import { htmlReport } from "https://raw.githubusercontent.com/benc-uk/k6-reporter/main/dist/bundle.js";

export function handleSummary(data) {
  return {
    "summary.html": htmlReport(data),
    "summary.json": JSON.stringify(data),
  };
}

E nos testes eu apenas faço:

import { handleSummary } from '../../lib/utils/reporter.js';
export { handleSummary };

Observability: Prometheus + Grafana

Para observability local usei docker-compose.yml com k6, Prometheus e Grafana. Configurei o k6 para enviar métricas via remote write para o Prometheus, e ativei remote-write-receiver no contêiner do Prometheus.

Execução local recomendada:

docker-compose up -d
# rodar um teste (container k6 já monta o repositório):
docker-compose run --rm k6 run tests/smoke/01-health-check.js

Após subir a stack você pode abrir Grafana (http://localhost:3000) e Prometheus (http://localhost:9090).

Integração com CI (GitHub Actions)

Usei a grafana/k6-action para executar scripts no CI. Exemplo de step:

- name: Run K6 Smoke Test
  uses: grafana/k6-action@v0.2.0
  with:
    filename: tests/smoke/01-health-check.js
  env:
    BASE_URL: ${{ secrets.BASE_URL }}
    ENVIRONMENT: staging

Recomendo rodar smoke em PRs e load/stress em jobs separados ou agendados para evitar impacto em ambientes de produção.

Boas práticas que segui

Não commitar segredos (.env está no .gitignore).
Reutilizar helpers em lib/ para diminuir duplicação.
Definir thresholds para transformar métricas em critérios de sucesso/falha.
Manter testes idempotentes para que possam ser executados várias vezes sem efeitos colaterais.

Problemas que enfrentei e como resolvi

Leitura de .env: implementei parsing que aceita aspas e ignora comentários.
Autenticação: incluí suporte a AUTH_TOKEN estático para facilitar debug sem chamadas de login.
Observability: configurei Prometheus para aceitar remote write do k6 no ambiente local.

Exemplo mínimo pronto para copiar

// tests/smoke/01-health-check.js
import http from 'k6/http';
import config from '../../lib/config/loader.js';
import { standardChecks } from '../../lib/common/checks.js';

export const options = {
  vus: 1,
  duration: '10s',
};

export default function () {
  const res = http.get(`${config.BASE_URL}/health`);
  standardChecks.is200(res);
}

Conclusão

Criar este template me ajudou a padronizar a forma como escrevemos e executamos testes de carga: fica mais fácil rodar localmente com observability, sendo assim para cada projeto, inicio um novo repositório a partir desse template, posso utilizar os testes padrões para validação e escrever novos testes logicamente, tendo assim mais flexibilidade, robustez, escala e padronização, além de poder, integrar/utilizar o K6 nas pipelines de CI/CD.

Como integrei testes de carga com K6, GitHub Actions e OpenTelemetry

Marcos Vilela — Tue, 10 Feb 2026 11:24:58 +0000

Neste artigo, compartilho minha experiência construindo uma infraestrutura de testes de carga gerida de forma eficiente com GitHub Actions e observável via integração com OpenTelemetry (OTel). O objetivo era garantir que o desempenho da nossa API pudesse ser monitorado facilmente dentro dos pipelines de CI/CD.

O Problema

Precisávamos executar testes de desempenho regularmente contra nossos ambientes de staging e produção sem intervenção manual. Além disso, as métricas geradas por esses testes precisavam ficar visíveis nos nossos dashboards centralizados do Grafana, que usam o Amazon Managed Prometheus (AMP) alimentado por um OpenTelemetry Collector.

Por que o K6?

Escolhi o K6 porque permite escrever testes em JavaScript, tornando-os acessíveis para toda a equipe. É leve, compatível com containers e tem suporte nativo para exportar métricas para OpenTelemetry.

Estrutura do caso de uso

Estruturei o repositório para lidar com diferentes tipos de testes:

Smoke Tests: Verificações rápidas de saúde executadas em pull requests.
Load Tests: Baselines de desempenho padrão executadas em agendamentos.
Stress & Soak Tests: Testes mais agressivos para identificar pontos de ruptura.

Aqui está um exemplo simplificado de como estruturei um teste básico usando checks e thresholds:

import http from 'k6/http';
import { check } from 'k6';

export const options = {
    thresholds: {
        http_req_duration: ['p(95)<2000'], // 95% das requisições devem estar abaixo de 2s
        http_req_failed: ['rate<0.01'],     // Menos de 1% de falha
    },
};

export default function () {
    const res = http.get('https://api.staging.example.com/health');

    check(res, {
        'status é 200': (r) => r.status === 200,
    });
}

Passo 1: Implementação no GitHub Actions

O núcleo da automação fica no GitHub Actions. Criei um workflow que permite execução agendada (cron) e acionamento manual (workflow_dispatch) para ambientes específicos.

Um desafio específico foi garantir que o binário do K6 estivesse corretamente instalado e disponível no PATH. Usar a action oficial grafana/setup-k6-action foi a solução mais confiável.

Aqui está a configuração essencial do arquivo de workflow .github/workflows/load-tests.yml:

name: K6 Load Tests

on:
    schedule:
        - cron: '0 0 * * 5' # Toda sexta-feira à meia-noite
    workflow_dispatch:
        inputs:
            environment:
                type: choice
                options: 
                    - staging
                    - production
            test_type:
                type: choice
                options: 
                    - smoke
                    - load

jobs:
    run-tests:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v4

            - name: Setup k6
                uses: grafana/setup-k6-action@v1

            - name: Run K6 Test
                run: k6 run --out opentelemetry tests/${{ inputs.test_type }}/test.js
                env:
                    K6_OTEL_EXPORTER_TYPE: http
                    K6_OTEL_HTTP_EXPORTER_ENDPOINT: ${{ vars.OTEL_COLLECTOR_ENDPOINT }}

Passo 2: Integração com OpenTelemetry

Esta foi a parte mais crítica da configuração. Integrar o K6 com nosso OpenTelemetry Collector exigiu configurações específicas para garantir que as métricas viajassem do runner do GitHub Action para nosso collector e, finalmente, para o Prometheus.

O suporte nativo do K6 ao OTel é excelente, mas nuances de configuração importam.

Configuração do protocolo

Precisei definir explicitamente o tipo do exporter para http porque o collector escuta na porta 4318 para payloads HTTP/OTLP. Por padrão, algumas ferramentas assumem gRPC (porta 4317).

env:
    K6_OTEL_EXPORTER_TYPE: http
    K6_OTEL_HTTP_EXPORTER_ENDPOINT: ${{ vars.OTEL_COLLECTOR_ENDPOINT }}
    K6_OTEL_EXPORTER_INSECURE: true

A variável de endpoint geralmente é algo como seu-domínio.com:4318. O K6 adiciona o protocolo/caminho correto se configurado apropriadamente, mas aprendi que K6_OTEL_HTTP_EXPORTER_ENDPOINT é a variável específica quando o tipo é http, enquanto K6_OTEL_EXPORTER_ENDPOINT costuma ser usada para gRPC ou defaults genéricos.

Atributos de recurso e filtragem

Em um ambiente de observabilidade compartilhado, taguear suas métricas é obrigatório. Nosso collector descarta qualquer métrica que não contenha um client_id específico. Resolvi isso injetando K6_OTEL_RESOURCE_ATTRIBUTES diretamente no pipeline:

K6_OTEL_RESOURCE_ATTRIBUTES: client_id=test3,environment=${{ matrix.environment }},service_name=k6-load-tests

Isso garante que, ao consultar k6_http_req_duration no Grafana, eu possa filtrar exatamente pela execução do teste e ambiente.

Passo 3: Simulação local com Act

Testar workflows do GitHub Actions cometendo e dando push com mensagens "fix ci" é tedioso. Integrei o act para simular o ambiente do GitHub Actions localmente.

Criando um arquivo simples de payload de evento dispatch-event.json, pude verificar o comportamento exato da injeção de variáveis de ambiente e da execução do comando K6 sem sair do terminal:

act workflow_dispatch -e .github/dispatch-event.json -W .github/workflows/load-tests.yml

Isso economizou horas de depuração, especialmente ao ajustar as variáveis de ambiente do OTel.

Conclusão

Ao combinar K6, GitHub Actions e OpenTelemetry, implementei um sistema onde o desempenho é monitorado como a saúde da aplicação.

Automação: Não há mais execução manual dos testes de carga.
Visibilidade: Métricas estão no mesmo dashboard que as métricas da aplicação.
Depuração: Testes locais com act garantem que o pipeline permaneça estável.

Se for montar testes de carga, recomendo priorizar o aspecto de observabilidade desde cedo. Ver gráficos em tempo real de Virtual Users (VUs) e Duração de Requisições ao lado do uso de CPU do servidor oferece insights que um relatório local isolado nunca proporciona.

Economia não é sorte, é automação. Veja como monitorei custos na AWS com Terraform.

Marcos Vilela — Tue, 03 Feb 2026 12:09:13 +0000

Automatizando FinOps na AWS: Como construímos um módulo de Monitoramento de Custos com Terraform e incident.io

Marcos Vilela ・ Feb 3

#finops #aws #terraform #iac

A /home encheu? Como usei Block Storage para expandir o armazenamento sem dor.

Marcos Vilela — Tue, 03 Feb 2026 12:07:59 +0000

Marcos Vilela

Nov 6 '24

Como expandi o armazenamento da minha pasta /home com Block Storage

#beginners #linux #blockstorage #braziliandevs

Comments

4 min read

A /home encheu? Como usei Block Storage para expandir o armazenamento sem dor

Marcos Vilela — Tue, 03 Feb 2026 12:06:56 +0000

Marcos Vilela

Nov 6 '24

Como expandi o armazenamento da minha pasta /home com Block Storage

#beginners #linux #blockstorage #braziliandevs

Comments

4 min read

Automatizando FinOps na AWS: Como construímos um módulo de Monitoramento de Custos com Terraform e incident.io

Marcos Vilela — Tue, 03 Feb 2026 12:03:52 +0000

Gerenciar custos em nuvem e um desafio constante para equipes de engenharia. A disciplina de FinOps busca trazer visibilidade e accountability para esses gastos, mas sem as ferramentas certas, e fácil ser surpreendido pela fatura no final do mês.

Neste artigo, compartilho a experiência e os detalhes técnicos da criação de um módulo Terraform reutilizável para automatizar alertas de orçamento na AWS, integrando diretamente com ferramentas de resposta a incidentes (neste caso, o incident.io), eliminando intermediários desnecessários como funções Lambda para esse fim específico.

O Problema

Precisávamos de uma maneira padronizada de criar "guardrails" financeiros para novos projetos. Toda nova conta ou ambiente (staging, production) na AWS deveria nascer com um orçamento definido e um canal de alerta configurado.

Os requisitos eram:

Definir um limite mensal em dólares.
Alertar quando o gasto real atingir certas porcentagens (ex: 80%, 100%).
Alertar quando a previsão (forecast) indicar que o orçamento será estourado.
Enviar esses alertas para nossa plataforma de gerenciamento de incidentes.
Ser seguro (dados criptografados em repouso).

A Arquitetura Simplificada

Inicialmente, considerou-se usar AWS Lambda para processar os alertas do AWS Budgets e formatar o JSON para o webhook. No entanto, percebemos que poderíamos simplificar a arquitetura utilizando a capacidade nativa do SNS de realizar chamadas HTTPS (Webhooks).

O fluxo ficou assim:
AWS Budgets -> SNS Topic (Criptografado) -> HTTP POST -> Incident.io

Essa abordagem reduz a complexidade operacional (menos código para manter) e o custo.

A Implementação com Terraform

Abaixo, detalho as partes cruciais do módulo, focando em como resolvemos os desafios de segurança e flexibilidade.

1. Segurança Primeiro: Criptografia KMS

O AWS SNS suporta criptografia de dados (Server-Side Encryption). Para ambientes corporativos, isso não é opcional. No entanto, usar uma chave KMS gerenciada pelo cliente (CMK) requer politicas de acesso especificas para permitir que o serviço de AWS Budgets (que é um serviço global) chame um recurso regional e use a chave para criptografar a mensagem antes de enviá-la ao tópico.

resource "aws_kms_key" "cost_alerts_key" {
  description             = "KMS key for encrypting FinOps SNS topics"
  deletion_window_in_days = 10
  enable_key_rotation     = true

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "Enable IAM User Permissions"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${local.account_id}:root"
        }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "Allow AWS Budgets to use the key"
        Effect = "Allow"
        Principal = {
          Service = "budgets.amazonaws.com"
        }
        Action = [
          "kms:GenerateDataKey*",
          "kms:Decrypt"
        ]
        Resource = "*"
      }
    ]
  })
}

Observe a permissão explicita para budgets.amazonaws.com. Sem isso, o orçamento falha silenciosamente ao tentar publicar no tópico.

2. O Tópico SNS e a política de Publicação

O tópico SNS atua como o roteador. Além de criar o tópico, precisamos de uma aws_sns_topic_policy para autorizar o serviço de orçamento a publicar nele.

resource "aws_sns_topic" "cost_alerts" {
  name_prefix       = "${local.name_prefix}-cost-alerts-"
  kms_master_key_id = aws_kms_key.cost_alerts_key.arn
}

resource "aws_sns_topic_policy" "default" {
  arn = aws_sns_topic.cost_alerts.arn
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AWSBudgets-Publish"
        Effect = "Allow"
        Principal = {
          Service = "budgets.amazonaws.com"
        }
        Action   = "SNS:Publish"
        Resource = aws_sns_topic.cost_alerts.arn
      }
    ]
  })
}

3. Flexibilidade com Dynamic Blocks

Um dos maiores desafios ao criar módulos reutilizáveis e atender as diferentes necessidades de notificação de cada time. Alguns querem alertas aos 50%, outros apenas aos 100%.

Utilizamos o recurso dynamic do Terraform para gerar as configurações de notificação com base em uma lista de objetos fornecida via variável.

resource "aws_budgets_budget" "cost_budget" {
  name              = "${local.name_prefix}-budget"
  budget_type       = "COST"
  limit_amount      = var.limit_amount
  limit_unit        = var.limit_unit
  time_period_start = "2024-01-01_00:00"
  time_unit         = var.time_unit

  # Bloco dinamico para notificacoes
  dynamic "notification" {
    for_each = var.notifications
    content {
      comparison_operator       = notification.value.comparison_operator
      threshold                 = notification.value.threshold
      threshold_type            = notification.value.threshold_type
      notification_type         = notification.value.notification_type
      subscriber_sns_topic_arns = [aws_sns_topic.cost_alerts.arn]
    }
  }
}

Isso permite que o consumidor do module configure alertas de forma declarativa e simples no arquivo .tfvars:

notifications = [
  {
    comparison_operator = "GREATER_THAN"
    threshold           = 80
    threshold_type      = "PERCENTAGE"
    notification_type   = "ACTUAL"
  },
  {
    comparison_operator = "GREATER_THAN"
    threshold           = 100
    threshold_type      = "PERCENTAGE"
    notification_type   = "FORECASTED"
  }
]

4. Integração via Webhook (A Parte "Chata")

A integração final e feita via uma assinatura SNS com protocolo HTTPS:

resource "aws_sns_topic_subscription" "incident_io" {
  topic_arn = aws_sns_topic.cost_alerts.arn
  protocol  = "https" # Detectado dinamicamente no codigo real
  endpoint  = var.incident_io_webhook_url
}

O Desafio da Confirmação da Assinatura:
Diferente de Lambda ou SQS, endpoints HTTP/HTTPS requerem uma confirmação de assinatura. O SNS envia um POST inicial com uma URL de confirmação.
Como estamos usando uma ferramenta de terceiros (incident.io), não temos controle direto para clicar programaticamente nesse link.

A solução adotada foi processual:

O Terraform aplica a infraestrutura.
O estado da assinatura fica como "PendingConfirmation".
O administrador acessa os logs do incident.io, localiza a mensagem de SubscriptionConfirmation e clica no link manualmente.

Embora não seja 100% automatizado (zero-touch), e um compromisso aceitável para uma configuração que ocorre apenas uma vez por ambiente.

Conclusão

Criar módulos de infraestrutura como código para FinOps e essencial para escalar o uso da nuvem de forma responsável. Ao centralizar a lógica de orçamentos, criptografia e notificações em um único modulo, garantimos que todos os ambientes seguem as melhores praticas de segurança e observabilidade financeira.

A escolha de remover camadas intermediarias (como Lambdas) simplificou a stack, tornando-a mais robusta e fácil de manter a longo prazo.

Reestudando sua infraestrutura

Marcos Vilela — Tue, 27 Jan 2026 17:30:47 +0000

Recentemente, parei para rever/revisar o IaC de infra/redes e sua infraestrutura aplicada, de um ecossistema de uma fintech (que chamaremos aqui de GlobalPay). O objetivo era avaliar a postura de segurança de seus apps diferentes que compõem o produto principal.

O que parecia ser uma varredura de rotina revelou uma lição valiosa: a segurança não é apenas um problema técnico, mas um desafio de governança e automação e também, revisão.

Aqui estão os principais aprendizados para quem trabalha com DevOps, Cloud e Segurança de Aplicações que pude tirar reestudando meu próprio código.

1. O perigo dos Templates de IaC Inadequados

Um dos achados mais curiosos foi que nos apps analisados apresentavam exatamente a mesma falha: a fuga de nomes internos de Load Balancers de staging e regiões da no cabeçalho Location de redirecionamentos HTTP.

O aprendizado: Quando usamos ferramentas como Terraform ou CloudFormation, um erro no template original é replicado em escala. Adversários usam essas informações para mapear ambientes de teste, que geralmente possuem controles de segurança menos rigorosos.

2. A Inconsistência é o seu maior inimigo

Durante a minha análise, encontramos um cenário de "dois mundos". Enquanto um app apresentava uma postura exemplar (o nosso benchmark), com HSTS, CSP e X-Frame-Options configurados corretamente, os apps adjacentes — teoricamente mais sensíveis — não possuíam poucos desses controles.

A lição: A segurança não pode ser seletiva. A falta de uma baseline mínima obrigatória centralizada faz com que cada time de desenvolvimento implemente sua própria versão de "segurança", criando buracos previsíveis no perímetro.

3. Vulnerabilidades "Clássicas" ainda derrubam gigantes

Identificamos uma vulnerabilidade ao ataque Slowloris DoS (CVE-2007-6750) em um dos endpoints. É uma falha de 2009 que ainda assombra ambientes que não configuram corretamente os timeouts de conexão em seus Load Balancers ou WAFs.

Além disso, o Bypass de Rate Limit no endpoint de autenticação foi classificado como crítico. Sem um limite rigoroso, a aplicação fica exposta a ataques de Account Takeover (ATO) via Credential Stuffing.

4. Hardening de Borda: Mais que apenas HTTPS

Muitos desenvolvedores acreditam que subir um certificado SSL/TLS é o suficiente. No entanto, a análise revelou que:

CORS Permissivo: Configurações de access-control-allow-origin: * (wildcard) em APIs financeiras permitem que qualquer site malicioso faça requisições em nome de usuários autenticados.
Fingerprinting de Tecnologia: Manter o cabeçalho X-Powered-By: Express facilita a vida do atacante, que pode buscar exploits específicos para aquela versão do framework.
Segurança de Cabeçalhos: A ausência de cabeçalhos críticos (como CSP para evitar XSS e HSTS para forçar HTTPS) foi uma falha abrangente.

5. Do Manual para o "Security as Code"

A maior conclusão deste relato não foi sobre quais portas estavam abertas, mas sobre a ausência de validações automáticas em pipelines de CI/CD.

Se tivesse implementado verificações de segurança automatizadas, seria impossível um app chegar à produção sem os cabeçalhos obrigatórios ou com políticas de CORS abertas.

Conclusão: O Projeto Arquitetônico Digital

A infraestrutura de uma empresa é como um edifício residencial. Não adianta o andar de investimentos ter portas blindadas se o andar de gestão de contas foi construído com janelas que não trancam.

A solução definitiva para os problemas encontrados não é consertar cada domínio manualmente, mas atualizar o único projeto arquitetônico digital (os templates de IaC) e garantir que cada novo andar construído siga o mesmo padrão de segurança máxima desde o alicerce.

Produtividade no Terminal: O Poder dos Aliases no Linux

Marcos Vilela — Tue, 13 Jan 2026 11:46:53 +0000

Se você utiliza a linha de comando diariamente, já deve ter percebido que passamos boa parte do tempo digitando os mesmos comandos repetidamente. Seja para limpar o cache do Docker, realizar um deploy ou formatar uma string, a repetição é a inimiga da eficiência. É aqui que entram os aliases do Linux.

O que são Aliases?

De forma simplificada, um alias é um apelido ou um atalho para um comando mais longo e complexo. Eles funcionam como substituições de texto no seu shell (Bash ou Zsh). Em vez de digitar uma sequência de 50 caracteres, você pode definir uma palavra de quatro letras que executa exatamente a mesma função.

Por que utilizar?

Redução de erros de digitação: Comandos complexos com muitas flags são propensos a erros.

Padronização: Você pode criar um fluxo de trabalho padrão para sua equipe ou para seus diferentes projetos.

Velocidade: A economia de segundos em cada comando se traduz em horas de produtividade ao final de um mês.

Exemplos simples mas práticos de uso

Gerenciamento de Infraestrutura Quem trabalha com Docker sabe que resíduos de contêineres e redes podem consumir gigabytes de memória rapidamente. Um alias de limpeza pode ser um grande aliado, o que costumo utilizar:

alias docker-prune-all="docker system prune --all --volumes -f"

Normalização de Strings Muitas vezes precisamos renomear arquivos removendo espaços, acentos e transformando tudo em minúsculas. Uma função no seu arquivo de perfil pode automatizar isso, esse me ajuda a normalizar frases que posso utilizar na criação de branchs:

normaliza() {
  echo "$*" | iconv -f utf8 -t ascii//TRANSLIT | tr "[:upper:]" "[:lower:]" | sed "s/ /-/g"
}

Lembretes de Workflow Se o seu processo de merge e deploy envolve muitos passos manuais, você pode criar um alias que apenas imprime o passo a passo na tela, servindo como um guia rápido, como um man de algum software/função:

alias deploy-help='echo -e "1. git pull\n2. npm run build\n3. dep deploy stage"'

Como configurar

Para tornar seus aliases permanentes, você deve adicioná-los ao arquivo de configuração do seu shell, geralmente o .bashrc ou .zshrc, localizados na pasta raiz do seu usuário (~/).

Uma boa prática é manter seus aliases em um arquivo separado chamado .bash_aliases e apenas o chamar dentro do seu arquivo principal. Isso mantém suas configurações organizadas e fáceis de transportar para outras máquinas.

Aliases não são apenas sobre digitar menos, são sobre criar um ambiente de trabalho que se adapta às suas necessidades. Ao identificar padrões no seu dia a dia e automatizá-los, você libera espaço mental para focar no que realmente importa: a solução dos problemas e o desenvolvimento de código de qualidade.

Como Estruturei um Template de AWS Lambda com Terraform e GitHub Actions

Marcos Vilela — Tue, 25 Nov 2025 13:30:26 +0000

Recentemente, desenvolvi um template reutilizável para aplicações AWS Lambda em Python, integrando infraestrutura como código via Terraform e automação de CI/CD com GitHub Actions. Neste artigo, compartilho minha experiência, decisões de arquitetura e exemplos práticos para quem deseja acelerar projetos serverless na AWS.

Motivação

A necessidade de padronizar e acelerar entregas de funções Lambda me levou a criar um template que pudesse ser facilmente adaptado para diferentes projetos. O objetivo era garantir segurança, rastreabilidade e facilidade de manutenção, sem depender de nomes de empresas ou clientes.
Ao longo do tempo, percebi que cada projeto serverless traz desafios recorrentes: integração com múltiplos triggers, controle de ambientes, versionamento de código, automação de deploy e governança de permissões. Centralizar essas soluções em um template robusto foi essencial para evitar retrabalho e garantir consistência. A busca por automação e segurança guiou cada decisão técnica.

Estrutura do Projeto

A estrutura que utilizei foi a seguinte:

.
├── app/
│   └── handler.py              # Código da Lambda
├── infra/
│   └── terraform/
│       ├── main.tf             # Infra principal
│       ├── variables.tf        # Variáveis
│       ├── outputs.tf          # Outputs
│       ├── version.tf          # Provider e backend
│       └── envs/
│           ├── prod/
│           │   └── terraform.tfvars
│           └── staging/
│               └── terraform.tfvars

Lambda Handler Genérico

Implementei um handler que detecta automaticamente o tipo de evento recebido (HTTP, EventBridge, SNS, S3) e responde de forma adequada. Veja um exemplo simplificado:

import json
import logging
from datetime import datetime, timezone
from typing import Dict, Any

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event: Dict[str, Any], context: Any) -> Dict[str, Any]:
    logger.info("Lambda invocada - Request ID: %s", context.aws_request_id)
    logger.info("Evento recebido: %s", json.dumps(event, default=str))

    response_data = {
        "message": "Hello World!",
        "timestamp": datetime.now(timezone.utc).isoformat(),
        "request_id": context.aws_request_id,
        "event_type": get_event_type(event),
        "function_name": context.function_name,
        "function_version": context.function_version,
        "memory_limit_mb": context.memory_limit_in_mb,
    }

    logger.info("Resposta: %s", json.dumps(response_data))

    if is_http_event(event):
        return {
            "statusCode": 200,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps(response_data),
        }
    return {"statusCode": 200, "body": response_data}

Infraestrutura como Código com Terraform

Utilizei módulos oficiais da AWS para Lambda, API Gateway, EventBridge, SNS e S3. A configuração de variáveis permite habilitar ou desabilitar triggers conforme o ambiente. Exemplo de variáveis para produção:

aws_region   = "us-east-1"
environment  = "prod"
project_name = "my-lambda-app"
lambda_runtime     = "python3.12"
lambda_timeout     = 60
lambda_memory_size = 512
enable_eventbridge = false
enable_api_gateway = false
enable_function_url = false

A detecção automática de Lambda Layers foi feita via local no Terraform:

locals {
  layers_path = "${path.module}/../../app/layers"
  layer_files = fileset(local.layers_path, "*.zip")
  auto_detected_layers = {
    for file in local.layer_files :
    replace(file, ".zip", "") => {
      layer_name          = replace(file, ".zip", "")
      description         = "Auto-detected layer from ${file}"
      compatible_runtimes = [var.lambda_runtime]
      source_path         = file
      skip_destroy        = false
    }
  }
  all_layers = merge(
    local.auto_detected_layers,
    { for layer in var.lambda_layers : layer.layer_name => layer }
  )
}

CI/CD com GitHub Actions

Implementei pipelines para validação, lint, scan de segurança, deploy em staging e produção, além de automação de releases e rollback. O workflow principal para produção segue este padrão:

on:
  push:
    branches:
      - main

jobs:
  validate-lambda:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v5
      - name: Setup Python
        uses: actions/setup-python@v5
      - name: Check Python syntax
        working-directory: app
  # ... outros jobs para lint, scan, terraform, release

Boas Práticas Adotadas

Separação clara entre ambientes (staging/prod)
Uso de variáveis para habilitar/desabilitar recursos
Detecção automática de Lambda Layers
Templates de PR e rollback para padronizar processos
Outputs detalhados para facilitar integrações

Conclusão

Esse template acelerou significativamente o desenvolvimento de funções Lambda, garantindo padronização e segurança. Recomendo fortemente a abordagem para quem busca agilidade e governança em projetos serverless na AWS.

O código completo está disponível em repositórios privados, mas os exemplos acima podem ser adaptados para qualquer contexto. Se quiser discutir mais sobre arquitetura serverless, estou à disposição para trocar ideias.

Como Provisionar Infraestrutura AWS MediaConvert com Terraform

Marcos Vilela — Tue, 25 Nov 2025 13:28:05 +0000

Introdução

Recentemente, trabalhei em um projeto que envolvia o processamento de vídeos em escala na nuvem. Precisávamos de uma solução robusta para converter vídeos automaticamente, e o AWS MediaConvert se mostrou perfeito para isso. No entanto, configurar toda a infraestrutura necessária – filas, roles IAM, templates de job e logs – pode ser complexo. Decidi usar Terraform para automatizar tudo, criando uma infraestrutura como código que pudesse ser reutilizada em diferentes ambientes.

Neste artigo, vou compartilhar minha experiência implementando essa infraestrutura. Vou explicar passo a passo como provisionar os recursos essenciais do MediaConvert usando Terraform, desde a configuração inicial até o deploy. O foco é em uma abordagem prática, com exemplos de código e dicas para evitar armadilhas comuns.

Por Que Terraform para Infraestrutura de MediaConvert?

Antes de mergulhar no código, vamos entender o contexto. O AWS MediaConvert é um serviço gerenciado para transcodificação de vídeos. Ele suporta formatos variados e pode processar jobs em paralelo usando filas. Para integrá-lo com uma aplicação, como uma função Lambda que detecta uploads de vídeos no S3, precisamos de:

Uma fila MediaConvert para gerenciar jobs.
Um role IAM com permissões para acessar buckets S3 e escrever logs no CloudWatch.
Um template de job que define as configurações de transcodificação (resolução, bitrate, etc.).
Logs para monitoramento e debugging.

Fazer isso manualmente via console AWS é possível, mas propenso a erros e difícil de versionar. Com Terraform, tudo fica declarativo, versionado no Git e replicável em ambientes como staging e produção.

Estrutura do Projeto

Organizei o projeto da seguinte forma:

infra/terraform/
├── main.tf                        # Recursos principais
├── variables.tf                   # Declarações de variáveis
├── outputs.tf                     # Outputs para integração
├── version.tf                     # Configuração do provider
├── mediaconvert-template.json     # Template de job
└── envs/
    ├── staging/
    │   └── variables.tfvars
    └── prod/
        └── variables.tfvars

Essa estrutura permite gerenciar múltiplos ambientes com arquivos de variáveis específicos. O template JSON define as configurações de vídeo, como resolução 720p, codec H.264 e bitrate variável.

Pré-requisitos

Antes de começar, certifique-se de ter:

Terraform instalado.
AWS CLI configurado com credenciais válidas.
Buckets S3 existentes para input e output de vídeos (o Terraform não cria buckets, apenas configura permissões).

Para configurar o backend S3 do Terraform (para armazenar o estado remotamente), edite o version.tf:

terraform {
  backend "s3" {
    bucket = "meu-bucket-tfstate"
    key    = "infra/mediaconvert.tfstate"
    region = "us-east-1"
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.40.0, <= 5.55.0"
    }
  }

  required_version = ">= 1.6.0"
}

Definindo as Variáveis

No variables.tf, declarei todas as variáveis necessárias. Isso inclui região AWS, nomes de buckets, status da fila e configurações de aceleração. Por exemplo:

variable "aws_region" {
  description = "AWS region where resources will be created"
  type        = string
  default     = "us-east-1"
}

variable "s3_input_bucket" {
  description = "S3 bucket name for input videos"
  type        = string
}

variable "queue_status" {
  description = "MediaConvert queue status (ACTIVE or PAUSED)"
  type        = string
  default     = "ACTIVE"
}

Para staging, criei um arquivo envs/staging/variables.tfvars com valores específicos:

aws_region   = "us-east-1"
environment  = "staging"
project_name = "mediaconvert-infra"

s3_input_bucket  = "meu-bucket-staging-input"
s3_output_bucket = "meu-bucket-staging-output"
queue_status     = "ACTIVE"

Isso permite customizar por ambiente sem alterar o código principal.

Provisionando os Recursos Principais

No main.tf, comecei configurando o provider AWS com tags padrão:

provider "aws" {
  region = var.aws_region

  default_tags {
    Project     = "MediaConvert Infra"
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

Em seguida, criei o role IAM para o MediaConvert. Esse role precisa de permissões para ler do bucket de input, escrever no de output e publicar logs. Usei policy documents para definir as permissões granularmente:

data "aws_iam_policy_document" "mediaconvert_assume_role" {
  statement {
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["mediaconvert.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "mediaconvert_role" {
  name               = "${var.project_name}-role-${var.environment}"
  assume_role_policy = data.aws_iam_policy_document.mediaconvert_assume_role.json
  description        = "Service role for AWS MediaConvert"
}

Anexei políticas para acesso S3 e operações MediaConvert. Para a fila, foi simples:

resource "aws_media_convert_queue" "main" {
  name   = "${var.project_name}-queue-${var.environment}"
  status = var.queue_status
}

O template de job foi o mais desafiador, pois o provider Terraform não suporta nativamente. Usei um null_resource com local-exec para criar via AWS CLI:

resource "null_resource" "mediaconvert_job_template" {
  provisioner "local-exec" {
    command = "aws mediaconvert create-job-template --name ${var.project_name}-job-template-${var.environment} --settings file://${var.job_template_json_path}"
  }

  depends_on = [aws_media_convert_queue.main]
}

Isso garante que o template seja criado após a fila. Por fim, adicionei um log group no CloudWatch para monitoramento.

Outputs para Integração

No outputs.tf, exportei os ARNs e nomes necessários para que a função Lambda possa criar jobs:

output "mediaconvert_queue_arn" {
  description = "ARN of the MediaConvert queue"
  value       = aws_media_convert_queue.main.arn
}

output "mediaconvert_role_arn" {
  description = "ARN of the MediaConvert IAM role"
  value       = aws_iam_role.mediaconvert_role.arn
}

Isso facilita a integração com outros componentes da aplicação.

Deploy e Validação

Para aplicar em staging:

cd infra/terraform
terraform init
terraform plan -var-file=envs/staging/variables.tfvars
terraform apply -var-file=envs/staging/variables.tfvars

Sempre valide com terraform plan antes de aplicar. Para produção, use o arquivo prod/variables.tfvars e considere adicionar aprovação manual nos workflows de CI/CD.

Lições Aprendidas

Durante a implementação, aprendi que:

Buckets S3 devem existir antes do Terraform; caso contrário, as políticas IAM falham.
O template JSON precisa ser validado manualmente, pois erros só aparecem no runtime.
Use workspaces Terraform para isolar ambientes e evitar conflitos de estado.

Essa abordagem tornou o deploy previsível e escalável. Se você está trabalhando com processamento de mídia na AWS, recomendo fortemente o Terraform para gerenciar essa infraestrutura.

Conclusão

Provisionar infraestrutura MediaConvert com Terraform não só automatiza o processo como também o torna versionável e replicável. Comecei com scripts manuais e migrei para IaC, o que reduziu erros e acelerou deploys. Se você tiver dúvidas ou quiser ver o código completo, confira o repositório no GitHub. Estou curioso para ouvir suas experiências com MediaConvert!