지금 진행중인 SNS 프로젝트 에 Cacahe를 적용하기 전에
캐시 적용 전, 후 부하 테스트 결과의 차이를 확인하기 위해서
배포를 위해 Jenkins로 CI/CD 부터 자동화 시켜보자.
Jenkins 관련 포스팅
CI/CD란?
RedHat 에서 정의한 CI/CD의 개념은 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법이다.
이렇게만 들으면 왜 CI/CD 자동화를 구축해야 하는지 와닿지 않는다.
애플리케이션의 규모가 크다고 가정하자.
그럼 단순히 개발하고 테스트, 빌드, 배포를 하는데만 시간이 꽤 걸릴 것이다.
또한 한 사람이 관리하는 게 아니라 몇십명으로 구성된 팀이 관리할 것이기 때문에
이 애플리케이션의 수정본을 하나로 합치는 것부터 배포까지 시간이 오래 걸려 긴 배포 주기를 갖게 될 것이다.
시간이 오래 걸리면 사용자의 피드백을 빠르게 반영할 수 없고 배포 과정 속에서 문제가 발생할 가능성도 높다.
이런 문제점을 개선하기 위해 CI/CD를 적용해야 한다.
애플리케이션 코드 병합부터 테스트, 배포까지 라이프사이클 전체에 걸쳐
자동화시켜 더 짧은 주기로 고객들에게 애플리케이션을 제공할 수 있어야 한다.
따라서 CI/CD는 지속적인 통합(Continuous Integration),
지속적인 서비스 제공(Continuous Delivery), 지속적인 배포(Continuous Deployment)로 구성되어 있다.
지속적인 통합
지속적인 통합, CI(Continuous Integration)란 자동화된 빌드 및 테스트가 수행된 후,
개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하는 DevOps 소프트웨어 개발 방식이다.
버전 관리를 통한 코드 병합, 빌드, 테스트, 오류 보고를 자동화하여 반복적인 작업을 줄이고,
발생한 문제에 대해 빠르게 처리가 가능하여 더 좋은 품질의 소프트웨어를 개발할 수 있다.
지속적인 서비스 제공
지속적인 서비스 제공, CD(Continuous Delivery)는 반복적인 작업을 자동화한 CI 과정을 거친 소스코드를 레포지토리에 자동으로 반영하는 단계를 의미한다.
바로 프로덕션 단계로 배포하는 지속적인 배포 단계로 확장이 가능하지만, 따로 테스트 환경에 배포하여 추가적인 여러 사용자 차원에서 테스트를 검증할 수 있다.
지속적인 배포
지속적인 배포, CD(Continuous Deployment)는 CI/CD의 마지막 단계로 모든 테스트를 거친 코드를 레포지토리에 자동으로 반영하는 지속적인 서비스 제공 단계의 확장된 형태이다.
애플리케이션을 프로덕션 단계로 자동으로 배포하는 작업을 자동화하여, 개발자가 변경 사항을 적용한 후 짧은 시간 이내에 사용자는 새로운 버전의 애플리케이션을 사용할 수 있다.
CI/CD 프로세스 속에서의 애플리케이션 배포 과정
- 개발자는 소스 코드를 수정하고, 코드 컨벤션을 준수했는지, 코드가 잘 작동하는지 Pull Request를 보내 자동으로 확인합니다.
- 변경된 소스 코드에 대해 코드 리뷰를 진행한다.
- 코드 리뷰가 끝나면 PR Merge 작업이 수행된다.
- 배포 가능한 소스 코드를 주기적으로 빌드하여 테스트 버전을 생성한 후, 여러 테스트를 진행한다.
- 테스트 과정에서 발생한 오류를 수정하여 스토어에 배포한다.
위와 같은 작업을 자동화하여 배포 주기 단축 및 불편함을 최소화하는 것이 CI/CD 구축 목적이다.
Jenkins 설치 & 기본 설정
Jenkins는 CI/CD 자동화를 제공하는 툴이다.
다양한 플로그인과 문서를 지원하기 때문에 나도 프로젝트에서 항상 사용해왔다.
설치 방법이 어려운건 아닌데 최신 버전이 아니면 플러그인이 정상적으로 설치되지 않는다.
클라우드에서 제공하는 Jenkins 서버는 최신 버전이 설치되지 않는 경우가 많으니
직접 설치하는게 좋을 것 같다.
$ sudo yum install wget
$ sudo yum install maven
$ sudo yum install git
$ sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
$ sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
$ sudo yum install jenkins
$ sudo systemctl start jenkins
$ sudo systemctl status jenkins
위와 같은 명령어로 Jenkins를 설치하고 시작할 수 있다.
이 외에 주의할 점은 java, gradle 버전 체크이다.
당연히 동일해야 하므로 확인해보는 것이 좋다.
PR 이벤트 발생 후 머지해도 되는지 자동으로 체크
PR을 올렸는데 merge해도 될지 자동으로 테스트 후,
결과를 Git에 출력해주는 CI를 구축했다.
만약 빌드에 실패하면 merge할 수 없다고 알려주고
Details 클릭 시 스크립트를 보여주기 때문에 빠르게 오류를 찾고
PR 이벤트에 관련된 작업을 쉽게 자동화할 수 있다.
다음과 같이 PR이 발생하면 젠킨스 작업이 진행된다.
젠킨스 작업이 완료되면 PR 페이지에서 결과를 확인할 수 있다.
원하는 branch 배포하기
학습을 목적으로 진행하는 프로젝트이기 때문에 master 브랜치에 push 될 때
무조건 배포되게 설정하지 않고 Git에서 내가 원하는 브랜치를 배포하기 위해서
Build With Parameters에 String 매개변수를 지정해놨다.
브랜치를 입력하고 빌드 하기를 누르면 해당 브랜치를 clone 하고 운영 서버에 배포된다.
Jenkins에서 빌드하고 jar와 config를 운영 서버에 전송하는데
예전 프로젝트에서 배포 과정을 이해하기 위해 scp, ssh 명령어로 직접 전송하고 배포했는데
Jenkins의 Publish Over SSH 플러그인을 사용하면 쉽게 파일들을 전송할 수 있다.
한가지 주의할 점은 절대경로가 아닌 상대경로로 지정해야 정상적으로 작동한다는 것이다.
운영 서버와 ssh 접속 설정은 젠킨스 시스템 설정 > Publish over SSH 에서 가능하다.
port, password, remote directory 까지 쉽게 설정할 수 있다.
- Name: SSH Server 이름을 선택하면 된다.
- Verbose output in console을 체크하면 빌드할 때 상세 내역이 표시 된다.
- Source files : 전송할 파일을 지정한다. 전체 파일 이동을 하려면
**/*과 같이 입력 - Remove prefix : Source files에서 지정한 경로의 하위 폴더를 지우는 기능 이다.
위의 예시같이 입력한다면 폴더를 제외하고 jar 파일만 전송하게 될 것이다. - Remote directory : SSH Server로 지정한 서버의 원격지 폴더이다.
- Exec command : 파일 전송이 모두 끝난 이후에, SSH Server로 지정한 서버에서 실행될 스크립트를 지정할 수 있는 기능
끝!
모든 설정이 끝나면 위와 같이 테스트, 배포를 편하게 진행할 수 있다.
참고
- https://www.redhat.com/ko/topics/devops/what-is-ci-cd
- https://engineering.linecorp.com/ko/blog/build-a-continuous-cicd-environment-based-on-data/