O blog da AWS
Implementação de CI/CD entre contas com o AWS SAM para funções Lambda baseadas em contêineres
Os aplicativos em contêineres geralmente têm vários ambientes e contas distintos, como desenvolvimento, teste e produção. Um aplicativo precisa passar por um processo de implantação e teste nesses ambientes. Um padrão comum para implantar aplicativos em contêineres é fazer com que uma contra central da AWS crie uma única imagem de contêiner e realize a implantação em outras contas da AWS. Para obter a implantação automatizada do aplicativo em diferentes ambientes, os clientes usam pipelines de CI/CD com ferramentas de contêiner.
Este blog explora como usar os pipelines do AWS Serverless Application Model (AWS SAM) para criar um pipeline de implantação de CI/CD e implantar uma função Lambda baseada em contêiner em várias contas.
Visão geral da solução
Este exemplo inclui três contas: ferramental, teste e produção. A conta de ferramentas é uma conta central na qual você provisiona o pipeline e constrói o contêiner. O pipeline implanta o contêiner no Lambda nas contas de teste e produção usando o AWS CodeBuild. Também requer os recursos necessários na conta de teste e produção. Isso consiste em uma função de gerenciamento de identidade e acesso (IAM) que confia na conta de ferramentas e fornece as permissões específicas de implantação necessárias. O AWS CodeBuild assume essa função do IAM na conta de ferramentas para realizar a implantação.
A solução usa o AWS SAM Pipelines para criar recursos de pipeline de implantação de CI/CD. Ele fornece comandos para gerar os recursos de infraestrutura da AWS necessários e um arquivo de configuração de pipeline que o sistema CI/CD pode usar para implantar usando o AWS SAM. Encontre o código de exemplo dessa solução no repositório do GitHub.
Criando um repositório Git e enviando o código
Execute o seguinte comando na conta de ferramentas do seu terminal para criar um novo repositório do CodeCommit:
Inicialize o repositório Git e envie o código.
Criação de funções entre contas em contas de teste e produção
Para que o pipeline tenha acesso ao ambiente de teste e produção, ele deve assumir uma função do IAM. No cenário entre contas, a função do IAM para o pipeline deve ser criada nas contas de teste e produção.
Altere o diretório para os templates de diretório e execute o comando a seguir para implantar funções para testar e produzir usando os respectivos perfis nomeados.
Perfil (Profile) de teste
Abra o arquivo codepipeline_parameters.json do diretório raiz. Substitua o valor de TestCodePipelineCrossAccountRolearn e TestCloudFormationCrossAccountRoLearn pelo valor de saída do CloudFormation de CodePipelineCrossAccountRole e CloudFormationCrossAccountRole, respectivamente.
Perfil (Profile) de produção
Abra o arquivo codepipeline_parameters.json do diretório raiz. Substitua o valor de ProdCodePipelineCrossAccountRolearn e ProdCloudFormationCrossAccountRoLearn pelo valor de saída do CloudFormation de CodePipelineCrossAccountRole e CloudFormationCrossAccountRole, respectivamente.
Criação das funções e da infraestrutura do IAM necessárias na conta de ferramentas
Vá para o diretório de template e execute o seguinte comando usando uma ferramenta chamada profile:
Abra o arquivo codepipeline_parameters.json do diretório raiz. Substitua o valor de ImageRepositoryUri, ArtifactsBucket, ToolingCodePipelineExecutionRoLearn e ToolingCloudFormationExecutionRoLearn pelo valor de saída correspondente do CloudFormation.
Atualização de funções do IAM entre contas
As funções do IAM entre contas na conta de teste e produção exigem permissão para acessar artefatos que contêm o código do aplicativo (bucket do S3 e repositório ECR). Observe que as funções entre contas são implantadas duas vezes. Isso ocorre porque há uma dependência circular das funções nas contas de teste e produção e dos recursos de artefatos do pipeline provisionados na conta de ferramentas.
O pipeline deve referenciar e resolver os ARNs das funções que precisa assumir para implantar o aplicativo nas contas de teste e produção, portanto, as funções devem ser implantadas antes que o pipeline seja provisionado. No entanto, as políticas associadas às funções precisam incluir o bucket do S3 e o repositório ECR. Mas o bucket do S3 e o repositório ECR não existem até que os recursos sejam implantados na etapa anterior. Implantando as funções duas vezes, uma vez sem uma política para que seus ARNs resolvam e uma segunda vez para anexar políticas às funções existentes que fazem referência aos recursos na conta de ferramentas.
Substitua ImageRepositorYarn e ArtifactBucketArn pelo valor de saída da etapa acima no comando abaixo e execute-o no diretório de templates usando os perfis nomeados Teste e Prod.
Perfil de teste
Perfil do Produção
Implantando o pipeline
Substitua o valor DeploymentRegion pela região atual e o valor CodeCommitRepositoryName pelo nome do repositório CodeCommit no arquivo codepipeline_parameters.json.
Envie as alterações para o repositório do CodeCommit usando os comandos do Git.
Substitua o valor CodeCommitRepositoryName pelo nome do repositório CodeCommit criado na primeira etapa e execute o comando a seguir no diretório raiz do projeto usando uma ferramenta chamada profile.
Limpando
- Execute o comando a seguir no diretório raiz do projeto para excluir o pipeline:
- Esvazie o balde de artefatos. Substitua o nome do bucket de artefatos pelo valor de saída da etapa anterior:
- Exclua as funções do Lambda das contas de teste e produção:
- Exclua funções entre contas das contas de teste e produção:
- Exclua o repositório ECR:
- Exclua recursos da conta de ferramentas:
Conclusão
Este blog discute como automatizar a implantação do Lambda baseado em contêineres em várias contas usando o AWS SAM Pipelines.
Navegue até o repositório do GitHub e analise a implementação para ver como o CodePipeline envia a imagem do contêiner para o Amazon ECR e implanta a imagem no Lambda usando a função entre contas. Examine o arquivo codepipeline.yml para ver como o AWS SAM Pipelines cria recursos de CI/CD usando esse modelo.
Para obter mais recursos de aprendizado Serverless, visite Serverless Land.
Este artigo foi traduzido do Blog da AWS em Inglês.