240701 백그라운드 실행으로 다중 인스턴스 배포하기, webhooks로 자동 배포하기

백그라운드 실행으로 다중 인스턴스 배포하기

240628 실습에 이어서 진행했다.

 

clone한 애플리케이션을 배포할 것이다.

Build Steps의 Execute shell에 위와 같이 작성한다.

이 칸에는 다양한 스크립트와 명령어를 작성해서 배포 프로세스를 자동화할 수 있다.

코드 컴파일이나 테스트, 패키징, 서버로의 배포 등 여러 작업을 수행할 수 있다.

 

만약 해당 애플리케이션 디렉터리가 있다면 삭제하고 clone한 뒤 해당 디렉터리로 이동한다.

젠킨스가 빌드툴을 실행할 수 있도록 파일 권한을 변경해주고 build를 한다.

build가 되었다면 build 하위의 libs 디렉터리로 이동한다.

 

 

 

배포할 인스턴스들을 추가한다. 

instance-1, instance-2 모두 추가했다.

이때 Source files에는 jenkins-instance가 빌드 작업을 수행하고 생성한 파일이 위치한 경로를 작성한다.

빌드가 수행되었다면 위 경로에서 파일을 찾아 원격 서버(instance-1 또는 instance-2)로 전송한다.

젠킨스 서버가 빌드에 성공하면 SSH를 통해 instance-1에게 .jar 파일을 전송한다.

 

Remove prefix는 파일 경로에서 제거할 접두사를 작성한다.

위처럼 작성하면 홈 아래에 jar 파일만 남을 것이다.

 

Remote directory에는 파일이 전송될 instance-1의 디렉터리를 지정한다.

 

Exec command는 파일 전송 후 instance-1에서 실행할 명령어를 지정한다.

위 명령어로 jar 파일을 백그라운드에서 실행하도록 했다.

로그아웃 후에도 프로세스가 계속 실행되도록 설정했고 출력을 nohup.out 파일로 저장하도록 했다.

 

nohup은 사용자가 로그아웃을 하더라도 해당 프로세스가 종료되지 않고 계속 실행되도록 한다.

따라서 SSH 세션을 종료하거나 터미널을 닫아도 애플리케이션이 계속 실행된다.

 

java -jar cpuboundapp-0.0.1-SNAPSHOT.jar는 애플리케이션을 실행하는 명령어다.

-jar 옵션이 JAR 파일을 실행하라는 의미이다.

 

> nohup.out은 표준 출력을 nohup.out 파일로 리다이렉트하라는 의미이다. 애플리케이션의 출력 내용이 이 파일에 기록된다.

 

2>&1는 표준 오류 출력을 표준 출력으로 리다이렉트하라는 의미이다. 표준 오류 메시지도 nohup.out 파일에 기록된다.

 

 

 

빌드와 배포가 성공되었다면 powershell 에서 위와 같이 확인할 수 있다.

jenkins-instance에서도 .jar 파일을 찾을 수 있고

 

 

 

instance-1과 instance-2에서도 .jar를 찾을 수 있다.

상위 디렉터리 경로를 제외했기 때문에 홈 아래에 바로 .jar 파일이 위치한다.

 

 

 

+) 빌드 전에 위와 같이 update 후 자바를 설치해줘야 한다. 빌드에 실패해서 찾아보니 java를 꼭 설치해줘야 한다고 했다.

이 과정은 jenkins-instance, instance-1, instance-2 모두 수행해야 한다.

 

 

 

인스턴스플로팅ip:포트번호

로 배포가 정상적으로 되었는지 확인할 수 있다.

접속하면 hash값을 볼 수 있다.

배포가 정상적으로 된 것이다.

 

---

webhooks를 도입한 자동 배포

jar 배포의 프로세스

1. 사용자가 코드를 깃허브 레포지토리에 push한다.
2. push를 받은 깃허브는 webhook 요청을 젠킨스 서버로 보낸다.
3. 젠킨스 서버에서 해당 레포지토리의 소스코드를 활용해 jar파일을 빌드한 다음 각 인스턴스에 전달한다.
4. 사전에 설정된 스크립트를 실행해 각 인스턴스가 배포에 들어간다.

 

빌드는 비용이 많이 들기 때문에 적게 하는 것이 좋다.

 

webhooks의 특징

사용자가 commit이나 push 등을 해 깃허브에 새 업데이트가 생겼다면 webhook으로 젠킨스에 알린다.

젠킨스는 깃허브에 새 코드가 업로드가 되었으니 새로운 코드를 clone한다.

따라서 webhooks을 사용하면 자동으로 배포할 수 있다.

 

webhooks을 사용하면 업데이트본이 생겼을 때 새롭게 빌드할 필요가 없어진다.

 

 

 

실습을 위해 새 아이템을 생성했다.

 

 

 

깃허브 커밋을 감지해야 하기 때문에 

item의 구성에 들어가 소스 코드 관리 옵션은 Git으로 변경한다.

연동할 레포지토리의 URL을 입력한다.

 

이렇게 레포지토리 URL을 작성하면 젠킨스 서버가 자동으로 클론한다.

이 옵션을 사용하지 않았던 위에서의 실습에서는 Execute shell에 직접 clone 구문을 작성했었다.

 

 

 

branch는 master로 뒀다.

+) master로 두니 에러가 나서 main으로 수정했더니 해결되었다.

 

빌드 유발은 GitHub hook 기반으로 설정한다.

이 옵션을 선택하면 깃허브에 hook 요청이 들어갔을 때 자동으로 빌드가 된다.

 

 

build steps에서 execute shell을 선택하고

위와 같이 입력한다.

 

 

 

경로 출력, 권한 변경, 빌드, 파일 및 디렉터리 출력

현재 작업폴더에 하위 폴더 없이 github에 있던 작업 폴더들이 모두 clone 되었다.

rolling-deploy-prj 폴더가 없이 clone된 것이다.

이것은 webhook의 특징이다.

webhook을 사용하면 폴더 이동을 할 필요가 없다.

 

 

 

빌드 후 조치에 들어가서

instance-1, instance-2 서버를 추가한다.

 

jenkins-instance의 .jar 파일을 instance-1, instance-2에 전송한다.

전송 후 java 애플리케이션을 백그라운드에서 실행하고 

표준 출력, 표준 오류를 nohup.out 파일에 저장한다.

 

 

 

콘솔을 확인하니 SUCCESS가 떴다.

 

 

instance-1 접속

instance-2 접속

 

배포 성공확인