[AWS] Codepipeline - Source 및 Deploy 단계 자동화 테스트

Squirrel·2022년 1월 12일

CI/CD CodePipeline aws awscicd awscodecommit awscodedeploy awscodepipeline awstest aws테스트 코드파이프라인

AWS

목록 보기

4/5

AWS Codepipeline은 소프트웨어 릴리스 프로세스를 모델링 및 시각화에 사용하고,
코드 변경이 있을때마다 코드 빌드, 테스트 및 배포를 자동화할 수 있게 해주는 지속적 전달 서비스이다.

즉, 개발자는 배포 스크립트를 수동으로 트리거하지 않아도 애플리케이션에 대한 새로운 기능과 버그 수정 등을 빠르고 안전하게 릴리스할 수 있다.

여기에서는 Source 단계에서 Codecommit을, Deploy 단계에서 CodeDeploy를 사용한다. Codecommit에 변경 사항을 푸시하면 파이프라인이 트리거되는데 파이프라인은 CodeDeploy를 사용하여 EC2에 변경 사항을 배포하는 로직을 자동화한다. (아래 링크의 AWS 자습서를 참고하였다.)

https://docs.aws.amazon.com/ko_kr/codepipeline/latest/userguide/tutorials-simple-codecommit.html

1. Codecommit 리포지토리 생성

파이프라인이 실행될때 소스 코드를 가져올 리포지토리를 생성한다.

Create Repository > 이름 설정(’TestRepo’) > Create

2. Codecommit 리포지토리에 샘플 코드 추가

AWS 자습서에 나와있는 샘플 코드를 다운로드하여 Codecommit 리포지토리에 파일을 업로드한다.

SampleApp_Linux 파일 링크

위 링크에 있는 파일을 로컬에 다운로드 후 압축을 풀면 아래와 같은 구조가 되는데 MyDemoRepo 디렉토리 안에 총 3개의 파일과 1개의 폴더(scripts) 그리고 scripts 폴더 하위에 세 개의 파일들이 있다.

/tmp
   └-- MyDemoRepo
       │-- appspec.yml
       │-- index.html
       │-- LICENSE.txt
       └-- scripts
           │-- install_dependencies
           │-- start_server
           └-- stop_server

콘솔을 사용하여 리포지토리에 위 파일들을 업로드하는 경우
먼저, 세 개의 파일들에 대해서는 아래와 같은 단계로 추가해준다.

생성한 Repository > Add file > Upload file > Choose file > 파일 선택 > author 이름 및 메일 기입 > Commit changes 선택

위 세 개의 파일에 대한 업로드 후 scripts 폴더 하위에 있는 파일들의 경우 아래와 같이 업로드해주었다.

Create file > 파일 내용 복사 + 붙여넣기 > file name에 ‘폴더’/’파일이름’(scripts/install_dependencies)과 같이 순차적으로 기입 > author 이름 및 메일주소 기입 > Commit changes

나머지 2개 파일도 동일하게 수행해준다.

파일을 모두 업로드하면 리포지토리에 아래와 같이 보여진다.

3. EC2 linux 인스턴스 생성 및 Codedeploy 에이전트 설치

이제 샘플 애플리케이션을 배포할 EC2 인스턴스를 생성하고
Codedeploy 배포에서 인스턴스를 사용할 수 있도록 EC2 인스턴스에 codedeploy 에이전트를 설치한다.

또, IAM role을 인스턴스에 연결하여 CodeDeploy 에이전트가 애플리케이션을 배포하는 데 사용하는 파일을 가져올 수 있도록 한다.

3-1. IAM role 생성

아래와 같이 AmazonEC2RoleforAWSCodeDeploy 정책을 연결한 IAM role을 생성한다.

3-2. 인스턴스 생성

인스턴스를 생성하는데 생성 시 아래 항목에 대해 체크 및 기입한다.
자세한 내용은 링크[1]의 3단계를 참고하자.

Auto-assign Public IP > Enable.
앞에서 생성한 IAM role 선택 (EC2InstanceRole)
Advanced Details > User data > 아래 기입

#!/bin/bash
yum -y update
yum install -y ruby
yum install -y aws-cli
cd /home/ec2-user
wget https://aws-codedeploy-us-east-2.s3.us-east-2.amazonaws.com/latest/install
chmod +x ./install
./install auto

Tag > Name/MyCodePipelineDemo
보안그룹 > (1) SSH : MyIp / (2) HTTP: MyIP

이 때, 지정해주는 Tag는 CodeDeploy에서 배포 대상 EC2 인스턴스를 찾는 데 사용된다.

4. CodeDeploy에서 애플리케이션 만들기

인스턴스를 구성한 후 revision을 배포하려면 먼저 Codedeploy에서 애플리케이션을 만들어야 한다.
애플리케이션은 CodeDeploy에서 배포 중에 올바른 revision, 배포 구성 및 배포 그룹이 참조되는지 확인하기 위해 사용하는 이름 또는 컨테이너이다.

4-1. CodeDeploy Service role 생성

먼저, Codedeploy가 배포를 수행하도록 허용하는 역할을 생성해준다.

CodeDeployRole이라는 이름의 역할을 생성하였다.

4-2. CodeDeploy에 애플리케이션 생성

CodeDeploy > Applications > Create application

EC2에서 수행할 것이므로 compute platform은 EC2/On-premises로 선택한다.

4-3. Deployment group 설정

Deployment group을 생성한다.
배포 그룹은 배포 중에 사용되는 설정 및 구성이 포함되는데 대부분의 배포 그룹 설정은 애플리케이션에서 사용하는 컴퓨팅 플랫폼에 따라 달라진다.

앞에서 생성한 Codedeploy service role을 선택해준다.

In-place > Amazon EC2 instances > Key:Name / Value:MyCodePipelineDemo
⇒ value 값에는 앞에서 생성한 EC2 인스턴스에 태그한 이름을 그대로 기입해준다.

CodeDeployDefault.OneAtATime > 로드밸런서는 여기에서는 사용하지 않을 것이므로 체크되어 있는 Enable load balancing 박스를 해제해준다.

5. CodePipeline에서 pipeline 생성

Source(Codecommit) 및 CodeDeploy 구성이 모두 완료되었으니
이제 CodeCommit 리포지토리에 코드가 푸시될때 자동으로 실행될 파이프라인을 생성한다.

Pipeline > Create pipeline

source provider로 AWS CodeCommit 선택 > Repository는 앞에서 생성한 Codecommit 리포지토리 명 선택 > Branch name은 main을 선택 > 나머지는 default > Next

Build 단계는 여기서는 테스트하지 않을 것이기 때문에 Skip하자.
Skip build stage 를 선택하면 아래와 같은 메시지가 나오는데 Skip을 눌러주면 된다.

deploy 단계도 아래 항목에 대해 앞서 생성한 리소스를 순차적으로 선택해준다 > Next > Create pipeline

이렇게 pipeline을 생성하고 시간이 지나면 아래와 같이 Source → Deploy 단계가 Succeeded로 변경된다.

앞에서 생성한 EC2 인스턴스의 Public DNS로 접근해보면 아래와 같이 애플리케이션이 성공적으로 배포되었음을 알리는 화면이 나타난다.

6. CodeCommit 리포지토리에서 코드 수정

그렇다면 이제 실제로 CodeCommit 리포지토리에 코드가 변경될 때마다 파이프라인이 앞에서 구성한대로 동작하는지 확인해보자.
여기에서는 Codecommit 리포지토리에 있는 html 파일을 변경한다.

html 파일에서 웹페이지의 배경색 및 일부 내용을 변경한 후 commit changes해준다.
변경 후 Codepipeline을 바로 확인하니, 리포지토리의 변경 사항을 감지하고 파이프라인이 트리거되어
이전에 배포된 source 및 deploy와는 다른 실행 ID를 가진 파이프라인이 생성되고 있는 것을 확인할 수 있다.