Cloud Run으로 웹사이트 배포

1. 시작하기 전에

가상 머신 (VM) 인스턴스, 클러스터, 포드, 서비스 등을 만들고 관리하는 모든 오버헤드로 인해 웹사이트 실행이 어려울 수 있습니다. 대규모의 다중 계층 앱에는 문제가 없지만 웹사이트를 배포하고 표시하려고 하면 오버헤드가 매우 높습니다.

Knative의 Google Cloud 구현인 Cloud Run을 사용하면 VM 또는 Kubernetes 기반 배포에 필요한 오버헤드 없이 웹사이트를 관리하고 배포할 수 있습니다. 이는 관리 관점에서 보다 간단한 접근 방식일 뿐만 아니라, 웹사이트에 들어오는 요청이 없을 때 Scale-to-zero 기능도 제공합니다.

Cloud Run은 서버리스 개발을 컨테이너에 제공할 뿐 아니라 자체 Google Kubernetes Engine (GKE) 클러스터 또는 Cloud Run에서 제공하는 완전 관리형 서비스로서의 플랫폼 (PaaS) 솔루션에서 실행할 수도 있습니다. 이 Codelab에서 후자의 시나리오를 테스트합니다.

다음 다이어그램은 배포 및 Cloud Run 호스팅의 흐름을 보여줍니다. Cloud Shell에서 트리거하는 Cloud Build를 통해 만든 Docker 이미지로 시작합니다. 그런 다음 Cloud Shell에서 명령어를 사용하여 이미지를 Cloud Run에 배포합니다.

db5f05c090d5ebcb.png

기본 요건

학습할 내용

  • Cloud Build로 Docker 이미지를 빌드하고 gcr.io에 업로드하는 방법
  • Cloud Run에 Docker 이미지를 배포하는 방법
  • Cloud Run 배포를 관리하는 방법
  • Cloud Run에서 앱의 엔드포인트를 설정하는 방법

빌드할 항목

  • Docker 컨테이너 내에서 실행되는 정적 웹사이트
  • Container Registry에 있는 이 컨테이너의 버전입니다.
  • 정적 웹사이트를 위한 Cloud Run 배포

필요한 항목

  • 프로젝트를 만들 수 있는 관리 액세스 권한이 있는 Google 계정 또는 프로젝트 소유자 역할이 있는 프로젝트를 만들어야 합니다.

2. 환경 설정

자습형 환경 설정

아직 Google 계정이 없다면 계정을 만들어야 합니다. 그런 다음 Google Cloud 콘솔에 로그인하고 프로젝트를 클릭합니다. 프로젝트 만들기.

53dad2cefdae71da.png

faab21976aabeb4c.png

프로젝트 이름 아래에 자동으로 채워지는 프로젝트 ID를 기억해 두세요. 프로젝트 ID는 모든 Google Cloud 프로젝트에서 고유한 이름이므로 스크린샷에 있는 이름은 이미 사용되었으므로 사용할 수 없습니다. 이후 PROJECT_ID로 참조됩니다.

다음으로 Cloud 콘솔에서 결제를 사용 설정하여 Google Cloud 리소스를 사용하고 Cloud Run API를 사용 설정해야 합니다.

Cloud Run API 사용 설정

탐색 메뉴 ☰ >를 클릭합니다. API 및 서비스 > 대시보드 > API 및 서비스를 사용 설정합니다. .

5dbb2e6e27a55fcf.png

'Cloud Run API'를 검색합니다. 그런 다음 Cloud Run API를 클릭합니다. 사용 설정.

f1fd486174a744cf.png

이 Codelab을 실행하는 데에는 많은 비용이 들지 않지만 더 많은 리소스를 사용하기로 결정하거나 리소스를 실행 상태로 두면 더 많은 비용이 들 수 있습니다 (마지막 삭제 참고). 자세한 내용은 가격 책정을 참조하세요.

Google Cloud 신규 사용자에게는 $300 상당의 무료 체험판이 제공됩니다.

Cloud Shell

Google Cloud 및 Cloud Run은 노트북에서 원격으로 조작할 수 있지만 여기서는 Google Cloud에서 실행되는 명령줄 환경인 Cloud Shell을 사용하게 됩니다. 환경은 필요한 모든 클라이언트 라이브러리와 프레임워크로 사전 구성되어 있습니다.

이 Debian 기반 가상 머신에는 필요한 모든 개발 도구가 로드되어 있습니다. 영구적인 5GB 홈 디렉터리를 제공하고 Google Cloud에서 실행되므로 네트워크 성능과 인증이 크게 개선됩니다. 즉, 이 Codelab에 필요한 것은 브라우저뿐입니다(Chromebook에서도 작동 가능).

  1. Cloud Console에서 Cloud Shell을 활성화하려면 단순히 Cloud Shell 활성화fEbHefbRynwXpq1vj2wJw6Dr17O0np8l-WOekxAZYlZQIORsWQE_xJl-cNhogjATLn-YxLVz8CgLvIW1Ncc0yXKJsfzJGMYgUeLsVB7zSwz7p6ItNgx4tXqQjag7BfWPcZN5kP-X3Q를 클릭합니다. 환경을 프로비저닝하고 연결하는 데 몇 정도만 소요됩니다.

I5aEsuNurCxHoDFjZRZrKBdarPPKPoKuExYpdagmdaOLKe7eig3DAKJitIKyuOpuwmrMAyZhp5AXpmD_k66cBuc1aUnWlJeSfo_aTKPY9aNMurhfegg1CYaE11jdpSTYNNIYARe01A

Screen Shot 2017-06-14 at 10.13.43 PM.png

Cloud Shell에 연결되면 사용자 인증이 이미 완료되었고 프로젝트가 내 PROJECT_ID에 설정되어 있음을 확인할 수 있습니다.

gcloud auth list

명령어 결과

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)
gcloud config list project

명령어 결과

[core]
project = <PROJECT_ID>

어떤 이유로든 프로젝트가 설정되지 않았으면 다음 명령어를 실행하면 됩니다.

gcloud config set project <PROJECT_ID>

PROJECT_ID를 찾고 계신가요? 설정 단계에서 사용한 ID를 확인하거나 Cloud Console 대시보드에서 확인하세요.

R7chO4PKQfLC3bvFBNZJALLTUiCgyLEq_67ECX7ohs_0ZnSjC7GxDNxWrJJUaoM53LnqABYamrBJhCuXF-J9XBzuUgaz7VvaxNrkP2TAn93Drxccyj2-5zz4AxL-G3hzxZ4PsM5HHQ

또한 Cloud Shell은 기본적으로 이후 명령어를 실행할 때 유용할 수 있는 몇 가지 환경 변수를 설정합니다.

echo $GOOGLE_CLOUD_PROJECT

명령어 결과

<PROJECT_ID>
  1. 마지막으로 기본 영역 및 프로젝트 구성을 설정합니다.
gcloud config set compute/zone us-central1-f

다양한 영역을 선택할 수 있습니다. 자세한 내용은 리전 및 영역을 참조하세요.

3. 소스 저장소 클론

기존 웹사이트를 배포하는 경우 저장소에서 소스만 클론하면 되므로 Docker 이미지를 만들고 Cloud Run에 배포하는 데 집중할 수 있습니다.

다음 명령어를 실행하여 저장소를 Cloud Shell 인스턴스에 클론하고 적절한 디렉터리로 변경합니다. 또한 배포 전에 앱을 테스트할 수 있도록 Node.js 종속 항목도 설치합니다.

cd ~
git clone https://github.com/googlecodelabs/monolith-to-microservices.git
cd ~/monolith-to-microservices
./setup.sh

그러면 저장소가 클론되고 디렉터리가 변경되며 로컬에서 앱을 실행하는 데 필요한 종속 항목이 설치됩니다. 스크립트가 실행되는 데 몇 분 정도 걸릴 수 있습니다.

실사를 실시하고 앱을 테스트합니다. 다음 명령어를 실행하여 웹 서버를 시작합니다.

cd ~/monolith-to-microservices/monolith
npm start

출력:

Monolith listening on port 8080!

웹 미리보기 acc630712255c604.png를 클릭하고 포트 8080에서 미리보기를 선택하여 앱을 미리 볼 수 있습니다.

5869738f0e9ec386.png

그러면 Fancy Store가 작동하는 모습을 볼 수 있는 새 창이 열립니다.

9ed25c3f0cbe62fa.png

웹사이트를 확인한 후 창을 닫아도 됩니다. 웹 서버 프로세스를 중지하려면 터미널 창에서 CONTROL+C (Macintosh의 경우 Command+C)를 누릅니다.

4. Cloud Build로 Docker 컨테이너 만들기

이제 소스 파일을 사용할 준비가 되었으므로 앱을 도커화해야 합니다.

일반적으로 Docker 컨테이너를 빌드하고 레지스트리로 푸시하여 GKE가 가져올 이미지를 저장하는 2단계 접근 방식을 취해야 합니다. 하지만 Cloud Build를 사용하면 명령어 하나로 Docker 컨테이너를 빌드하고 Container Registry에 이미지를 저장해 더욱 쉽게 만들 수 있습니다. Dockerfile을 만들고 푸시하는 수동 프로세스를 보려면 Container Registry 빠른 시작을 참조하세요.

Cloud Build가 디렉터리에서 파일을 압축하여 Cloud Storage 버킷으로 이동합니다. 그러면 빌드 프로세스가 버킷의 모든 파일을 가져와 Docker 빌드 프로세스를 실행하기 위해 동일한 디렉터리에 있는 Dockerfile을 사용합니다. 호스트가 Docker 이미지의 gcr.io로 지정된 --tag 플래그를 지정하면 결과로 생성되는 Docker 이미지가 Container Registry에 푸시됩니다.

먼저 Cloud Build API가 사용 설정되어 있는지 확인해야 합니다. 다음 명령어를 실행하여 사용 설정합니다.

gcloud services enable cloudbuild.googleapis.com

API가 사용 설정되면 Cloud Shell에서 다음 명령어를 실행하여 빌드 프로세스를 시작합니다.

gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 .

이 프로세스는 몇 분 정도 걸리지만 완료되면 터미널에 다음과 비슷한 출력이 표시됩니다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                  IMAGES                              STATUS
1ae295d9-63cb-482c-959b-bc52e9644d53  2019-08-29T01:56:35+00:00  33S       gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz  gcr.io/<PROJECT_ID>/monolith:1.0.0  SUCCESS

빌드 기록을 보거나 프로세스를 실시간으로 확인하려면 Cloud 콘솔로 이동한 다음 탐색 메뉴 맞춤형 > Cloud Build > 기록. 여기에서 이전 빌드 목록을 모두 확인할 수 있지만 자신이 만든 빌드만 표시됩니다.

4c753ede203255f6.png

빌드 ID를 클릭하면 로그 출력을 포함하여 해당 빌드의 모든 세부정보를 볼 수 있습니다. 이미지 옆의 링크를 클릭하면 생성된 컨테이너 이미지를 볼 수 있습니다.

6e88ed1643dfe629.png

5. Cloud Run에 컨테이너 배포

웹사이트를 컨테이너화하고 Container Registry에 푸시했으므로 이제 Cloud Run에 배포해 보겠습니다.

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

  • Cloud Run (완전 관리형)은 전체 컨테이너 수명 주기가 관리되는 PaaS 모델입니다. 이 Codelab에서는 이 접근 방식을 사용합니다.
  • Cloud Run for Anthos는 추가 제어 레이어가 포함된 Cloud Run으로 GKE에서 클러스터와 포드를 가져올 수 있습니다. 자세한 내용은 Cloud Run for Anthos on Google Cloud 설정을 참조하세요.

이전에 설정한 환경 변수를 사용하는 명령줄 예시는 Cloud Shell에 있습니다.

명령줄

다음 명령어를 실행하여 앱을 배포합니다.

gcloud run deploy --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 --platform managed 

실행할 리전을 지정하라는 메시지가 표시됩니다. 가장 가까운 리전을 선택한 다음 기본 추천 서비스 이름 (모놀리식)을 수락합니다.

d52d9419c5166674.png

테스트 목적으로는 앱에 대한 인증되지 않은 요청을 허용합니다. 프롬프트가 표시되면 y를 입력합니다.

3a57b32f133dad61.png

배포 확인

배포가 성공적으로 생성되었는지 확인하려면 다음 명령어를 실행합니다. Pod statusRunning가 되는 데 몇 분 정도 걸릴 수 있습니다.

gcloud run services list

[1] Cloud Run (완전 관리형)을 선택합니다.

출력:

SERVICE   REGION    URL  LAST DEPLOYED BY          LAST DEPLOYED AT
✔  monolith  us-east1 <your url>  <your email>  2019-09-16T21:07:38.267Z

출력에는 다음과 같은 정보가 표시됩니다. 배포뿐만 아니라 배포를 배포한 사용자 (이메일 주소), 앱에 액세스하는 데 사용할 수 있는 URL을 확인할 수 있습니다. 모든 항목이 성공적으로 생성된 것 같습니다.

웹브라우저의 서비스 목록에 제공된 URL을 열면 로컬에서 미리 본 것과 동일한 웹사이트가 표시됩니다.

6. 더 적은 동시 실행으로 새 버전 만들기

이제 앱을 다시 배포하되 이번에는 매개변수 중 하나를 조정합니다.

기본적으로 Cloud Run 앱의 동시 실행 값은 80입니다. 즉, 각 컨테이너 인스턴스가 한 번에 최대 80개의 요청을 처리합니다. 이는 인스턴스가 한 번에 하나의 요청을 처리하는 서비스로서의 기능 (FaaS) 모델과는 큰 차이가 있습니다.

동시 실행 값이 1인 동일한 컨테이너 이미지를 다시 배포하고 (테스트 목적으로만) 어떤 일이 일어나는지 확인합니다.

gcloud run deploy --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 --platform managed --concurrency 1

처음에 한 것처럼 후속 질문에 답합니다. 명령어가 정상적으로 실행되면 Cloud 콘솔에서 결과를 확인합니다.

Cloud Run 대시보드에서 monolith 서비스를 클릭하여 세부정보를 확인합니다.

7d1eed2e4728a4f2.png

버전 탭을 클릭합니다. 생성된 버전 2개가 표시됩니다. monolith-00002를 클릭하고 세부정보를 검토합니다. 동시 실행 값이 1로 감소하는 것을 확인할 수 있습니다.

217185c0eccc87dd.png]

4ad481b8bcd0343d.png

이 구성으로 테스트하기에 충분하지만 대부분의 프로덕션 시나리오에서는 여러 동시 요청을 지원하는 컨테이너가 있습니다.

이제 재배포 없이 원래 동시 실행을 복원합니다. 동시 실행 값을 기본값인 80 또는 0으로 설정할 수 있습니다. 이렇게 하면 동시 실행 제한이 삭제되고 기본 최댓값 (이 문서 작성 시점에서는 80)으로 설정됩니다.

Cloud Shell에서 다음 명령어를 실행하여 현재 버전을 업데이트합니다.

gcloud run deploy --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 --platform managed --concurrency 80

다른 버전이 생성되었고 트래픽이 리디렉션되었으며 동시 실행이 80으로 돌아왔습니다.

7. 웹사이트 변경

마케팅팀에서 회사 웹사이트의 홈페이지를 변경해 달라고 요청했습니다. 회사의 회사 정보와 판매 제품 또는 서비스에 대해 더 많은 정보를 제공해야 한다고 생각합니다. 이 섹션에서는 마케팅팀이 만족할 수 있도록 홈페이지에 텍스트를 추가합니다.

개발자가 이미 파일 이름이 index.js.new인 변경사항을 만든 것 같습니다. 이 파일을 index.js에 복사하기만 하면 변경사항이 반영됩니다. 안내에 따라 적절하게 변경합니다.

다음 명령어를 실행하고 업데이트된 파일을 올바른 파일 이름으로 복사한 후 콘텐츠를 출력하여 변경사항을 확인합니다.

cd ~/monolith-to-microservices/react-app/src/pages/Home
mv index.js.new index.js
cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js

결과 코드는 다음과 같습니다.

/*
Copyright 2019 Google LLC

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

import React from "react";
import { makeStyles } from "@material-ui/core/styles";
import Paper from "@material-ui/core/Paper";
import Typography from "@material-ui/core/Typography";
const useStyles = makeStyles(theme => ({
  root: {
    flexGrow: 1
  },
  paper: {
    width: "800px",
    margin: "0 auto",
    padding: theme.spacing(3, 2)
  }
}));
export default function Home() {
  const classes = useStyles();
  return (
    <div className={classes.root}>
      <Paper className={classes.paper}>
        <Typography variant="h5">
          Fancy Fashion &amp; Style Online
        </Typography>
        <br />
        <Typography variant="body1">
          Tired of mainstream fashion ideas, popular trends and societal norms?
          This line of lifestyle products will help you catch up with the Fancy trend and express your personal style.
          Start shopping Fancy items now!
        </Typography>
      </Paper>
    </div>
  );
}

React 구성요소를 업데이트했지만 정적 파일을 생성하려면 React 앱을 빌드해야 합니다. 다음 명령어를 실행하여 React 앱을 빌드한 다음 모놀리식 공개 디렉터리에 복사합니다.

cd ~/monolith-to-microservices/react-app
npm run build:monolith

이제 코드가 업데이트되었으므로 Docker 컨테이너를 다시 빌드하여 Container Registry에 게시해야 합니다. 이전과 동일한 명령어를 사용할 수 있지만 이번에는 버전 라벨을 업데이트합니다.

다음 명령어를 실행하여 업데이트된 이미지 버전 2.0.0으로 새 Cloud Build를 트리거합니다.

cd ~/monolith-to-microservices/monolith

#Feel free to test your application
npm start

gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .

다음 섹션에서는 이 이미지를 사용하여 다운타임 없이 앱을 업데이트합니다.

8. 다운타임 없이 웹사이트 업데이트

변경이 완료되었으며 마케팅팀에서 업데이트에 만족합니다. 이제 사용자를 방해하지 않고 웹사이트를 업데이트해야 합니다.

Cloud Run은 각 배포를 새 버전으로 취급하여 온라인으로 전환한 후 트래픽이 이 버전으로 리디렉션됩니다.

다음 안내에 따라 웹사이트를 업데이트합니다.

명령줄

명령줄에서 서비스를 재배포하면 다음 명령어로 이미지를 새 버전으로 업데이트할 수 있습니다.

gcloud run deploy --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 --platform managed

배포 확인

다음 명령어를 실행하여 배포 업데이트를 검증합니다.

gcloud run services describe monolith --platform managed 

출력 형식은 다음과 같습니다.

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  annotations:
    client.knative.dev/user-image: gcr.io/my-cloudrun-codelab/monolith:2.0.0
...

이제 서비스에서 새 버전에 배포된 최신 버전의 이미지를 사용하고 있는 것을 확인할 수 있습니다.

변경사항을 확인하려면 Cloud Run 서비스의 외부 URL로 다시 이동하여 앱 제목이 업데이트된 것을 확인합니다.

다음 명령어를 실행하여 서비스를 나열하고 IP 주소를 잊어버렸다면 IP 주소를 확인합니다.

gcloud run services list

이제 홈페이지 구성요소에 추가한 텍스트가 웹사이트에 표시됩니다.

451ca252acae6928.png

9. 삭제

Container Registry 이미지 삭제

# Delete the container image for version 1.0.0 of our monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 --quiet

# Delete the container image for version 2.0.0 of our monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 --quiet

Cloud Storage에서 Cloud Build 아티팩트 삭제

# The following command will take all source archives from all builds and delete them from cloud storage

# Run this command to print all sources:
# gcloud builds list | awk 'NR > 1 {print $4}' 

gcloud builds list | awk 'NR > 1 {print $4}' | while read line; do gsutil rm $line; done

Cloud Run 서비스 삭제

gcloud run services delete monolith --platform managed

10. 축하합니다

Cloud Run으로 웹사이트를 배포, 확장, 업데이트했습니다.

자세히 알아보기