Traduzido do English • Ver original Até agora, se você quisesse rodar comandos de CLI da AWS, comandos de CLI de terceiros ou simplesmente invocar uma API, era preciso criar um projeto CodeBuild, configurar o projeto com os comandos apropriados e adicionar uma ação CodeBuild ao seu pipeline para rodar o projeto.
Claramente, os usuários tiveram que lidar com 2 componentes, CodePipeline e CodeBuild, e claro, aprender os componentes internos de ambos para poder usar o.
Este blog explica sobre a Command Action do CodePipeline, 'uma nova atualização do Codepipeline', que permite facilmente executar comandos shell como parte da execução do seu pipeline.
Com a ação Commands, você pode rodar AWS CLI, ferramentas de terceiros ou qualquer comando shell.
No final, também discutiremos se realmente não precisamos do codeBuild ou em que situações podemos usar o codeBuild em que a ação de comando não seria suficiente.
Motivação
- A AWS lançou uma nova atualização em 4 de outubro de 2024 para o CodePipeline.
- AWS CodePipeline introduz nova ação de computação de uso geral
Pré-requisitos
- Funcionamento básico do CodePipeline, CodeBuild (já que este blog vai focar principalmente apenas na atualização)
- Conhecimento radical do Terraform
- Compreensão do núcleo da AWS e suas operações
Entendendo a Ação do Comando CodePipeline
- Na essência mais básica, 'permite executar comandos de shell em uma instância virtual de computação'.
- Quando executa, os comandos que você configura são executados em um contêiner separado.
- Quaisquer arquivos ou dados necessários de etapas anteriores (artefatos de entrada) no pipeline estão disponíveis para uso nesse ambiente. A melhor parte é que você não precisa configurar um projeto CodeBuild separado para usá-lo.
O que acontece nos bastidores de Command Action
- CODEBUILD AINDA É USADO !!
É só que todo esse processo de criar o projeto CodeBuild primeiro e depois adicionar uma ação ao CodePipeline foi abstraído por essa ação.
- Como depende dos recursos do CodeBuild, qualquer build acionada pela ação Commands contará para os limites de build da sua conta CodeBuild, incluindo o timeout da build, que é de 55 minutos, e o número de builds simultâneas permitidas.
- Nota: A ação Commands executa computação EC2 gerenciada sob demanda pelo CodeBuild e usa uma imagem padrão 5.0 do Amazon Linux 2023.
Algumas ressalvas para ação de Comando:
- Todos os formatos de comando são suportados, exceto formatos multi-linha.
- A ação de comandos não é suportada para ações entre contas ou entre regiões.
- Quando o CodePipeline executa a ação, o CodePipeline cria um grupo de log usando o nome do pipeline, portanto a ação de comando precisa da seguinte permissão:
logs:CreateLogGroup
logs:CreateLogStream
logs:PutLogEvents
- Como o ambiente de build isolado é usado no nível da conta, uma instância pode ser reutilizada para outra execução de pipeline.
Vamos ver como funciona a Ação de Comando !!
- Vamos criar um pipeline simples de CD que gera recursos de terraform em nossa conta AWS
- A premissa básica desse pipeline é exatamente a mesma do meu blog anterior.
Enviar terraform zip para s3 -> CodePipeline é acionado -> Ação de comando executa terraform apply
Passo 1: Criar um balde S3 para armazenar o backend e o código-fonte de terraformação
- Criar um bucket 'versionado' do s3 para armazenar nosso zip de terraform (artefato de origem)
- Fazer upload para esse bucket aciona o pipeline
- Criar outro bucket 'versionado' do s3 para armazenar o backend do terraform para seu estado.
Passo 2: Criar Pipeline
- Para manter este blog simples, estou mantendo tudo padrão.
- Nota: estou usando o novo papel de serviço, pois na documentação ele tem as permissões para ações de comando. Se você estiver usando o papel existente, precisa adicionar as permissões manualmente, como mencionei antes.
Passo 3: Escolha da Fase de Origem
- Escolha o balde S3 usado no passo 1
- Note o nome da 'chave de objeto S3': 'tf.zip'.
- claro que você pode escolher qualquer nome
Passo 4: Adicionar estágio de construção / comandos de adicionar
- Este é o passo mais importante do nosso pipeline. O essencial deste blog.
- Aqui, neste comando seguinte, estou fazendo 3 coisas
- Instalando o comando Terraform para implantar recursos terraform. Note o uso do gerenciador de pacotes dnf, já que o Amazon Linux 2023 usa dnf como gerenciador de pacotes
- usando terraform init e apply
- Usando o comando AWS para listar todos os buckets do S3 na minha conta.
Sudo DNF install -y yum-utils shadow-utils
Sudo DNF Config-Manager --Add-Repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
Sudo DNF -Y instalar terraform
terraform --versão
terraform init -no-color -input=false
terraform apply -auto-approval -no-color -input=false
AWS S3 LS
Nota: Não adicione um espaço em branco entre comandos, caso contrário você verá um erro de restrição
de comprimento
Passo 5: Pular a implantação e a revisão
- No estágio final, pule a fase de implantação e revise.
Voilà, você acabou de criar um pipeline de CD sem nem saber ou envolver o Codebuild (pelo menos pelo seu próprio)
Funcionou mesmo?
- Crie o código postal do terraform
Passo opcional para backend
terraform {
backend "s3" {
bucket = "codepipeline-command-action-backend-jatin"
Região = "EUA-Leste-1"
chave = "terraform-deployment.tfstate"
}
}
resource "aws_s3_bucket" "deploy-bucket" {
bucket = "codepipeline-command-action-backend-1-jatin"
tags = {
Projeto = "Para teste de implantação de CD de CI"
Ambiente = "Dev"
}
}
recurso "aws_s3_bucket" "deploy-bucket-two" {
bucket = "codepipeline-command-action-backend-2-jatin"
tags = {
Projeto = "Para teste de implantação de CD de CI"
Ambiente = "Dev"
}
}
zip -r tf.zip main.tf
Você também precisa adicionar manualmente a permissão '(AmazonS3FullAccess)' ao papel de serviço criado pelo Codepipeline para permitir que o Terraform rodando dentro do CodePipeline envie o estado terraform para o bucket s3, já que usamos a configuração do backend do terraform.
Enviar o arquivo Zip para o bucket do s3.
Neste momento do blog, há um bug no papel de serviço criado pelo CodePipeline. Ele não possui permissões para Ação de Comando.
- Adicionar manualmente as permissões conforme discutido anteriormente. Para fins do blog, vou anexar a política 'CloudWatchLogsFullAccess' ao cargo
- Esta etapa é opcional. Também adicione a permissão para poder enviar o estado do terraform para o bucket do s3 '(AmazonS3FullAccess)', pois usamos a configuração do backend do terraform.
Verifique os Logs do CodePipeline e o bucket do S3
- Podemos confirmar claramente que o terraform conseguiu criar buckets e buckets presentes na conta.
Da perspectiva do Arquiteto DevOps
Com a ação de comandos não preciso mexer ou lidar com a ação do CodeBuild, apenas focar em construir meu pipeline de CI/CD. Mas isso realmente é suficiente para a abstração?
- De acordo com o Docs, a ação do comando CodePipeline executa 'CodeBuild managed on-demand EC2 compute', então claramente não conhecemos os limites de memória, vCpus e espaço em disco
- Se estivermos usando o CodeBuild, teríamos a liberdade de escolher a flexibilidade otimizada durante sua build ou até mesmo o Lambda como computação para builds e implantações mais rápidas.
- Claramente, essa abstração de 'ação de comando' é o equilíbrio entre flexibilidade, economia de custos, dar tempo extra para aprender CodeBuild versus simplicidade, facilidade e economia de tempo.
- Do ponto de vista do custo, essa abstração não deve ser confundida com pipelines de CD de CI "mais baratos". Executar a ação do comando gerará cargas separadas no AWS CodeBuild.
Estou muito curioso para saber como a comunidade vai usar essa atualização para seus Pipelines e como eles acham que isso vai ajudar na eficiência?
Deixe suas perguntas, comentários e vamos facilitar nossa vida para os pipelines de CD de CI. Você sempre pode me procurar no Linkedin, X.