Os clientes usam padrões de arquitetura modulares e modelos operacionais Serverless para criar aplicativos mais sustentáveis, escaláveis e resilientes no desenvolvimento de aplicativos modernos. O AWS Lambda é uma escolha popular para criar esses aplicativos.Se os clientes investiram em ferramentas de contêiner para seus fluxos de trabalho de desenvolvimento, eles implantam no Lambda usando o formato de imagem de contêiner para cargas de trabalho como inferência de aprendizado de máquina ou cargas de trabalho com uso intenso de dados. Usando funções implantadas como imagens de contêiner, os clientes se beneficiam da mesma simplicidade de operação, escalabilidade de automação, alta disponibilidade e integração nativa com muitos serviços.
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.
Arquitetura de solução completa
O AWS CodePipeline segue essas etapas para implantar a função Lambda baseada em contêiner nas contas de teste e produção:
- O desenvolvedor confirma o código da função Lambda no AWS CodeCommit ou em outros repositórios de controle de codigo, o que aciona o fluxo de trabalho de CI/CD.
- O AWS CodeBuild prepara o código, cria uma imagem de contêiner e envia a imagem para o repositório Amazon Elastic Container Registry (ECR) usando o AWS SAM.
- O AWS CodeBuild assume uma função entre contas para a conta de teste.
- O AWS CodeBuild usa o AWS SAM para implantar a função Lambda ao extrair imagens do Amazon ECR.
- Se a implantação for bem-sucedida, o AWS CodeBuild implanta a mesma imagem na conta de produção usando o AWS SAM.
Implantando o exemplo
Pré-requisitos
- Uma conta da AWS. O usuário do IAM que você usa deve ter permissões suficientes para fazer as chamadas de serviço da AWS necessárias e gerenciar os recursos da AWS.
- AWS CLI instalado e configurado.
- Git instalado.
- AWS SAM instalado.
- Configure perfis nomeados.aws/credentials para contas de ferramentas, teste e produção para que você possa executar comandos CLI e AWS SAM neles.
- Defina as variáveis de ambiente TOOLS_ACCOUNT_ID, TEST_ACCOUNT_ID e PROD_ACCOUNT_ID:
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.