5. 주요 프로세스

애플리케이션의 스펙을 수정하는 화면을 열어서 아래 그림처럼 [Webhook 정보 조회] 버튼을 클릭한다.

Webhook 정보 조회 팝업 화면이 열리면 다음 그림과 같이 애플리케이션의 Webhook 정보를 조회하는 화면을 볼 수 있다.

Webhook 정보 조회 팝업 화면의 목적은 사용자에게 Gitlab 서버에 Webhook 설정을 편하게 할 수 있도록 URL 정보 및 토큰 정보를 제공하고 생성하는 등의 기능을 제공하여 편의성을 높였다.

Webhook 토큰은 Gitlab 서버가 사용하는 정보로 아래 그림처럼 [토큰 추가] 버튼을 클릭하면 바로 사용할 수 있는 Webhook 토큰이 만들어진다.

[토큰 추가] 버튼을 누르자마자 아래 그림처럼 Webhook 토큰이 생성되는데 우측 하단에 성공한 메세지를 볼 수 있으며 생성된 토큰 데이터가 화면에서 새로고침 되어 조회가 되고 이 토큰으로 Gitlab 서버에 이동해서 등록을 시켜줘야 한다.

애플리케이션에 대한 Webhook 토큰까지 생성을 완료하면 아래 그림과 같이 Webhook URL 및 Webhook 인증 토큰 값을 복사한다.

Webhook 설정을 위해 필요한 정보는 복사를 했으니 Gitlab으로 접속해서 해당 애플리케이션에 저장소 화면으로 이동하여 아래 그림처럼 Webhook 설정할 수 있는 화면으로 이동하기 위해 왼쪽에 Webhooks 메뉴를 클릭한다.

Webhook Settings 화면으로 이동을 하면 위에서 복사했던 값을 아래 그림처럼 표기된 부분에 붙여넣기 한다.

그리고 아래 그림처럼 밑으로 스크롤 해서 Enable SSL verification 체크박스는 체크해제 상태로 변경하여 Webhook 연동 시 SSL/TLS 검증 처리를 비활성화 하고 [Add webhook] 버튼을 눌러서 설정을 마무리 한다.

저장이 성공적으로 끝나면 아래 그림처럼 저장한 정보가 조회된다. 그림을 기준으로 하단에 Project Hooks(1) 항목에 보이는 정보가 저장을 성공한 데이터이다.

이렇게 저장된 Webhook 설정은 아래 그림처럼 [Test] 버튼을 사용하면 이벤트를 발생시켜서 Webhook 테스트를 할 수 있다. 여기서는 브랜치가 context-path 문자열로 시작하는 브랜치에 Push 이벤트가 발생하면 발동하기 때문에 테스트를 하기 위해서는 Push Events를 선택한다.

아래 그림은 productpage 애플리케이션에 대한 Gitlab 저장소 첫 화면인데 BXCP ADM에서 애플리케이션 스펙에서 context-path 브랜치로 지정했기 때문에 브랜치 변경을 해야한다.

context-path 브랜치로 변경을 하고 임의로 소스를 수정해서 이벤트를 발생시켜야 하기 때문에 아래 그림처럼 변경에 무리가 되지 않는 선에서 수정을 해야한다.

init.sh 소스를 수정하기 위해서 아래 그림처럼 소스코드 내용 화면으로 진입해서 [Edit] 버튼을 눌러서 수정을 진행해야 한다.

수정 샘플 파일은 쉘스크립트이기 때문에 간단하게 주석을 넣어서 [Commit changes] 버튼을 누르면 Webhook 설정이 올바르게 설정이 되었는지 확인할 수 있다.

릴리즈를 하기 위한 사전 절차이기 때문에 CI/CD 파이프라인 처리가 성공한 빌드번호를 찾고 그 빌드번호를 등록한다.

아래 그림은 [빌드] 메뉴를 통해서 애플리케이션에 대한 빌드 이력을 제공하는 빌드 화면으로 이동한 예시이다.

[빌드] 화면에 진입했으면 성공한 빌드 이력에서 릴리즈를 원하는 대상을 아래 그림처럼 수행 상태 항목이 성공인 것을 식별한다.

아래 그림을 기준으로는 #34 빌드 이력을 선정하여 릴리즈 등록 처리를 한다. 우측에 메뉴를() 클릭하면 릴리즈 등록을 할 수 있는 메뉴를 볼 수 있는데 이것을 클릭한다.

릴리즈 등록 메뉴를 선택하면 아래 그림처럼 지정한 빌드 이력을 릴리즈 등록하기 위한 팝업 화면이 나타난다. 입력이 가능한 릴리즈 제목, 릴리즈 설명 항목에 값을 입력하고 [저장] 버튼을 누르면 릴리즈 등록 처리가 완료되며 재조회가 되면 릴리즈 등록 여부 항목은 Y 상태로 보인다.

위에서 릴리즈 등록을 하고 릴리즈 등록 여부 항목으로 Y 상태를 확인하였다. 이렇게 릴리즈 등록이 되면 [릴리즈] 메뉴를 통해서 릴리즈 화면으로 이동하면 아래 그림처럼 등록한 #34 빌드번호에 대한 릴리즈를 볼 수 있다.

아래 그림은 릴리즈 화면으로 릴리즈 등록이 성공한 데이터만 조회되는 화면이다. 특이사항은 데이터에 버전을 나타내는 아이콘으로() 등록된 릴리즈 정보가 현재 배포된 상태라면 버전에 맞춰서 표시된다.

위에서는 릴리즈 등록에 대한 절차를 설명했다. 릴리즈 등록을 완료하면 이를 바탕으로 릴리즈 이관을 할 수 있다.

릴리즈 이관을 하기 위해서는 가장 먼저 확인할 사항은 릴리즈 등록 절차를 완료한 릴리즈 정보가 승인 처리가 되었는지 확인하고 승인을 하는 것이다. 아래 그림을 보면 이전에 릴리즈 등록을 완료한 #34 빌드번호에 릴리즈는 아직 승인 처리가 되지 않은 것을 알 수 있다.

우측에 메뉴를() 클릭하여 [릴리즈 승인] 메뉴를 클릭하면 승인 처리를 할 수 있다.

위에서 [릴리즈 승인] 메뉴를 클릭하면 아래 그림처럼 승인 처리의 진행을 최종적으로 사용자에게 확인을 받게 된다.

그리고 승인되지 않은 릴리즈를 승인 처리하면 아래 그림처럼 성공 메시지와 함께 승인 항목에는 Y 값으로 재조회가 되는 것을 알 수 있다. 이 절차까지 진행을 하면 릴리즈 이관을 하기 위한 상태가 된다.

릴리즈 승인을 완료한 데이터를 릴리즈 이관하려면 워크스페이스 전환을 해야한다. Development 워크스페이스가 아닌 Staging 또는 Production 워크스페이스로 전환을 해야하며 아래 그림은 워크스페이스 전환을 위해 선택할 수 있는 워크스페이스 팝업을 여는 예시이다.

bxcp-sta 워크스페이스를 선택을 하면 아래 그림처럼 전환된 워크스페이스를 기준으로 릴리즈 화면이 보이는 것을 알 수 있다. 조회된 데이터를 보면 릴리즈 승인을 처리한 릴리즈 데이터는 아직 볼 수 없는데 릴리즈 이관을 위해서 [릴리즈 조회] 버튼을 클릭한다.

[릴리즈 조회] 버튼을 클릭하여 화면을 열면 아래 그림처럼 이전에 릴리즈 승인 처리를 완료한 빌드번호(#34) 릴리즈 정보가 조회되는 것을 볼 수 있다.

우측에 메뉴를() 클릭하고 [릴리즈 이관]을 선택하여 릴리즈 이관 처리를 진행한다. 그러면 bxcp-dev 워크스페이스를 기준으로 접근 가능한 컨테이너 레지스트리에 이미지를 Pull하고 bxcp-sta 워크스페이스가 접근하는 컨테이너 레지스트리로 컨테이너 이미지를 Push한다.

릴리즈 조회 팝업 화면을 닫으면 아래 그림처럼 릴리즈 화면이 나오는데 릴리즈 이관 처리를 완료한 데이터가 제일 첫 번째 데이터로 조회된 것을 알 수 있다. 이렇게 릴리즈 이관 처리가 완료되면 bookinfo-sta 프로젝트에 속한 productpage 애플리케이션이 사용할 수 있는 컨테이너 이미지가 준비된 상태로 볼 수 있다.

위에서 컨테이너 이미지가 준비된 상태로 볼 수 있다는 의미는 아래 그림처럼 Harbor 레지스트리에서 bookinfo-sta 프로젝트에 productpage에 v34 태그로 이미지가 저장된 것이다.

CANARY 배포는 이미 배포된 애플리케이션이 있는 상태에서 사용할 수 있다. 하지만 추가로 CANARY 배포를 할 수 있도록 애플리케이션의 스펙을 확인해봐야 하는 내용이 있다. 아래 그림은 본 절에 예시로 사용할 productpage 애플리케이션이다.

CANARY 배포는 애플리케이션이 쿠버네티스 클러스터에 이미 배포된 상태에서 사용할 수 있지만 추가로 CANARY 배포를 할 수 있도록 애플리케이션의 스펙을 확인해봐야 하는 내용이 있다고 위에서 언급을 하였는데 아래 그림은 본 절에 예시로 사용할 productpage 애플리케이션의 스펙이다.

아래 그림은 [애플리케이션 메뉴] > [애플리케이션 수정] 메뉴를 통해서 애플리케이션 수정 팝업 화면을 열어본 예시이다. Ingress 유형을 보면 k8s Ingress 유형으로 선택이 되어 있는데 이 유형은 CANARY 배포를 할 수 없기 때문에 위에 있는 Service Mesh 유형으로 변경한다.

위에서 Service Mesh 유형으로 선택을 했고 이제는 아래 그림처럼 [롤아웃 설정] 탭 화면으로 이동을 한다. productpage 애플리케이션에 스펙이 Rolling 유형으로 선택이 되어있다. 이 선택된 Rolling 롤아웃 유형을 CANARY 유형으로 변경이 필요하다.

아래 그림은 CANARY 롤아웃으로 선택하기 위해 롤아웃 유형 콤보를 클릭한 화면을 보여준다. 펼쳐진 선택 가능한 롤아웃 유형이 3개가 보이며 여기서 Canary(B/G)를 클릭하여 선택한다.

아래 그림은 위에서 Canary(B/G) 유형으로 선택시 보이는 화면인데 Blue, Green 버전을 기준으로 트래픽의 비중을 지정하는 슬라이더 형태에 컨트롤가 보인다. 이것을 사용해서 버전에 대한 트래픽을 조절한다. 트래픽 비중의 조절을 완료하면 [저장] 버튼을 눌러서 스펙을 저장시킨다.

하지만 위에서 설명한 순서대로 수정하고 저장을 하면 다음과 같은 오류 메시지가 나오게 된다. 메시지에 나온 내용을 기준으로 위에서 설정했던 롤아웃 유형은 일단 Rolling 유형 값으로 다시 돌려놓고 저장을 한다.

위에서 설명한대로 Rolling 유형으로 돌려놓고 Service Mesh 유형으로 수정한 스펙을 저장하면 아래 그림처럼 저장이 완료되고 애플리케이션 상세 화면으로 이동이 된다.

이제 다시 애플리케이션 수정을 통해서 롤아웃 유형을 Canary(B/G) 유형으로 선택하고 저장을 한다.

위에서 설명한 과정을 완료하면 이제부터 배포가 이루어지면 그 배포 처리는 GREEN 버전의 CANARY 롤아웃 배포가 처리되는 상태가 된다.

배포하는 방법을 설명하는 Task가 아니기 때문에 배포는 처리한 것으로 가정하고 이 과정은 생략한다. 배포의 경우에는 CI/CD 파이프라인 프로세스를 통해서 하거나 릴리즈 배포를 사용하여 배포한다.

위에서 생략한 배포 처리를 완료하면 애플리케이션 상세 화면에서 이와 같은 상태를 인식할 수 있게 다양한 정보로 제공하고 있다.

아래 그림은 GREEN 버전의 배포가 완료되고 애플리케이션 목록 화면으로 이동한 조회 결과인데, 이 화면에서는 GREEN 버전이 정상적으로 배포가 되었는지 확인할 수 있는 확정적인 정보는 없다.

애플리케이션 목록 화면에서는 GREEN 버전 배포를 확인할 수 없으며 아래 그림은 애플리케이션 상세 화면으로 진입한 결과이다.

위 그림을 기준으로 빨간색으로 표기된 부분을 보면 BLUE 버전과 GREEN 버전이 모두 배포되어 동작하고 있는 것을 알 수 있는 정보를 제공한다.

만약에 애플리케이션 스펙에서 [가용 클러스터 설정] 탭 화면에서 더 선택할 수 있는 클러스터를 선택하여 배포를 했다면 상단에 클러스터별 버전별 레플리카 갯수를 표시하는 카드가 더 나타날 것이다.

그리고 kubectl 커맨드를 사용해서 FederatedDeployment 유형에 리소스를 조회하면 아래 그림처럼 조회할 수 있다.

또한 이 애플리케이션 ID를 사용해서 BXCP ADM에서 아래 그림과 같이 열람할 수 있는데 여기서 FederatedDeployment 리소스의 조회는 ClusterID 항목의 콤보를 클릭해서 지정할 수 있다.

BXCP ADM에서 BLUE 및 GREEN 버전이 모두 배포된 상태에서 아래 그림처럼 특정 버전에 레플리카 개수를 늘리거나() 줄이는() 조정을 할 수 있다.

레플리카 조정 처리가 완료되면 아래 그림처럼 변경된 레플리카를 적용한 쿠버네티스 리소스 정보가 조회된다.