이번에는 젠킨스를 활용하여 배포를 자동으로 할 수 있도록 환경을 세팅해보는 시간을 가져볼 것이다.
젠킨스가 설치된 환경에 배포하는 것 보다는 실제로 빌드를 하여 실제 운영하는 서버에 SSH를 통해 빌드된 파일을 전송하여 배포하는 방식을 많이 사용하기 때문에 이번에는 SSH 플러그인을 활용하여 빌드파일 전송 및 배포하는 작업을 설명하겠다.
소스코드는 Git에 저장된 레파지토리를 모니터링 하다가 특정 브랜치에 상태가 바뀌었을 시 젠킨스가 소스코드를 가져와 빌드를 하는 방식이다.
이렇게 빌드를 하는 순간에는 젠킨스가 빌드와 테스트를 하며, 빌드가 끝나면 Jar파일이 만들어 진다.
먼저 SSH 플러그인 다운로드 작업을 진행한다. 플러그인을 다운 받기 위해서는 Jenkins 관리의 플러그인 관리를 클릭하여 검색 후 설치가 가능하다.
SSH라고 검색을 하면 Publish Over SSH라는 목록이 보일 것이다.
체크박스를 클릭하고 하단의 Download now and install after restart를 클릭한다.
해당 버튼을 클릭하면 제일 하단에 지금 재부팅이라는 버튼이 있을 것이다. 해당 버튼을 클릭하면 젠킨스 서버가 재구동 되면서 사용할 수 있는 환경이 만들어진다.
이후 시스템 설정의 제일 하단으로 가면 그전에는 볼 수 없었던, Publish over SSH를 볼 수 있다.
그림에 보이는 SSH Servers의 추가를 클릭하여 젠킨스에 등록할 애플리케이션 서버 정보를 등록한다.
고급버튼을 누르면 해당 서버의 비밀번호나 기타 설정할 수 있는 화면이 나오니 참고 바란다.
이제 빌드 애플리케이션을 하나 만들어보도록 하겠다.
좌측 상단의 item 버튼을 눌러 프로젝트를 하나 만들어보도록 하자
프로젝트 이름을 상단에 삽입을 한 뒤 Freestyle project를 눌러 생성을 해준다.
프로젝트를 생성한 이후에는 프로젝트 설정을 진행한다. 이번에 진행할 애플리케이션은 Github에 있는 프로젝트를 사용하여 자동 배포를 진행 할 것이기 때문에 Github Project를 클릭해준다.
Git에 대한 정보를 채워준 후 Credentials 정보를 리스트에서 선택한다.
처음에는 없기 때문에 새롭게 만들어준다.
하단의 Add 버튼을 클릭하여 GitHub에 대한 정보를 생성한다.
Username : Git에서 사용하는 이름을 채워 넣는다.
Password에는 git의 tocken을 생성해서 넣어주면된다.
ID는 해당 Credential의 이름으로 아무거나 구별가능하도록 만들어 주면된다.
Desctription은 채워넣지 않아도 무관하다.
깃허브에 들어가면 오른쪽 상단에 프로필이 보일 것이다.
이것을 클릭하면 Settings를 볼 수 있을 것이다. 이것을 클릭하여 페이지를 이동한다.
프로필의 최하단의 Developer Settings를 눌러주도록한다.
다음으로 Personal access tokens를 클릭하여 새로운 토큰을 생성 해주도록 한다.
Expiration은 원하는 기간 만큼 설정 하도록 하고, scope도 필요한 것 만 체크 하도록 한다.
체크를 완료하고 Generate Token을 클릭하면 Token을 1회로 보여주게 된다.
이것을 복사하여 Password에 첨부하여 넣어주기만 하면 된다.
다음 설정은 Hook 설정이다. 젠킨스가 Git Repository에 소스코드가 갱신되었다는 것을 자동으로 알 수 가 없다. 따라서 Hook이라는 것을 설정하여 젠킨스가 모니터링을 할 수 있도록 만들어 주는 것이다.
상단에 그림처럼 Github hook trigger for GITScm polling을 체크하여 젠킨스가 모니터랑 할 수 있도록 해준다.
하지만 이것만 해서는 완전히 끝난 것이 아니다. GitHub에 들어가 설정을 마무리 해야한다.
Hook을 지정할 Repository에 Settings에 들어가면 Webhooks라는 기능이 있다.
이곳에서 Add webhook을 클릭하여 훅을 설정해준다.
위 화면에서 검은색으로 마킹해놓은 곳은 Jenkins가 운영되고 있는 서버주소이다.
뒤에 나오는 github-webhook은 절때 바꿔서는 안되고 가운데 젠킨스 서버 주소만 변경하도록 하자.
프로젝트를 빌드를 진행하겠다.
필자는 Gradle을 사용했기 때문에 Gradle를 선택하였지만, Maven을 사용하는 필자가 있으면 변경 하면된다.
Task에는 필드를 수행하기 위한 명령어를 넣어두면된다.
이전 빌드파일을 지우기 위한 clean과 build를 함께 작성하여 빌드 파일을 지운 후 다시 빌드하는 절차를 거치도록 세팅해놓는다.
빌드를 무사히 마친 후 운영서버에 실제로 배포를 하는 작업을 할 차례이다.
빌드를 마친 파일을 SSH를 통하여 다른 곳으로 전송하는 설정을 해보도록 하겠다.
전에 젠킨스를 설치 할때 같이 설치한 Open SSH 플러그인 설정을 불러와 세팅을 진행한다.
여기서 가장 주용한 것은 Source Files, Remove prefix 경로이다.
이것을 잘 세팅해주지 않으면 SSH 전송이 되지 않는 불상사가 생기게 된다.
상단에서 먼저 작업했던 SSH Server 목록이 최상단의 Name 리스트에서 확인이 가능하다 연결할 정보를 클릭하여 선택을 한 뒤 Source files 경로를 설정해준다.
여기서 제일 시간을 많이 잡아먹는 곳으로 필자도 고생을 많이 하였다.
기본적으로 프로젝트 baseUrl은 /var/jenkins_home/workspace/[프로젝트 이름] 이다.
필드를 수행하게 되면 하위 폴더의 build/libs 아래 빌드가 완료된 파일이 들어있다.
사진에서 처럼 기본 baseUrl을 때고 그 다음 하위 부터 적어주면 되겠다.
Remote directory는 SSH 서버를 세팅했을 당시의 경로의 하위경로에 파일을 전송하고자 할 때 사용하는 것으로 필자는 SSH 서버 세팅시 미리 빌드 파일 저장 경로를 지정했기 때문에 사용하지 않았다.
Exec command는 SSH를 통해 파일을 전송하고 난 후 수행할 명령을 입력하는 곳이다.
필자는 여기서 docker를 재실행 하는 명령어를 넣어주어 빌드파일이 업로드 될 때 자동으로 재실행 까지 하도록 제작을 하였다.
여기서 중요한 것은 Shell script를 만들어서 한번에 실행하는 것이 중요한데, 경로는 절대 경로로 지정하는 것이 가장 빠르고 편리하다.
여기까지 모두 완료가 되면 Git에 파일을 Push 하면 지정한 브렌치에 변화가 생길 때 젠킨스가 g레파지토리 정보를 가져와 빌드를 수행하고 배포, 실행까지 하는 절차를 수행하게 된다.
정상적으로 수행되는 것을 확이 할 수 있다.