CLImbaprenda AWS CLI digitando Praticar de graça

🔀Entenda o CodeDeploy blue/green: Lambda e ECS

Em Lambda e em contêiner não existe "copiar o pacote pra máquina". O que o CodeDeploy faz é trocar o tráfego: a versão nova sobe ao lado da velha, recebe uma fatia pequena (ou nada, enquanto você testa) e só depois recebe tudo. Se algo der errado, o tráfego volta — a versão velha nunca saiu do ar.

Pra que serve

É o deploy sem medo de produção: no Lambda, o canary manda 10% das chamadas pra versão nova e espera; no ECS, as tarefas novas sobem atrás de um segundo target group e o load balancer troca de um pro outro de uma vez. Voltar atrás é mudar o ponteiro de volta, em segundos.

Onde se usa no mundo real

Uma API de cobrança em Lambda recebe a versão nova só em 10% das chamadas por 5 minutos; se os erros subirem, o CodeDeploy devolve tudo pra versão anterior.
O site da loja em ECS sobe as tarefas novas no target group verde, o QA testa, e só aí o listener troca — sem nenhuma requisição cair.
Um deploy de sexta à tarde é parado com rollback: o alias volta pra versão de ontem antes de o suporte perceber.

Vocabulário

Blue/green: a versão atual (azul) e a nova (verde) no ar ao mesmo tempo; o tráfego troca de uma pra outra.
Canary: a nova recebe uma fatia pequena primeiro (10%), e o resto depois do tempo de espera.
Alias: o apelido estável do Lambda; o deploy muda pra qual versão ele aponta.
Target group: o grupo de tarefas atrás do load balancer; no blue/green do ECS são dois, e eles se revezam.
Listener: quem escuta a porta no load balancer e decide pra qual target group o tráfego vai.
appspec: o arquivo do deploy: em Lambda, alias e versões; em ECS, a task definition nova e o container.

💰 Como cobra: O CodeDeploy não cobra pra Lambda nem pra ECS — você paga o Lambda e as tarefas do ECS, que durante o blue/green ficam em dobro por alguns minutos. Comparando: blue/green x rolling — o rolling troca as tarefas aos poucos no mesmo lugar (e voltar exige outro deploy); o blue/green mantém a versão velha pronta até o fim, e voltar é só mudar o tráfego.

Comandos que você aprende nesta trilha

Cada um deles roda de verdade no terminal do CLImb, com a mesma saída e as mesmas mensagens de erro que a AWS devolve.

`aws lambda create-function`

aws lambda create-function

aws lambda create-function --function-name <nome>
--runtime <runtime> --role <arn-da-role>
--handler <arquivo.função> --zip-file fileb://<código.zip>

`aws lambda publish-version`

aws lambda publish-version

aws lambda publish-version --function-name processa-pedido

`aws lambda create-alias`

aws lambda create-alias

aws lambda create-alias --function-name processa-pedido \
--name prod --function-version 1

`aws lambda get-alias`

USO

aws lambda get-alias --function-name <função> --name <alias>

`aws deploy create-application`

USO

aws deploy create-application --application-name <nome> [--compute-platform Server|Lambda|ECS]

`aws deploy create-deployment-group`

USO

aws deploy create-deployment-group --application-name <app> --deployment-group-name <grupo> \
--service-role-arn arn:aws:iam::<conta>:role/<role> \
--ec2-tag-filters Key=<tag>,Value=<valor>,Type=KEY_AND_VALUE \
[--deployment-config-name CodeDeployDefault.OneAtATime] \
[--auto-rollback-configuration enabled=true,events=DEPLOYMENT_FAILURE]

`aws lambda update-function-code`

aws lambda update-function-code

aws lambda update-function-code --function-name processa-pedido \
--zip-file fileb://app.zip

`aws deploy create-deployment`

USO

aws deploy create-deployment --application-name <app> --deployment-group-name <grupo> \
--s3-location bucket=<bucket>,key=<pacote.zip>,bundleType=zip \
[--deployment-config-name ...] [--description <texto>]

`aws deploy get-deployment`

USO

aws deploy get-deployment --deployment-id <d-XXXXXXXXX>

`aws deploy get-deployment-target`

USO

aws deploy get-deployment-target --deployment-id <id> --target-id <i-...>

`aws deploy stop-deployment`

USO

aws deploy stop-deployment --deployment-id <id>

`aws ecs create-cluster`

aws ecs create-cluster

aws ecs create-cluster --cluster-name cluster-loja

`aws ecs register-task-definition`

aws ecs register-task-definition

aws ecs register-task-definition --family tarefa-web --container-definitions file://tarefa-web.json
aws ecs register-task-definition --family tarefa-web --container-definitions '[{"name":"web","image":"nginx:latest","memory":512}]'

`aws elbv2 create-load-balancer`

USO

aws elbv2 create-load-balancer --name loja-alb --subnets subnet-a subnet-b

`aws elbv2 create-target-group`

USO

aws elbv2 create-target-group --name loja-tg --protocol HTTP --port 80 --vpc-id vpc-xxxx

`aws elbv2 create-listener`

USO

aws elbv2 create-listener --load-balancer-arn <arn> --protocol HTTP --port 80 --default-actions Type=forward,TargetGroupArn=<tg-arn>

`aws ecs create-service`

aws ecs create-service

aws ecs create-service --cluster cluster-loja --service-name servico-web --task-definition tarefa-web --desired-count 2

`aws elbv2 describe-listeners`

USO

aws elbv2 describe-listeners --load-balancer-arn <arn> | --listener-arns <arn>

`aws deploy continue-deployment`

USO

aws deploy continue-deployment --deployment-id <id> [--deployment-wait-type READY_WAIT|TERMINATION_WAIT]

O que você pratica (30 atividades)

Cada atividade é um pedido de trabalho, do jeito que ele chega no dia a dia — você resolve digitando os comandos, não escolhendo alternativa.

A API de cobrança

O time de pagamentos tem uma API de cobrança em Lambda e quer trocar de versão sem derrubar ninguém. Comece pela função: crie a cobranca-api (python3.12, handler app.handler, role arn:aws:iam::123456789012:role/cobranca-role, código no app.zip).

Congele a versão 1

O CodeDeploy troca tráfego entre VERSÕES — o $LATEST não serve, porque muda a cada deploy. Publique a versão 1 da cobranca-api com a descrição primeira.

O nome que os clientes chamam

Quem chama a API não deve saber número de versão. Crie o alias producao apontando pra versão 1.

Pra onde o alias aponta?

Confira o alias producao: a versão e o ARN que os clientes usam.

A aplicação de Lambda

Crie no CodeDeploy a aplicação cobranca-lambda para a plataforma Lambda.

Canary de 10%

Crie o grupo cobranca-producao na cobranca-lambda com a role arn:aws:iam::123456789012:role/codedeploy-servico e a configuração CodeDeployDefault.LambdaCanary10Percent5Minutes: 10% das chamadas vão pra versão nova primeiro, o resto depois.

O código novo da cobrança

O time corrigiu o cálculo de juros. Suba o código novo (app.zip) na cobranca-api — isso muda só o $LATEST; o alias continua na versão 1.

Congele a versão 2

Publique a versão 2 da cobranca-api (descrição juros-corrigidos) — é ela que o deploy vai levar pro alias.

O appspec do deploy

Leia o revisao-cobranca-v2.json: é a revisão do deploy. Dentro do content, o appspec diz qual alias (producao) sai de qual versão (CurrentVersion 1) pra qual (TargetVersion 2).

O deploy da versão 2

Entregue a versão 2 no grupo cobranca-producao usando a revisão revisao-cobranca-v2.json.

10% na versão nova

Consulte o deploy uma vez e olhe o alias producao: ele continua na versão 1, mas com um RoutingConfig mandando 10% das chamadas pra versão 2. É o canary acontecendo.

O canary passou

Os 5 minutos de canary passaram sem erro. Consulte o deploy até ele terminar e confira: agora o alias aponta inteiro pra versão 2.

O que o CodeDeploy fez no alias

Veja o deploy do ponto de vista do alvo: o alias como alvo, as etapas (BeforeAllowTraffic, AllowTraffic, AfterAllowTraffic) e o peso da versão nova.

A versão 3 está dando erro

Sexta, 17h: a versão 3 foi pro canary e o monitoramento mostra erro de pagamento nos 10%. Reproduza — código novo, publique a versão 3 (descrição nova-bandeira), deploy com revisao-cobranca-v3.json e uma consulta — e pare o deploy com rollback. Confira que o alias voltou inteiro pra versão 2.

O cluster da vitrine

Agora o site da loja, que roda em contêiner. Crie o cluster cluster-vitrine no ECS.

A receita da vitrine

Registre a task definition vitrine-web com o arquivo pronto tarefa-web.json (container web, porta 80).

O load balancer da loja

O tráfego da loja entra por um load balancer. Crie o alb-vitrine nas sub-redes subnet-vitrine-a e subnet-vitrine-b.

Os dois lados: azul e verde

Blue/green precisa de DOIS target groups, um pra cada lado. Crie o tg-vitrine-azul e o tg-vitrine-verde (HTTP, porta 80, VPC vpc-0f00d1e00c11ab001).

A porta 80 aponta pro azul

Crie o listener do alb-vitrine na porta 80 (HTTP) encaminhando pro tg-vitrine-azul — ele é o lado que está no ar hoje.

O serviço que o CodeDeploy controla

Crie o serviço vitrine-web no cluster-vitrine (task definition vitrine-web, 2 tarefas) atrás do tg-vitrine-azul, e — o ponto principal — com o controlador de deploy CODE_DEPLOY.

Pra onde o tráfego vai hoje?

Confira os listeners do alb-vitrine: a porta 80 manda pro target group azul. Anote o ListenerArn — o CodeDeploy vai precisar dele.

A aplicação de ECS

Crie no CodeDeploy a aplicação vitrine-ecs para a plataforma ECS.

O grupo blue/green

Crie o grupo vitrine-producao na vitrine-ecs: serviço vitrine-web do cluster-vitrine, os dois target groups (azul e verde), o listener da porta 80, a role arn:aws:iam::123456789012:role/codedeploy-servico, configuração CodeDeployDefault.ECSAllAtOnce e — pra dar tempo de testar — o deploy parando em Ready antes de trocar o tráfego.

A revisão 2 da vitrine

O time mudou o layout da loja. Registre a revisão 2 da vitrine-web (mesmo arquivo — cada registro vira uma revisão nova).

O verde sobe, o azul atende

Entregue a revisão 2 com revisao-vitrine-v2.json no grupo vitrine-producao e consulte o deploy: ele para em Ready — as tarefas novas estão de pé no verde, e o tráfego AINDA vai pro azul.

Os dois lados no ar

Veja o alvo do deploy: dois conjuntos de tarefas, BLUE com 100% do tráfego e GREEN com 0%, cada um no seu target group.

O QA aprovou: troque o tráfego

O QA testou a versão nova no verde e aprovou. Libere o deploy e acompanhe até terminar.

O listener trocou de lado

Confirme no load balancer: a porta 80 agora encaminha pro tg-vitrine-verde. No próximo deploy, ele é o "azul".

A revisão 3 não passou no teste

Revisão 3 no ar pra teste: registre a nova task definition, entregue com revisao-vitrine-v3.json, espere o Ready — o QA reprovou. Pare o deploy com rollback e confirme que o tráfego nunca saiu do lado que estava atendendo.

A revisão 4: os lados se revezam

O time corrigiu o que o QA achou. Registre a revisão 4, entregue com revisao-vitrine-v4.json, espere o Ready, libere depois do teste e acompanhe até terminar. Aí confira o listener: o tráfego voltou pro tg-vitrine-azul — a cada deploy, o lado que estava parado vira o novo.

Continue por aqui

Ler explica. Digitar fixa. No CLImb você roda os comandos de verdade num terminal AWS simulado — o estado persiste entre eles, como na nuvem real.

As 3 primeiras atividades desta trilha são abertas; o resto faz parte do plano Pro.

Começar — 3 atividades grátis

Todas as lições · Instalar a AWS CLI · Comandos básicos · Erros comuns · Praticar no terminal · Sobre