Cloud Run でウェブサイトをデプロイする

ウェブサイトの運用は容易ではありません。仮想マシン（VM）インスタンス、クラスタ、Pod、サービスなどの作成と管理にオーバーヘッドが発生するからです。大規模な多層アプリであれば仕方ありませんが、ウェブサイトをデプロイして公開するだけの場合、こうしたオーバーヘッドは大きな負担です。

Cloud Run は、Knative の Google Cloud 実装です。これを使用すると、VM ベースや Kubernetes ベースのデプロイに伴うオーバーヘッドなしでウェブサイトを管理、デプロイできます。管理が簡素化されるだけでなく、ウェブサイトでリクエストを受信していないときは「ゼロにスケール」できます。

Cloud Run は、コンテナにサーバーレスの開発環境をもたらすだけでなく、独自の Google Kubernetes Engine（GKE）クラスタ上で実行することも、Cloud Run が提供するフルマネージドの Platform as a Service（PaaS）ソリューションで実行することもできます。この Codelab では、後者のシナリオをテストします。

次の図は、Cloud Run にデプロイしてホストする際のフローを示しています。まず、Cloud Shell で Cloud Build をトリガーして Docker イメージを作成します。次に、Cloud Shell でコマンドを使用して、そのイメージを Cloud Run にデプロイします。

前提条件

学習内容

  • Cloud Build を使用して Docker イメージをビルドして gcr.io にアップロードする方法
  • Docker イメージを Cloud Run にデプロイする方法
  • Cloud Run デプロイメントを管理する方法
  • Cloud Run でアプリのエンドポイントを設定する方法

作成するアプリの概要

  • Docker コンテナ内で実行される静的ウェブサイト
  • Container Registry に存在するこのコンテナのバージョン
  • 静的ウェブサイトの Cloud Run デプロイ

必要なもの

  • プロジェクトを作成するための管理者権限を持つ Google アカウント、またはプロジェクト オーナーのロールを持つプロジェクト

セルフペース型の環境設定

Google アカウントをまだお持ちでない場合は、アカウントを作成する必要があります。次に、Google Cloud コンソールにログインし、[プロジェクト] > [プロジェクトを作成] をクリックします。

プロジェクト ID は、プロジェクト名の下に自動的に入力されます。この ID を覚えておいてください。プロジェクト ID はすべての Google Cloud プロジェクトを通じて一意の名前にする必要があります。スクリーンショットの名前はすでに使用されているため、使用できません。後で PROJECT_ID として参照します。

次に、Google Cloud リソースを使用し、Cloud Run API を有効にするために、Cloud コンソールで課金を有効にする必要があります。

Cloud Run API を有効にする

ナビゲーション メニュー ☰ > [API とサービス] > [ダッシュボード] > [API とサービスを有効にする] をクリックします。。

「Cloud Run API」を検索し、[Cloud Run API] > [有効にする] をクリックします。

この Codelab の操作をすべて行っても、費用は数ドル程度です。ただし、その他のリソースを使いたい場合や、実行したままにしておきたいステップがある場合は、追加コストがかかる可能性があります（最後にあるクリーンアップをご覧ください）。詳細は、料金をご覧ください。

Google Cloud の新規ユーザーは、300 ドル分の無料トライアルの特典があります。

Cloud Shell

Google Cloud と Cloud Run はノートパソコンからリモートで操作できますが、ここでは Cloud Shell（Google Cloud 上で動作するコマンドライン環境）を使用します。環境には、必要なすべてのクライアント ライブラリとフレームワークが事前構成されています。

この Debian ベースの仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。つまり、この Codelab に必要なのはブラウザだけです（Chromebook でも動作します）。

Google Cloud Shell を有効にするには、デベロッパー コンソールの右上にあるボタンをクリックします（環境のプロビジョニングと接続に若干時間を要します）。

activateCloudShell.png

[Cloud Shell を起動] ボタンをクリックします。

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>

Cloud Shell では、デフォルトで環境変数もいくつか設定されます。これらの変数は、以降のコマンドを実行する際に有用なものです。

echo $GOOGLE_CLOUD_PROJECT

コマンド出力

<PROJECT_ID>

なんらかの理由でプロジェクトが設定されていない場合は、次のコマンドを実行します。

gcloud config set project <PROJECT_ID>

PROJECT_ID が見つからない場合は、設定手順で使用した ID を確認するか、コンソールのダッシュボードで検索します。

Project_ID.png

重要: 最後に、デフォルトのゾーンとプロジェクト構成を設定します。

gcloud config set compute/zone us-central1-f

さまざまなゾーンを選択できます。詳しくは、リージョンとゾーンのドキュメントをご覧ください。

デプロイするウェブサイトはすでに存在するため、リポジトリからソースのクローンを作成するだけで、後は 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!

[ウェブでプレビュー] をクリックし、[ポート 8080 でプレビュー] を選択して、アプリをプレビューできます。

新しいウィンドウが開き、Fancy Store の動作状態を確認できます。

ウェブサイトの確認後にこのウィンドウを閉じることができます。ウェブサーバー プロセスを停止するには、ターミナル ウィンドウで CONTROL+C（Macintosh の場合は Command+C）を押します。

ソースファイルを使用できる状態になったので、次はアプリを Docker 化します。

通常、Docker コンテナを作成するには 2 ステップのアプローチを取る必要があります。具体的には、Docker コンテナをビルドするステップと、ビルドしたコンテナをレジストリに push してそのイメージを保管し、GKE がそこからイメージを pull できるようにするステップです。ただし、Cloud Build を使用して 1 つのコマンドで Docker コンテナをビルドし、イメージを Container Registry に保存すると、作業が楽になります。Dockerfile を作成して push する手動プロセスを確認するには、Container Registry のクイックスタートをご覧ください。

Cloud Build がディレクトリにあるファイルを圧縮して Cloud Storage バケットに移動します。次に、ビルドプロセスでそのバケットからすべてのファイルを取得し、同じディレクトリにある Dockerfile を使用して Docker ビルドプロセスを実行します。--tag フラグで Docker イメージのホストとして gcr.io を指定したため、ビルドされた Docker イメージは Container Registry に push されます。

まず、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] > [履歴] をクリックします。過去のすべてのビルドのリストが表示されます。リストには、作成したばかりのビルドが 1 つだけ示されているはずです。

[ビルド ID] をクリックすると、ログ出力など、そのビルドのすべての詳細が表示されます。作成されたコンテナ イメージを表示するには、[イメージ] の横にあるリンクをクリックします。

ウェブサイトをコンテナ化して Container Registry に push したので、次は Cloud Run にデプロイしましょう。

Cloud Run にデプロイするには次の 2 つの方法があります。

  • Cloud Run（フルマネージド）は、コンテナのライフサイクル全体が管理される PaaS モデルです。この Codelab では、このアプローチを使用します。
  • Cloud Run for Anthos は、制御が強化された Cloud Run であり、GKE で作成したクラスタと Pod を導入できます。詳細については、Cloud Run for Anthos on Google Cloud の設定をご覧ください。

コマンドラインの例は、Cloud Shell で、事前に設定した環境変数を使用して実行します。

コマンドライン

次のコマンドを実行して、アプリをデプロイします。

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

実行するリージョンを指定するよう求められます。最も近いリージョンを選択し、提案されているデフォルトのサービス名（monolith）を受け入れます。

テスト用に、認証されていないリクエストをアプリで許可します。プロンプトが表示されたら、「y」と入力します。

デプロイメントを確認する

次のコマンドを実行して、デプロイが正常に作成されたことを確認します。Pod status が Running になるまで少し時間がかかることがあります。

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 をウェブブラウザで開くと、ローカルでプレビューしたものと同じウェブサイトが表示されます。

アプリケーションを再度デプロイします。ただし、今回はパラメータのうちの 1 つを調整します。

デフォルトでは、Cloud Run アプリの同時実行の値は 80 に設定されます。つまり、各コンテナ インスタンスは一度に最大 80 件のリクエストを処理します。これは、1 つのインスタンスが一度に 1 件のリクエストを処理する Functions as a Service（FaaS）モデルとは大きく異なります。

同時実行の値を（テスト用に）1 に設定して同じコンテナ イメージを再デプロイし、どうなるかを確認します。

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

以降の質問には、初回と同じように答えます。コマンドが正常に実行されたら、Cloud コンソールで結果を確認します。

Cloud Run ダッシュボードで、[monolith] サービスをクリックして詳細を表示します。

[変更内容] タブをクリックします。2 つのリビジョンが作成されていることを確認します。[monolith-00002] をクリックして、詳細を確認します。同時実行の値が 1 に減らされていることがわかります。

]

テストにはこの構成で十分ですが、本番環境でのほとんどのシナリオでは、コンテナで複数の同時リクエストをサポートすることになります。

再デプロイせずに同時実行の値を復元します。同時実行の値をデフォルトの 80 または 0 に設定できます。後者の場合、同時実行の制限がすべて削除され、デフォルトの最大値（このドキュメントの作成時点では 80）に設定されます。

Cloud Shell で次のコマンドを実行して、現在のリビジョンを更新します。

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

別のリビジョンが作成され、トラフィックがリダイレクトされ、同時実行数が 80 に戻ったことを確認します。

マーケティング チームから、会社のウェブサイトのホームページを変更するよう依頼されました。マーケティング チームは、会社の概要と販売している製品のより詳しい情報を追加する必要があると考えています。このセクションでは、マーケティング チームからの依頼に応じたテキストをホームページに追加します。

開発者の 1 人が 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 アプリをビルドし、monolith の公開ディレクトリにコピーします。

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 .

次のセクションでは、このイメージを使用してダウンタイムなしでアプリを更新します。

変更が完了し、マーケティング チームも更新内容に満足してくれました。次は、ユーザーへのサービスを中断させずにウェブサイトを更新します。

Cloud Run は各デプロイメントを新しいリビジョンとして扱い、リビジョンをオンライン状態にして、トラフィックをそこにリダイレクトします。

次の手順に沿ってウェブサイトを更新してください。

コマンドライン

コマンドラインから、次のコマンドを使用してサービスを再デプロイし、イメージを新しいバージョンに更新できます。

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

デプロイメントを確認する

次のコマンドを実行して、Deployment の更新を検証します。

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

ウェブサイトのホームページ コンポーネントに追加したテキストが表示されるようになりました。

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

Cloud Run を使用してウェブサイトをデプロイ、スケーリング、更新しました。

その他の情報