티스토리 뷰

Google Cloud/Qwiklabs Advanced

[Qwiklabs advanced]구글 클라우드에 웹사이트 빌드하기(Using Google Cloud Build)

로또_ 2020. 9. 27. 02:37

Qwiklabs Advanced에서는 Basic보다는 여러 개념들을 조합하여 실습을 진행하겠습니다. 제가 직접 아래의 실습을 진행하다 보니 역시 문서를 읽기보다는 손으로 직접 해보는 게 기억에 많이 남아요. 실습하는데 시간이 좀 들어도 한번 시도해보시는 걸 추천드립니다! 어려운 부분이 있으시거나 궁금한 사항이 있으시면 댓글로 남겨주세요.

이번에는 static website를 Cloud Build를 사용하여 클라우드에 올려보겠습니다~

Cloud Build에 대해 모르시는 분들은 먼저 아래의 포스팅을 읽고 오시는 것을 추천드립니다.

[GCP] Cloud Build

Cloud Build 애플리케이션을 수정하고 다시 빌드하고 배포하는 작업은 시간 소비가 크며, 수작업으로 지속적으로 수행하기 번거로운 작업입니다. 작은 단위의 테스트는 간단히 실행할 수 있지만 ��

puzzle-puzzle.tistory.com

포스팅에서 할 것을 간략히 말씀드리면

Cloud Build를 사용하여 Docker 이미지를 작성하고 gcr.io에 업로드하는 방법
Docker 이미지를 Cloud Run에 배포하는 방법
Cloud Run 배치들을 관리하는 방법
Cloud Run에서 애플리케이션의 endpoint를 설정하는 방법

크게 4가지로 나뉠 수 있습니다.

아래의 그림은 Cloud Run 호스팅과 배치 흐름도입니다.(Architectrue diagram)

처음에 Cloud shell이 트리거가 되어 Cloud Build를 이용하고 Docker image를 빌드합니다. 그리고 Cloud Run을 통해 이미지를 배포합니다.

Flow of the deployment and Cloud Run hosting

Clone Source Repository

Cloud shell에 다음과 같이 입력합니다. 기존 웹 사이트를 배포하는 것이므로 소스 복제만 하면 됩니다. Docker image 생성과 Cloud Run의 배치에만 집중할 수 있습니다. 아래의 코드를 실행하시면 몇 분 뒤 끝났다는 메시지를 볼 수 있습니다.

다음 명령을 실행하여 웹 서버를 시작하고 애플리케이션을 테스트합니다.

Output:

Cloud Shell에서도 해당 포트로 접속하여 테스트를 확인 가능합니다.

Create Docker Container with Cloud Build

소스파일도 준비가 되었으니 애플리케이션을 Dokerize 해보겠습니다.

일반적으로 다음과 같은 2단계 접근법을 사용합니다.

Docker container를 만들고
레지스트리에 push 하여 GKE가 pull 할 수 있는 이미지를 저장해야 합니다.

하지만 Cloud Build를 사용하여 위 2단계를 하나의 명령어로 실행 가능합니다. 수동으로 2단계를 실시하는 방법은 따로 포스팅하겠습니다!

중요 :

Cloud Build는 디렉토리에서 파일을 압축하여 Cloud Storage bucket으로 이동시킵니다. 그다음 빌드 프로세스는 버킷의 모든 파일을 가져오고 동일한 디렉토리에 있는 Docker 파일을 사용하여 Docker 빌드 프로세스를 실행합니다. 호스트가 Docker 이미지에 대해 --tag 플래그를 gcr.io로 지정했으므로 결과 Docker 이미지가 Container Registry로 푸시됩니다.

첫 번째, Cloud Build API를 사용하기 위해 다음과 같이 입력합니다.

API를 사용하도록 설정한 후, 다음 명령을 실행하여 빌드 프로세스를 시작합니다.

Output:

위와 같이 빌드 요약을 확인하거나 Cloud Build > History로 가셔서 콘솔에서 빌드 내역을 확인할 수 있습니다.

Deploy Container To Cloud Run

위의 과정까지 저희는 웹 사이트를 container로 만들고 container registry에 push 했습니다. 이제 Cloud Run에 배포하는 과정을 알아보겠습니다.

Cloud Run에 배포하는 방법에는 두 가지가 있습니다.

Managed Cloud Run : 모든 container 라이프사이클을 Cloud Run 제품 자체에서 관리하는 서비스형 플랫폼(saas) 모델입니다.
Cloud Run on GKE : GKE에서 clusters&pods를 가져올 수 있는 추가 제어 계층과 함께 Cloud Run을 실행합니다.

이전 단계에서 구축된 이미지를 배포하고 --platform managed를 지정하여 위에서 설명한 Cloud Run의 관리 버전을 선택합니다.

첫 번째, Cloud Run API를 사용할 수 있게 다음의 코드를 실행합니다.

애플리케이션을 배포합니다.

실행시키고 싶은 rigion을 선택하고 번호를 입력하시면 됩니다.

배포가 완료되었다는 것을 확인하고 싶으시다면 다음의 명령어를 입력합니다

Output:

Create new revision with lower concurrency

매개변수 중 하나를 조정하여 어플리케이션을 재배포합니다.

기본적으로 Cloud Run 애플리케이션은 concurrency 값이 80입니다. 즉 각 container 인스턴스가 한 번에 최대 80개의 요청을 처리하는 것을 의미합니다. 이 부분의 parameter를 1로 바꾸어 재배포를 실시합니다.

이후의 결과는 Cloud Run에서 확인할 수 있습니다.

Service Detail page에서 Revisions 탭을 클릭합니다. 그리고 다음과 같이 2개의 revisions가 생성된 것을 볼 수 있습니다.

concurrency 값이 1로 감소한 것을 볼 수 있습니다.

위의 과정을 test를 위한 실험으로, 대부분의 시나리오에서는 multiple concurrent requests를 가질 수 있습니다.

다음으로는 재배포 없이 초기의 concurrency값으로 복구하겠습니다.

Make Changes To The Website

시나리오 : 기업의 마케팅 팀이 웹사이트의 변경을 요청하였습니다. 마케팅 팀은 회사가 무엇을 파는지 더 확실히 할 필요성을 느껴 몇 가지를 추가하고자 합니다.

다음의 명령어를 실행시켜 index.js.new를 index.js로 복사 후 이름도 변경합니다. 이후 cat명령어를 사용하여 내용을 확인합니다.

Output:

React 구성 요소를 업데이트했지만 static files을 생성하려면 React app을 구축해야 합니다.

React app을 구축하고 monolith의 공용 디렉토리로 복사합니다.

코드가 업데이트되었으므로 다시 Docker container를 재구성하여 container registry에 게시합니다. 이전과 동일한 명령어를 사용할 수 있지만, 이번에는 버전 label을 업데이트합니다.

Update website with zero downtime

변경 사항의 반영이 완료되고, 이제는 이용자들이 어떠한 방해를 겪지 않게끔 웹사이트를 업데이트해야 합니다.

중요:

Cloud Run은 각 배포를 먼저 온라인으로 전환한 다음, 트래픽을 리디렉션 하는 새로운 버전으로 간주합니다. 기본적으로 최신 버전은 서비스에 대한 인바운드 트래픽의 100%가 할당됩니다. "Routes"를 사용하여 서비스 내의 서로 다른 개정판에 트래픽의 다른 비율을 할당할 수 있습니다.

Cloud Shell에서 새로운 버전으로 업데이트하기 위해 서비스를 재배포합니다.