Automatização do gerenciamento dinâmico de pipelines para implantar soluções de hotfix em ambientes Gitflow usando o AWS Service Catalog e o AWS CodePipeline - Recomendações da AWS
ResumoPré-requisitos e limitaçõesArquiteturaFerramentasPráticas recomendadasÉpicosSolução de problemasRecursos relacionadosMais informações

Automatização do gerenciamento dinâmico de pipelines para implantar soluções de hotfix em ambientes Gitflow usando o AWS Service Catalog e o AWS CodePipeline

Balaji Vedagiri, Faisal Shahdad, Shanmugam Shanker e Vivek Thangamuthu, Amazon Web Services

Resumo

nota

O AWS CodeCommit não está mais disponível para novos clientes. Os clientes atuais do AWS CodeCommit podem continuar usando o serviço normalmente. Saiba mais

Este padrão aborda um cenário de gerenciamento de um pipeline dinâmico de hotfix dedicado exclusivamente à implantação segura de soluções de hotfix em um ambiente de produção. A solução é implementada e gerenciada usando um portfólio e um produto do AWS Service Catalog. Uma regra do Amazon EventBridge é usada para automação de eventos. As restrições são aplicadas usando as restrições do portfólio do Service Catalog e os perfis do AWS Identity and Access Management (IAM) para desenvolvedores. Somente uma função do AWS Lambda tem permissão para iniciar o produto do Service Catalog, acionada pela regra do EventBridge. Este padrão foi projetado para ambientes com uma configuração específica do Gitflow, descrita em Informações adicionais.

Normalmente, um hotfix é implantado para resolver problemas críticos ou de segurança relatados em um ambiente ativo, como de produção. Os hotfixes devem ser implantados diretamente somente nos ambientes de preparação e produção. Os pipelines de preparação e produção são usados extensivamente para solicitações regulares de desenvolvimento. Esses pipelines não podem ser usados para implantar hotfixes porque há atributos contínuos de garantia de qualidade que não podem ser promovidos à produção. Para lançar hotfixes, este padrão descreve um pipeline dinâmico e de curta duração com os seguintes atributos de segurança:

  • Criação automática: um pipeline de hotfix é criado automaticamente sempre que uma ramificação de hotfix é criada em um repositório do AWS CodeCommit.

  • Restrições de acesso: os desenvolvedores não têm acesso para criar esse pipeline fora do processo de hotfix.

  • Estágio controlado: o pipeline tem um estágio controlado com um token de acesso especial, garantindo que uma solicitação de pull (PR) só possa ser criada uma vez.

  • Estágios de aprovação: os estágios de aprovação são incluídos no pipeline para obter as aprovações necessárias das partes interessadas relevantes.

  • Exclusão automática: o pipeline de hotfix é excluído automaticamente sempre que uma ramificação hotfix é excluída no repositório do CodeCommit após ser mesclada com uma PR.

Pré-requisitos e limitações

Pré-requisitos

  • São necessárias três Contas da AWS ativas da seguinte forma:

    • Conta de ferramentas: para a configuração de integração contínua e entrega contínua (CI/CD).

    • Conta de preparação: para testes de aceitação do usuário.

    • Conta de produção: para um usuário final comercial.

    • (Opcional) Adicione uma Conta da AWS para atuar como uma conta de controle de qualidade. Essa conta é necessária se você quiser uma configuração de pipeline principal, incluindo controle de qualidade, e uma solução de pipeline de hotfix para testes.

  • Uma pilha do AWS CloudFormation com uma condição opcional para ser implantada na conta de controle de qualidade usando o pipeline principal, se necessário. O padrão ainda pode ser testado sem a configuração do pipeline principal, criando e excluindo uma ramificação hotfix.

  • Um bucket do Amazon Simple Storage Service (Amazon S3) para armazenar os modelos do CloudFormation que são usados para criar produtos do Service Catalog.

  • Crie regras de aprovação para uma PR no repositório do CodeCommit de acordo com os requisitos de conformidade (depois de criar o repositório).

  • Restrinja as permissões do IAM de desenvolvedores e líderes de equipe para negar a execução da função do Lambda prcreation-lambda, pois ela deve ser invocada somente pelo pipeline.

Limitações

  • O provedor do CloudFormation é usado no estágio de implantação, e a aplicação é implantada usando um conjunto de alterações do CloudFormation. Se você quiser usar uma opção de implantação diferente, modifique a pilha do CodePipeline conforme necessário.

  • O padrão usa o AWS CodeBuild e outros arquivos de configuração para implantar um microsserviço de amostra. Se você tiver um tipo de workload diferente (por exemplo, workloads com tecnologia sem servidor), deverá atualizar todas as configurações relevantes.

  • Este padrão implanta a aplicação em uma única Região da AWS (por exemplo, Leste dos EUA (Norte da Virgínia) us-east-1) em todas as Contas da AWS. Para implantar em várias regiões, altere a referência da região em comandos e pilhas.

  • Alguns Serviços da AWS não estão disponíveis em todas as Regiões da AWS. Para conferir a disponibilidade de uma região, consulte AWS Services by Region. Para endpoints específicos, consulte Service endpoints and quotas e clique no link correspondente ao serviço desejado.

Arquitetura

Os diagramas nesta seção fornecem fluxos de trabalho para um evento do ciclo de vida de criação e para um evento do ciclo de vida de exclusão.

Fluxo de trabalho para criar um evento de ciclo de vida.

O diagrama anterior para criar um evento de ciclo de vida mostra o seguinte:

  1. O desenvolvedor cria uma ramificação hotfix-* no repositório do CodeCommit para desenvolver uma solução relacionada ao hotfix.

  2. O evento de criação da ramificação hotfix-* é capturado por meio da regra do EventBridge. Os detalhes do evento incluem o nome do repositório e o nome da ramificação.

  3. A regra do EventBridge invoca a função hotfix-lambda-function do AWS Lambda. A regra do EventBridge passa as informações do evento para a função do Lambda como entrada.

  4. A função do Lambda processa a entrada para recuperar o nome do repositório e o nome da ramificação. Ele lança o produto do Service Catalog com valores recuperados da entrada processada.

  5. O produto do Service Catalog inclui uma configuração de pipeline que implantará a solução nos ambientes de preparação e produção. O bloco de pipeline inclui estágios de origem, compilação e implantação. Além disso, há um estágio de aprovação manual para promover a implantação no ambiente de produção.

  6. O estágio de origem recupera o código do repositório e da ramificação hotfix-* que foram criados na primeira etapa. O código é passado para o estágio de compilação por meio de um bucket do Amazon S3 para artefatos. No estágio de compilação, é criada uma imagem de contêiner que inclui o hotfix que é desenvolvido na ramificação hotfix-* e enviado ao Amazon Elastic Container Registry (Amazon ECR).

  7. O estágio de implantação ao ambiente de estágio atualiza o Amazon Elastic Container Service (Amazon ECS) com a imagem de contêiner mais recente que inclui o hotfix. O hotfix é implantado criando e executando um conjunto de alterações do CloudFormation.

  8. A função prcreation-lambda do Lambda é invocada após a implantação bem-sucedida no ambiente de preparação. Essa função do Lambda cria uma PR com base na ramificação hotfix-* para as ramificações develop e main do repositório. A função do Lambda garante que a correção desenvolvida na ramificação hotfix-* seja mesclada novamente e incluída nas implantações subsequentes.

  9. Um estágio de aprovação manual ajuda a garantir que as partes interessadas necessárias revisem a correção e aprovem a implantação na produção.

  10. O estágio de implantação ao ambiente de produção atualiza o Amazon ECS com a imagem de contêiner mais recente que inclui o hotfix. O hotfix é implantado criando e executando um conjunto de alterações do CloudFormation.

Fluxo de trabalho para excluir um evento de ciclo de vida.

O diagrama anterior para excluir um evento de ciclo de vida mostra o seguinte:

  1. O desenvolvedor exclui a ramificação hotfix-* após a implantação bem-sucedida do hotfix no ambiente de produção.

  2. O evento de exclusão da ramificação hotfix-* é capturado por meio de uma regra do EventBridge. Os detalhes do evento incluem o nome do repositório e o nome da ramificação.

  3. A regra do EventBridge invoca a função do Lambda. A regra do EventBridge passa as informações do evento para a função do Lambda como entrada.

  4. A função do Lambda processa a entrada para recuperar o nome do repositório e o nome da ramificação. A função do Lambda determina o respectivo produto do Service Catalog com base na entrada passada e, em seguida, encerra o produto.

  5. O encerramento do produto provisionado pelo Service Catalog exclui o pipeline e os recursos relevantes que foram criados anteriormente nesse produto.

Automação e escala

  • O padrão inclui uma regra do EventBridge e uma função do Lambda, que podem lidar com várias solicitações de criação de ramificações de hotfix em paralelo. A função do Lambda provisiona o produto do Service Catalog para a regra de evento correspondente.

  • A configuração do pipeline é feita usando o produto do Service Catalog, que fornece recursos de controle de versão. A solução também se expande automaticamente para lidar com vários desenvolvimentos de hotfix para a mesma aplicação em paralelo.

  • A função prcreation-lambda garante que essas alterações de hotfix também sejam mescladas novamente nas ramificações main e develop por meio de uma criação automática de solicitação de pull. Essa abordagem é essencial para manter as ramificações main e develop atualizadas com todas as correções e evitar possíveis regressões de código. Esse processo ajuda a manter a consistência entre as ramificações e evitar regressões de código, garantindo que todas as ramificações de longa duração tenham as correções mais recentes.

Ferramentas

Serviços da AWS

  • O AWS CloudFormation permite configurar recursos da AWS, provisioná-los com rapidez e consistência e administrá-los durante todo o ciclo de vida, abrangendo Contas da AWS e Regiões da AWS.

  • O AWS CodeBuild é um serviço de compilação totalmente gerenciado que permite compilar o código-fonte, realizar testes de unidade e produzir artefatos preparados para a implantação.

  • O AWS CodeCommit é um serviço de controle de versão que ajuda no armazenamento e no gerenciamento de repositórios Git de forma privada, sem a necessidade de administrar o próprio sistema de controle de origem. O AWS CodeCommit não está mais disponível para novos clientes. Os clientes atuais do AWS CodeCommit podem continuar usando o serviço normalmente. Para obter mais informações, consulte How to migrate your AWS CodeCommit repository to another Git provider.

  • O AWS CodePipeline ajuda você a modelar e configurar rapidamente os diferentes estágios de uma versão de software, além de automatizar as etapas necessárias para a implantação contínua de alterações.

  • O Amazon Elastic Container Registry (Amazon ECR) é um serviço gerenciado de registro de imagens de contêineres seguro, escalável e confiável.

  • O Amazon Elastic Container Service (Amazon ECS) é um serviço de gerenciamento de contêineres escalável e rápido que facilita a execução, a interrupção e o gerenciamento de contêineres em um cluster.

  • O AWS Key Management Service (AWS KMS) ajuda na criação e no controle de chaves criptográficas, contribuindo para a proteção dos seus dados.

  • O AWS Service Catalog permite gerenciar de forma centralizada catálogos de serviços de TI que têm aprovação para uso na AWS. Os usuários finais podem implantar rapidamente somente os serviços de TI aprovados de que precisam, seguindo as restrições definidas pela organização.

  • O Amazon Simple Storage Service (Amazon S3) é um serviço de armazenamento de objetos baseado na nuvem que ajuda você a armazenar, proteger e recuperar qualquer quantidade de dados.

Outras ferramentas

  • O CloudFormation Linter (cfn-lint) é um linter que verifica os modelos YAML ou JSON do CloudFormation em relação à especificação de recursos do CloudFormation. Ele também executa outras verificações, como a verificação de valores válidos para as propriedades dos recursos e a adesão às práticas recomendadas.

  • cfn-nag é uma ferramenta de código aberto que identifica possíveis problemas de segurança nos modelos do CloudFormation por meio de uma busca de padrões.

  • O Docker é um conjunto de produtos de plataforma como serviço (PaaS) que usam a virtualização no nível do sistema operacional para fornecer software em contêineres. Esse padrão usa o Docker para compilar e testar imagens de contêiner localmente.

  • O Git é um sistema de controle de versão distribuído e de código aberto.

Repositório de código

O código para este padrão está disponível no repositório dynamic_hotfix_codepipeline do GitHub.

Práticas recomendadas

Analise e ajuste os perfis do IAM e as políticas de controle de serviços (SCP) em seu ambiente para garantir que elas restrinjam o acesso de forma adequada. Isso é crucial para evitar quaisquer ações que possam anular as medidas de segurança incluídas neste padrão. Respeite o princípio de privilégio mínimo, garantindo somente as permissões estritamente necessárias para a execução de uma tarefa. Para obter mais informações, consulte Concessão de privilégio mínimo e Práticas recomendadas de segurança na documentação do IAM.

Épicos

TarefaDescriçãoHabilidades necessárias

Clonar o repositório.

Para clonar o repositório de amostra em um novo diretório em seu local de trabalho, execute o seguinte comando:

git clone git@github.com:aws-samples/dynamic_hotfix_codepipeline.git
AWS DevOps

Exporte variáveis de ambiente para implantação de pilha do CloudFormation.

Defina as variáveis de ambiente que serão usadas como entrada para as pilhas do CloudFormation posteriormente neste padrão.

  • ApplicationName: essa variável é usada para nomear recursos criados para uma aplicação, facilitando o rastreamento deles. Use o seguinte comando, substituindo Applicationname pelo nome real da aplicação: 

    export ApplicationName=<Applicationname>

  • BucketStartName: essa variável serve para nomear um bucket do Amazon S3. Os nomes de buckets do S3 devem ser exclusivos globalmente em todas as Contas da AWS. Use o seguinte comando, substituindo BucketName por um nome exclusivo do seu bucket do S3:

export BucketStartName=<BucketName>

  • Números de conta e regiões: essas variáveis armazenam números de Conta da AWS de diferentes ambientes e da região de implantação. Use os comandos a seguir, substituindo os espaços reservados (como prodaccountnumber e region) pelos números reais de suas Conta da AWS e a Região da AWS que você usa.

    nota

    QAAccount é opcional. Se você quiser usar QAAccount, configure-o usando os parâmetros da pilha principal do pipeline.

export ProdAccount=<prodaccountnumber>
export StageAccount=<stage/preprodaccountnumber>
export QAAccount=<qaccountnumber>
export ToolsAccount=<toolsaccountnumber>
export DepRegion=<region>
AWS DevOps
TarefaDescriçãoHabilidades necessárias

Crie os recursos necessários para CI/CD na conta de ferramentas.

Para implantar a pilha do CloudFormation na conta de ferramentas, use os comandos a seguir. (Remova o parâmetro QAAccount se você não estiver usando a conta de controle de qualidade para configuração.)

#InToolsAccount
aws cloudformation deploy \
    --template-file pre-requisites/pre-reqs.yaml \
    --stack-name prereqs \
    --parameter-overrides BucketStartName=${BucketStartName} \
    ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \
    StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \
    QAAccount=${QAAccount} \
    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}

Anote os recursos que o repositório do CodeCommit e o Amazon ECR criaram com base na pilha anterior. Esses parâmetros são necessários para configurar a ramificação main do pipeline nas próximas etapas.

AWS DevOps

Crie os recursos necessários para CI/CD nas contas de workload.

  1. Para empacotar o modelo do CloudFormation em cada conta de workload (estágio, produção e controle de qualidade opcional), use os comandos a seguir. No seguinte comando, substitua S3bucketpackage pelo nome do bucket do Amazon S3 que você deseja usar para empacotar.

    #InStageAccount
aws cloudformation package \
    --template-file pre-requisites/infrastack.yaml \
    --s3-bucket <S3bucketpackage> \
    --s3-prefix infraStack \
    --region ${DepRegion} \
    --output-template-file pre-requisites/infrastructure_stage.template

#InProdAccount
aws cloudformation package \
    --template-file pre-requisites/infrastack.yaml \
    --s3-bucket <S3bucketpackage> \
    --s3-prefix infraStack \
    --region ${DepRegion} \
    --output-template-file pre-requisites/infrastructure_prod.template

  2. Para implantar o modelo do CloudFormation em cada conta de workload, use os seguintes comandos:

    #InStageAccount
aws cloudformation deploy --stack-name inframainstack \
--parameter-overrides  ApplicationName=${ApplicationName} ToolsAccount=${ToolsAccount} DepRegion=${DepRegion} \
--template-file pre-requisites/infrastructure_stage.template  --region ${DepRegion} --capabilities CAPABILITY_NAMED_IAM

#InProdAccount
aws cloudformation deploy --stack-name inframainstack \
--parameter-overrides  ApplicationName=${ApplicationName} ToolsAccount=${ToolsAccount} DepRegion=${DepRegion} \
--template-file pre-requisites/infrastructure_prod.template  --region ${DepRegion} --capabilities CAPABILITY_NAMED_IAM
AWS DevOps

Atualize a política de bucket de artefatos do S3 para permitir o acesso às contas de workload.

Para atualizar os pré-requisitos da pilha do CloudFormation na conta de ferramentas, use os comandos a seguir para adicionar todas as permissões necessárias às contas de workload de preparação e produção. (Remova o parâmetro QAAccount se você não o estiver usando para configuração.)

#InToolsAccount
aws cloudformation deploy \
    --template-file pre-requisites/pre-reqs.yaml \
    --stack-name prereqs \
    --parameter-overrides BucketStartName=${BucketStartName} \
    ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \
    StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \
    QAAccount=${QAAccount} PutPolicy=true \
    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}
AWS DevOps
TarefaDescriçãoHabilidades necessárias

Configure o portfólio e os produtos do Service Catalog.

Para configurar o portfólio e os produtos do Service Catalog, faça o seguinte:

  1. Faça upload dos modelos pipeline-main.yaml e pipeline-hotfix.yaml do repositório no diretório do CodePipeline para um bucket existente do Amazon S3 (Bucketname) na região em que você deseja implantar (DepRegion).

    #InToolsAccount
aws s3 cp ./codepipeline/pipeline-main.yaml s3://<Bucketname>/pipeline-main.yaml
aws s3 cp ./codepipeline/pipeline-hotfix.yaml s3://<Bucketname>/pipeline-hotfix.yaml

  2. Configure o portfólio e o produto do Service Catalog que vão gerenciar o pipeline das ramificações main e hotfix. Anote os detalhes da seção Outputs para MainProductId e MainProductArtifactId da pilha a seguir. As informações são necessárias em etapas posteriores durante o pipeline de configuração da ramificação main.

    #InToolsAccount
aws cloudformation deploy \
    --template-file pre-requisites/servicecatalogsetup.yaml \
    --stack-name servicecatalogsetup \
    --parameter-overrides TemplateBucket=<Bucketname> \
    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}

  3. Forneça acesso a um perfil do IAM que implantará recursos na conta de ferramentas no portfólio principal do pipeline do portfólio Service Catalog. Use esse portfólio para implantar a aplicação usando a ramificação main. Para obter mais informações sobre como fornecer acesso, consulte Granting Access to Users na documentação do Service Catalog.

AWS DevOps

Configure as funções do Lambda.

Essa solução usa as seguintes funções do Lambda para gerenciar fluxos de trabalho de hotfix:

  • hotfix-lambda-function executa o provisionamento de produtos do Service Catalog quando uma ramificação hotfix é criada.

  • hotfix-cleanup-lambda-function gerencia o encerramento do produto quando uma ramificação hotfix é excluída.

  • prcreation-lambda cria solicitações de pull da ramificação hotfix para as ramificações develop e main.

Para permitir que as funções do Lambda provisionem e encerrem produtos do Service Catalog quando ramificações hotfix forem criadas ou excluídas por meio da regra do EventBridge associada, siga as etapas abaixo:

  1. Para criar as permissões e perfis do IAM para as funções do Lambda, use o comando a seguir para implantar uma pilha do CloudFormation:

    #InToolsAccount aws cloudformation deploy \ --template-file pre-requisites/lambdasetup.yaml \ --stack-name prsclambdasetup \ --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}

  2. Após a implantação da pilha, conceda o acesso hotfix-lambda-execution-role ao portfólio do pipeline de hotfix do portfólio Service Catalog usando o Console de gerenciamento da AWS. Esse acesso permite que a função do Lambda inicie ou encerre o produto do Service Catalog para ramificações de hotfix.

AWS DevOps
TarefaDescriçãoHabilidades necessárias

Configure o pipeline da ramificação main.

Para configurar o pipeline da ramificação principal, execute o comando a seguir na conta de ferramentas. Substitua os parâmetros de MainProductId e MainProductArtifactId por valores das saídas da pilha servicecatalogsetup.

#InToolsAccount
aws servicecatalog provision-product \
    --product-id <MainProductId> \
    --provisioning-artifact-id <MainProductArtifactId> \
    --provisioned-product-name "${ApplicationName}-main-pipeline" \
    --provisioning-parameters Key=CodeCommitRepoName,Value="${ApplicationName}-repository" Key=ECRRepository,Value="${ApplicationName}-app" \
    --region=${DepRegion}
AWS DevOps

Implante a aplicação usando a ramificação main.

  1. Para clonar o repositório do CodeCommit que foi criado em prereqs, use o comando git clone. Para obter mais informações, consulte Connect to the CodeCommit repository by cloning the repository na documentação do CodeCommit.

  2. Copie todos os arquivos da aplicação do diretório repotemplates disponível no repositório para o clone local do seu repositório (${ApplicationName}-repository). Modifique os arquivos a seguir para atualizar o ID ToolsAccount. Em cada arquivo, localize o parâmetro RegistryAccountid e defina esse valor como seu ID ToolsAccount. Confirme as alterações no repositório do CodeCommit e envie os arquivos para as ramificações main e develop.

  3. Para verificar a implantação da aplicação, monitore a execução do CodePipeline usando o Console de gerenciamento da AWS. Após a conclusão da implantação, acesse a aplicação usando o FQDN do Application Load Balancer no ambiente de preparação. Confirme se a aplicação funciona conforme o esperado.

  4. Para aprovar a implantação para produção, use o console do CodePipeline para localizar o pipeline da sua aplicação. Encontre o estágio ApprovalToStart. Analise as alterações e, se satisfatórias, forneça aprovação manual para continuar com a implantação da produção.

AWS DevOps
TarefaDescriçãoHabilidades necessárias

Crie uma ramificação hotfix-* e confirme as alterações.

Para criar um pipeline para a ramificação hotfix-* e implantar o hotfix nas contas de workload, faça o seguinte:

  1. Crie uma ramificação usando um nome que inicie com a palavra-chave hotfix. Por exemplo, este padrão usa a ramificação hotfix-check1 no repositório de aplicação do CodeCommit (${ApplicationName}-repository). Para etapas mais detalhadas, consulte Connect to an AWS CodeCommit repository e Basic Git commands na documentação do CodeCommit.

  2. Verifique se o produto Hotfix CICD Pipeline do Service Catalog foi provisionado dinamicamente com sucesso para a ramificação hotfix-check1. O nome do produto provisionado tem o nome dessa ramificação do hotfix e o nome do repositório do CodeCommit da aplicação.

  3. Confirme pequenas alterações no arquivo index.html e envie-as ao repositório do CodeCommit.

  4. Verifique se a execução do CodePipeline foi bem-sucedida no ambiente de preparação. Para implantar no ambiente de produção, forneça aprovação manual no CodePipeline.

  5. Verifique se as alterações estão visíveis na página inicial da aplicação usando o nome de domínio totalmente qualificado (FQDN) do Application Load Balancer. O FQDN está disponível na seção Outputs de inframainstack-ALBStack-*.

AWS DevOps

Exclua a ramificação hotfix-check1.

Para excluir a ramificação hotfix-check1 criada anteriormente, faça o seguinte:

  1. Exclua a ramificação hotfix-check1 que está no repositório da aplicação do CodeCommit.

  2. Verifique se o produto do Service Catalog que foi provisionado para a ramificação hotfix-check1 foi encerrado com êxito.

AWS DevOps
TarefaDescriçãoHabilidades necessárias

Limpe os recursos implantados.

Para limpar os recursos que foram implantados anteriormente, faça o seguinte:

  1. Para reduzir a escala verticalmente do serviço Amazon ECS para zero réplicas nas contas de workload, use o seguinte comando:

    aws ecs update-service --cluster ${ApplicationName}-Cluster --service ${ApplicationName}-Service-stage --desired-count 0 --region ${DepRegion}
aws ecs update-service --cluster ${ApplicationName}-Cluster --service ${ApplicationName}-Service-prod --desired-count 0 --region ${DepRegion}

  2. Encerre o produto do Service Catalog que foi provisionado para a ramificação main.

  3. Limpe objetos criados nos buckets do Amazon S3 na conta de ferramentas. Exclua todas as imagens do Docker no Amazon ECR antes de excluir o registro em si.

  4. Remova os perfis do IAM na seção de acesso concedido dos portfólios do Service Catalog antes de excluir o portfólio do Service Catalog.

  5. Exclua as pilhas do CloudFormation implantadas na conta de ferramentas e nas contas de workload.

##In Tools Account##
aws cloudformation delete-stack --stack-name servicecatalogsetup --region ${DepRegion}
aws cloudformation delete-stack --stack-name prlambdasetup --region ${DepRegion}
aws cloudformation delete-stack --stack-name prereqs --region ${DepRegion}
##In Workload Accounts##
aws cloudformation delete-stack --stack-name inframainstack --region ${DepRegion}

Para obter mais informações, consulte Deleting provisioned products na documentação do Service Catalog.

AWS DevOps

Solução de problemas

ProblemaSolução

As alterações que você confirmou no repositório do CodeCommit não estão sendo implantadas.

Verifique se há erros nos logs do CodeBuild na ação de compilação do Docker. Para obter mais informações, consulte a documentação do CodeBuild.

O produto do Service Catalog não está sendo provisionado.

Analise as pilhas relacionadas do CloudFormation em busca de eventos com falha. Para obter mais informações, consulte a documentação do CloudFormation.

Recursos relacionados

Mais informações

Este padrão foi projetado para ambientes com uma configuração do Gitflow que é adotada para o fluxo de trabalho de desenvolvimento no processo de CI/CD. Os pipelines seguem o ciclo de implantação que começa no desenvolvimento e passa pelos ambientes de garantia de qualidade (QA), preparação e produção. A configuração de CI/CD inclui duas ramificações do git com implantações promocionais em ambientes da seguinte forma:

  • A ramificação develop é implantada no ambiente de desenvolvimento.

  • A ramificação main é implantada nos ambientes de controle de qualidade, preparação e produção.

Nessa configuração, é um desafio aplicar um hotfix ou um patch de segurança mais rápido do que o ciclo normal de implantação enquanto o desenvolvimento ativo de novos recursos está em andamento. É necessário um processo dedicado para atender às solicitações de hotfix ou segurança, garantindo que os ambientes ativos permaneçam funcionando adequadamente e com segurança.

No entanto, você pode usar outras opções disponíveis sem precisar de um processo de implantação dedicado se:

  • O processo de CI/CD está bem equipado com testes automatizados, como testes funcionais e de ponta a ponta, que eliminam a necessidade de testes manuais e evitam atrasos nas implantações na produção. No entanto, se o teste automatizado não estiver bem integrado ao processo de CI/CD, enviar uma pequena correção para o ambiente de produção pode se tornar complexo e complicado para os desenvolvedores. Isso ocorre porque é possível que novos recursos estejam no ambiente de controle de qualidade aguardando aprovação e liberação. Um hotfix ou correção de segurança não pode ser colocado em produção de forma direta e simultânea.

  • As equipes de desenvolvimento implantam continuamente novos recursos no ambiente de produção, integrando hotfixes ou patches de segurança na implantação programada de cada novo recurso. Em outras palavras, a próxima atualização de recursos para o ambiente de produção compreende dois componentes: a adição de um novo recurso e a inclusão do hotfix ou patch de segurança. No entanto, se o ciclo de implantação não for contínuo, pode haver vários novos recursos já aguardando aprovação no ambiente de controle de qualidade. Gerenciar versões diferentes e garantir que as alterações corretas sejam reaplicadas pode se tornar um trabalho complexo e propenso a erros.

nota

Se você estiver usando a versão 2 do AWS CodePipeline com os gatilhos adequados configurados na ramificação hotfix, ainda precisará de um processo dedicado para atender às solicitações não programadas. Na versão 2, você pode configurar gatilhos para solicitações de push ou pull. A execução será colocada em fila ou executada imediatamente, dependendo do estado anterior do pipeline. No entanto, com um pipeline dedicado, as correções são aplicadas imediatamente ao ambiente de produção, garantindo que problemas urgentes sejam resolvidos sem demora.