728x90

CI/CD 적용 후 아키텍처 도식도

 

CI/CD가 필요한 이유

  • 새로운 코드 변경사항이 정기적으로 테스트 빌드 되므로, 여러 명의 개발자가 동시에 어플리케이션 개발을 할 때 충돌 문제를 해결할 수 있다. 그리고 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하기 위함이다.
  • CI/CD 프로세스를 적용함으로써 수작업으로 진행되었던 많은 부수적인 일들을 줄일 수 있다. 그리하여 개발자는 개발에 집중할 수 있다.

 

CI/CD 적용

NBP(네이버 클라우드 플랫폼)에는 CI/CD 구축을 돕기 위해 SourceCommit, SourceBuild, SourceDeploy, SourcePipeline을 제공하고 있다. 나열한 순서대로 CI 부터 CD까지 적용을 돕는다. 그리고 SourcePipeline으로 CI/CD 모든 과정을 이어준다.

SourceCommit

1. 외부 레포지토리 복사를 클릭

image

"레포지토리 생성"을 누르면 빈 레포지토리가 생성되고 "외부 레포지토리 복사"를 누르면 외부의 레포지토리를 복사할 수 있다. 나는 깃헙에 있는 레포지토리를 복사하는 것을 선택했다.

 

2. 레포지토리 생성

image

레포지토리 이름과 복사할 Git URL을 입력한다.

그 다음 File Safer 상품과 연동할 것인지 묻는다. (File Safer는 고객이 업로드/다운로드 하는 파일의 악성코드 여부를 검사할 수 있는 서비스이다.)

처음에 연동을 하고 하루가 지나고 지불된 금액을 확인했는데 바로 10만원 가까이 나가있었다.. 그래서 나는 연동을 하지 않았다.

 

3. 생성

image

확인을 누르면 생성이 된다.

 

4. 생성된 레포지토리를 클릭하고 코드 이동을 누르면

imageimage

깃헙에 있었던 코드들이 그대로 옮겨져 있는 것을 볼 수 있다. 여기서 오해할 수 있는 점이 깃에 푸시를 해도 NCP의 SourceCommit 레포지토리에 반영은 되지 않는다. 그 의미는 깃헙의 깃액션 CI를 사용하지 못한다는 의미이다.

해당 SourceCommit 레포지토리에 반영을 하려면

image

따로 git clone을 해줘야한다. SourceCommit은 git 명령어를 지원해서 기존 깃헙 사용자들도 사용하기 편리할 것이다.

 

SourceBuild

1. 빌드 프로젝트 생성

image

2. Object Storage 연결

image

빌드한 결과물을 저장해두는 저장소 같은 개념이다. AWS의 S3랑 비슷한 개념을 가진 저장소이다.

 

3. 빌드 프로젝트 생성 - 기본 설정

image

여기서 중요한 곳은 빌드 대상인데, SourceCommit, 깃헙, Bitbucket에 있는 레포지토리 세 가지를 선택할 수 있다. 나는 SourceCommit을 선택하였다.

깃헙을 선택해서 깃헙에 있는 레포지토리에 push를 하면 그게 트리거가 되어서 배포 파이프라인이 작동되게끔 하고 싶었는데 NCP에서는 깃헙의 트리거를 못받는 것 같았다. 그래서 빌드 대상을 깃헙 대신 SourceCommit을 선택 하였다.

이 부분은 추후 젠킨스로 구현 해봐도 좋을 것 같다.

 

4. 빌드 프로젝트 생성 - 빌드 환경

빌드 환경 설정이다.

image

ubuntu 16.04 (x64) 환경에서 java로 빌드하게 하였다. 비용 문제로 컴퓨팅 유형은 제일 작은걸로 하였다.

그리고 나의 프로젝트에서 docker-compose를 사용하기 때문에 도커 환경이 필요했다. 그래서 도커 이미지 빌드 를 체크 해주었다. 도커 환경이 필요하지만 체크를 하지 않으면 명령어로 도커를 다운로드하고 설정하는 귀찮은 작업을 따로 해주어야한다.

 

5. 빌드 프로젝트 생성 - 빌드 명령어 설정

image

SourceCommit에 있는 프로젝트를 빌드 하고 필요한 명령어를 입력하는 곳이다.

나는 빌드 후 프로젝트 전체를 jar파일로 말아올려 서버에서 실행시킬 명령어인 ./gradlew bootjar 명령어를 입력 해주었고 깃헙을 거쳐 깃헙 액션을 실행시키지 못하는 환경을 대신해서 ./gradlew test 명령어를 실행시켜 빌드 후 테스트 과정도 거치게 하였다.

 

6. 빌드 프로젝트 생성 - 결과물 업로드 설정

image

빌드 후 결과물을 Object Storage에 저장할 때 경로를 설정하는 곳이다. 빌드 결과물은 .zip 파일로 저장이 된다. 빌드 결과물을 저장할 Storage를 설정하고 경로, 폴더/파일명을 설정한다. 그리고 백업파일 여부도 설정한다.

백업 사용을 설정하면 Object Storage에 따로 백업 폴더가 생성된다.

 

7. 빌드 프로젝트 생성 - 추가 상품 연동

image

추가 상품은 비용 문제로 연동하지 않았다.

 

SourceDeploy

1. 배포 프로젝트 생성

image

2. 프로젝트 이름 설정

image

3. 배포 환경 설정

image

배포 환경 설정에서 stage를 설정하고 배포 타겟을 설정한다. 나는 Auto Scaling 되고있는 서버 전체에 모두 배포를 하기 위해서 배포 타겟을 Auto Scaling으로 했다. 사실 Server를 체크 해서 해도 되지만 만약 Auto Scaling에서 서버를 자동적으로 늘릴 때 그 서버를 수동으로 포함 시켜줘야하기 때문에 Auto Scaling으로 체크 하였다.

 

4. 배포 시나리오 설정

설정이 끝나면 배포 시나리오를 설정 해야한다.

image

아래처럼 배포 시나리오를 설정하면 된다.

image

배포 전략에 지금은 기본으로 되어있지만 추후 블루/그린 배포 전략을 사용 해볼 예정이다.

배포 과정은 순차 배포, 동시 배포가 있는데 순차 배포가 더 낫다고 생각하여 순차배포를 선택하였다. 그 이유는 배포과정에 놓여진 서버는 로드벨런서가 트래픽을 보낼 수 없기 때문에 순차적으로 배포 될 때 배포 되고 있지 않는 서버들에게는 트래픽을 보낼 수 있기 때문에 무중단 배포가 된다고 생각하여 순차 배포가 낫다고 생각하였다.

배포 파일은 Object Storage에 있는 빌드된 zip 파일을 배포하는 것으로 설정 해두었다.

그 다음은 배포 명령어를 설정한다.

image

배포 전 실행, 파일 배포, 배포 후 실행으로 나뉜다.

설정할 때 주의할 점이 경로이다. 그리고 한 줄이 실행되면 원래의 경로로 돌아오기 때문에 &&로 구분하여 묶여있는 명령어는 한번에 처리해야한다.

 

배포 전 실행

구분 실행 명령어 설명
1 cd /usr/lib && wget https://download.java.net/java/GA/jdk16.0.2/d4a915d82b4c4fbb9bde534da945d746/7/GPL/openjdk-16.0.2_linux-x64_bin.tar.gz /usr/lib 경로로 가서 자바 다른 버전을 다운 받는다. (다른 버전을 받는 이유가 NCP가 지원하는 자바 버전이 최고 11버전이기 때문에 16버전을 다운 받기 위함)
2 tar -zxvf /usr/lib/openjdk-16.0.2_linux-x64_bin.tar.gz -C /usr/lib 위에서 받은 .tar 파일을 /usr/lib에 압축 풀기
3 yum install -y yum-utils yum-utils 를 최신 버전으로 업데이트를 한다.
4 yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo Docker Engine을 설치할 수 있도록 저장소를 추가한다.
5 yum install docker-ce docker-ce-cli http://containerd.io/ -y 도커 엔진 최신 버전을 설치한다.
6 curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose 도커 컴포즈를 설치한다.
7 chmod +x /usr/local/bin/docker-compose 도커 컴포즈가 실행할 수 있게 권한을 부여 한다.

 

파일 배포

구분 소스 파일 경로 배포 경로 설명
1 skka.zip/ /root/deploy skka.zip 파일을 /root/deploy 경로에 배포한다.

 

배포 후 실행

구분 실행 명령어 설명
1 systemctl start docker 도커 엔진 수동으로 데몬 실행
2 systemctl enable docker 도커 서비스 등록하여 부팅시 실행 하도록 하기
3 /usr/local/bin/docker-compose -f /root/deploy/docker-compose.yml up -d /usr/local/bin/docker-compose 로 도커 컴포즈로docker-compose.yml 파일에 설정 되어 있는 도커 이미지 띄우기
4 nohup /usr/lib/jdk-16.0.2/bin/java -jar /root/deploy/build/libs/skka-0.0.1-SNAPSHOT.jar & bootjar로 말아 올린 jar 파일 백그라운드로 실행

 

SourcePipeline

1. 파이프라인 생성

image

2. 파이프라인 이름 설정

image

3. 파이프라인 구성

image

작업 추가를 눌러서 파이프라인을 구성해야 한다.

그리고 Trigger를 설정한다. 트리거가 설정되면 설정된 트리거가 발생하면 설정된 파이프라인이 실행된다. 나는 SourceCommit에 push가 되면 트리거가 발동되어 설정 되어 있던 파이프라인인 빌드, 배포가 순차적으로 실행된다.

다음은 설정된 화면이다.

image

 

+ Recent posts