개요
회사에서 maven을 이용해 war 기반으로 프로젝트를 운영하고 있었습니다. 기존에 원격 서버에 filezilla를 이용해서 손수 배포하고 있기 때문에 불편했습니다. 따라서, jenkins를 이용해서 간단한 클릭만으로 배포하도록 개선했습니다. 수분이 걸리고, 이력관리가 힘들었던 기존의 환경에서 단 몇 초 만에 배포가 되도록 개선하였습니다.
Jenkins 를 선택한 이유
(Jenkins 선택 이유는 아래 글을 참고해주세요)
CI 어떤 도구를 사용할까?(GitLab CI vs Jenkins vs Travis CI)
Jenkins 셋팅하기
이 글은 온프레미스 환경의 윈도우 서버 Jenkins 설치를 다룹니다.
세팅은 다음과 같습니다. Jenkins에 기존에 사용했던 버전과 똑같은 jdk, maven을 설정합니다. 실제 서비스가 배포되는 원격 서버를 등록하고, maven 빌드가 완료되면 SSH를 통해 서버에 배포되도록 합니다.
세팅에 설정해야 하는 부분은 크게 3가지입니다. 1. 시스템 설정, 2. Global Tool Configuration, 3. 플러그인 관리
- 플러그인 관리
SSL을 스킵하는 플러그인(skip-certificate-check.hpi)을 수동으로 다운로드하여서 젠킨스 plugin 폴더에 넣고 재시작합니다.
- Global Tool Configuration
JDK와 MAVEN을 설정합니다.
JDK
Jenkins 서버에 JDK를 설치하고 JAVA_HOMES 경로를 잡습니다.
MAVEN
Jenkins 서버에 Maven을 설치하고 MAVEN_HOME 경로를 잡습니다.
- 시스템 설정
맨 하단에 Publish over SSH를 선택해서 SSH 서버를 연결합니다. front, admin의 was, web 각각 2개를 연결합니다.
아래 사진은 1개의 was web 세트의 예시입니다.
Name : 등록하고자 하는 이름
Hostname : 내부 IP
Username : 서버명
Remote Directory : 파일의 위치
새로운 Item 생성
기본적인 환경 세팅이 끝났으면, 소스코드 관리, 빌드, 빌드 후 조치를 설정합니다. svn을 사용하여 maven으로 빌드하고, 각 서버의 경로에 따라서 빌드된 파일들을 이동시킵니다.
만들어야 할 Item은 크게 front, admin 2개의 프로젝트가 있으며 다시 하위에 각각 2대의 서버가 있습니다.
각 프로젝트들이 이중화가 되어있어 총 4대의 서버입니다. front, admin 2개만 item을 만들어도 되지만, 안전하게 각각 배포 적용하기 위해서 개별적으로 모두 item으로 만들었습니다.
- svn 연동
svn 정보를 입력합니다.
Repository URL : svn 주소
Credentials : 계정 정보
- Build
Global Tool Configuration에서 등록했던 maven으로 Build를 합니다.
먼저 clean으로 초기화하고, package를 하는데 live 설정 파일을 이용합니다.
- 빌드 후 조치
web과 was 2가지 설정을 합니다. 이는 이전에 시스템 설정에서 등록했던 서버들입니다.
빌드된 파일 war를 해제하고 정해진 경로로 이동시킵니다.
- 재기동 자동화하기
container 재기동을 자동화할 수도 있습니다. 위의 명령어를 추가하면 boot.properties에 저장된 관리자 권한을 이용해 재기동을 합니다. 이 부분은 선택사항입니다. 한 번에 재기동을 할 수도 있고, 경우에 따라서 재기동을 따로 관리할 수 있습니다.
아무래도 좀 더 안전하게 운영을 반영하려면 재기동은 수동으로 하는 것이 좋습니다
배포 운영 방식
front, admin 프로젝트는 각각 2개의 서버로 이중화가 되어있습니다. 이를 쉽게 A컨테이너, B컨테이너로 구성되어 있다고 가정하겠습니다. 배포를 위해 A 컨테이너를 빌드, 배포하고 재기동을 합니다. 그리고 B 컨테이너는 잠시 내리고 A 컨테이너에서 반영 테스트를 합니다.
이상이 없으면 B 컨테이너도 빌드, 배포 및 재기동을 합니다.
만약 A 컨테이너만 띄운 상태에서 문제가 생기는 경우, A컨테이너를 다시 내리고 B 컨테이너만 서비스에 운영합니다. 그리고 A를 롤백시키고 다시 재기동합니다. 이후 코드를 수정하고 다시 배포 과정을 거칩니다.
경우에 따라 front와 admin이 같이 연동되어 테스트를 해야 한다면, 역시나 한쪽만 배포하여 하나의 컨테이너로 먼저 테스트를 합니다.
결론
- 수동으로 배포하던 작업을 자동으로 하므로 간편한 버튼 클릭만으로 CI/CD가 가능해졌습니다.
- 명시적으로 이력을 남기고 손쉽게 배포를 가져갈 수 있다는 점에서 굉장히 편리해졌습니다.
- 배포 시간이 5분 이내로 단축하였습니다.
- 사람이 손으로 배포하면서 실수할 수 있었던 위험성을 제거했습니다.
- 후에 Github, 혹은 Docker를 같이 사용해서 좀 더 유연한 배포를 도전해보면 좋을 것 같습니다.
'문제 해결, 기술 비교 > 실무 업무 회고' 카테고리의 다른 글
| 할인 쿠폰 개선하기 (0) | 2022.12.28 |
|---|---|
| 수기 업로드 작업 자동화 및 이메일 솔루션 사용 (0) | 2022.12.16 |
| NICE API 일시불 취소 개발하기 (0) | 2022.12.09 |
| 스케줄링에 어떤 기술을 사용할까?(@Scheduled vs Spring Batch vs Quartz) (0) | 2022.11.10 |
| CI 어떤 도구를 사용할까?(GitLab CI vs Jenkins vs Travis CI) (0) | 2022.05.25 |
