Jenkins를 사용하여 EC2에 자동배포하기

728x90

문제 상황

테스트를 위한 서버에 배포할 때 수동으로 진행을 하였다. 과정은 다음과 같다.

1. 깃허브에서 코드를 받아온다
2. 로컬 환경에서 빌드한다
3. 빌드 완료 후, 작업물을 .tar.gz 파일로 압축한다
4. 테스트 서버로 전송한다
5. 테스트 서버에서 압축을 푼다
6. 테스트 서버에서 필요한 install을 진행
7. 테스트 서버에서 프로젝트를 실행

QA를 진행하면서 수정사항이 생길때 마다 위의 작업을 반복하였다😂

백엔드 소스와 프론트 소스 2가지를 매번 수작업으로 진행하려니 너무너무 귀찮았다

사실 그린/블루 배포가 구축된게 있으나

테스트 서버 배포에 사용하기에는 너무 과한 느낌이고 무엇보다 너무 느려서 결국 수동 배포를 하게 된다

수동 배포가 결국 위의 작업을 반복하는 것이기에 귀찮음을 이기지 못하고 자동화를 하기로 마음먹었다😁

준비

기술 Stack 선정

처음에는 AWS를 이용할까했다. 다른 팀원분들도 배포를 할 수 있게 개발하고 싶었는데 AWS를 이용하면 계정도 부여를 해주어야 되고 DevOps를 모르는 분들이 사용할때 부담스러워하실 것도 같아서 포기.

CI/CD 툴 중에 무엇이 좋은지 살펴보던 중, Jenkins가 눈에 들어왔다.

구글링을 하던 도중 한 포스트 글을 발견하였다. 비슷한 문제 상황을 가지고 있는 것 같았고 결과물 또한 내가 원하는것과 흡사해 보였다.

해당 글을 참고하여 개발하면 되겠다 싶어서 바로 Jenkins로 결정!

요즘 흥미를 가지고 있었던 Doker도 이참에 한 번 써볼까 싶었다. 자료를 찾아보니 Doker + Jenkins 좋은 자료도 많고 재미있어보여서 바로 채택!

구상

1. 도커에 Jenkins 설치해서 실행
2. Jenkins를 통해서 배포를 시키면 위의 배포 작업을 알아서 실행
3. 배포 완료 후, 슬랙을 통해 완료 메세지 발송

개발

1. 도커 설치

윈도우에 도커를 설치하는 방법은 구글링하면 잘 정리된 글이 많기에 패스!

2. 도커에 Jenkins 설치

관련 내용은 블로그 다른 글(https://rosyhuedoyou.tistory.com/147)에 정리하였습니다

3. 깃허브 레포 소스코드 받아오기

회사 코드 레포가 private라서 ssh 방식으로 연동하였다

public 레파지토리면 굳이 ssh말고 깃허브 계정으로도 연동이 가능한 것 같다

관련 내용은 블로그 다른 글(https://rosyhuedoyou.tistory.com/145)에 정리하였습니다

4. Jenkins에서 EC2로 배포하기 (php)

소스코드를 받아왔으니 이제 해당 코드를 빌드 및 압축을 한 뒤 EC2 인스턴스로 보내어 압축 해제 후 배포하는 일만 남았다

⭐ 압축하기

대시보드 > Jenkins Item > 구성으로 이동하여 Build Steps를 찾는다

여러 항목들 중에서 Execute shell를 선택하여 추가해주자

Execute shell을 이용하면 소스코드를 받아온 후에 실행시킬 스크립트를 작성할 수 있다

테스트 서버 배포 과정 중에서

2. 로컬 환경에서 빌드한다
3. 빌드 완료 후, 작업물을 .tar.gz 파일로 압축한다

이 두가지 작업을 스크립트를 통해서 처리하고 싶었기에, 다음과 같이 스크립트를 작성해주었다.

#!/bin/sh
cd ..
tar -zcvf ./file-name.tar.gz ./jenkins-item-name
mv ./file-name.tar.gz ./jenkins-item-name/file-name.tar.gz

압축하는 디렉터리 안에 .tar.gz 파일을 위치시키면 tar: file changed as we read it에러가 발생하게 된다

압축 파일은 계속 수정이 되고 있는데, 압축 공간을 읽어 나가며 압축을 진행하다가 압축 파일 본인을 읽으면 변경 중인 파일이기에 충돌이 나는 것이었다

결국 압축이 되는 공간 안에 압축 파일을 존재시키기에 문제가 발생하는 것이기에, 압축 공간 바깥에다가 압축 파일을 위치 시키고 종료 후에 작업 공간으로 옮겨오는 방법을 택하였다

⭐ AWS EC2에 파일 전송

이제 압축한 파일을 EC2 인스턴스에 전송해야 한다

관련 내용은 블로그 다른 글 (https://rosyhuedoyou.tistory.com/148)에 정리하였습니다

위 글에서는 파일을 EC2 인스턴스로 보내는 방법까지만 정리를 하였으니, 그 이후 작업에 대해서 조금 더 끄적여보자면

일단 본인은 위와 같이 설정을 하였다

.tar.gz 압축 파일을 EC2 인스턴스로 전송한 뒤에 build.sh라는 스크립트 파일을 실행시키는 과정까지 진행하게 된다

build.sh의 내용은 다음과 같다

#!/bin/sh
rm -rf jenkins-item-name
tar -zxvf file-name.tar.gz
cd jenkins-item-name
composer install

기존에 배포되었던 파일을 제거 ➡ 압축 해제 ➡ 해당 폴더로 이동 ➡ php 프로젝트이기 때문에 composer install 진행

4. 테스트 서버로 전송한다
5. 테스트 서버에서 압축을 푼다
6. 테스트 서버에서 필요한 install을 진행
7. 테스트 서버에서 프로젝트를 실행

여기까지 진행하면 저 모든 배포 과정을 완료한 것과 동일하다. 이제 테스트서버에 가서 확인을 해보면 잘 동작하는 것을 확인해 볼 수 있었다😁

5. Jenkins에서 EC2로 배포하기 (vue)

대부분의 과정은 위와 동일하나 Vue 프로젝트이다보니 npm install과 build에서 에러가 발생했다

작업공간에 npm이 설치되어있지 않기 때문에 발생한 문제였는데

이를 해결하기 위한 방법은 다른 블로그 글(https://rosyhuedoyou.tistory.com/150)에 정리해두었습니다

6. 슬랙으로 배포 완료 메세지 발송

배포 완료 후에 슬랙으로 안내 메세지를 발송하고 싶었다

이에 관한 방법은 다른 블로그 글(https://rosyhuedoyou.tistory.com/146)에 정리해두었습니다

7. 빌드 시, 깃허브 브랜치 선택

다른 브랜치로 바꾸어 배포하고 싶을 때, 매번 jankins item > 구성 으로 가서 브랜치 명을 입력하는게 귀찮게 느껴졌다

브랜치명을 잘못 입력할 수도 있고, 실수로 빌드해둔 배포 시스템을 건들 위험성도 있어보여서 수정작업에 들어갔다

이에 관한 방법은 다른 블로그 글(https://rosyhuedoyou.tistory.com/151)에 정리해두었습니다