チェックポイント
Create GCS bucket
/ 10
Copy startup script and code to Cloud Storage bucket
/ 10
Deploy instances and configure network
/ 20
Create managed instance groups
/ 20
Create HTTP(S) load balancers
/ 10
Update the frontend instances
/ 10
Scaling GCE
/ 10
Update the website
/ 10
Google Cloud における Compute Engine を使用したウェブアプリのホスティング
GSP662
概要
Google Cloud 内にウェブサイトをデプロイする方法はたくさんあります。各ソリューションで提供される機能や制御レベルはそれぞれ異なります。Compute Engine では、ウェブサイトの実行に使用するインフラストラクチャを細かく制御できますが、Google Kubernetes Engine(GKE)や App Engine などのソリューションより運用管理の手間が必要になります。Compute Engine を使用すると、仮想マシン、ロードバランサといったインフラストラクチャの側面を細かく制御できます。
このラボでは、サンプルのアプリケーションとして「Fancy Store」という名前の e コマース ウェブサイトをデプロイし、Compute Engine でウェブサイトのデプロイとスケーリングを簡単に実行できることを確認していきます。
学習内容
このラボでは、次の方法について学びます。
- Compute Engine インスタンスを作成する
- ソース インスタンスからインスタンス テンプレートを作成する
- マネージド インスタンス グループを作成する
- マネージド インスタンス グループのヘルスチェックを作成してテストする
- HTTP(S) ロードバランサを作成する
- ロードバランサのヘルスチェックを作成する
- キャッシュにコンテンツ配信ネットワーク(CDN)を使用する
このラボが完了するまでに、マネージド インスタンス グループ内に複数のインスタンスを作成し、ウェブサイトのための自動修復、ロード バランシング、自動スケーリング、ローリング アップデートを行えるようになります。
設定と要件
[ラボを開始] ボタンをクリックする前に
こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。
このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
- 標準的なインターネット ブラウザ(Chrome を推奨)
- ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。
ラボを開始して Google Cloud コンソールにログインする方法
-
[ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。
- [Google Cloud コンソールを開く] ボタン
- 残り時間
- このラボで使用する必要がある一時的な認証情報
- このラボを行うために必要なその他の情報(ある場合)
-
[Google Cloud コンソールを開く] をクリックします(Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウでリンクを開く] を選択します)。
ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。 -
必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。
{{{user_0.username | "Username"}}} [ラボの詳細] パネルでも [ユーザー名] を確認できます。
-
[次へ] をクリックします。
-
以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。
{{{user_0.password | "Password"}}} [ラボの詳細] パネルでも [パスワード] を確認できます。
-
[次へ] をクリックします。
重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。 -
その後次のように進みます。
- 利用規約に同意してください。
- 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
- 無料トライアルには登録しないでください。
その後、このタブで Google Cloud コンソールが開きます。
Cloud Shell をアクティブにする
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
- Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン
をクリックします。
接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。
gcloud
は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
- (省略可)次のコマンドを使用すると、有効なアカウント名を一覧表示できます。
-
[承認] をクリックします。
-
出力は次のようになります。
出力:
- (省略可)次のコマンドを使用すると、プロジェクト ID を一覧表示できます。
出力:
出力例:
gcloud
ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。
リージョンとゾーンを設定する
一部の Compute Engine リソースは、リージョン内やゾーン内に存在します。リージョンとは、リソースを実行できる特定の地理的な場所です。1 つのリージョンには 1 つ以上のゾーンがあります。
Cloud コンソールで次の gcloud コマンドを実行して、ラボのデフォルトのリージョンとゾーンを設定します。
タスク 1. Compute Engine API を有効にする
- 次のコマンドを実行して、Compute Engine API を有効にします。
タスク 2. Cloud Storage バケットを作成する
Cloud Storage バケットに、ビルド済みのコードと起動スクリプトを格納します。
- Cloud Shell で次のコマンドを実行して、新しい Cloud Storage バケットを作成します。
$DEVSHELL_PROJECT_ID
環境変数を使用することで、オブジェクトの名前を一意にすることができます。Google Cloud 内のすべてのプロジェクト ID は一意なので、他の名前の末尾にプロジェクト ID を付けるとその名前も一意になります。[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
タスク 3. ソース リポジトリのクローンを作成する
monolith-to-microservices
リポジトリに基づく既存の「Fancy Store」e コマース ウェブサイトをウェブサイトのベースとして使用します。
ソースコードのクローンを作成して、Compute Engine へのデプロイに集中できるようにします。このラボで後ほどコードを少し更新して、Compute Engine での更新が簡単であることを確認します。
- ソースコードのクローンを作成し、
monolith-to-microservices
ディレクトリに移動します。
- ここで初めてコードをビルドし、アプリケーションをローカルで実行できるようにします。
このスクリプトの実行が完了するまでに数分かかります。
- 完了したら、次のコマンドを使用して、対応している NodeJS バージョンを Cloud Shell が実行していることを確認します。
- 次に、アプリケーションをテストするために次のコマンドを実行し、
microservices
ディレクトリに移動して、ウェブサーバーを起動します。
次の出力が表示されます。
- 「ウェブでプレビュー」アイコンをクリックし、[ポート 8080 でプレビュー] を選択してアプリケーションをプレビューします。
新しいウィンドウが開き、Fancy Store のフロントエンドが表示されます。
- ウェブサイトを確認したら、このウィンドウを閉じ、ターミナル ウィンドウで Ctrl+C キーを押してウェブサーバー プロセスを停止します。
タスク 4. Compute Engine インスタンスを作成する
Compute Engine インスタンスのデプロイを開始します。
次に行う手順は以下のとおりです。
- 起動スクリプトを作成してインスタンスを構成します。
- ソースコードのクローンを作成して、Cloud Storage にアップロードします。
- Compute Engine インスタンスをデプロイしてバックエンドのマイクロサービスをホストします。
- バックエンドのマイクロサービス インスタンスを使用するようにフロントエンドのコードを再構成します。
- Compute Engine インスタンスをデプロイして、フロントエンドのマイクロサービスをホストします。
- 通信を許可するようにネットワークを構成します。
起動スクリプトを作成する
起動スクリプトを使用して、インスタンスが起動するたびに実行する処理をインスタンスに指示します。このようにしてインスタンスを自動的に構成します。
- Cloud Shell で次のコマンドを実行して、
startup-script.sh
というファイルを作成します。
- Cloud Shell リボンの [エディタを開く] をクリックして、コードエディタを開きます。
-
monolith-to-microservices
フォルダに移動します。 -
startup-script.sh
ファイルに次のコードを追加します。その後コードの一部を編集します。
- ファイル内の
[DEVSHELL_PROJECT_ID]
というテキストを探し、実際のプロジェクト ID に置き換えます。
startup-script.sh
内のコードの行は、次のようになります。
-
startup-script.sh
ファイルを保存しますが、まだ閉じないでください。 -
Cloud Shell コードエディタの右下で、[End of Line Sequence](改行シーケンス)が [CRLF] ではなく [LF] に設定されていることを確認します。
- [CRLF] に設定されている場合は、[CRLF] をクリックしてからプルダウンで [LF] を選択します。
- すでに [LF] に設定されている場合は、そのままにします。
-
startup-script.sh
ファイルを閉じます。 -
Cloud Shell ターミナルに戻り、次のコマンドを実行して
startup-script.sh
ファイルをバケットにコピーします。
これで、https://storage.googleapis.com/[BUCKET_NAME]/startup-script.sh
から起動スクリプトにアクセスできるようになります。
[BUCKET_NAME] は Cloud Storage バケットの名前に置き換えます。デフォルトでは、起動スクリプトは承認されたユーザーとサービス アカウントのみが閲覧することができ、ウェブブラウザからアクセスすることはできません。Compute Engine インスタンスは、サービス アカウントを使用して自動的に起動スクリプトにアクセスできるようになります。
起動スクリプトは次のタスクを実行します。
- Logging エージェントをインストールします。このエージェントは syslog から自動的にログを収集します。
- Node.js および Supervisor をインストールします。Supervisor はアプリをデーモンとして実行します。
- Cloud Storage バケットからアプリのソースコードのクローンを作成し、依存関係をインストールします。
- アプリを実行するように Supervisor を構成します。アプリが予期せずに終了した場合や、管理者やプロセスにより停止した場合、Supervisor はアプリを確実に再起動します。また、アプリの stdout と stderr を syslog に送信し、Logging エージェントが収集できるようにします。
Cloud Storage バケットにコードをコピーする
インスタンスを起動すると、インスタンスは Cloud Storage バケットからコードを pull するため、ユーザーはコードの .env
ファイルに環境変数を保存することができます。
- クローンを作成したコードをバケットにコピーします。
node_modules
は削除されます。これらはインスタンスの起動時にインスタンス上に再作成されます。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
バックエンド インスタンスをデプロイする
デプロイする最初のインスタンスはバックエンド インスタンスです。バックエンド インスタンスには、Orders(注文)と Products(商品)のマイクロサービスを配置します。
- 次のコマンドを実行して、起動スクリプトを使用するように構成された
e2-standard-2
インスタンスを作成します。バックエンド インスタンスであることを示すためにインスタンスにbackend
のタグを付け、後で専用のファイアウォール ルールを適用できるようにします。
バックエンドへの接続を構成する
アプリケーションのフロントエンドをデプロイする前に、先ほどデプロイしたバックエンドを参照するように構成を更新する必要があります。
- 次のコマンドでバックエンドの外部 IP アドレスを取得し、バックエンド インスタンスの
EXTERNAL_IP
(外部 IP)の値を確認します。
出力例:
-
バックエンドの外部 IP をコピーします。
-
Cloud Shell エクスプローラで
monolith-to-microservices
>react-app
に移動します。 -
コードエディタで [View] > [Toggle Hidden Files] を選択し、
.env
ファイルを表示します。
次のステップでは、.env
ファイルを編集してバックエンドの外部 IP を参照します。[BACKEND_ADDRESS] は、前述の gcloud
コマンドで確認したバックエンド インスタンスの外部 IP アドレスです。
-
.env
ファイルで、localhost
を[BACKEND_ADDRESS]
に置き換えます。
-
ファイルを保存します。
-
Cloud Shell で、次のコマンドを実行して
react-app
を再ビルドします。これにより、フロントエンドのコードが更新されます。
- 次に、アプリケーション コードを Cloud Storage バケットにコピーします。
フロントエンド インスタンスをデプロイする
コードの構成が完了したので、フロントエンド インスタンスをデプロイします。
- 前回と同じような次のコマンドを実行して
フロントエンド
インスタンスをデプロイします。ファイアウォールで使用するために、このインスタンスにはfrontend
のタグを付けます。
ネットワークを構成する
- フロントエンドではポート 8080 へのアクセス、バックエンドではポート 8081、8082 へのアクセスを許可するように、ファイアウォール ルールを作成します。次のファイアウォール コマンドでは、アプリケーションのインスタンス作成時に割り当てたタグを使用します。
これでウェブサイトが完全に機能するようになりました。
-
frontend
の外部 IP にアクセスするには、そのアドレスを知っておく必要があります。次のコマンドを実行してfrontend
インスタンスの EXTERNAL_IP(外部 IP)を確認します。
出力例:
インスタンスが起動して構成されるまでに数分かかることがあります。
-
3 分待ってからブラウザの新しいタブを開き、URL に
http://[FRONTEND_ADDRESS]:8080
と入力してウェブサイトにアクセスします。[FRONTEND_ADDRESS] は、先ほど確認した frontend インスタンスの EXTERNAL_IP(外部 IP)に置き換えます。 -
[Products](商品)と [Orders](注文)のページにアクセスし、動作することを確認します。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
タスク 5. マネージド インスタンス グループを作成する
アプリケーションのスケーリングを可能にするために、マネージド インスタンス グループを作成します。また、frontend
インスタンスと backend
インスタンスをインスタンス テンプレートとして使用します。
マネージド インスタンス グループ(MIG)には、単一のゾーンで単一のエンティティとして管理可能な同一のインスタンスが複数含まれます。マネージド インスタンス グループは、インスタンスの可用性を積極的に維持する(ステータスを RUNNING(実行中)の状態に保つ)ことで、アプリの高可用性を維持します。自動修復、ロード バランシング、自動スケーリング、ローリング アップデートを行えるように、フロントエンドとバックエンドのインスタンスでマネージド インスタンス グループを使用します。
ソース インスタンスからインスタンス テンプレートを作成する
マネージド インスタンス グループを作成するには、まず最初にグループのベースとなるインスタンス テンプレートを作成する必要があります。インスタンス テンプレートを使用することで、新しい VM インスタンスを作成する際に使用するマシンタイプ、ブートディスク イメージまたはコンテナ イメージ、ネットワーク、その他のインスタンス プロパティを定義できます。また、マネージド インスタンス グループに含めるインスタンスや、独立したインスタンスを作成することもできます。
インスタンス テンプレートを作成するには、作成済みの既存のインスタンスを使用します。
- はじめに、両方のインスタンスを停止します。
- 次に、各ソース インスタンスからインスタンス テンプレートを作成します。
- インスタンス テンプレートが作成されたことを確認します。
出力例:
- インスタンス テンプレートを作成したら、
backend
VM を削除してリソース容量を節約します。
- プロンプトが表示されたら、「y」と入力します。
通常は frontend
VM も削除できますが、このラボで後ほどこれを使用してインスタンス テンプレートを更新します。
マネージド インスタンス グループを作成する
- フロントエンド用とバックエンド用の 2 つのマネージド インスタンス グループを作成します。
これらのマネージド インスタンス グループではインスタンス テンプレートを使用して、各グループ内で 2 つのインスタンスが起動するように構成します。インタンスには自動で名前が付けられ、base-instance-name
で指定した名前の後にランダムな文字が付いたものになります。
- このアプリケーションでは、
frontend
マイクロサービスをポート 8080 で実行します。また、backend
マイクロサービスのOrders
(注文)をポート 8081 で実行し、Products(商品)をポート 8082 で実行します。
これらは標準のポートではないため、ポートを識別するために名前付きポートを指定します。名前付きポートは Key-Value ペアのメタデータで、サービス名とサービスを実行するポートを表します。名前付きポートをインスタンス グループに割り当てることで、そのインスタンス グループに含まれるすべてのインスタンスでサービスを利用することができます。この情報は HTTP ロード バランシング サービスで使用されます。ロード バランシング サービスの構成は後ほど行います。
自動修復を構成する
アプリケーションの可用性を高め、そのレスポンスを検証するために、マネージド インスタンス グループ用の自動修復ポリシーを構成します。
自動修復ポリシーは、アプリケーション ベースのヘルスチェックを使用して、アプリのレスポンスが期待どおりであることを検証します。デフォルトの動作ではインスタンスのステータスが RUNNING(実行中)かどうかを検証するだけですが、アプリのレスポンスを確認することでより正確に状態を知ることができます。
-
frontend
用とbackend
用の両方のヘルスチェックを作成し、3 回連続して Unhealthy(異常)のステータスが返った場合は修復を行うようにします。
- ヘルスチェックのプローブがポート 8080、8081 のマイクロサービスに接続できるようにファイアウォール ルールを作成します。
- ヘルスチェックを各サービスに適用します。
- そのため、ラボを続けながら、モニタリングが開始するのを待ちます。ラボの最後に障害をシミュレーションして自動修復をテストします。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
タスク 6. ロードバランサを作成する
マネージド インスタンス グループを補完するには、HTTP(S) ロードバランサを使用してフロントエンドとバックエンドのマイクロサービスにトラフィックを配信し、マッピングを使用してパスルールに基づいて適切なバックエンド サービスにトラフィックを送信します。これにより、ロードバランスされた単一の IP がすべてのサービスに公開されます。
Google Cloud でのロード バランシング オプションの詳細については、Cloud Load Balancing の概要をご覧ください。
HTTP(S) ロードバランサを作成する
Google Cloud ではさまざまな種類のロードバランサを提供しています。このラボでは、トラフィックに HTTP(S) ロードバランサを使用します。HTTP ロードバランサの構成は次のとおりです。
- 受信したリクエストを転送ルールによってターゲットの HTTP プロキシに転送します。
- ターゲット HTTP プロキシは各リクエストを URL マップと照合し、各リクエストに適したバックエンド サービスを判断します。
- バックエンド サービスは、バックエンドの処理能力、ゾーン、インスタンスの健全性に基づき、適切なバックエンドに各リクエストを転送します。HTTP ヘルスチェックを使用して各バックエンド インスタンスの健全性を検証します。バックエンド サービスが HTTPS または HTTP/2 のヘルスチェックを使用するように構成されている場合、リクエストは途中で暗号化されてからバックエンド インスタンスに送信されます。
- ロードバランサとインスタンス間のセッションでは、HTTP、HTTPS、HTTP/2 プロトコルを使用できます。HTTPS または HTTP/2 を使用する場合、バックエンド サービスの各インスタンスには SSL 証明書が必要です。
- 各サービスのトラフィックを処理できるインスタンスを判断するためのヘルスチェックを作成します。
- ロードバランスされたトラフィックの送信先となるバックエンド サービスを作成します。バックエンド サービスでは、先ほど作成したヘルスチェックと名前付きポートを使用します。
- ロードバランサのバックエンド サービスを追加します。
- URL マップを作成します。URL マップは、どの URL をどのバックエンド サービスに転送するのかを決めるものです。
- パスマッチャーを作成して
/api/orders
と/api/products
のパスを、それぞれのサービスに転送するようにします。
- URL マップに関連付けるプロキシを作成します。
- パブリック IP アドレスとポートをプロキシに関連付けるグローバル転送ルールを作成します。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
構成を更新する
新しい静的 IP アドレスを取得したので、frontend
のコードを更新します。このコードではこれまで、backend
インスタンスを参照するエフェメラル アドレスを指定していましたが、その代わりに新しい IP アドレスを指定します。
- Cloud Shell で、構成が含まれている
.env
ファイルの保存先であるreact-app
フォルダに移動します。
- ロードバランサの IP アドレスを確認します。
出力例:
- Cloud Shell エディタに戻って
.env
ファイルを再編集し、ロードバランサのパブリック IP を参照するようにします。[LB_IP] は先ほど確認したバックエンド インスタンスの外部 IP アドレスに置き換えます。
-
ファイルを保存します。
-
react-app
を再ビルドします。再ビルドすると、フロントエンドのコードが更新されます。
- アプリケーション コードをバケットにコピーします。
フロントエンド インスタンスを更新する
コードと構成を更新したので、マネージド インスタンス グループに含まれるフロントエンド インスタンスが新しいコードを pull するようにします。
インスタンスは起動時にコードを pull するので、ローリング再起動コマンドを発行します。
--max-unavailable
パラメータですべてのマシンを即座に置換するように指定しています。このパラメータを指定しない場合、このコマンドは 1 つのインスタンスをそのままの状態で残して他のインスタンスを再起動することで可用性を確保します。ここではデモであるため、速く処理するためにすべてを即座に置換するように指定します。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
ウェブサイトをテストする
-
rolling-action replace
コマンドを実行してから、インスタンスが処理されるまで 3 分間待ちます。その後、マネージド インスタンス グループのステータスを確認します。次のコマンドを実行してサービスのステータスが HEALTHY(正常)であることを確認します。
- 2 つのサービスが HEALTHY(正常)と表示されるまで待ちます。
出力例:
しばらく待ってもどちらのインスタンスも HEALTHY(正常)にならない場合は、フロントエンド インスタンスの設定に問題があり、ポート 8080 でアクセスできない状態になっています。ポート 8080 で直接インスタンスにアクセスして確認します。
- 両方のインスタンスがリスト上に HEALTHY(正常)と表示されたら、Ctrl+C キーを押して
watch
コマンドを終了します。
gcloud compute forwarding-rules list --global
タスク 7. Compute Engine をスケーリングする
ここまで、2 つのマネージド インスタンス グループと、各グループに 2 つのインスタンスを作成しました。この構成は負荷に関係のない静的な構成ですが、十分に機能します。次に、使用率に基づいて自動スケーリング ポリシーを作成し、各マネージド インスタンス グループを自動的にスケーリングします。
使用率に応じて自動的にサイズを変更する
- 自動スケーリング ポリシーを作成するには、次のコマンドを実行します。
このコマンドによって、マネージド インスタンス グループにオートスケーラーが作成されます。このオートスケーラーはロードバランサの使用率が 60% を超えるとインスタンスを自動的に追加し、60% を下回るとインスタンスを削除します。
コンテンツ配信ネットワークを有効にする
スケーリングに役立つもう 1 つの機能として、コンテンツ配信ネットワーク サービスがあります。このサービスを有効にすると、フロントエンドにキャッシュを提供することができます。
- フロントエンド サービスで次のコマンドを実行します。
ユーザーが HTTP(S) ロードバランサを経由してコンテンツをリクエストすると、リクエストは Google Front End(GFE)に届きます。GFE はユーザーのリクエストにレスポンスするために最初に Cloud CDN キャッシュ内を探します。レスポンスがキャッシュに保存されていた場合、GFE はそれをユーザーに送信します。これを「キャッシュ ヒット」と呼びます。
レスポンスがキャッシュに保存されていなかった場合、GFE はリクエストをバックエンドに直接送信します。このリクエストに対するレスポンスをキャッシュに保存できる場合、GFE はそのレスポンスを Cloud CDN キャッシュに保存して、以降のリクエストで使用できるようにします。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
タスク 8. ウェブサイトを更新する
インスタンス テンプレートを更新する
既存のインスタンス テンプレートを編集することはできません。ただし、現在のインスタンスはステートレスであり、起動スクリプトですべての構成が行われます。そのため、テンプレートの構成を変更する場合にのみ、インスタンス テンプレートを変更する必要があります。ここでは、サイズの大きいマシンタイプを使用するように簡単な変更を行い、それを push します。
次の手順を行います。
-
インスタンス テンプレートのベースとして機能する
frontend
インスタンスを更新します。更新中に、インスタンス テンプレート イメージの更新されたバージョンにファイルを適用します。その後、インスタンス テンプレートを更新し、新しいテンプレートを展開して、最後にマネージド インスタンス グループのインスタンスにファイルが存在することを確認します。 -
インスタンス テンプレートのマシンタイプを
e2-standard-2
からe2-small
に切り替えて変更します。
- 次のコマンドを実行してフロントエンド インスタンスのマシンタイプを変更します。
- 新しいインスタンス テンプレートを作成します。
- 新しいインスタンス テンプレートをマネージド インスタンス グループに展開します。
- 3 分待ってから、次のコマンドを実行して更新のステータスをモニタリングします。
このコマンドが完了するまでに少し時間がかかります。
次の状態のインスタンスが 1 つ以上あることを確認します。
- STATUS: RUNNING(実行中)
- ACTION: None(なし)
- INSTANCE_TEMPLATE: fancy-fe-new(新しいテンプレート名)
-
リストにあるマシン名の 1 つをコピーして次のコマンドで使用します。
-
Ctrl+C キーを押して
watch
プロセスを終了します。 -
次のコマンドを実行して、仮想マシンが新しいマシンタイプ(e2-small)を使用していることを確認します。[VM_NAME] は新しく作成されたインスタンス名に置き換えます。
出力例:
ウェブサイトに変更を加える
シナリオ: あなたはマーケティング チームから、サイトのホームページを変更するよう依頼されました。マーケティング チームは、会社の概要と販売している製品のより詳しい情報を追加する必要があると考えています。
タスク: マーケティング チームからの依頼に応じたテキストをホームページに追加します。デベロッパーの 1 人が index.js.new
というファイルですでに変更したようです。このファイルを index.js
にコピーするだけで、変更を反映できます。以下の手順に沿って適切な変更を行います。
- 次のコマンドを実行して、更新されたファイルをコピーして正しいファイル名にします。
- ファイルの内容を出力して変更を確認します。
変更後のコードは次のようになっています。
これで React コンポーネントは更新されましたが、React アプリをビルドして静的ファイルを生成する必要があります。
- 次のコマンドを実行して React アプリをビルドし、monolith の公開ディレクトリにコピーします。
- このコードをバケットに再度 push します。
ローリング置換で変更を push する
- すべてのインスタンスを強制的に置換して、更新を pull します。
注: このローリング置換の例では、--max-unavailable
パラメータですべてのマシンを即座に置換するように指定しています。このパラメータを指定しない場合、このコマンドは 1 つのインスタンスをそのままの状態で残し、他のインスタンスを置換します。ここではテストとして、速く処理するためにすべてを即座に置換するように指定します。本番環境では余裕を持たせて、更新中でもウェブサイトのサービスが停止しないようにします。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
-
rolling-action replace
コマンドを実行してから、インスタンスが処理されるまで 3 分間待ちます。その後、マネージド インスタンス グループのステータスを確認します。次のコマンドを実行してサービスのステータスが HEALTHY(正常)であることを確認します。
- 両方のサービスが表示され、ステータスが HEALTHY(正常)になるまで待ちます。
出力例:
-
リストに HEALTHY(正常)であるインスタンスが表示されたら、Ctrl+C を押して
watch
コマンドを終了します。 -
ウェブサイトには
http://[LB_IP]
でアクセスできます。[LB_IP] はロードバランサに指定した IP アドレスで、次のコマンドで確認できます。
更新された新しいウェブサイトが表示されます。
障害をシミュレーションする
ヘルスチェックが機能することを確認するために、インスタンスにログインしてサービスを停止します。
- インスタンス名を確認するには、次のコマンドを実行します。
- インスタンス名をコピーしてから、次のコマンドを実行してインスタンスに SSH でアクセスします。INSTANCE_NAME はリストから取得したインスタンス名に置き換えます。
-
「y」と入力し、Enter キーを 2 回押してパスワードを使用しないようにします。
-
インスタンス内で
supervisorctl
を使用してアプリケーションを停止します。
- インスタンスからログアウトします。
- 修復される様子をモニタリングします。
完了するまでに数分かかります。
出力例:
マネージド インスタンス グループがインスタンスを再作成して修復したことがわかります。
- また、ナビゲーション メニュー > [Compute Engine] > [VM インスタンス] に移動して、コンソールからモニタリングすることもできます。
お疲れさまでした
このデモでは、Compute Engine でウェブサイトをデプロイ、スケーリング、更新しました。また、Compute Engine でのマネージド インスタンス グループ、ロードバランサ、ヘルスチェックの操作についても確認しました。
次のステップと詳細情報
Google Cloud トレーニングと認定資格
Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。
マニュアルの最終更新日: 2024 年 4 月 26 日
ラボの最終テスト日: 2023 年 12 月 15 日
Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。