본문 바로가기

DevOps

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

728x90
반응형

https://tomatohj.tistory.com/82 에서 이어집니다.


이전에 설명했듯, Jenkins는 Github로 부터 Repository에 변화가 있음을 알아채고, 빌드/배포 과정을 진행할 것이다.
그렇다면 Github은 어떻게 Jenkins에게 그 정보를 전달 할 수 있을까? 
답은 바로 Github Webhook에 있다. Github Webhook을 이용하면 Repository에 발생하는 이벤트들을 특정 URI로 전달할 수 있다.

Fork 해온 Repository로 가서, 우측 상단 Settings 메뉴를 클릭한다.

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

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

그렇다면 어떻게 하면 될까?

이렇게 로컬 PC에 구성한 환경을 외부에 노출 시키고자 할때 사용할 수 있는 도구중 하나가 바로 ngrok이라는 도구이다.
아래 사이트로 이동하여 ngrok 사이트에 가입 후 로그인하자.

https://ngrok.com/

 

ngrok | Unified Application Delivery Platform for Developers

ngrok is a secure unified ingress platform that combines your global server load balancing, reverse proxy, firewall, API gateway and Kubernetes Ingress Controller to deliver applications and APIs.

ngrok.com

로그인 하면 dashboard.ngrok.com으로 이동될 것이다.
여기서 왼쪽에 있는 Your Authtoken 메뉴로 이동하면 ngrok 사용을 위한 토큰 값을 확인할 수 있다. 이 값을 복사해두도록 하자.

그리고 또 하나의 터미널을 열어 'docker run --net=host -it -e NGROK_AUTHTOKEN=[복사한 토큰값] ngrok/ngrok:latest http 8080' 명령어를 통해 ngrok을 Docker 컨테이너를 이용하여 실행시킨다. 
이때 옵션을 통해 Jenkins가 사용중인 8080 포트를 외부에 노출 시킨다.

정상적으로 실행된다면 아래 그림에 표시된 바와 같이 ngrok 도메인을 할당 받을 수 있고, 이 도메인으로 접속하면 설정한 바와 같이 http://localhost:8080에 접근한 것과 똑같은 화면을 확인 할 수 있다.

직접 확인해보기 위해 ngrok을 통해 할당받은 도메인을 브라우저를 통해 접근해보면, 아래 그림과 같은 메시지가 나온다.
Visit 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 파일을 찾아 클릭한다.

파일을 열었다면 우측 상단에 Edit this file을 의미하는 연필모양 아이콘을 클릭한다.
이를 통해 Github에서 바로 내용을 수정할 수 있다.

이 중 6, 7번째 줄에 있는 '127.0.0.1' 을 '0.0.0.0'으로 변경한다. 이렇게 변경해야지만 WebGoat가 정상적으로 동작하기 때문이다.
완료되었다면 우측 상단 Commit changes를 클릭한다.

아래와 같은 창이 나타난다면, Commit changes를 눌러주면 된다.

수정이 모두 끝났다면 Jenkins로 가보자.
아마 좌측 하단 Build History를 보면 아래 그림처럼 자동으로 빌드가 이루어지고 있을것이다.
해당 Build 과정에 대하여 Console Output을 확인해보자.

정상적으로 빌드 과정이 일어나고 있었음을 알 수 있고, 아래 그림에 표시된 메시지를 통해 어떤 서버에 배포가 되었는지 확인할 수 있다.
이번 빌드를 통해 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에서 동작중이던 웹 애플리케이션은 종료될 것이다.

직접 Github에서 코드를 한번 다시 수정해보고 테스트해보도록 하자.

 

여기까지가 아주 간단한 DevOps 아키텍처 구성을 위한 과정이다.
분명 간단하고 쉽다고 생각했는데, 쓰다보니 4개나 되는.....


728x90
반응형