2020. 2. 17. 23:11ㆍIT/AWS
1. 구성 소개
1.1 구성 아키텍처
AWS에서 제공하는 서비스를 이용한 CI/CD 구성은 다음과 같다.
1.2 AWS에서 제공하는 CI/CD 솔루션
AWS 서비스명 | 설명 |
CodeCommit | 먼저 기존 코드를 Github에서 AWS CodeCommit으로 마이그레이션 한다. AWS CodeCommit은 AWS에서 호스팅하는 버전 제어 서비스로 클라우드에서 자산을 비공개로 저장하고 관리하는 데 사용한다. |
CodeBuild | 애플리케이션 코드를 빌드하기 위해 CodeBuild를 구성한다. AWS CodeBuild는 소스 코드를 컴파일하고 테스트를 실행하며 배포 준비가 된 소프트웨어 패키지를 생성하는 완전히 관리된다. |
CodeDeploy | 코드를 EC2 서버에 배포한다. AWS CodeDeploy는 Amazon EC2 인스턴스, 온 프레미스 인스턴스 또는 서버리스 Lambda 기능에 대한 애플리케이션 배포를 자동화하는 배포 서비스이다. |
CodePipeline | 코드를 지속적으로 제공하는 파이프 라인을 구축한다. AWS CodePipeline은 소프트웨어 배포에 필요한 단계를 모델링, 시각화 및 자동화하는 데 사용할 수 있는 지속적인 제공 서비스이다. 코드를 프로덕션에 전달하기 전에 파이프 라인에 승인 프로세스를 통합한다. |
2. 구성 방법
2.1. Codecommit 리포지토리 생성
CodeCommit에서 리포지토리를 생성한다.
(파이프라인이 실행되면 이 리포지토리에서 소스 코드를 가져오게 된다.)
리포지토리 페이지에서 리포지토리 생성을 선택한다.
리포지토리 생성 페이지에서 리포지토리 이름(예: joohyun-repo)를 입력한다.
2.2. Codecommit 리포지토리에 코드 추가
GitHub와 동일한 명령어로 Codecommit에 접근한다.
git init
git add -A
git commit -m "commit message"
git remote add origin https://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/joohyun-repo
git push -u origin master
git clone https://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/joohyun-repo
2.3. CodeBuild에서 빌드 프로젝트 생성
빌드 프로젝트 생성을 선택한다.
빌드 프로젝트 생성 페이지의 프로젝트 구성에 이 빌드 프로젝트의 이름을 지정한다.
각 AWS 계정에서 빌드 프로젝트 이름은 고유해야 한다.
소스 공급자에서 해당되는 소스 코드 공급자 유형을 선택한다.
AWS CodeBuild가 관리하는 도커 이미지를 사용하려면 관리형 이미지를 선택한다. 다른 도커 이미지를 사용하려면 사용자 지정 이미지를 선택한다. (ARM, Linux, Linux GPU, or Windows 등)
사전에 CodeBuild 서비스 역할을 생성하여, 기존 서비스 역할을 선택한다. 추후 Amazon S3 버킷에 빌드 출력을 저장하려면 Amazon S3를 선택한다. 또한 Amazon CloudWatch Logs 로그나 Amazon S3 로그를 생성할 수 있다.
소스 코드에 buildspec 파일이 있는 경우 빌드 사양 파일 사용을 선택한다.
buildspec은 CodeBuild가 빌드를 실행하는 데 사용하는 YAML 형식의 빌드 명령 및 관련 설정의 모음이다.
다음과 같이 작성될 수 있다.
version: 0.2
phases:
install:
commands:
- npm install
pre_build:
commands:
- npm run lint
build:
commands:
- npm test
post_build:
commands:
- echo Build completed
artifacts:
files:
- '**/*'
- version : 사용 중인 빌드 사양 표준의 버전이다.
- phases : CodeBuild가 명령을 실행하도록 지시할 수 있는 빌드 단계이다. 빌드 단계 이름의 철자는 변경할 수 없으며 추가로 빌드 단계 이름을 생성할 수 없다.
- artifact : CodeBuild가 출력 버킷에 업로드하는 빌드 출력 결과물이다.
- buildspec은 YAML 형식에 맞아야하고, 디렉터리 구조를 맞춰야한다.
2.4. 배포 EC2 인스턴스 생성 및 CodeDeploy 에이전트 설정
CodeDeploy를 통해 배포될 서버를 생성하고 설정한다.
CodeDeploy 에이전트는 배포에서 사용할 수 있게 해주는 소프트웨어 패키지이다.
CodeDeploy가 해당 EC2 인스턴스에서 웹 서버를 설정하는 데 사용할 수 있는 스크립트이다.
CodeDeploy에서 설정하기 위해 식별할 태그를 지정한다.
2.5. CodeDeploy 애플리케이션 생성
애플리케이션: 배포하고자 하는 소프트웨어 애플리케이션이 포함된 리소스이다.
해당 애플리케이션을 Codepipeline과 함께 사용하여 배포를 자동화할 수 있다.
애플리케이션을 생성한다.
애플리케이션 이름을 입력하고, 컴퓨팅 플랫폼에서 EC2/온프레미스를 선택한다.
2.6. CodeDeploy 배포그룹 생성
배포 그룹: 배포할 인스턴스, 배포 속도와 같은 배포 관련 설정을 정의하는 리소스이다.
애플리케이션이 표시되는 페이지에서 배포 그룹 생성을 선택한다.
배포 그룹 이름과 CodeDeployRole 서비스 역할을 선택한다.
배포 유형은 현재 위치로 선택한다. 환경 구성에서 Amazon EC2 인스턴스를 선택한다.
키 필드에서 배포할 인스턴스를 선택한다.
배포 설정에서 해당하는 것을 선택한다.
(CodeDeployDefault.OneAtaTime) 배포 설정에서 선택할 수 있는 사항은 다음과 같다.
-
CodeDeployDefault.AllAtOnce : 한 번에 가급적 많은 수의 인스턴스에 애플리케이션 개정을 배포한다. 어떤 인스턴스에도 애플리케이션 개정이 배포되지 않으면 전체 배포 상태가 실패로 표시된다.
-
CodeDeployDefault.HalfAtATime : 최대 절반의 인스턴스에 한번에 배포한다. 애플리케이션 개정이 인스턴스의 절반 이상에 배포되면 전체 배포가 성공한다. 그렇지 않으면 배포가 실패이다.
-
CodeDeployDefault.OneAtATime : 한 번에 한 인스턴스에만 애플리케이션 개정을 배포한다.
배포 그룹 설정이 완료된 것을 확인한다.애플리케이션이 EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 경우, AppSpec file이 필요하다.
AppSpec file은 appspec.yml이라는 YAML 형식 파일이어야 하며 애플리케이션 소스 코드의 루트에 저장해야 한다.
appspec은 다음과 같이 작성될 수 있다.
version: 0.0
os: linux
files:
- source: app.js
destination: /var/www/
hooks:
BeforeInstall:
- location: install_dependencies.sh
timeout: 300
runas: root
ApplicationStart:
- location: start_server.sh
timeout: 300
ApplicationStop:
- location: stop_server.sh
timeout: 300
runas: root
ValidateService:
- location: validate_server.sh
timeout: 300
runas: root
- source : 인스턴스에 복사할 업데이트 파일 또는 디렉터리를 식별한다.
- destination : 인스턴스에서 파일이 복사되어야 하는 위치를 식별한다.
마지막으로, 배포할 EC2 인스턴스에서 CodeDeploy 에이전트가 실행 중인지 여부를 확인한다.
다음은 CodeDeploy 에이전트 상태를 확인 및 시작하는 명령어이다.
sudo service codedeploy-agent status
sudo service codedeploy-agent start
2.7. CodePipeline 생성 및 연결
이전에 만들었던 CodeCommit, CodeBuild, CodeDeploy를 연결하게 되면, 바로 CodePipeline을 통해 배포 가능하다.
파이프라인 설정 선택의 파이프라인 이름을 입력하고, 서비스 역할에서 CodePipeline이 IAM에 서비스 역할을 생성하도록 허용한다.
아티팩트 스토어 및 암호화 키를 지정한다.
소스 단계 추가의 소스 공급자에서 AWS CodeCommit를 선택한다.
이전 단계에서 생성한 CodeCommit 리포지토리 이름을 선택한다. 브랜치 이름에서 master를 선택한다.
빌드 단계 추가에서 이전 단계에서 진행했던 프로젝트를 선택한다.
빌드 단계 또는 배포 단계는 스킵이 가능하다. 하지만 빌드 단계와 배포 단계 모두 스킵할 수 없다.
배포 단계 추가의 배포 공급자에서 AWS CodeDeploy를 선택한다.
애플리케이션과 배포그룹은 이전 단계에서 생성한 이름을 선택한다.
검토에서 정보를 검토한 다음, 파이프라인 생성을 선택한다.
파이프라인이 성공적으로 실행되었는지 확인하려면, 파이프라인의 초기 진행 상황을 확인해야 한다.
각 단계의 상태는 [No executions yet]에서 [In Progress]로 바뀌며, 다시 [Succeeded]나 [Failed] 중 하나로 바뀐다. 파이프라인 상태가 성공 또는 실패로 표시되면 Staging 단계의 상태 영역에서 세부 정보를 통해 자세한 상태를 확인할 수 있다.
3. 구현 결과
AWS 인프라만 이용해야 할 경우 또는 GitHub 이외의 다른 저장소를 이용할 경우, 유용한 구성 방법이다. AWS EC2 서버 이용 시, 유기적으로 빠른 배포와 AWS로 관리 포인트 통합될 수 있다. AWS Code Pipeline는 소스코드를 가져오고, 어떠한 툴을 통해 빌드하고, 배포할지 전체 Flow를 관리함에 있어서 편리하다. 정해진 기간(월단위) 동안 빌드 개수 및 걸리는 시간이 유동적일 경우, 본 방법을 고려한다. 하지만, 가격과 AWS에 종속될 수 있음을 고려해야 한다. 예를 들어 CodeDeploy 서비스의 경우, 배포를 위하여 AWS-CLI 환경 세팅을 위한 IAM이 필요하다.
'IT > AWS' 카테고리의 다른 글
AWS DataSync 이용하여 S3 버킷에서 EFS 파일 시스템으로 데이터 전송 (0) | 2020.04.09 |
---|---|
Amazon CloudWatch, AWS Lambda를 이용한 Slack notification (0) | 2020.02.26 |
AWS에서의 DevOps (0) | 2020.02.18 |
AWS S3 버킷을 이용한 CI/CD Pipeline 구축 (0) | 2020.02.17 |
AWS Elastic BeanStalk, Jenkins 기반 CI/CD 구축 (0) | 2020.02.17 |