[DevOps 구축] Github Webhook 설정, DevOps 구축 완성

본 실습은 아래 자료를 바탕으로 진행되었습니다.
https://tomatohj.tistory.com/83

 

우리가 구성하고자 하는 DevOps 아키텍처는 Jenkins가 Github로 부터 Repository에 변화가 있음을 알아채고, 빌드/배포 과정을 진행할 것이다.

Github는 Github Webhook을 통해 Jenkins에게 정보를 전달할 수 있다

▶ Github Webhook : Repository에 발생하는 이벤트들을 특정 URI로 전달할 수 있음

 

Fork 해온 Repositroy로 이동하여 Settings 메뉴를 클릭한다.

 

왼쪽 메뉴 중 Webhooks를 선택한 후, 우측 상단 Add webhook을 클릭한다.

 

Webhook을 추가하기 위해 Repository의 변경사항을 전달할 URL 정보가 필요한데, 이 부분에 Jenkins URL을 입력해주면 된다. 하지만 우리가 구성한 Jenkins는 로컬 PX에 구성했고 로컬 PC에 공인 IP를 할당받지도, 포트포워딩을 하지도 않아 외부에 노출되지 않는다는 문제점이 있다. 즉, Github라는 사이트는 우리가 구성한 Jenkins를 찾을 수 없는 것이다.

 

이러한 문제를 해결하고자 로컬 PC에 구성한 환경을 외부에 노출시킬 수 있는 도구 중 하나인 ngrok이라는 도구를 활용할 수 있다.

 

ngrok 사이트에 회원가입 후 로그인하면 dashboard로 이동이 되는데 여기서 'Your Authtoken' 메뉴로 이동하면 ngrok 사용을 위한 토큰 값을 확인할 수 있다. 이 값을 복사해두자.

 

터미널을 하나 더 열어 "docker run --net=host -it -e NGROK_AUTHTOKEN=[복사한 토큰값] ngrok/ngrok:latest http 8080" 명령어를 통해 ngrok을 도커 컨테이너를 이용하여 실행시킬 수 있다. 이때 옵션을 통해 Jenkins가 사용중인 8080 포트를 외부로 노출시키는 것이다.

 

정상적으로 실행되면 아래 이미지와 같이 ngrok 도메인을 할당받을 수 있고, 이 도메인으로 접속하면 'http://localhost:8080'에 접근한 것과 동일한 화면을 볼 수 있다.

 

실제로 동일한 화면이 나오는지 확인해보고자 할당받은 도메인을 브라우저를 통해 접속하고, 'Visite Site'를 눌러 방문하면 실제로 로컬에 구성한 Jenkins를 확인할 수 있다.

→ 이를 통해 외부에 있는 Github에서 로컬 PC에 구성한 Jenkins에게 Repository 변경 관련 이벤트 전달 가능

 

다시 Webhook 설정화면으로 돌아와 Payload URL 부분에 "https://[ngrok 도메인]/github-webhook/" 을 입력한다. 그리고 Content type은 application/json으로 변경한 후 Add webhook 버튼을 클릭해 추가해주어야 한다.

 

Webhook이 정상적으로 잘 추가되었는지, Jenkins와 연결이 잘 되었는지 확인하고자 직접 코드를 수정해보자.Repository에서 src → main → resources → application-webgoat.properties 파일을 찾아 클릭한다.

 

이제 해당 파일의 일부를 변경해줄 것이다.

 

해당 코드 중 6, 7번째 줄에 있는 '127.0.0.1'을 '0.0.0.0'으로 변경해준다. 이는 WebGoat를 정상적으로 작동시키기 위함이다.

 

수정이 완료되었다면 Jenkins로 이동하여 좌측 하단 Build History 부분에서 자동으로 빌드가 이루어지고 있는 것을 확인할 수 있다. 더욱 자세히 살펴보고자 Console Output을 확인해보자.

 

정상적으로 빌드 과정이 일어나고 있으며, 어떤 서버에 배포가 되었는지 확인할 수 있다. 사실 위에 부분을 보면 알겠지만 중간에 코드를 잘못 작성한 부분이 있어서 해당 오류를 해결하느라 5번의 빌드를 거쳐 성공하였다..

이번 빌드를 통해 172.17.0.3 IP를 지닌 서버에 배포가 이루어졌다.

 

'http://127.0.0.1/WebGoat'로 접속하여 배포와 실행이 정상적으로 잘 실행되어 WebGoat에 접속할 수 있음을 확인하였다.

 

다음으로 172.17.0.3 IP를 지닌 webserver-blue 컨테이너로 이동하여 'ps -ef | grep java' 명령어를 입력해보자. 아래와 같이 'java -jar /root/webgoat.jar'가 잘 실행되고 있음을 확인할 수 있다

 

📌 한번 더 코드 수정을 진행할 경우
현재 webserver-blue에서 애플리케이션이 동작중이니, 배포는 webserver-green에서 진행될 것이고, 정상적으로 배포가 완료된다면, Nginx 리버스 프록시는 webserver-green을 바라보도록 수정될 것이고, webserver-blue에서 동작중이던 웹 애플리케이션은 종료될 것이다.

 

실제로 한번 더 코드를 수정했을 때, green 서버에서 배포가 진행되는지 확인해보자.

Github에서 코드를 다시 수정했다가(실제 코드 내에서 변동 사항은 없다) 저장한 후 Jenkins로 이동하면 자동으로 빌드 과정이 이루어지는 것을 볼 수 있고, 콘솔을 확인해본 결과 이번에는 green 서버의 IP 주소인 172.17.0.4에 배포된 것을 볼 수 있었다.

 

그럼 다음으로 172.17.0.4 IP를 지닌 webserver-green 컨테이너로 이동하여 "ps -ef | grep java" 명령어를 실행한 결과, 아래와 같이 'java -jar /root/webgoat.jar'가 잘 실행되고 있음을 확인할 수 있다.

 

webserver-blue에서 동작중인 웹 애플리케이션이 종료되었는지 확인해보고자 다시 해당 컨테이너로 이동하여 "ps -ef | grep java" 명령어를 실행한 결과, 앞서 'java -jar /root/webgoat.jar'가 잘 실행되었던 것과 함께 비교해보았을 때, 'java -jar /root/webgoat.jar'의 동작이 종료된 것을 볼 수 있었다.