No exame DOP-C02, as estrategias de implantacao sao um dos topicos mais amplamente testados. Alem de conhecer os nomes das estrategias, voce precisa determinar qual e otima para requisitos empresariais especificos — tempo de inatividade aceitavel, velocidade de rollback, manutencao de capacidade durante a implantacao e restricoes de custo. Compreender o fluxo completo desde o gerenciamento de artefatos ate a execucao da implantacao e essencial.
Servicos de gerenciamento de artefatos
Amazon ECR - Registro de imagens de conteineres
ECR e um registro de conteineres totalmente gerenciado para armazenar imagens Docker. Pontos principais do ECR para o exame:
Tags de imagem vs resumos de imagem: A tag e mutavel — uma nova imagem enviada ao ECR com a tag nao garante que tarefas ja em execucao usarao a nova imagem, pois o ECS pode usar uma versao em cache. Os resumos de imagem (hashes SHA256) sao identificadores imutaveis que fixam uma imagem exata. Especificar uma imagem como em uma definicao de tarefa ECS garante que a mesma imagem seja sempre usada.
Varredura de imagens ECR: Varredura basica (verificacao automatica de vulnerabilidades no envio) e varredura avancada (integracao do Inspector v2 com monitoramento continuo).
AWS CodeArtifact - Repositorio de pacotes
O CodeArtifact fornece repositorios privados para npm, pip, Maven, Gradle e outros formatos de pacotes. Conexoes de upstream com registros publicos (PyPI, registro npm, Maven Central) armazenam automaticamente em cache os pacotes, reduzindo dependencias de internet e habilitando controles de seguranca sobre quais pacotes podem ser usados nas compilacoes.
EC2 Image Builder - Automacao de AMI
O EC2 Image Builder automatiza a criacao, teste e distribuicao de AMIs. Uma receita de imagem define a AMI base, os componentes de software a serem instalados e os testes de validacao. Os pipelines de imagem sao executados em um cronograma para produzir AMIs atualizadas automaticamente.
Cenario do exame: "A inicializacao da instancia apos o scale-out do Auto Scaling leva 15 minutos devido a instalacao de bibliotecas grandes." A solucao e criar uma AMI dourada com bibliotecas pre-instaladas usando EC2 Image Builder. Isso e explicitamente diferente da instalacao em tempo de execucao do .ebextensions.
Comparacao completa de estrategias de implantacao
Estrategias de implantacao EC2
Opcoes de implantacao in-place do CodeDeploy: AllAtOnce: Todas as instancias atualizadas simultaneamente. Mais rapido. Ocorre tempo de inatividade durante a atualizacao. OneAtATime: Uma instancia por vez sequencialmente. Mais lento. Maxima disponibilidade mantida. Sem custo adicional. HalfAtATime: Metade das instancias por vez. Velocidade e disponibilidade equilibradas.
Implantacao Blue/Green do CodeDeploy: Provisiona um novo grupo de Auto Scaling (Green) ao lado do grupo existente (Blue). A troca de grupo de destino do ALB transfere o trafego instantaneamente. A capacidade total e mantida durante a implantacao. Rollback imediato e possivel voltando para o grupo anterior.
Grupos de destino ponderados do ALB para canary: Registra dois ASGs como grupos de destino separados e ajusta pesos na regra do listener do ALB. Comeca com 5% de peso no grupo de destino da nova versao e aumenta gradualmente. Definir o peso da nova versao como 0 alcanca rollback instantaneo.
Instance Refresh do ASG: Apos atualizar a AMI em um Launch Template, inicia um Instance Refresh para substituir automaticamente instancias antigas por novas enquanto mantem MinHealthyPercentage (padrao 90%). Nenhuma instalacao de agente separado ou configuracao complexa de grupo de implantacao necessaria.
Estrategias de implantacao do Elastic Beanstalk em profundidade
O Elastic Beanstalk oferece cinco politicas de implantacao. O exame requer diferenciacao precisa entre elas.
| Politica | Inatividade | Rollback | Custo | Caracteristica principal | |---------|------------|---------|------|------------------------| | All at once | Sim | Requer reimplantacao | Nenhum | Mais rapido, mais simples | | Rolling | Nao (capacidade reduzida) | Requer reimplantacao | Nenhum | Versoes misturadas durante a implantacao | | Rolling with additional batch | Nao (capacidade total) | Requer reimplantacao | Pequena adicao temporaria | Manutencao de capacidade eficiente em custo | | Immutable | Nao | Imediato (encerrar novo ASG) | Temporariamente duplo | Rollback seguro em um unico ambiente | | Traffic splitting | Nao | Reajuste de proporcao | Adicional temporario | Testes A/B canary |
Caracteristicas principais da implantacao Immutable
O Immutable implanta novas instancias em um ASG temporario completamente separado, isolado do ASG de producao existente. Apos as verificacoes de saude passarem, as instancias migram para o ASG existente e o ASG temporario e excluido. Se a implantacao falhar, encerrar o ASG temporario e tudo que e necessario — as instancias originais nao sao afetadas. Ao contrario do Blue/Green (que requer um ambiente Beanstalk separado mais troca de CNAME), o Immutable opera dentro de um unico ambiente.
Blue/Green CNAME Swap vs Immutable
Ambas as estrategias fornecem implantacao sem tempo de inatividade e rollback rapido, mas o contexto de uso e diferente. CNAME Swap e otimo quando dois ambientes Beanstalk separados (preparacao e producao) ja existem — a troca de trafego e uma mudanca em nivel de DNS e e praticamente sem tempo de inatividade. Immutable e apropriado quando se gerencia um unico ambiente sem necessidade de um ambiente de preparacao paralelo. Para rollback mais rapido quando ha dois ambientes disponiveis, CNAME Swap e preferivel porque o rollback e simplesmente outra troca de CNAME, sem necessidade de reimplantar.
!CNAME Swap vs implantação Immutable
Estrategias de implantacao Lambda
Lambda Aliases e versoes
Uma versao do Lambda e um snapshot imutavel de codigo e configuracao em um momento especifico. Um alias do Lambda e um ponteiro para uma versao especifica (ou duas versoes com roteamento ponderado). Quando os chamadores usam o ARN do alias, o trafego pode ser deslocado para diferentes versoes subjacentes sem nenhuma modificacao de codigo no lado do chamador.
Configuracoes de implantacao CodeDeploy Lambda
LambdaCanary10Percent5Minutes: 10% do trafego para a nova versao por 5 minutos, depois transicao para 100% LambdaLinear10PercentEvery1Minute: 10% a mais de trafego para a nova versao a cada minuto, atingindo 100% apos 10 minutos
O hook BeforeAllowTraffic no appspec.yml executa uma funcao Lambda de validacao antes que qualquer trafego seja deslocado para a nova versao. Pode verificar a conclusao da migracao do esquema do banco de dados, a prontidao do endpoint de API ou qualquer outro prerequisito. Falha aciona rollback automatico antes que qualquer usuario experiencie a nova versao.
SAM AutoPublishAlias + DeploymentPreference
Em um template SAM, definir AutoPublishAlias publica automaticamente uma nova versao do Lambda em cada implantacao e a conecta ao alias nomeado. Adicionar DeploymentPreference configura a implantacao canary ou linear do CodeDeploy automaticamente. A configuracao completa requer apenas mudancas YAML no template SAM — o pipeline de CI/CD existente nao requer nenhuma modificacao.
Estrategias de implantacao ECS
ECS Rolling Update
Atualiza o servico substituindo gradualmente as tarefas pela nova definicao de tarefa. MinimumHealthyPercent e MaximumPercent controlam a taxa de substituicao. Simples de configurar, mas nao fornece isolamento de listener de teste nem capacidade de rollback instantaneo. E adequado para atualizacoes de baixo risco onde se aceita que versoes antigas e novas executem simultaneamente durante a implantacao.
CodeDeploy ECS Blue/Green
Configura o ALB com um listener de teste (porta 8080) separado do listener de producao (porta 80/443). O novo conjunto de tarefas (Green) e validado pelo listener de teste antes que qualquer trafego de producao o toque. O hook AfterAllowTestTraffic executa testes automatizados contra o ambiente Green. Somente apos validacao bem-sucedida o CodeDeploy desloca o trafego de producao. Problemas acionam rollback instantaneo para o conjunto de tarefas Blue.
A disciplina na rotulagem de imagens ECR importa: usar tags em definicoes de tarefas ECS e um anti-padrao documentado. Fixar nos resumos de imagem combinado com agrupar todas as dependencias no Dockerfile em tempo de build elimina tanto a ambiguidade de versionamento quanto o risco de dependencia externa.
Pontos-chave do exame
"substituir AMI em centenas de instancias EC2 no Auto Scaling sem tempo de inatividade" -- ASG Instance Refresh (atualizar AMI do Launch Template, iniciar refresh, manteve MinHealthyPercentage)
"manter capacidade total durante implantacao Beanstalk com custo adicional minimo" -- Rolling with additional batch (mais eficiente em custo que Immutable)
"implantacao sem tempo de inatividade com rollback instantaneo em um unico ambiente Beanstalk" -- implantacao Immutable
"troca instantanea de trafego entre dois ambientes Beanstalk com capacidade de rollback" -- URL Swap (troca de CNAME)
"implantacao canary baseada em EC2 com controle fino de proporcao de trafego" -- grupos de destino ponderados do ALB (dois ASGs, ajustar pesos na regra do listener)
"nova versao do Lambda com 10% de trafego primeiro depois transicao gradual com rollback automatico" -- configuracao de implantacao LambdaCanary do CodeDeploy + gatilho de rollback do CloudWatch Alarm
"validar prontidao do esquema de banco de dados antes da transicao de trafego do Lambda" -- hook de ciclo de vida BeforeAllowTraffic do CodeDeploy (funcao Lambda de validacao)
"isolar e validar ambiente Green do ECS antes da transicao do trafego de producao" -- CodeDeploy ECS Blue/Green + listener de teste (porta 8080) + hook AfterAllowTestTraffic
"reduzir tempo de inicializacao de instancias EC2 de 15 minutos para segundos" -- AMI dourada do EC2 Image Builder com bibliot