Thallyson Yakko | DevOps Engineer

Desafio SRE – Primeira Parte

2025-12-23T00:00:00-03:00

Contexto do Desafio

O objetivo dessa primeira etapa foi:

Rodar a aplicação localmente
Dockerizar a aplicação
Orquestrar App + Redis + PostgreSQL
Publicar a imagem em um registry
Provisionar um cluster Kubernetes local com KIND via Terraform
Subir toda a stack no Kubernetes
Expor a aplicação via Ingress
Implementar monitoramento com Prometheus e Grafana
Criar ServiceMonitor e regras de alerta baseadas no método GOLD

Dockerização da Aplicação

Primeira coisa foi containerizar a aplicação Python. Criei um Dockerfile e um docker-compose.yml para subir o app junto com Redis e Postgres.

FROM python:3.11-slim

WORKDIR /app

RUN apt-get update && apt-get install -y gcc libpq-dev && \
    pip install --no-cache-dir \
        Flask==2.0.3 \
        Werkzeug==2.3.8 \
        prometheus-client==0.13.1 \
        prometheus-flask-exporter==0.18.7 \
        psycopg2-binary==2.9.7 \
        redis==4.5.4 && \
    apt-get remove -y gcc && apt-get autoremove -y && apt-get clean

COPY . .

EXPOSE 5000

CMD ["python", "app.py"]

A imagem base é python:3.11-slim pra manter o tamanho controlado. Precisei instalar gcc e libpq-dev porque o psycopg2 tem extensão C e sem eles o build quebra. No final removo o gcc pra não carregar lixo na imagem final.

Build da imagem Docker

Execute no diretório onde está o Dockerfile:

docker build -t app-elven:latest .

docker-compose.yml

version: '3.9'

services:
  app-elven:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - 5001:5000
      - 9999:9999
    networks:
      - elven
    environment:
      - POSTGRES_HOST=db
      - POSTGRES_DB=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=senhafacil
      - REDIS_HOST=redis
    volumes:
      - .:/app
    depends_on:
      - db
      - redis
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:5000 || exit 1"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

  redis:
    image: redis:8
    ports:
      - "6379:6379"
    networks:
      - elven
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

  db:
    image: postgres:15
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: senhafacil
      POSTGRES_DB: postgres
    ports:
      - "5432:5432"
    networks:
      - elven
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

networks:
  elven:
    driver: bridge

volumes:
  pgdata:

Subindo toda a stack

docker-compose up -d

Acesso pelo navegador no localhost ou por curl. Resultado esperado é ver uma mensagem “App on”.

Para ver os logs e derrubar a infra:

docker-compose logs -f app-elven

docker-compose down

Subindo a imagem para o Registry:

docker login

docker tag app-elven:latest seuusuario/app-elven:latest

Puxando a imagem para o Registry:

docker push seuusuario/app-elven:latest

Problemas:

**Problemas com build por falta do compilator de extensão C:

 Solução: no lugar de fazer multistage com duas fases de build foi feito apenas uma fase e instalado o gcc libpq-dev: ``apt-get install -y gcc libpq-dev``

Healthcheck da aplicação falhando: A aplicação subia mais devagar do que o tempo estipulado no healthcheck, problema solucionado colocando o “start_period: 10s”

Criando o cluster KIND com Terraform

Usei o provider loft-sh/kind pra provisionar o cluster via Terraform em vez de rodar kind create cluster na mão.

terraform {
  required_providers {
    kind = {
      source  = "loft-sh/kind"
      version = "0.4.0"
    }
  }
}

provider "kind" {}

# Criação do cluster Kind
resource "kind_cluster" "kind" {
  name           = "kind-elven"
  wait_for_ready = true

  node_image = "kindest/node:v1.30.0"

  # Configuração do cluster Kind (equivalente ao kind.yaml)
  config = <
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 30000
        hostPort: 30000
      - containerPort: 30001
        hostPort: 30001
  - role: worker
  - role: worker
EOF
}

output "kubeconfig_file" {
  value = kind_cluster.kind.kubeconfig_path
}

Iniciando o Terraform:

terraform init

Criando o cluster:

terraform apply -auto-approve

Verificando o cluster:

kubectl get nodes -A

Kubernetes com KIND

A stack rodou inteira dentro do namespace desafio-sre:

App Flask
Redis
Postgres
Ingress NGINX
Prometheus + Grafana via Helm (kube-prometheus-stack)
Regras personalizadas
Monitoramento via ServiceMonitor

O monitoramento ficou no namespace monitoring.

Criação Namespace:

kubectl create namespace desafio-sre

Aplicação – Deployment

Arquivo: app-deployment.yaml

apiVersion: apps/v1    #Sempre vai ser apps/v1
kind: Deployment         #Tipo do manisfesto
metadata:
  labels:
    app: app-sre
  name: app-sre
  namespace: desafio-sre
spec:             #caracteristicas do deployment
  replicas: 3
  selector:       #Controla os Pods referentes a essa aplicação
    matchLabels:  #Todos os Pods que tiverem a mesma label é esse deployment que vai cuidar
      app: app-sre
  strategy:     #Estrategias de deployment
      type: RollingUpdate  #Estrategia de atualização
      rollingUpdate:
          maxSurge: 1     # Pode ter até 1 pod a mais do que eu pedi
          maxUnavailable: 2  #Vai atualizar de 2 em 2
  template:       #Template criado para o POD
    metadata:
      labels:
        app: app-sre
    spec:          # Caracteristica agora do meu POD/Container
      containers:
      - image: thallysonyakko/desafiosre:1.0
        env:                     #Variaveis de ambiente DB-postgres
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret         #Nome do postgres-secret
              key: POSTGRES_PASSWORD
        - name: POSTGRESS_DB
          valueFrom:
            secretKeyRef:
              name: postgres-secret         #Nome do postgres-secret
              key: POSTGRES_DB
        - name: POSTGRESS_USER
          valueFrom:
            secretKeyRef:
              name: postgres-secret         #Nome do postgres-secret
              key: POSTGRES_USER
        name: app-sre
        resources:     #Resources do meu POD e seus limits
            limits:
              cpu: "0.8"
              memory: "256Mi"
            requests:
              cpu: "0.3"
              memory: "64Mi"
        livenessProbe:       # Tipo de helthcheck
          httpGet:
            path: /          #Pasta raiz
            port: 5000
          initialDelaySeconds: 10    #Tempo que vai esperar até testar a primeira probes
          periodSeconds: 10     # De quanto em quanto tempo ele vai testar
          timeoutSeconds: 5
          failureThreshold: 3    # Após 3 vezes ele vai tentar restartar o POD

Comando aplicado:

kubectl apply -f app-deployment.yaml -n desafio-sre

Aplicação - Service

Arquivo: app-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: app-sre
  namespace: desafio-sre
  labels:
    app: app-sre
    env: dev
spec:
  selector:       #Quais pods vão ser expostos
    app: app-sre    #Seleciona os Pods com essa label
  ports:
  - port: 5000      #Porta do serviço
    name: http
    targetPort: 5000   #A porta onde o cluster tá escutando
  type: ClusterIP

kubectl apply -f app-service.yaml -n desafio-sre

Redis - Deploy, Service e Secret:

Arquivo: redis-deployment.yaml

apiVersion: apps/v1    #Sempre vai ser apps/v1
kind: Deployment         #Tipo do manisfesto
metadata:
  labels:
    app: redis
  name: redis
  namespace: desafio-sre
spec:             #caracteristicas do deployment
  replicas: 2
  selector:       #Controla os Pods referentes a essa aplicação
    matchLabels:  #Todos os Pods que tiverem a mesma label é esse deployment que vai cuidar
      app: redis
  strategy:     #Estrategias de deployment
      type: RollingUpdate  #Estrategia de atualização
      rollingUpdate:
          maxSurge: 1     # Pode ter até 1 pod a mais do que eu pedi
          maxUnavailable: 1  #Vai atualizar de 2 em 2
  template:       #Template criado para o POD
    metadata:
      labels:
        app: redis
    spec:          # Caracteristica agora do meu POD/Container
      containers:
      - image: redis:7
        name: redis
        resources:     #Resources do meu POD e seus limits
            limits:
              cpu: "0.8"
              memory: "500Mi"
            requests:
              cpu: "0.3"
              memory: "256Mi"

Arquivo: redis-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: redis-secret
  namespace: desafio-sre
type: Opaque
data:
  redis-password: ZGVzYWZpb2VsdmVu       # "desafioelven"

Arquivo: redis-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: redis-service
  namespace: desafio-sre
  labels:
    app: redis
    env: dev
spec:
  selector:       #Quais pods vão ser expostos
    app: redis   #Seleciona os Pods com essa label
  ports:
  - port: 6379      #Porta do serviço
    name: http
    targetPort: 6379   #A porta onde o cluster tá escutando
  type: ClusterIP

kubectl apply -f ./REDIS -n desafio-sre

Problemas enfrentados:

YAML com erro de indentação

yaml: line 25: mapping values are not allowed in this context

Ajustei o redis-deployment.yaml.

Service sem nome (“resource name may not be empty”)

Corrigido para:

metadata: name: redis-service

Postgres

Arquivo: postgres-deployment.yaml

apiVersion: apps/v1    #Sempre vai ser apps/v1
kind: Deployment         #Tipo do manisfesto
metadata:
  labels:
    app: postgres
  name: postgres
  namespace: desafio-sre
spec:             #caracteristicas do deployment
  replicas: 2
  selector:       #Controla os Pods referentes a essa aplicação
    matchLabels:  #Todos os Pods que tiverem a mesma label é esse deployment que vai cuidar
      app: postgres
  strategy:     #Estrategias de deployment
      type: RollingUpdate  #Estrategia de atualização
      rollingUpdate:
          maxSurge: 1     # Pode ter até 1 pod a mais do que eu pedi
          maxUnavailable: 1  #Vai atualizar de 2 em 2
  template:       #Template criado para o POD
    metadata:
      labels:
        app: postgres
    spec:          # Caracteristica agora do meu POD/Container
      containers:
      - image: postgres:15
        name: postgres
        envFrom:
          - secretRef:
              name: postgres-secret
        resources:     #Resources do meu POD e seus limits
            limits:
              cpu: "0.8"
              memory: "500Mi"
            requests:
              cpu: "0.3"
              memory: "256Mi"

Arquivo: postgres-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: postgres-secret
  namespace: desafio-sre
type: Opaque
data:
  POSTGRES_DB: ZGVzYWZpbw==          # desafio
  POSTGRES_USER: cG9zdGdyZXM=        # postgres
  POSTGRES_PASSWORD: MTIzNDU2        # 123456
  POSTGRES_HOST: cG9zdGdyZXMtc2VydmljZQ==   # postgres-service
  POSTGRES_PORT: NTQzMg==            # 5432

Arquivo: postgres-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: postgres-service
  namespace: desafio-sre
  labels:
    app: postgres
    env: dev
spec:
  selector:       #Quais pods vão ser expostos
    app: postgres   #Seleciona os Pods com essa label
  ports:
  - port: 5432      #Porta do serviço
    name: http
    targetPort: 5432   #A porta onde o cluster tá escutando
  type: ClusterIP

kubectl apply -f ./POSTGRES -n desafio-sre

Conferência dos Pods

kubectl get pods -A

Configurando o Ingress no cluster

Crie um arquivo chamado kind-config.yaml com o conteúdo abaixo:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443

Em seguida, crie o cluster usando este arquivo de configuração:

kind create cluster --config kind-config.yaml

Instalando o Ingress Nginx Controller

Instalação:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml

Aguarda os pods ficarem prontos:

kubectl wait --namespace ingress-nginx \
--for=condition=ready pod \
--selector=app.kubernetes.io/component=controller \
--timeout=90s

Criando a primeira regra de Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: desafio-sre-ingress
  namespace: desafio-sre
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /        #Rewrite= Rescreva, idenpendente do que for passado ele vai redirecionar para o /
spec:
  rules:
  - host: app.elven.works							#Criando um dns na minha maquina, preciso modificar no /etc/hosts para passar esse "dominio" par o meu local hostt
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-sre
            port:
              number: 5000
---
#---------
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: monitoring-ingress
  namespace: monitoring
spec:
  rules:
  - host: grafana.elven.works
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: prometheus-stack-grafana
            port:
              number: 80

  - host: prometheus.elven.works
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: prometheus-stack-kube-prom-prometheus
            port:
              number: 9090

kubectl apply -f ingress.yaml

kubectl get ingress

Teste do Ingress:

Via Navegador:
Via CLI:

Instalação do Prometheus via Helm:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Criando o namespace:

kubectl create namespace monitoring

Instalando:

helm install prometheus-stack prometheus-community/kube-prometheus-stack -n monitoring

Verificando:

kubectl get pods -n monitoring

Acessando o Grafana via Ingress:

Navegador: url: grafana.elven.works
Dashboards

Métricas do cluster:

Secrets:

kubectl get secret prometheus-stack-grafana -n monitoring -o jsonpath='{.data.admin-password}' | base64 --decode

Prometheus acesso via ingress:

url:prometheus.elven.works

Criando o ServiceMonitor da aplicação:

Arquivo: app-sre-monitor.yaml

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-sre-monitor
  namespace: monitoring # O ServiceMonitor DEVE estar no mesmo namespace do Prometheus
  labels:
    release: prometheus-stack # Importante: Selecionar o Prometheus Operator
spec:
  namespaceSelector:
    matchNames:
      - desafio-sre # O namespace onde sua aplicação está
  selector:
    matchLabels:
      app: app-sre # Use o rótulo do seu Service (verifique o Service 'app-sre' para o rótulo correto)
  endpoints:
  - port: http-metrics # Nome da porta (deve ser definido no seu Service, veja nota abaixo)
    path: /metrics       # O caminho onde as métricas estão (ex: /metrics ou /actuator/prometheus)
    interval: 30s        # Frequência de coleta (opcional)

kubectl apply -f app-sre-monitor.yaml

Criando o PrometheusRule:

Arquivo: prometheus-gold-rules.yaml

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: application-gold-alerts
  namespace: monitoring # Altere se seu PrometheusRule estiver em outro namespace
  labels:
    prometheus: k8s
    role: alert-rules
    app.kubernetes.io/name: application-gold
spec:
  groups:

    # ----------------------------------------------------
    # GRUPO 1: REGRAS GOLD PARA APLICAÇÃO FLASK (flask-app)
    # ----------------------------------------------------
    - name: flask.gold.alerts
      rules:

      # [G/D] - Get/Duration: Alta Taxa de Erros (5xx)
      - alert: FlaskHighErrorRate
        expr: |
          sum(rate(http_requests_total{job="flask-app", code=~"5xx"}[5m]))
          /
          sum(rate(http_requests_total{job="flask-app"}[5m]))
          > 0.05 # Mais de 5% de erros de servidor
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "Flask: Taxa de Erros 5xx Acima do Limite ({{ $value | printf \"%.2f%%\" }})"
          description: "Mais de 5% das requisições resultaram em erro de servidor nas últimas 3 minutos."

      # [O] - Output: Alta Latência P95
      - alert: FlaskHighLatencyP95
        expr: |
          histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="flask-app"}[5m])) by (le))
          > 0.8 # Latência P95 acima de 800ms
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Flask: Latência P95 Acima do Limite ({{ $value | printf \"%.3f\" }}s)"
          description: "O 95º percentil de requisições está lento por 5 minutos, afetando a experiência do usuário."

      # [L] - Load: Queda Súbita de Tráfego
      - alert: FlaskTrafficDrop
        expr: |
          sum(rate(http_requests_total{job="flask-app"}[5m]))
          <
          (
            sum(rate(http_requests_total{job="flask-app"}[30m] offset 5m))
            * 0.2
          )
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Flask: Queda Súbita de Tráfego"
          description: "O RPS caiu mais de 80% em comparação com os 30 minutos anteriores. Pode indicar uma falha de serviço ou de coleta de métricas."

    # ----------------------------------------------------
    # GRUPO 2: REGRAS GOLD PARA REDIS (redis-exporter)
    # ----------------------------------------------------
    - name: redis.gold.alerts
      rules:

      # [G] - Get: Verificação de Saúde (up)
      - alert: RedisDown
        expr: up{job="redis"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Redis: Serviço Inativo"
          description: "O Prometheus não consegue raspar (scrape) o exporter do Redis por mais de 1 minuto. Instância: {{ $labels.instance }}"

      # [O] - Output: Alta Utilização de Memória (Overhead)
      - alert: RedisMemoryHigh
        expr: redis_memory_used_bytes{job="redis"} / redis_total_system_memory_bytes{job="redis"} > 0.85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Redis: Memória Utilizada Excedeu 85%"
          description: "O Redis está próximo de atingir o limite de memória. Valor atual: {{ $value | humanizePercentage }}"

    # ----------------------------------------------------
    # GRUPO 3: REGRAS GOLD PARA POSTGRESQL (postgres-exporter)
    # ----------------------------------------------------
    - name: postgres.gold.alerts
      rules:

      # [G] - Get: Verificação de Saúde (up)
      - alert: PostgresDown
        expr: up{job="postgres"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "PostgreSQL: Serviço Inativo"
          description: "O Prometheus não consegue raspar (scrape) o exporter do PostgreSQL por mais de 1 minuto. Instância: {{ $labels.instance }}"

      # [D] - Duration/Details: Bloqueios no Banco de Dados (Deadlocks)
      - alert: PostgresDeadlocks
        expr: rate(pg_stat_database_deadlocks{job="postgres"}[5m]) > 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "PostgreSQL: Deadlocks Detectados"
          description: "Foram detectados deadlocks no banco de dados nas últimas 5 minutos. Isso requer atenção imediata."

      # [L] - Load: Muitas Conexões Ativas (Pode causar esgotamento de recursos)
      - alert: PostgresTooManyConnections
        expr: pg_stat_activity_count{datname="mydatabase"} > 100 # Exemplo: mais de 100 conexões ativas
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "PostgreSQL: Excesso de Conexões"
          description: "O banco de dados 'mydatabase' tem mais de 100 conexões ativas. Valor: {{ $value }}. Revise o pool de conexões da aplicação."

kubectl apply -f prometheus-gold-rules.yaml -n monitoring

kubectl get prometheusrules -n monitoring

Esse foi o resultado da primeira semana do desafio em que tinha que ser desenvolvido:
- Rodar a aplicação na máquina
- Dockernizar essa aplicação e provisionar
- Provisionar a app usando o terraform local na maquina
- Usar kind para provisionar a mesma
- Monitorar o cluster local com prometheus + grafana (instalação via helm)
↩︎

Hands-On Terraform - Criando uma VPC

2025-08-05T00:00:00-03:00

Desafio: Provisionando uma VPC com Terraform

Esse desafio foi criar uma VPC completa usando Terraform, sem tocar no console da AWS. Trabalhei com subnets públicas e privadas, Internet Gateway, NAT Gateway e tabelas de rota, tudo via código.

Pré-requisitos

Criar uma rede básica na AWS com os seguintes recursos:

1 VPC
2 Subnets privadas
2 Subnets públicas
2 NAT Gateways
1 Internet Gateway

Por que Terraform?

Já usei CloudFormation antes, mas o Terraform tem uma vantagem clara: funciona em qualquer provider. Com ele dá pra subir o mesmo ambiente várias vezes sem variação, e o state garante que você sempre sabe o que está rodando. Terraform Workspaces então facilitam muito quando precisa isolar ambientes do mesmo projeto.

Como foi pensada a resolução do desafio

Para deixar o código mais dinâmico e reutilizável, utilizei Built-in Functions e Meta-Arguments.

O que são Built-in Functions?

O Terraform tem funções nativas que evitam repetição de lógica. As que usei aqui:

cidrsubnet() → calcula automaticamente o CIDR das subnets
lower() → transforma strings em minúsculas
format() → formata strings dinamicamente

O que são Meta-Arguments?

Meta-arguments controlam como os recursos se comportam. Os principais que usei:

for_each → cria múltiplos recursos a partir de listas ou mapas
depends_on → garante a ordem correta de criação de recursos

Resolução e criação da VPC

A VPC é sua rede privada dentro da AWS. É nela que fica o CIDR, as subnets, as tabelas de rota. Basicamente a base de tudo.

vpc.tf

// Criando VPC
resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr_block
  tags = {
    Name        = "vpc-project-elven"
    terraformed = "true"
  }
}

// Subnets Públicas
resource "aws_subnet" "public" {
  for_each = { for idx, name in local.subnet_public : idx => name } # Cria o recurso com base em uma lista
  vpc_id = aws_vpc.main.id
  cidr_block = cidrsubnet(var.vpc_cidr_block, 8, each.key) # Calcula automaticamente o CIDR
  map_public_ip_on_launch = true

  tags = {
    Name = lower(format("subnet-%s", each.value)) # Formata o nome da subnet
  }
}

// Subnets Privadas
resource "aws_subnet" "priv" {
  for_each = { for idx, name in local.subnet_priv : idx => name }
  vpc_id = aws_vpc.main.id
  cidr_block = cidrsubnet(var.vpc_cidr_block, 8, each.key + length(local.subnet_public))
  map_public_ip_on_launch = false

  tags = {
    Name = lower(format("subnet-%s", each.value))
  }
}

// Internet Gateway
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name        = "igw"
    terraformed = "true"
  }
}

// Tabela de Rotas Públicas
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
}

resource "aws_route" "internet_access" {
  route_table_id = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id = aws_internet_gateway.igw.id
}

resource "aws_route_table_association" "public" {
  for_each = aws_subnet.public # Associa cada subnet à tabela de rota
  subnet_id = each.value.id
  route_table_id = aws_route_table.public.id
}

// EIP para NAT Gateways
resource "aws_eip" "nat" {
  for_each = aws_subnet.public # Cria um EIP por subnet pública
  domain   = "vpc"
  tags = {
    Name        = "nat-eip-${each.key}"
    terraformed = "true"
  }
}

// NAT Gateway
resource "aws_nat_gateway" "ngw" {
  for_each = aws_subnet.public
  subnet_id = each.value.id
  allocation_id = aws_eip.nat[each.key].id

  tags = {
    Name        = "nat-gw-${each.key}"
    terraformed = "true"
  }

  depends_on = [aws_internet_gateway.igw] # Garante que o IGW seja criado antes do NAT Gateway
}

// Tabela de Rotas Privadas
resource "aws_route_table" "priv" {
  for_each = aws_subnet.public
  vpc_id = aws_vpc.main.id
  tags = {
    Name        = "rtb-priv-${each.key}"
    terraformed = "true"
  }
}

// Rotas Privadas
resource "aws_route" "priv" {
  for_each = aws_route_table.priv
  route_table_id = each.value.id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id = aws_nat_gateway.ngw[each.key].id
}

// Associações de Subnets Privadas às Tabelas de Rotas
resource "aws_route_table_association" "priv" {
  for_each = aws_subnet.priv
  subnet_id = each.value.id
  route_table_id = aws_route_table.priv[each.key % length(aws_nat_gateway.ngw)].id
}

Criação do módulo Locals

Locals são variáveis internas do Terraform. Em vez de repetir as mesmas listas em vários recursos, centralizo tudo num lugar só.

locals.tf

locals {
  subnet_public = [
    "public-1a",
    "public-1c"
  ]

  subnet_priv = [
    "priv-1a",
    "priv-1c"
  ]
}

Criação das Variables

Variables evitam que você fixe valores no código. Com elas dá pra subir ambientes diferentes sem mudar nada no Terraform, só passando os valores via .tfvars ou linha de comando.

variables.tf

variable "region" {
  description = "Região da AWS"
  default     = "us-east-1"
}

variable "vpc_cidr_block" {
  type        = string
  description = "Bloco CIDR /16 para VLSM"
  default     = "10.100.0.0/16"
}

variable "aws_subnet" {
  type        = number
  description = "Tamanho do bloco /24"
  default     = 24
}

Criação do Main

O main.tf é o ponto de entrada: aqui fica a definição do provider e a versão do Terraform. Os outros arquivos complementam, mas é o main que amarra tudo.

main.tf

// Definindo provedor
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

Finalização do Desafio

Esse desafio faz parte do Programa SRE Advanced da Elvenworks.

Repositório oficial da Elven: Minha Primeira VPC com Terraform
Meu repositório com o código deste desafio: Terraform VPC no GitLab

VPC em Subnet Pública

2025-03-28T00:00:00-03:00

O intuito deste post é iniciar falando sobre VPC e desenvolver o projeto em futuras postagens. Primeiramente, criaremos uma instância em uma sub-rede pública para servir como bastion host de acesso a uma instância em uma sub-rede privada. Ao longo dos próximos posts, iremos detalhar mais sobre o projeto.

Serviços Utilizados

VPC (Virtual Private Cloud): Rede isolada na AWS.
Internet Gateway (IGW): Conecta sua VPC à internet.
Subnet: Subdivisão de uma VPC.
Tabela de Rotas: Define o tráfego dentro da VPC e para a internet.
EC2: Serviço da AWS para instâncias de máquinas virtuais.

Cenário

Criar uma VPC.
Criar um Internet Gateway e associá-lo à VPC.
Criar uma subnet pública.
Criar uma tabela de rotas.
Associar a tabela de rotas à subnet.
Criar uma instância EC2.
Conectar-se à EC2 usando SSH.

Passo 1: Criando a VPC

Acesse a AWS Console e vá para “VPC”.
Clique em “Criar VPC”.
Nomeie como VPC-A.
Defina o CIDR como 10.100.0.0/16.
Clique em “Criar VPC”.

Passo 2: Criar Internet Gateway e Associar à VPC

Acesse “Internet Gateway” na AWS Console e crie um novo.
Nomeie como VPC-A-IGW.
Após a criação, associe o IGW à VPC VPC-A.

Passo 3: Criar a Subnet

Acesse VPC > Subnets e crie uma nova subnet com o nome VPC-A-Public.
Escolha uma AZ e defina o CIDR 10.100.0.0/24.

Colocando IP Public:
- Ações > Editar configuração de sub-rede . Configurações de atribuição automática de IP > Habilitar endereço IPV4 Público de atribuição automática > Habilitar

Passo 4: Criar Tabela de Rotas

Vá para VPC > Tabelas de rotas e crie uma nova tabela chamada VPC-A-Public-RT.
Adicione a rota 0.0.0.0/0 com o target IGW.

Passo 5: Associar Tabela de Rotas à Subnet

Selecione a tabela VPC-A-Public-RT.
Associe a subnet VPC-A-Public à tabela de rotas.

Passo 6: Criar uma EC2

Ao criar a EC2, escolha a VPC-A e a subnet VPC-A-Public.
Habilite a opção para atribuir um IP público.

Passo 7: Configuração de Segurança

Crie um Grupo de Segurança permitindo SSH (porta 22) para qualquer IP (0.0.0.0/0).

No próximo post, abordaremos como configurar uma instância EC2 em uma subnet privada.