Lab 03 — Da imagem ao deploy sem indisponibilidade: ECR, rolling update e drenagem

# Rode ANTES de mudar nada. O numero que sair daqui e a linha de base.
URL="https://$(terraform output -raw dominio)/api/health/ready"
ruins=0; total=0
( while true; do
    c=$(curl -s -o /dev/null -w "%{http_code}" --max-time 3 "$URL")
    total=$((total+1)); [ "$c" = "200" ] || ruins=$((ruins+1))
    echo "$(date +%T) $c"; sleep 0.2
  done ) &
LACO=$!
terraform apply -auto-approve   # o deploy do desenho MINIMO
kill $LACO
# Na Cadencia: 1.847 requisicoes, 412 nao-200 — cerca de 82 s de janela real,
# contra os "seis a doze minutos" do documento. Medir corrigiu as duas pontas.

// O que o EventBridge entrega quando o rollout muda de fase. E o payload que
// vale assinar para saber de deploy revertido sem ninguem olhando painel.
{
  "source": "aws.ecs",
  "detail-type": "ECS Deployment State Change",
  "resources": ["arn:aws:ecs:us-east-1:111122223333:service/ffv-lab/ffv-lab-api"],
  "detail": {
    "eventType": "ERROR",
    "eventName": "SERVICE_DEPLOYMENT_FAILED",
    "deploymentId": "ecs-svc/9223370491062737000",
    "updatedAt": "2026-08-07T14:22:31.618Z",
    // A mensagem do disjuntor: o rollout nao estabilizou e foi revertido.
    // Repare que a versao anterior volta sozinha — ninguem foi acordado.
    "reason": "ECS deployment circuit breaker: rolling back to desired count."
  }
}

# Dockerfile — multi-stage, e por que cada estagio existe

# ── Estagio de build: traz o SDK inteiro, que nao vai para producao ───────────
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

# Copiar SO o csproj antes do restore aproveita o cache de camada: mudar codigo
# nao invalida o restore, e o build cai de minutos para segundos. E tambem
# encurta a parcela `partida` da formula de rollout.
COPY ["Api/Api.csproj", "Api/"]
RUN dotnet restore "Api/Api.csproj"

COPY . .
RUN dotnet publish "Api/Api.csproj" -c Release -o /app/publish /p:UseAppHost=false

# ── Estagio final: runtime apenas ─────────────────────────────────────────────
# O SDK tem compilador, NuGet e cadeia de build — nada disso serve em producao, e
# tudo isso e superficie de ataque e bytes a baixar em CADA task nova.
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app

# Usuario sem privilegio. A imagem `aspnet` ja traz o `app` (UID 64198) criado.
USER app

# curl e para o health check do conteiner declarado na task definition. Se voce
# preferir imagem sem shell nem curl, troque por uma rota checada apenas pelo
# grupo de destino — mas ai perca a deteccao de conteiner vivo que nao serve.
COPY --from=build /app/publish .

EXPOSE 8080
ENV ASPNETCORE_URLS=http://+:8080

ENTRYPOINT ["dotnet", "Api.dll"]

# ecr.tf — o registro, e a imutabilidade que torna rollback possível

resource "aws_ecr_repository" "api" {
  name = "${var.projeto}-api"

  # A trava central deste laboratório. Com IMMUTABLE, enviar de novo a mesma tag
  # falha em vez de sobrescrever — então a task definition que aponta para
  # `...:a1b2c3d` continua se referindo ao MESMO conteúdo daqui a seis meses.
  # É o que transforma rollback de "reconstruir e esperar dar certo" em "apontar".
  image_tag_mutability = "IMMUTABLE"

  # Varredura na entrada. Reprovar aqui é barato; descobrir a CVE em produção não.
  image_scanning_configuration {
    scan_on_push = true
  }

  encryption_configuration {
    encryption_type = "KMS"
    kms_key         = aws_kms_key.app.arn
  }
}

# Sem política de ciclo de vida, tag imutável vira dívida de armazenamento: cada
# commit deixa uma imagem para sempre. Mantemos as 30 últimas — o suficiente para
# voltar alguns dias, que é o horizonte real de um rollback.
resource "aws_ecr_lifecycle_policy" "api" {
  repository = aws_ecr_repository.api.name

  policy = jsonencode({
    rules = [{
      rulePriority = 1
      description  = "Mantem as 30 imagens mais recentes"
      selection = {
        tagStatus   = "any"
        countType   = "imageCountMoreThan"
        countNumber = 30
      }
      action = { type = "expire" }
    }]
  })
}

# A task só precisa LER do registro, e quem lê é o agente de execução — não a
# aplicação. Menor privilégio aqui é separar os dois papéis, e é por isso que
# existem `execution_role` e `task_role` distintos.
data "aws_iam_policy_document" "pull_imagem" {
  statement {
    effect = "Allow"
    actions = [
      "ecr:GetAuthorizationToken",
      "ecr:BatchCheckLayerAvailability",
      "ecr:GetDownloadUrlForLayer",
      "ecr:BatchGetImage",
    ]
    # GetAuthorizationToken nao aceita recurso especifico: e uma operacao de
    # conta, nao de repositorio. As outras tres sao restritas ao repositorio,
    # e e assim que o `*` se justifica em vez de se esconder.
    resources = ["*"]
  }
}

output "repositorio_api" {
  value       = aws_ecr_repository.api.repository_url
  description = "URL do repositorio; a tag e sempre o SHA do commit"
}

// Program.cs — prontidao que diz a verdade, e desligamento que devolve tempo

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContextPool<AppDb>(o =>
    o.UseNpgsql(builder.Configuration.GetConnectionString("Padrao")));

// As duas rotas de saude respondem a perguntas DIFERENTES, e e por isso que sao
// duas. Misturá-las produz um dos dois defeitos: ou o balanceador manda trafego
// para quem nao pode atender, ou o ECS mata um conteiner que estava so ocupado.
builder.Services.AddHealthChecks()
    // VIVACIDADE: "o processo esta vivo?". Nao toca em dependencia nenhuma.
    // Se ela consultasse o banco, uma queda do banco reiniciaria todas as tasks
    // em laco — trocando indisponibilidade parcial por indisponibilidade total.
    .AddCheck("self", () => HealthCheckResult.Healthy(), tags: ["live"])
    // PRONTIDAO: "posso receber requisicao AGORA?". Aqui a dependencia entra,
    // porque uma task sem pool de conexao aberto vai responder 500 ao primeiro
    // cliente — e esse 500 aparece depois do rollout, sem ninguem ligar as duas coisas.
    .AddNpgSql(
        builder.Configuration.GetConnectionString("Padrao")!,
        name: "banco",
        tags: ["ready"]);

// Coerente com o stopTimeout de 30 s da definicao da task: o .NET tem de
// terminar ANTES de o ECS perder a paciencia e enviar SIGKILL.
builder.Services.Configure<HostOptions>(o =>
    o.ShutdownTimeout = TimeSpan.FromSeconds(
        builder.Configuration.GetValue("SHUTDOWN_TIMEOUT_SECONDS", 25)));

var app = builder.Build();

app.MapHealthChecks("/health/live", new HealthCheckOptions
{
    Predicate = r => r.Tags.Contains("live")
});

app.MapHealthChecks("/health/ready", new HealthCheckOptions
{
    Predicate = r => r.Tags.Contains("ready")
});

// O ASP.NET Core ja trata SIGTERM: ele para de aceitar conexao nova, termina o
// que esta em voo e sai. O log abaixo existe para o laboratorio — e para tornar
// a ordem dos estados OBSERVAVEL, que e a prova da secao seguinte.
var vida = app.Services.GetRequiredService<IHostApplicationLifetime>();
var log = app.Services.GetRequiredService<ILogger<Program>>();

vida.ApplicationStopping.Register(() =>
    log.LogWarning("SIGTERM recebido em {Instante} — drenagem do grupo de destino JA terminou",
        DateTimeOffset.UtcNow.ToString("O")));

vida.ApplicationStopped.Register(() =>
    log.LogWarning("processo encerrado em {Instante}", DateTimeOffset.UtcNow.ToString("O")));

app.MapGet("/api/pedidos/{id:guid}", async (Guid id, AppDb db) =>
    await db.Pedidos.FindAsync(id) is { } p ? Results.Ok(p) : Results.NotFound());

app.Run();

# deploy.tf — os tres relogios do rollout, explicitos

# ── Relogio 1: quanto tempo até a task nova ser considerada pronta ────────────
resource "aws_lb_target_group" "api" {
  name        = "${var.projeto}-api"
  port        = 8080
  protocol    = "HTTP"
  vpc_id      = aws_vpc.principal.id
  target_type = "ip" # awsvpc: o alvo e o IP da task, nao a instancia

  health_check {
    path = "/health/ready" # prontidao, nao vivacidade — sao rotas diferentes
    # 2 × 5 s = 10 s para entrar em servico, contra 150 s do padrao
    # (5 × 30 s). E o ajuste com maior efeito sobre a duracao do rollout.
    interval            = 5
    timeout             = 4 # < interval, senao verificacoes se sobrepoem
    healthy_threshold   = 2
    unhealthy_threshold = 2
    matcher             = "200"
  }

  # ── Relogio 2: o TETO da drenagem ──────────────────────────────────────────
  # Nao e uma espera fixa. O ECS aguarda o balanceador informar que a conexao
  # keep-alive do cliente fechou (alvo em UNUSED); este valor e o limite dessa
  # paciencia. Como o p99 desta API e 400 ms, 30 s cobre com folga de duas ordens
  # de grandeza. O padrao de 300 s nao esta errado — esta apenas generoso, e
  # multiplica por dez o tempo de cada rollout.
  #
  # NAO baixe para 5 s se a rota tiver upload lento, download longo, SSE ou
  # WebSocket: ai o prazo passa a cortar conexao legitima.
  deregistration_delay = 30

  stickiness {
    enabled = false # sessao pegajosa faz a conexao durar mais e a drenagem tambem
    type    = "lb_cookie"
  }
}

resource "aws_ecs_task_definition" "api" {
  family                   = "${var.projeto}-api"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 512
  memory                   = 1024
  execution_role_arn       = aws_iam_role.execucao.arn
  task_role_arn            = aws_iam_role.task.arn

  container_definitions = jsonencode([{
    name = "api"

    # O SHA do commit, injetado pelo pipeline. Nunca `:latest`: e o que permite
    # dizer qual versao esta no ar e voltar para a anterior.
    image     = "${aws_ecr_repository.api.repository_url}:${var.sha_da_imagem}"
    essential = true

    portMappings = [{ containerPort = 8080, protocol = "tcp" }]

    # ── Relogio 3: do SIGTERM ao SIGKILL ─────────────────────────────────────
    # Em Fargate isto vai na definicao da task. O ECS_CONTAINER_STOP_TIMEOUT que
    # a documentacao cita e opcao do AGENTE, configurada na instancia — e em
    # Fargate voce nao tem instancia, entao ele nao se aplica. Confundir os dois
    # faz alguem ajustar uma variavel que nunca sera lida.
    stopTimeout = 30

    healthCheck = {
      # Health check do ECS ≠ health check do grupo de destino. Este decide se o
      # CONTEINER e substituido; o do grupo decide se ele RECEBE TRAFEGO. Ter os
      # dois evita a task viva que nao serve e nunca e trocada.
      command     = ["CMD-SHELL", "curl -f http://localhost:8080/health/live || exit 1"]
      interval    = 10
      timeout     = 5
      retries     = 3
      startPeriod = 30
    }

    environment = [
      { name = "ASPNETCORE_URLS", value = "http://+:8080" },
      # Coerente com o stopTimeout acima: o .NET encerra antes de o ECS perder a
      # paciencia. Se ficar maior, o SIGKILL chega no meio do desligamento limpo.
      { name = "SHUTDOWN_TIMEOUT_SECONDS", value = "25" },
    ]

    secrets = [{
      name      = "ConnectionStrings__Padrao"
      valueFrom = aws_secretsmanager_secret.banco.arn
    }]

    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = aws_cloudwatch_log_group.api.name
        "awslogs-region"        = var.regiao
        "awslogs-stream-prefix" = "api"
      }
    }
  }])
}

resource "aws_ecs_service" "api" {
  name            = "${var.projeto}-api"
  cluster         = aws_ecs_cluster.principal.id
  task_definition = aws_ecs_task_definition.api.arn
  desired_count   = 2 # duas AZs; e tambem o minimo para haver rollout sem janela
  launch_type     = "FARGATE"

  # O par que autoriza a troca sem janela. O maximo da o espaco para a task nova
  # existir; o minimo PROIBE descer abaixo da capacidade declarada. Um sem o
  # outro nao resolve: com maximo 200 e minimo 0, o ECS pode parar tudo primeiro.
  deployment_minimum_healthy_percent = 100
  deployment_maximum_percent         = 200

  # Rollout que nao estabiliza volta sozinho para a revisao anterior. E o que
  # permite publicar sem alguem de vigia — que era o problema real da equipe.
  deployment_circuit_breaker {
    enable   = true
    rollback = true
  }

  # Tempo em que o health check do balanceador e IGNORADO depois de a task subir.
  # Sem isto, aplicacao com migration na partida e marcada insalubre, morta e
  # reiniciada — um ciclo que parece "o deploy travou" e nao deixa erro claro.
  health_check_grace_period_seconds = 60

  network_configuration {
    subnets          = aws_subnet.privada[*].id
    security_groups  = [aws_security_group.task.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.api.arn
    container_name   = "api"
    container_port   = 8080
  }

  depends_on = [aws_lb_listener.https]
}

# Mede o ALVO, nao o balanceador. A distincao e diagnostica: 5xx do alvo acusa a
# versao nova respondendo errado; 5xx do ALB acusa ausencia de alvo saudavel.
# O mesmo numero nas duas metricas conta historias opostas.
resource "aws_cloudwatch_metric_alarm" "erro_5xx_do_alvo" {
  alarm_name          = "${var.projeto}-api-5xx-alvo"
  namespace           = "AWS/ApplicationELB"
  metric_name         = "HTTPCode_Target_5XX_Count"
  statistic           = "Sum"
  period              = 60
  evaluation_periods  = 2
  threshold           = 5
  comparison_operator = "GreaterThanThreshold"
  treat_missing_data  = "notBreaching" # ausencia de erro nao e ausencia de dado

  dimensions = {
    LoadBalancer = aws_lb.principal.arn_suffix
    TargetGroup  = aws_lb_target_group.api.arn_suffix
  }

  alarm_actions = [aws_sns_topic.alertas.arn]
}

#!/usr/bin/env bash
# implantar.sh — a ordem importa, e cada passo tem prova
set -euo pipefail

PROJETO="${PROJETO:?defina PROJETO}"
REGIAO="${REGIAO:-us-east-1}"
CONTA="$(aws sts get-caller-identity --query Account --output text)"
REPO="${CONTA}.dkr.ecr.${REGIAO}.amazonaws.com/${PROJETO}-api"

# A identidade da imagem. `--short=12` e legivel e nao colide na pratica; use o
# SHA completo se preferir. `--dirty` impede publicar arvore com alteracao nao
# comitada, que produziria imagem sem commit correspondente.
SHA="$(git describe --always --dirty --match='' --abbrev=12)"
if [[ "$SHA" == *-dirty ]]; then
  echo "arvore com alteracao nao comitada: a imagem nao teria commit que a explique" >&2
  exit 1
fi

aws ecr get-login-password --region "$REGIAO" \
  | docker login --username AWS --password-stdin "${CONTA}.dkr.ecr.${REGIAO}.amazonaws.com"

docker build --platform linux/amd64 -t "${REPO}:${SHA}" .

# Com tag imutavel, reenviar a mesma tag FALHA — e essa falha e desejavel: ela
# diz que este commit ja foi publicado, e que nao ha nada novo a implantar.
docker push "${REPO}:${SHA}" || {
  echo "push recusado: a tag ${SHA} ja existe (imutabilidade). Nada a publicar." >&2
  exit 0
}

# Terraform cria a REVISAO nova da task definition e atualiza o servico. A
# revisao anterior continua existindo — e e para ela que o rollback aponta.
terraform apply -var="sha_da_imagem=${SHA}" -auto-approve

# `services-stable` volta quando o rollout terminou E estabilizou. Sem esta
# espera, o pipeline segue e um rollout que sera revertido em 90 s e reportado
# como sucesso.
aws ecs wait services-stable \
  --cluster "${PROJETO}" --services "${PROJETO}-api" --region "$REGIAO"

echo "no ar: ${SHA}"

# provas.sh — quatro medições; nenhuma conclusão vem de "parece que funcionou"

PROJETO=ffv-lab; REGIAO=us-east-1
TG=$(aws elbv2 describe-target-groups --names "${PROJETO}-api" \
      --query 'TargetGroups[0].TargetGroupArn' --output text)

# ── Prova 1: zero erro do cliente durante o rollout inteiro ──────────────────
# Um laco de requisicoes em paralelo ao deploy. E a unica prova que interessa ao
# criterio de aceite: qualquer codigo diferente de 200 aqui reprova o rollout.
URL="https://$(terraform output -raw dominio)/api/health/ready"
( while true; do
    curl -s -o /dev/null -w '%{http_code} ' "$URL"; sleep 0.2
  done ) & LACO=$!
./implantar.sh
kill $LACO
# Esperado: uma fileira continua de 200. Um unico 503 significa janela sem alvo
# saudavel; um 502 ou 504 significa conexao cortada na drenagem.

# ── Prova 2: a ordem dos estados, observada — não decorada ───────────────────
# Roda durante o rollout. A task velha tem de passar por DEACTIVATING ANTES de
# STOPPING, e e isto que mostra que a drenagem precede o SIGTERM.
watch -n1 "aws ecs describe-tasks --cluster $PROJETO \
  --tasks \$(aws ecs list-tasks --cluster $PROJETO --service-name ${PROJETO}-api \
              --desired-status ALL --query 'taskArns' --output text) \
  --query 'tasks[].{ver:taskDefinitionArn,ultimo:lastStatus,desejado:desiredStatus}' \
  --output table"

# ── Prova 3: o SIGTERM chega DEPOIS da drenagem ──────────────────────────────
# Compare o instante do log da aplicacao com o instante em que o alvo saiu de
# `draining`. O log da aplicacao tem de ser o mais TARDIO dos dois.
aws logs filter-log-events \
  --log-group-name "/ecs/${PROJETO}-api" \
  --filter-pattern "SIGTERM recebido" \
  --query 'events[].message' --output text

# ── Prova 4: a imutabilidade da tag realmente impede sobrescrever ────────────
# Deve falhar. Se passar, `image_tag_mutability` nao esta como IMMUTABLE, e todo
# o raciocinio de rollback deste modulo esta sem base.
SHA=$(git describe --always --abbrev=12)
docker push "$(terraform output -raw repositorio_api):${SHA}" \
  && echo "FALHA DA PROVA: a tag foi sobrescrita" \
  || echo "OK: o registro recusou sobrescrever ${SHA}"

# O rollback que o resto do modulo tornou possivel: sem build, sem push.
# A revisao anterior da task definition continua existindo, e a imagem dela
# tambem — porque a tag e imutavel e o ciclo de vida guarda 30.
PROJETO=ffv-lab
ANTERIOR=$(aws ecs describe-services --cluster $PROJETO \
  --services ${PROJETO}-api \
  --query "services[0].deployments[?status=='ACTIVE'].taskDefinition | [0]" \
  --output text)

# Se o disjuntor ja reverteu sozinho, este comando nao tem o que fazer — e
# essa e a situacao desejada. O rollback manual e a rede sob a rede.
aws ecs update-service --cluster $PROJETO --service ${PROJETO}-api \
  --task-definition "$ANTERIOR"
aws ecs wait services-stable --cluster $PROJETO --services ${PROJETO}-api

# Confirme QUAL versao voltou. "O rollback funcionou" sem o SHA na mao e fe.
aws ecs describe-task-definition --task-definition "$ANTERIOR" \
  --query "taskDefinition.containerDefinitions[0].image" --output text

# 1. Derrube o que o Terraform administra.
terraform destroy -auto-approve

# 2. REPOSITORIO ECR COM IMAGEM: o destroy falha se houver imagem dentro, a
#    menos que force_delete esteja ligado. Se voce interrompeu no meio, o
#    repositorio pode continuar de pe COM as 30 imagens, cobrando GB-mes.
aws ecr describe-repositories --query "repositories[].repositoryName" --output table
aws ecr list-images --repository-name ffv-lab-api \
  --query "length(imageIds)" --output text
aws ecr batch-delete-image --repository-name ffv-lab-api \
  --image-ids "$(aws ecr list-images --repository-name ffv-lab-api \
                  --query 'imageIds' --output json)" 2>/dev/null || true
aws ecr delete-repository --repository-name ffv-lab-api --force

# 3. GRUPO DE LOGS: tem retencao propria e nao pertence ao ciclo do servico.
#    Fica cobrando ingestao retida depois de tudo apagado.
aws logs delete-log-group --log-group-name /ecs/ffv-lab-api 2>/dev/null || true

# 4. REVISOES DA TASK DEFINITION: nao cobram, mas acumulam e poluem. Um
#    rollout de 20 deploys deixa 20 revisoes ATIVAS.
for arn in $(aws ecs list-task-definitions --family-prefix ffv-lab-api \
               --query "taskDefinitionArns" --output text); do
  aws ecs deregister-task-definition --task-definition "$arn" >/dev/null
done

# 5. ALARME e topico SNS, se voce os criou fora do Terraform.
aws cloudwatch delete-alarms --alarm-names ffv-lab-api-5xx-alvo 2>/dev/null || true

# 6. E o que veio do L01 e continua cobrando por hora: ALB, RDS, endpoint de
#    VPC, NAT Gateway e o Elastic IP dele. Se voce nao vai seguir para o L04,
#    rode a limpeza do L01 tambem — e confira o Elastic IP orfao, que cobra
#    justamente por NAO estar associado a nada.
aws ec2 describe-addresses --query "Addresses[?AssociationId==null].PublicIp" \
  --output table

# 7. Prova final: nada com nome do projeto de pe.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=ffv-lab \
  --query "ResourceTagMappingList[].ResourceARN" --output table