詳細検索
↑↓移動
↵選択
ESC閉じる

추가 CodeBuild 프로젝트와 작별을 고하다: AWS CodePipeline의 새로운 명령어 실행 설명

아바타
글쓴이 Jatin Mehrotra2024. 10. 25.
태그 cloud-infra mid-career
추가 CodeBuild 프로젝트와 작별을 고하다: AWS CodePipeline의 새로운 명령어 실행 설명
English에서 번역 • 원문 보기

*지금까지 AWS CLI 명령어, 서드파티 CLI 명령어, 또는 API를 호출하려면 CodeBuild 프로젝트를 생성하고, 적절한 명령어로 프로젝트를 구성하며, 프로젝트를 실행하려면 파이프라인에 CodeBuild 액션을 추가해야 했습니다.*

분명히 사용자들은 CodePipeline과 CodeBuild 두 가지 구성 요소를 다뤄야 했고, 물론 두 구성 요소 모두의 내부 구조를 익혀야 했습니다.

이 블로그는 CodePipeline의 명령 동작, 즉 'Codepipeline의 새로운 업데이트'에 대해 설명합니다. 이 기능은 파이프라인 실행 시 셸 명령을 쉽게 실행할 수 있게 해줍니다.

명령어 동작을 사용하면 AWS CLI, 서드파티 도구, 또는 셸 명령어를 실행할 수 있습니다.

*마지막으로 우리는 정말 codeBuild가 필요 없는지, 명령 동작만으로는 충분하지 않은 상황에서 codeBuild를 사용할 수 있는 상황이 어디일지도 논의할 것입니다.

동기

선수 조건

  • CodePipeline, CodeBuild의 기본 작동 방식 (이 블로그는 주로 업데이트에만 집중할 예정입니다)
  • 테라포밍에 대한 급진적인 지식
  • 핵심 AWS 및 운영 개념 이해

코드파이프라인 명령 동작 이해하기

  • 가장 기본적인 의미는 '가상 컴퓨트 인스턴스에서 셸 명령을 실행할 수 있게 해준다'는 것입니다.
  • 실행될 때, 설정한 명령어는 별도의 컨테이너에서 실행됩니다.
  • 파이프라인 내 이전 단계에서 필요한 파일이나 데이터(입력 산출물)는 이 환경에서 사용할 수 있습니다. 가장 좋은 점은 별도의 CodeBuild 프로젝트를 설정할 필요가 없다는 것입니다.

커맨드 액션의 비하인드 스토리

  • 코드빌드는 여전히 사용 중입니다 !!

이 작업은 codeBuild 프로젝트를 먼저 만들고 그 후 CodePipeline에 액션으로 추가하는 전체 과정이 추상화되었습니다.

  • CodeBuild 리소스에 의존하기 때문에, Commands 동작으로 트리거된 모든 빌드는 CodeBuild 계정의 빌드 한도에 포함되며, 여기에는 55분의 빌드 타임아웃과 동시에 허용되는 빌드 수가 포함됩니다.
  • 참고: Commands 동작은 CodeBuild가 관리하는 온디맨드 EC2 컴퓨트를 실행하며, Amazon Linux 2023 표준 5.0 이미지를 사용합니다.

지휘 행동에 대한 몇 가지 주의사항:

  • 다중 줄 형식을 제외한 모든 명령 형식이 지원됩니다.
  • 명령 동작은 크로스 계정 또는 크로스 리전 액션에는 지원되지 않습니다.
  • CodePipeline이 작업을 실행할 때, CodePipeline은 파이프라인 이름을 사용해 로그 그룹을 생성하므로 명령 행동은 다음과 같은 권한이 필요합니다:
logs:CreateLogGroup
로그스:CreateLogStream
로그:PutLogEvents
  • 독립된 빌드 환경이 계정 수준에서 사용되기 때문에, 인스턴스가 다른 파이프라인 실행에 재사용할 수 있습니다.

커맨드 액션이 어떻게 작동하는지 보자!!

  • AWS 계정에서 테라폼 리소스를 생성하는 간단한 CD 파이프라인을 만들 예정입니다
  • 이 파이프라인의 기본 전제는 이전 블로그와 정확히 같습니다.
Upload terraform zip to s3 -> CodePipeline이 트리거됩니다 -> 명령 동작 runs terraform apply

1단계: Terraform 백엔드와 소스를 저장하는 S3 버킷 생성

  • terraform zip을 저장할 'versioned' s3 버킷 생성 (소스 아티팩트)
  • 이 버킷에 업로드하면 파이프라인이 트리거됩니다
  • terraform 백엔드를 저장할 또 다른 '버전화된' s3 버킷을 생성하세요.

2단계: 파이프라인 생성

  • 이 블로그를 간단하게 유지하기 위해 모든 것을 기본값으로 유지합니다.
  • 참고로 저는 docs에 따라 명령 행동 권한이 있는 New Service Role을 사용하고 있습니다. 기존 역할을 사용 중이라면 앞서 언급한 권한을 수동으로 추가해야 합니다.

3단계: 소스 단계 선택

  • 1단계에서 사용한 S3 버킷을 선택하세요
  • 'S3 객체 키' 이름: 'tf.zip'에 주목하세요.
  • 물론 어떤 이름이든 고를 수 있어

4단계: 빌드 단계 추가 / 명령어 추가

  • 이것이 우리 파이프라인에서 가장 중요한 단계입니다. 이 블로그의 요지입니다.
  • 다음 명령에서 나는 세 가지를 하고 있다
    • Terraform 리소스를 배포하기 위한 Terraform 명령어 설치 Amazon Linux 2023이 dnf 패키지 관리자로 사용하므로 dnf 패키지 관리자 사용에 주목하세요
    • Terraform init and apply 사용
    • AWS 명령어를 사용해 내 계정 내 모든 S3 버킷을 나열하는 것.
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 install terraform
테라폼 --버전
Terraform init -no-color -input=false
Terraform 적용 -자동 승인 -색상 없음 -입력=false
AWS S3 LS

참고: 명령어 사이에 여백을 추가하지 마세요. 그렇지 않으면 길이 제약

때문에 오류가 발생합니다

5단계: 배치 및 검토 건너뛰기

  • 최종 단계에서는 건너뛰고, 배치하고, 검토합니다.

짜잔, 코드빌드를 전혀 모르고 (적어도 본인만으로는) CD 파이프라인을 만들었네요.

진짜 효과가 있었나요?

  • 테라폼 코드 우편을 만들어

백엔드용 선택적 단계
테라포름 { 
  백엔드 "S3" { 
    bucket = "codepipeline-command-action-backend-jatin" 
    지역 = "미국-동-1" 
    key = "terraform-deployment.tfstate" 
  }
}

리소스 "aws_s3_bucket" "배포 버킷" { 
  bucket = "codepipeline-command-action-backend-1-jatin" 

  태그 = { 
    프로젝트 = "CI CD 배포 테스트" 
    환경 = "개발" 
  }
}

리소스 "aws_s3_bucket" "deploy-bucket-two" { 
  bucket = "codepipeline-command-action-backend-2-jatin" 

  태그 = { 
    프로젝트 = "CI CD 배포 테스트" 
    환경 = "개발" 
  }
}

집 -r tf.zip main.tf

  • 또한 Codepipeline에서 생성된 권한 '(AmazonS3FullAccess)'를 수동으로 추가해야 하며, 이를 통해 Terraform이 CodePipeline 내에서 실행될 때 Terraform 상태를 s3 버킷에 업로드할 수 있습니다.

  • s3 버킷에 zip 파일을 업로드하세요.

  • 현재 블로그 시점에서 CodePipeline이 만든 서비스 역할에 버그가 있습니다. 명령 행동에 대한 권한이 없습니다.

  • 앞서 논의한 권한 추가를 수동으로 하세요. 블로그 목적상 역할에 'CloudWatchLogsFullAccess' 정책을 첨부하겠습니다

  • 이 단계는 선택 사항입니다. 또한 Terraform 백엔드 설정을 사용했기 때문에 s3 버킷 '(AmazonS3FullAccess)'에 terraform 상태 업로드 권한도 추가했습니다.

CodePipeline 로그와 s3 버킷을 확인해

  • Terraform이 계정에 존재하는 버킷과 리스트 버킷을 생성할 수 있었음을 명확히 확인할 수 있습니다.

DevOps 아키텍트 관점에서

명령 동작은 CodeBuild 작업을 건드리거나 다룰 필요가 없고, 그냥 CI/CD 파이프라인 구축에 집중하면 됩니다. 그런데 추상화에 충분한가요?

  • 문서에 따르면 CodePipeline 명령 동작은 'CodeBuild 관리 온디맨드 EC2 컴퓨트'를 실행하므로 메모리, vCPU, 디스크 공간의 한계를 알 수 없습니다
  • CodeBuild를 사용할 경우, 빌드 중 최적화된 유연성 을 자유롭게 선택할 수 있고, Lambda를 컴퓨트로 선택하여 더 빠른 빌드와 배포를 할 수 있습니다.
  • 분명히 '명령 동작'이라는 추상화는 유연성, 비용 절감, CodeBuild 학습에 더 많은 시간을 주는 것과 단순함, 용이성, 시간 절약 사이의 절충관계입니다.
  • 비용 측면에서 이 추상화는 "더 저렴한" CI CD 파이프라인과 혼동해서는 안 됩니다. 명령 동작을 실행하면 AWS CodeBuild에서 별도의 요금이 발생합니다.

커뮤니티가 이번 업데이트를 파이프라인에 어떻게 활용할지, 그리고 효율성에 어떻게 도움이 될 것이라고 생각하는지 매우 궁금합니다.

질문과 의견을 남겨 주세요. CI CD 파이프라인 작업을 편리하게 만들어 주세요. 언제든지 LinkedIn, X에서 저에게 연락하실 수 있습니다.

더 보기

Related Articles