AWS 콘솔 환경에서 자동 배포하는 방법을 정리하고자 한다. AWS에서는 소스 코드 관리부터 빌드, 배포를 비롯해 이 과정을 하나의 파이프라인으로 묶어 관리할 수 있는 CI/CD 서비스를 제공한다.
각 단계에 대해 간단히 정리하면, Github와 같이 소스 코드의 저장 및 버전 관리를 도와주는 CodeCommit
, 소스 코드 빌드를 도와주는 CodeBuild
, 빌드된 파일을 서버에 배포하는 CodeBuild
, 마지막으로 위 3 단계를 하나로 묶어주는 Pipeline
이 있다.
지난 포스트에서는 위 개념 중 소스 저장소 CodeCommit에 대해 알아보았다( 링크 : https://log4day.tistory.com/41?category=1038764 ). 이번 포스트에서는 소스 저장소에서 코드를 읽어와 빌드 파일로 묶어주는 CodeBuild에 대한 가이드를 정리한다.
CodeBuild 단계는 아래와 같이 정리해보았다.
- IAM 권한 확인
- CodeBuild 프로젝트 생성
- 프로젝트 설정 - Confuguration
- 소스 저장소 지정 - Source
- 실행 환경 설정 - Environment
- buildspec 설정 - Buildspec
- Artifacts 및 Cache 설정 - Artifacts
- 로그 설정 - Logs
- CodeBuild 프로젝트 생성 확인
- 소스 빌드
1. IAM 권한 확인
CodeBuild를 진행하기 전, 먼저 사용 중인 계정에 CodeBuild 권한이 있는지 확인해야 한다. IAM User 메뉴에서 AWSCodeBuildAdminAccess
권한을 체크한다. 해당 권한이 있어야 CodeBuild에서 프로젝트 생성 및 소스 빌드를 실행할 수 있다.
권한이 없다면, Add Permissions 버튼을 눌러 위 권한을 넣어주자.
2. CodeBuild 프로젝트 생성
IAM에서 권한을 확인했다면, AWS 콘솔에서 CodeBuild를 검색한 뒤 빌드 프로젝트를 생성한다. 자세한 화면은 아래 캡처 이미지를 참고하면 된다.
3. 프로젝트 설정(Confuguration)
빌드 프로젝트 생성에는 꽤 많은 설정을 입력해주어야 한다. 총 6개 항목이 있는데 내용은 다음과 같다.
- Project Configuration : 빌드 프로젝트 이름, 상세 설명, 태그
- Source : 프로젝트 소스 저장소
- Environment : 실행 환경
- Buildspec : 빌드 실행 파일 설정 (빌드 진행 시 참조되는 .yml 타입의 설정 파일)
- Artifacts : 빌드 파일 저장 및 캐싱 파일 관리
- Logs : 빌드 로그
현 단계(Project Configuration)에서는 우리가 생성할 빌드 프로젝트의 명세를 작성한다. 나머지 5가지 항목에 대한 자세한 내용은 이후 글에서 순차적으로 설명해두었다.
빌드 프로젝트의 이름(Project Name)은 필수 항목이다. 나머지 프로젝트 상세 내용(Descrition)과 태그(Tag)의 경우 선택사항이니 넘어가도 좋다.
체크박스 옵션으로 빌드 뱃지(Build Badge)
와 빌드 횟수 제한(Build Limit)
이 있는데, GUI적으로 빌드 단계를 확인하고 싶다면 뱃지 활성화에 체크하면 되고, 해당 프로젝트가 동시에 빌드되는 횟수를 제한하고 싶다면 빌드 횟수 제한을 체크하고 숫자를 입력하면 된다.
4. 소스 저장소 지정(Source)
이 단계는 빌드할 프로젝트의 소스 저장소 경로를 지정한다. Github, AWS CodeCommit, AWS S3 등을 선택할 수 있다. 소스 저장소를 선택하고, 그곳에서 빌드하고자 하는 프로젝트를 선택한다.
클론 범위(Clone Depth)
옵션은 프로젝트 커밋 히스토리를 얼마나 읽어올지를 지정한다. 빌드를 실행할 때, 최신 소스만 빌드할 거라면 1, 읽어올 커밋 범위를 넓게 잡고 싶다면 숫자를 높게 혹은 Full로 잡으면 된다.
추가적으로, 우측 하단에 Add Source
라는 버튼이 있다. CodeBuild는 여러 개의 프로젝트를 동시에 빌드할 수 있다. 만약, 한 번에 여러 소스를 빌드하고 싶다면 해당 버튼을 클릭하고 추가적인 소스 저장소를 입력한다.
5. 실행 환경 설정(Environment)
빌드 실행 환경을 설정한다. 기본 옵션으로 Amazon Linux 2
, Ubuntu
, Window Server
등이 제시되며, 사용자가 만든 도커 이미지
를 입력할 수도 있다.
기본 옵션을 선택하면 AWS에서 제공하는 Runtime
및 Image
를 추가적으로 선택하는 항목이 출력된다. 빌드에 큰 영향을 주는 옵션들은 아니고 설명하려면 글이 길어지니 자유롭게 선택하고 넘어가도록 하겠다. (도커 관련 Privileged 체크 옵션 역시 생략한다.)
실행환경을 선택했다면, 빌드 실행 권한을 지정해줘야 한다. 해당 권한은 IAM -> Roles
에서 관리된다. 새로 생성할지, 사전에 생성된 권한을 사용할지 각자 환경에 맞춰 진행하면 된다. CodeBuild가 처음이라면 이 단계에서 새로 생성하는 것을 추천한다.
나처럼 미리 권한을 생성하고 진행하고자 한다면, 아래 2번째 이미지를 참고해서 진행하면 된다.
이 단계에 추가 설정 항목들이 있다. 타임아웃(Timeout)
, 인증(Certificate)
, VPC
, 파라미터(Parameter)
, 환경변수(Environment Variable)
등이다.
빌드 시간에 제한을 설정하는 타임아웃 값, 빌드 인증 파일, CodeBuild가 접근할 VPC 리소스 그룹, 그리고 빌드 시 참조할 파라미터 및 환경변수 등에 대한 내용이다.
6. Buildspec 설정 (.yml 파일)
CodeBuild에 가장 중요한 Buildspec이라는 설정 파일에 대한 내용이다. .yml
타입의 파일이며, 프로젝트 루트 경로에서 읽어온다. 기본적으로 buildspec.yml
파일로 생성해 관리한다. 이 단계에서는 소스 저장소에서 읽어온 코드에서 불러올.yml 파일 이름을 입력한다.
.yml
파일은 빌드 소스에 대한 명세(코드 및 버전)
, 빌드 라이프 사이클
, Output으로 나오는 파일
, 캐싱 데이터
를 관리한다. 크게 version, phases, artifacts, cache 항목으로 나누어진다.
version
에서는 AWS에서 지원하는 buildspec 버전을 명시한다. 지금 시점(2022년 04월)에서 0.2 버전을 지원한다.
phases
에서는 빌드 라이프 사이클에 맞는 설정값과 실행 커맨드를 입력한다. 총 4개의 세부 단계가 있으며, 내용은 다음과 같다.
install
: 빌드를 진행할 코드와 해당 코드 버전 명시pre_build
: 빌드 전 실행 CLI 명령어build
: 빌드 실행 CLI 명령어 (maven, gradle, node 등 각자 환경에 맞는 빌드 명령어 입력)post_build
: 빌드 후 실행 명령어
artifacts
는 빌드가 끝난 후, 가져올 파일을 경로와 함께 적어둔다.
cache
에서는 라이브러리와 같은 파일들을 캐시 데이터로 저장할 수 있게 한다. 최초 빌드 이후 해당 캐싱 데이터를 불러올 수 있어 빌드 시간과 사이즈가 줄어드는 장점이 있다.
위 내용과 관련해 내가 사용한 buildspec.yml 파일 아래 코드 블록에 참조해두었다. Java 8 버전 소스이며, Maven으로 빌드를 진행한다. m2 디렉토리 캐싱도 포함되어 있다. 자세한 내용은 코드 블록의 주석을 참조하자.
추가적으로 이 단계에서 자동 빌드 스케쥴러(Batch Configuration)
를 등록할 수 있다. 스케쥴링 기능을 사용하고자 한다면 이 옵션을 잘 활용하면 좋다.
# buildspec-dev.yml
# 개발과 상용 버전 구분을 위해 buildspec 이름을 구분했다.
# AWS CodeBuild 지원 버전
version: 0.2
# 라이프 사이클 관리
phases:
install:
runtime-versions:
java: corretto8 # Java 8 버전
pre_build:
commands:
- echo Nothing to do in the pre_build phase
build:
commands:
- echo Build Started on `date`
- mvn clean package # Maven 빌드
post_build:
commands:
- echo Build completed on `date`
- mv target/myProject-0.1.war target/myProject.war # 빌드된 .war 파일명 변경
- mv scripts/deploy-dev-before.sh scripts/deploy-before.sh # dev 환경 CodeDeploy 배포에 사용할 스크립트 파일 - 1
- mv scripts/deploy-dev-after.sh scripts/deploy-after.sh # dev 환경 CodeDeploy 배포에 사용할 스크립트 파일 - 2
# 빌드 산출물(Output) 경로 및 파일명 표기
artifacts:
files:
- target/myProject.war # 빌드된 .war 파일
- scripts/deploy-before.sh # CodeDeploy 실행 스크립트 파일 - 1
- scripts/deploy-after.sh # CodeDeploy 실행 스크립트 파일 - 2
- appspec.yml # CodeDeploy 설정 파일
discard-paths: yes
# 캐시 데이터 관리 (m2에 저장된 라이브러리)
# Maven을 사용한다면, 아래 경로는 모두 동일하게 입력해야 한다.
cache:
paths:
- '/root/.m2/**/*'
7. Artifacts 및 Cache 설정
빌드된 파일을 어떻게 관리할지 지정하는 단계다. Artifacts
는 빌드 산출물(Output)을 나타낸다. Type
부분에는 빌드 파일을 저장할 경로를 지정한다. AWS S3 버킷이 옵션으로 제시된다. 미리 S3 버킷을 생성해두는 게 좋으며, 생성한 버킷 경로를 입력한다.
추가 설정 사항으로 캐시 데이터 역시 입력할 수 있다. Cache Type
은 AWS S3와 local이 있는데, Artifacts와 동일하게 S3를 활용하자.
8. 로그 설정
프로젝트 빌드 설정의 마지막 단계다. 로그가 필요 없다면 넘어가도 좋다. 설정이 필요하면, S3와 CloudWatch 두 가지를 선택할 수 있는데, 원하는 로그 관리 방법을 체크한 뒤 관련 명세를 입력하면 된다.
9. CodeBuild 프로젝트 생성 확인
모든 입력이 끝났다면 프로젝트를 생성한다. CodeBuild에 프로젝트가 아래 이미지처럼 확인될 것이다. Edit 버튼으로 입력한 설정값을 추정할 수 있고, Start Build를 통해 빌드를 실행할 수 있다.
10. 소스 빌드
소스 빌드를 시작하면, 다음과 같은 실행 과정을 모니터링할 수 있다. 소스 저장소에서 코드를 불러오고 라이브러리를 다운받는 등 일련의 과정을 모니터링할 수 있다. 불러올 캐시 데이터가 없다면 빌드 시간이 다소 길어질 수 있다.
빌드가 성공적으로 끝나면 위에서 우리가 설정한 경로에 맞춰 Artifacts와 Cache 파일이 생성돼있을 것이다. 빌드 상태가 성공(Successed)으로 표기되고, 파일이 잘 생성되어 있다면, CodeBuild는 성공적으로 진행되었다고 생각하면 된다.
마치며
CodeBuild에 대한 내용은 AWS IAM 권한, 소스 저장소 설정, Buildspec에 대한 부분만 주의하면 쉽게 진행할 수 있다. 이후 포스트에서는 배포 단계인 CodeDeploy에 대해 정리한다. CodeBuild에서 생성된 Artifacts를 AWS 서버에 올리는 방법을 알아보자.
'Server & Network > AWS' 카테고리의 다른 글
[AWS] 로드벨런서(Load Balancer) - ALB, NLB (1) | 2022.05.08 |
---|---|
[AWS] CI/CD 구성(3) - 배포 CodeDeploy (0) | 2022.04.30 |
[AWS] CI/CD 구성(1) - 소스 저장소 CodeCommit (0) | 2022.04.24 |
[AWS] EBS Volume 확장, 파티션 수정 (3) | 2022.04.14 |
[AWS] 로드벨런서(Load Balancers) Listener 룰 추가 & 수정 - ALB, NLB (0) | 2022.04.14 |
댓글