Lab 39 — Blue/green e canário no ECS

// O que o EventBridge entrega quando o CodeDeploy reverte por alarme. Repare
// que a mensagem nomeia a CAUSA — o alarme, nao "falha generica".
{
  "source": "aws.codedeploy",
  "detail-type": "CodeDeploy Deployment State-Change Notification",
  "resources": ["arn:aws:codedeploy:us-east-1:111122223333:deploymentgroup:ffv-lab-api/ffv-lab-api"],
  "detail": {
    "deploymentId": "d-ABC123XYZ",
    "state": "STOP",
    // O motivo distingue de um DEPLOYMENT_FAILURE comum: o alarme do alvo
    // verde disparou DURANTE a janela do canario, nao antes nem depois dela.
    "deploymentTrigger": "DEPLOYMENT_STOP_ON_ALARM",
    "instanceGroupId": null
  }
}

# blue-green.tf — dois grupos de destino completos, e o listener de teste
#
# O grupo AZUL e o mesmo conceito do L03 (aws_lb_target_group.api), agora com
# um segundo nome porque passa a ser metade de um par, nao mais o unico. O
# grupo VERDE nasce vazio: quem o povoa, a cada deploy, e o CodeDeploy.

resource "aws_lb_target_group" "blue" {
  name        = "${var.projeto}-api-blue"
  port        = 8080
  protocol    = "HTTP"
  vpc_id      = aws_vpc.principal.id
  target_type = "ip"

  health_check {
    path                = "/health/ready"
    interval            = 5
    timeout             = 4
    healthy_threshold   = 2
    unhealthy_threshold = 2
    matcher             = "200"
  }

  # A drenagem continua existindo aqui - e atributo do GRUPO, nao do par
  # blue/green. O valor derivado do p99 no L03 nao muda: a pergunta que ele
  # responde (quanto esperar a conexao do cliente fechar) e a mesma.
  deregistration_delay = 30
}

resource "aws_lb_target_group" "green" {
  name        = "${var.projeto}-api-green"
  port        = 8080
  protocol    = "HTTP"
  vpc_id      = aws_vpc.principal.id
  target_type = "ip"

  health_check {
    path                = "/health/ready"
    interval            = 5
    timeout             = 4
    healthy_threshold   = 2
    unhealthy_threshold = 2
    matcher             = "200"
  }

  deregistration_delay = 30
}

# Listener de PRODUCAO: obrigatorio no schema, e o unico caminho do cliente
# real. Aponta para o grupo azul ate o primeiro deploy - depois disso, quem
# move a regra e o CodeDeploy, nao mais o Terraform.
resource "aws_lb_listener" "producao" {
  load_balancer_arn = aws_lb.principal.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = aws_acm_certificate.api.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.blue.arn
  }
}

# Listener de TESTE: opcional no schema da AWS, obrigatorio na pratica deste
# laboratorio - e o unico caminho pelo qual o hook AfterAllowTestTraffic
# alcanca a frota verde pelo MESMO balanceador do cliente, sem expor a frota
# ao publico. Porta separada; origem restrita ao grupo de seguranca do hook.
resource "aws_lb_listener" "teste" {
  load_balancer_arn = aws_lb.principal.arn
  port              = 8443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = aws_acm_certificate.api.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.blue.arn # o CodeDeploy troca para green durante o teste
  }
}

resource "aws_security_group_rule" "listener_teste_so_da_validacao" {
  type                     = "ingress"
  from_port                = 8443
  to_port                  = 8443
  protocol                 = "tcp"
  security_group_id        = aws_security_group.alb.id
  source_security_group_id = aws_security_group.hook_validacao.id
  description              = "so o hook de validacao alcanca o listener de teste; nunca a internet"
}

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
  launch_type     = "FARGATE"

  # A troca central deste laboratorio: quem decide substituir tasks deixa de
  # ser o proprio ECS (rolling update do L03) e passa a ser o CodeDeploy. Os
  # dois controladores sao mutuamente exclusivos - e e por isso que o
  # disjuntor de implantacao do L03 (deployment_circuit_breaker) NAO EXISTE
  # como opcao valida neste bloco.
  deployment_controller {
    type = "CODE_DEPLOY"
  }

  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.blue.arn # so a associacao INICIAL
    container_name   = "api"
    container_port   = 8080
  }

  # A partir do primeiro deploy pelo CodeDeploy, estes tres campos deixam de
  # refletir a realidade no Terraform: o CodeDeploy cria revisoes de task
  # definition e troca o grupo de destino por fora do state. Sem
  # ignore_changes, o PROXIMO `terraform apply` tenta devolver o servico ao
  # que o state ainda acha que e verdade - a guerra entre ferramentas que o
  # antipadrao desta secao nomeia.
  lifecycle {
    ignore_changes = [task_definition, load_balancer, desired_count]
  }
}

# codedeploy.tf — quem orquestra a troca, o alarme e a reversao automatica

resource "aws_codedeploy_app" "api" {
  name             = "${var.projeto}-api"
  compute_platform = "ECS"
}

resource "aws_codedeploy_deployment_group" "api" {
  app_name              = aws_codedeploy_app.api.name
  deployment_group_name = "${var.projeto}-api"
  service_role_arn      = aws_iam_role.codedeploy.arn

  # Canario, nao linear e nao all-at-once: desloca 10% por 5 minutos antes de
  # decidir o resto. E o parametro que responde ao problema declarado -
  # limita a exposicao a uma fatia pequena, por uma janela observavel. Um
  # Network Load Balancer so aceita CodeDeployDefault.ECSAllAtOnce; canario e
  # linear exigem Application Load Balancer, que e o que este laboratorio usa.
  deployment_config_name = "CodeDeployDefault.ECSCanary10Percent5Minutes"

  deployment_style {
    deployment_type   = "BLUE_GREEN"
    deployment_option = "WITH_TRAFFIC_CONTROL"
  }

  ecs_service {
    cluster_name = aws_ecs_cluster.principal.name
    service_name = aws_ecs_service.api.name
  }

  load_balancer_info {
    target_group_pair_info {
      prod_traffic_route {
        listener_arns = [aws_lb_listener.producao.arn]
      }
      target_group {
        name = aws_lb_target_group.blue.name
      }
      target_group {
        name = aws_lb_target_group.green.name
      }
      test_traffic_route {
        listener_arns = [aws_lb_listener.teste.arn]
      }
    }
  }

  blue_green_deployment_config {
    deployment_ready_option {
      action_on_timeout = "CONTINUE_DEPLOYMENT" # nao trava esperando aprovacao manual
    }

    terminate_blue_instances_on_deployment_success {
      action = "TERMINATE"
      # Sem padrao documentado pela AWS: declare explicitamente. 30 min cobre
      # o tempo humano de perceber um problema sutil que nem o alarme nem o
      # canario pegaram, sem manter a frota azul dobrada por muito tempo. O
      # teto do campo e 2880 minutos (48 h) - meca o SEU cenario antes de
      # copiar este numero.
      termination_wait_time_in_minutes = 30
    }
  }

  # Duas reversoes independentes, cobrindo gatilhos diferentes - mesma logica
  # de "duas redes de seguranca" do disjuntor + alarme do L03, com um
  # mecanismo diferente por baixo:
  #   DEPLOYMENT_FAILURE       -> o proprio CodeDeploy detectou falha (ex.: um
  #                               hook respondeu Failed, ou a frota verde
  #                               nunca ficou saudavel)
  #   DEPLOYMENT_STOP_ON_ALARM -> um alarme do CloudWatch associado disparou
  #                               DURANTE a janela de teste ou de canario
  auto_rollback_configuration {
    enabled = true
    events  = ["DEPLOYMENT_FAILURE", "DEPLOYMENT_STOP_ON_ALARM"]
  }

  alarm_configuration {
    alarms  = [aws_cloudwatch_metric_alarm.erro_5xx_do_alvo_verde.alarm_name]
    enabled = true
  }
}

# Mede o alvo VERDE, especificamente - nao "o servico" e nao o alvo azul, que
# continua saudavel e nao tem relacao com o deploy em curso. Escopar no grupo
# errado e o jeito mais comum de este alarme nunca disparar.
resource "aws_cloudwatch_metric_alarm" "erro_5xx_do_alvo_verde" {
  alarm_name          = "${var.projeto}-api-5xx-alvo-verde"
  namespace           = "AWS/ApplicationELB"
  metric_name         = "HTTPCode_Target_5XX_Count"
  statistic           = "Sum"
  period              = 60 # curto de proposito: o primeiro incremento do canario dura so 5 min
  evaluation_periods  = 2
  threshold           = 5
  comparison_operator = "GreaterThanThreshold"
  treat_missing_data  = "notBreaching"

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

  alarm_actions = [aws_sns_topic.alertas.arn]
}

# O papel do CodeDeploy: descreve alarmes, chama a Lambda dos hooks, e
# modifica ECS e ELB em nome do deploy. Managed policy oficial - nao
# reescrever a mao: ja e o menor privilegio documentado para este uso.
resource "aws_iam_role" "codedeploy" {
  name = "${var.projeto}-codedeploy-ecs"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "codedeploy.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "codedeploy_ecs" {
  role       = aws_iam_role.codedeploy.name
  policy_arn = "arn:aws:iam::aws:policy/AWSCodeDeployRoleForECS"
}

# appspec.yaml.tpl — a revisao que CreateDeployment registra
#
# TaskDefinition e o ARN completo, COM revisao - e o unico lugar que aponta
# para a imagem nova. ContainerName/ContainerPort tem de bater com o
# load_balancer da definicao de servico original. So um hook esta em uso
# aqui, de proposito - os outros quatro (BeforeInstall, AfterInstall,
# BeforeAllowTraffic, AfterAllowTraffic) existem e aceitam Lambda, mas
# adicionar validacao em todos sem necessidade so alonga o deploy sem
# alongar a cobertura: o teste de concorrencia so faz sentido depois que a
# frota verde existe e antes de qualquer trafego de producao chegar nela -
# que e exatamente o AfterAllowTestTraffic.
version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "${NOVA_TASK_DEFINITION_ARN}"
        LoadBalancerInfo:
          ContainerName: "api"
          ContainerPort: 8080
Hooks:
  - AfterAllowTestTraffic: "ffv-lab-validar-frota-verde"

// ValidarFrotaVerde/Function.cs — hook AfterAllowTestTraffic, em .NET 8
//
// O que o health check do L03 nao pode provar: que a frota aguenta
// CONCORRENCIA real, nao so uma conexao. Este hook dispara requisicoes
// SIMULTANEAS pelo listener de TESTE — o mesmo caminho do balanceador que o
// cliente usa, so que sem cliente nenhum — e so devolve Succeeded se a taxa
// de erro e a latencia ficarem dentro do que a versao anterior ja provou
// suportar. E o achado deste laboratorio: prontidao confirma que o PROCESSO
// responde; isto confirma que ele responde BEM sob carga real.

using Amazon.Lambda.Core;
using Amazon.CodeDeploy;
using Amazon.CodeDeploy.Model;

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

public class Function
{
    // Um socket por requisicao simultanea reproduz concorrencia real; reusar
    // uma unica conexao mascararia exatamente o defeito que este hook existe
    // para achar (pool de conexao do banco esgotando sob carga).
    private static readonly HttpClient _http = new(new SocketsHttpHandler
    {
        MaxConnectionsPerServer = 50
    });

    private const string ListenerTeste = "https://interno.ffv-lab.local:8443/api/pedidos/existente";
    private const int Concorrencia = 30;      // ~metade do pico medido em hora cheia
    private const double LimiteErro = 0.02;   // 2%: acima disso, a versao anterior nunca chegou
    private const int LimiteP99Ms = 800;      // 2x o p99 historico de 400 ms medido no L03

    public async Task FunctionHandler(HookEvent evt, ILambdaContext ctx)
    {
        using var codedeploy = new AmazonCodeDeployClient();

        var tarefas = Enumerable.Range(0, Concorrencia).Select(_ => MedirUmaRequisicao());
        var resultados = await Task.WhenAll(tarefas);

        var taxaErro = resultados.Count(r => !r.Ok) / (double)Concorrencia;
        var amostrasOrdenadas = resultados.Select(r => r.Ms).OrderBy(x => x).ToArray();
        var p99 = Percentil(amostrasOrdenadas, 0.99);

        var status = (taxaErro <= LimiteErro && p99 <= LimiteP99Ms)
            ? LifecycleEventStatus.Succeeded
            : LifecycleEventStatus.Failed;

        ctx.Logger.LogInformation(
            $"validacao da frota verde: erro={taxaErro:P1} p99={p99}ms -> {status}");

        // O CodeDeploy so segue (ou reverte) depois desta chamada. Sem ela
        // dentro de 1 hora, a implantacao inteira e marcada como falha.
        await codedeploy.PutLifecycleEventHookExecutionStatusAsync(
            new PutLifecycleEventHookExecutionStatusRequest
            {
                DeploymentId = evt.DeploymentId,
                LifecycleEventHookExecutionId = evt.LifecycleEventHookExecutionId,
                Status = status
            });
    }

    private static async Task<(bool Ok, long Ms)> MedirUmaRequisicao()
    {
        var relogio = System.Diagnostics.Stopwatch.StartNew();
        try
        {
            var resp = await _http.GetAsync(ListenerTeste);
            return (resp.IsSuccessStatusCode, relogio.ElapsedMilliseconds);
        }
        catch
        {
            return (false, relogio.ElapsedMilliseconds);
        }
    }

    private static long Percentil(long[] amostrasOrdenadas, double p)
    {
        var indice = (int)Math.Ceiling(p * amostrasOrdenadas.Length) - 1;
        return amostrasOrdenadas[Math.Clamp(indice, 0, amostrasOrdenadas.Length - 1)];
    }
}

public class HookEvent
{
    public string DeploymentId { get; set; } = "";
    public string LifecycleEventHookExecutionId { get; set; } = "";
}

#!/usr/bin/env bash
# implantar-canario.sh — registra a revisao nova e pede ao CodeDeploy para
# desloca-la aos poucos; nao ao ECS para substituir tudo de uma vez.
set -euo pipefail

PROJETO="${PROJETO:?defina PROJETO}"
SHA="$(git describe --always --dirty --abbrev=12)"
[[ "$SHA" == *-dirty ]] && { echo "arvore suja, comite antes" >&2; exit 1; }

# 1. Mesma disciplina do L03: imagem por SHA, registro imutavel.
REPO="$(terraform output -raw repositorio_api)"
docker build --platform linux/amd64 -t "${REPO}:${SHA}" .
docker push "${REPO}:${SHA}"

# 2. Task definition em REVISAO NOVA - nao toca no servico ainda. Quem faz o
#    servico apontar para ela e o CodeDeploy, nao um `update-service`.
NOVA=$(aws ecs register-task-definition \
  --cli-input-json "$(envsubst < task-definition.json)" \
  --query 'taskDefinition.taskDefinitionArn' --output text)
echo "revisao registrada: ${NOVA}"

# 3. O AppSpec e a revisao que o CodeDeploy consome - referencia a task
#    definition do passo 2.
NOVA_TASK_DEFINITION_ARN="$NOVA" envsubst < appspec.yaml.tpl > /tmp/appspec.yaml

DEPLOY_ID=$(aws deploy create-deployment \
  --application-name "${PROJETO}-api" \
  --deployment-group-name "${PROJETO}-api" \
  --revision "revisionType=AppSpecContent,appSpecContent={content=$(cat /tmp/appspec.yaml)}" \
  --query 'deploymentId' --output text)
echo "$DEPLOY_ID" > /tmp/deploy-id.txt

echo "deployment ${DEPLOY_ID}: canario de 10% por 5 min, depois 100% se o alarme ficar quieto"
aws deploy wait deployment-successful --deployment-id "$DEPLOY_ID"
echo "no ar: ${SHA}"

# provas.sh — cinco medicoes; a primeira e a que MUDA em relacao ao L03: aqui
# o criterio de aceite nao e "zero erro", e "erro contido a uma fatia pequena
# e por uma janela curta" — porque o canario existe para limitar exposicao,
# nao para eliminar risco de deploy ruim.

PROJETO=ffv-lab
TG_VERDE=$(aws elbv2 describe-target-groups --names "${PROJETO}-api-green" \
  --query 'TargetGroups[0].TargetGroupArn' --output text)

# ── Prova 1: a exposicao fica contida no percentual do canario ──────────────
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=$!
./quebrar-de-proposito.sh
kill $LACO
# Esperado: uma fatia pequena e finita de erros durante a janela do primeiro
# incremento (nunca mais que ~10-15% no total, mesmo somando 5 minutos), e
# ZERO erro depois da reversao. Erro crescendo sem teto indica que o alarme
# nao disparou ou o auto_rollback_configuration nao inclui DEPLOYMENT_STOP_ON_ALARM.

# ── Prova 2: a frota verde existe inteira antes do primeiro cliente ─────────
aws ecs describe-task-sets --cluster $PROJETO --service ${PROJETO}-api \
  --query 'taskSets[].{grupo:targetGroupInfo.targetGroupArn,status:status,estavel:computedDesiredCount}' \
  --output table
# Esperado: dois conjuntos de tarefas durante o deploy, os dois com o
# computedDesiredCount total do servico — nao um crescendo aos poucos.

# ── Prova 3: o alarme mede o alvo verde, e so ele ────────────────────────────
aws cloudwatch describe-alarms --alarm-names "${PROJETO}-api-5xx-alvo-verde" \
  --query 'MetricAlarms[0].{estado:StateValue,dimensoes:Dimensions}'
# Esperado: StateValue em ALARM durante a falha injetada, com a dimensao
# TargetGroup apontando para o grupo VERDE — se apontar para o azul ou para o
# ALB inteiro, o alarme nunca vai medir o que importa.

# ── Prova 4: a reversao e reapontar o listener, nao reconstruir nada ────────
aws elbv2 describe-listeners --load-balancer-arn "$(terraform output -raw alb_arn)" \
  --query "Listeners[?Port==\`443\`].DefaultActions[0].TargetGroupArn" --output text
# Esperado, apos a reversao: o ARN do grupo AZUL. Nenhum build, nenhum push,
# nenhuma nova revisao de task definition foi criada para reverter.

# ── Prova 5: a frota azul continua viva depois da reversao ──────────────────
aws ecs describe-task-sets --cluster $PROJETO --service ${PROJETO}-api \
  --query 'taskSets[?status==`PRIMARY`].{status:status,estavel:stabilityStatus}'
# Esperado: PRIMARY com STEADY_STATE. Se a azul tivesse sido derrubada, nao
# haveria para onde reverter — e o rollback deste laboratorio depende dela
# estar de pe.

# quebrar-de-proposito.sh — injeta o MESMO defeito do incidente real: uma
# variavel que forca uma consulta lenta sob concorrencia, sem mexer no
# health check (que continua respondendo 200, exatamente como no incidente
# que motivou este laboratorio).

# Ver Program.cs: sob 30+ chamadas simultaneas, cada uma prende o pool por
# 2 s a mais. Uma requisicao isolada nao mostra nada — e por isso o defeito
# passa no health check e so aparece sob carga real.
export SIMULAR_REGRESSAO_CONCORRENCIA=true
PROJETO=ffv-lab ./implantar-canario.sh &
IMPLANTAR_PID=$!

# Esperado: perto dos 5 minutos do primeiro incremento, o alarme de 5xx do
# alvo VERDE dispara, o CodeDeploy para o deslocamento e devolve o listener
# de producao 100% para a azul — sem voce tocar em nada.
sleep 360
aws deploy get-deployment --deployment-id "$(cat /tmp/deploy-id.txt)" \
  --query 'deploymentInfo.{estado:status,motivo:errorInformation.message}'

wait $IMPLANTAR_PID || echo "implantacao terminou com reversao — e o resultado esperado deste teste"

# limpar.sh — o que este laboratorio acrescenta ao L03, e o que sobrevive

# 1. Deployment group e app do CodeDeploy — nao cobram por hora, mas ficam
#    orfaos se voce apagar o servico ECS primeiro.
aws deploy delete-deployment-group \
  --application-name ffv-lab-api --deployment-group-name ffv-lab-api
aws deploy delete-application --application-name ffv-lab-api

# 2. Segundo grupo de destino, e o listener de teste — cobram por hora como
#    qualquer grupo/listener do L01, mesmo vazios.
terraform destroy -target=aws_lb_listener.teste \
                   -target=aws_lb_target_group.green \
                   -auto-approve

# 3. O alarme do alvo verde nao desaparece sozinho quando o grupo de destino
#    e apagado — ele so fica "sem dado", o que NAO e a mesma coisa que apagado.
aws cloudwatch delete-alarms --alarm-names ffv-lab-api-5xx-alvo-verde

# 4. Revisoes de task definition acumuladas pelos deploys do CodeDeploy —
#    nao cobram, mas poluem a lista tanto quanto no L03.
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. Resto do Terraform (blue.tf, codedeploy.tf) e o que o L03/L01 ja
#    cobravam — ALB, RDS, NAT, Elastic IP. Rode a limpeza deles tambem se nao
#    for seguir para o L54.
terraform destroy -auto-approve