GSP053

概要
DevOps では、「継続的デプロイ」「Blue/Green デプロイ」「カナリア デプロイ」などのアプリケーション デプロイのシナリオを管理するために、複数のデプロイメントを使用することが少なくありません。このラボでは、複数の異種混合デプロイメントが使用される一般的なシナリオに対応できるように、コンテナをスケールして管理する方法を学習します。
目標
このラボでは、次のタスクの実行方法について学びます。
-
kubectl ツールを使用する
- Deployment の
yaml ファイルを作成する
- Deployment をリリース、更新、スケールする
- Deployment を更新し、デプロイのスタイルについて学ぶ
前提条件
学習の効果を最大化するために、このラボでは次のことが推奨されます。
- 以下の Google Cloud Skills Boost ラボを受講済みであること。
- Linux システムの管理スキルがあること。
- DevOps の理論と継続的デプロイのコンセプトを理解していること。
デプロイメントの概要
異種混合デプロイメントには通常、技術上または運用上の特定のニーズに対応するために、2 つ以上の異なるインフラストラクチャ環境やリージョンが使用されています。異種混合デプロイメントは、その特性に応じて「ハイブリッド」「マルチクラウド」「パブリック / プライベート」と呼ばれます。
このラボでは、異種混合デプロイメントとして、単一クラウド環境内で複数のリージョンにまたがるもの、複数のパブリック クラウド環境にまたがるもの(マルチクラウド)、オンプレミス環境とパブリック クラウド環境を組み合わせたもの(ハイブリッド、つまりパブリックとプライベートの混合)を扱います。
単一の環境またはリージョンに限定されたデプロイメントでは、ビジネス上や技術上のさまざまな課題が発生する可能性があります。
-
リソースの枯渇: 単一の環境、特にオンプレミス環境では、本番環境のニーズを満たすコンピューティング リソース、ネットワーキング リソース、ストレージ リソースを確保できない場合があります。
-
地理的範囲の制限: 単一環境のデプロイメントでは、地理的に分散したユーザーが 1 つのデプロイメントにアクセスする必要があります。つまり、ユーザーのトラフィックは、中心となる場所に向けて地球の反対側から転送される可能性があります。
-
限られた可用性: ウェブ規模のトラフィック パターンにより、アプリケーションはフォールト トレランスと復元力を維持する必要に迫られます。
-
ベンダー ロックイン: プラットフォームとインフラストラクチャがベンダーレベルで抽象化されるため、アプリケーションの移植が妨げられる場合があります。
-
柔軟性の低いリソース: リソースの選択肢が特定のコンピューティング、ストレージ、ネットワーキングのオプションに限定される場合があります。
異種混合デプロイメントはこれらの課題への対処に役立ちますが、プログラマティックで確定的なプロセスと手順を使用して設計する必要があります。一度限りやその場しのぎのデプロイ手順では、デプロイメントやプロセスが脆弱になり、障害に耐えられない可能性があります。また、データの喪失やトラフィックのドロップにもつながることがあります。優れたデプロイ プロセスは再現可能でなければならず、プロビジョニング、構成、メンテナンスの管理には実証されたアプローチが必要になります。
異種混合デプロイメントの一般的なシナリオには、次の 3 つがあります。
- マルチクラウド デプロイ
- オンプレミス データのフロントエンド配置
- 継続的インテグレーション / 継続的デリバリー(CI / CD)プロセス
以降の演習では、Kubernetes とその他のインフラストラクチャ リソースを使用して適切に設計されたアプローチにより、異種混合デプロイメントの一般的なユースケースの実習を行います。
設定と要件
[ラボを開始] ボタンをクリックする前に
こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。
このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
- 標準的なインターネット ブラウザ(Chrome を推奨)
注: このラボの実行には、シークレット モード(推奨)またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。
- ラボを完了するための時間(開始後は一時停止できません)
注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。
ラボを開始して Google Cloud コンソールにログインする方法
-
[ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。
左側の [ラボの詳細] ペインには、以下が表示されます。
- [Google Cloud コンソールを開く] ボタン
- 残り時間
- このラボで使用する必要がある一時的な認証情報
- このラボを行うために必要なその他の情報(ある場合)
-
[Google Cloud コンソールを開く] をクリックします(Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します)。
ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。
-
必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。
{{{user_0.username | "Username"}}}
[ラボの詳細] ペインでもユーザー名を確認できます。
-
[次へ] をクリックします。
-
以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。
{{{user_0.password | "Password"}}}
[ラボの詳細] ペインでもパスワードを確認できます。
-
[次へ] をクリックします。
重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。
注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。
-
その後次のように進みます。
- 利用規約に同意してください。
- 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
- 無料トライアルには登録しないでください。
その後、このタブで Google Cloud コンソールが開きます。
注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。
Cloud Shell をアクティブにする
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
-
Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン
をクリックします。
-
ウィンドウで次の操作を行います。
- Cloud Shell 情報ウィンドウで操作を進めます。
- Cloud Shell が認証情報を使用して Google Cloud API を呼び出すことを承認します。
接続した時点で認証が完了しており、プロジェクトに各自の Project_ID、 が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。
Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}
gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
- (省略可)次のコマンドを使用すると、有効なアカウント名を一覧表示できます。
gcloud auth list
- [承認] をクリックします。
出力:
ACTIVE: *
ACCOUNT: {{{user_0.username | "ACCOUNT"}}}
To set the active account, run:
$ gcloud config set account `ACCOUNT`
- (省略可)次のコマンドを使用すると、プロジェクト ID を一覧表示できます。
gcloud config list project
出力:
[core]
project = {{{project_0.project_id | "PROJECT_ID"}}}
注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。
ゾーンを設定する
ローカルゾーンとして を指定して次のコマンドを実行し、使用する Google Cloud ゾーンを設定します。
gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}
このラボのサンプルコードを入手する
- コンテナと Deployment を作成して実行するためのサンプルコードを、ラボ用のバケットから入手します。
gcloud storage cp -r gs://spls/gsp053/kubernetes .
cd kubernetes
- ノードが 3 つあるクラスタを作成します(完了するまでに数分かかります)。
gcloud container clusters create bootcamp \
--machine-type e2-small \
--num-nodes 3 \
--scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"
タスク 1. Deployment オブジェクトの内容を確認する
まず、Deployment オブジェクトについて調べます。
-
kubectl の explain コマンドで、Deployment オブジェクトの詳細を確認します。
kubectl explain deployment
-
--recursive オプションを使用してすべてのフィールドを確認することもできます。
kubectl explain deployment --recursive
- ラボを進めながら explain コマンドを使用すると、Deployment オブジェクトの構造や各フィールドの機能を理解するのに役立ちます。
kubectl explain deployment.metadata.name
タスク 2. Deployment を作成する
-
fortune-app Deployment を作成します。Deployment の構成ファイルを確認します。
cat deployments/fortune-app-blue.yaml
出力:
# orchestrate-with-kubernetes/kubernetes/deployments/fortune-app-blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: fortune-app-blue
spec:
replicas: 3
selector:
matchLabels:
app: fortune-app
template:
metadata:
labels:
app: fortune-app
track: stable
version: "1.0.0"
spec:
containers:
- name: fortune-app
# 新しい、中央で管理されているイメージへのパス
image: "us-central1-docker.pkg.dev/qwiklabs-resources/spl-lab-apps/fortune-service:1.0.0"
ports:
- name: http
containerPort: 8080
...
Deployment でレプリカが 3 つ作成され、バージョン 1.0.0 の fortune-service コンテナが使用されていることがわかります。
- では、
kubectl create を使用して Deployment オブジェクトを作成しましょう。
kubectl create -f deployments/fortune-app-blue.yaml
- Deployment が実際に作成されていることを確認します。
kubectl get deployments
- Deployment が作成されると、Kubernetes はその
ReplicaSet を作成します。Deployment の ReplicaSet が作成されていることを確認します。
kubectl get replicasets
fortune-app-blue-xxxxxxx のような名前の ReplicaSet が表示されます。
- Deployment の一部として作成された Pod を確認します。
kubectl get pods
- 次に、
fortune-app Deployment を外部に公開する Service を作成します。
kubectl create -f services/fortune-app.yaml
-
fortune-app を、その外部 IP を取得して /version エンドポイントに curl を実行することによって操作します。
kubectl get services fortune-app
注: Service の External-IP フィールドに値が表示されるまでに数秒かかる場合がありますが、これは正常な動作です。このフィールドに値が表示されるまで、数秒ごとに上のコマンドを再実行します。
curl http://<EXTERNAL-IP>/version
{"version":"1.0.0"} を示す JSON レスポンスが返されます。
-
kubectl の出力テンプレート機能を使用して、curl を 1 行で実行することもできます。
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
完了したタスクをテストする
下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。Kubernetes クラスタと「fortune-app」の Deployment および Service が正常に作成されている場合は、評価スコアが表示されます。
Kubernetes クラスタと Deployment(fortune-app)を作成する
Deployment をスケールする
次は、作成した Deployment をスケールします。これを行うには、spec.replicas フィールドを更新します。
- replicas フィールドは、
kubectl scale コマンドを使って簡単に更新できます。
kubectl scale deployment fortune-app-blue --replicas=5
注: 新しい Pod がすべて起動するまでに 1 分前後かかる場合があります。
- 5 つの
fortune-app-blue Pod が実行されていることを確認します。
kubectl get pods | grep fortune-app-blue | wc -l
- 今度は、アプリケーションをスケールダウンします。
kubectl scale deployment fortune-app-blue --replicas=3
- ここでも、Pod の数が正しいことを確認します。
kubectl get pods | grep fortune-app-blue | wc -l
Kubernetes の Deployment について、そして Pod のグループを管理してスケールする方法について学びました。
タスク 3. ローリング アップデートを行う
Deployment では、ローリング アップデートのメカニズムを使用してイメージを新しいバージョンに更新できます。
ローリング アップデートをトリガーする
- ローリング アップデートは、「green」Deployment の構成を適用するだけでトリガーできます。Kubernetes は、既存の Deployment(
fortune-app-blue)を認識しているため、新しいファイルの変更を徐々に適用して更新を行います。
kubectl edit deployment fortune-app-blue
- エディタで
image 行を見つけ、バージョン タグを 1.0.0 から 2.0.0 に変更します。キーボードの i を押して「挿入モード」にすると、ファイルを編集できます。
-
まず、イメージタグを変更します:
- 次の行を探します。
image: "us-central1-docker.pkg.dev/qwiklabs-resources/spl-lab-apps/fortune-service:1.0.0"
- 次のように変更します。
image: "us-central1-docker.pkg.dev/qwiklabs-resources/spl-lab-apps/fortune-service:2.0.0"
-
次に、環境変数を更新します:
-
env セクションと APP_VERSION 変数を見つけます。
-
value: "1.0.0" を value: "2.0.0" に変更します。
-
保存してエディタを閉じます。これを行うには、Esc キーを押してから「:wq」と入力し、Enter キーを押します。これにより、正しい Deployment でローリング アップデートがトリガーされ、その履歴が適切に記録されます。これにより、正しい Deployment でローリング アップデートがトリガーされ、その履歴が適切に記録されます。
-
Kubernetes によって作成された新しい ReplicaSet を確認します。
kubectl get replicaset
- ロールアウト履歴にも新しいエントリが表示されます。
kubectl rollout history deployment/fortune-app-blue
ローリング アップデートを一時停止する
- 次のコマンドを実行してロールアウトを一時停止します。
kubectl rollout pause deployment/fortune-app-blue
- ロールアウトの現在の状態を確認します。
kubectl rollout status deployment/fortune-app-blue
注: ステータス コマンドによって、すぐに「deployment "fortune-app-blue" successfully rolled out」と返される場合があります。これは想定どおりであり、一時停止コマンド自体が成功したことを示しています。バージョン アップデートが完了したことを意味するものではありません。
- 各 Pod のバージョンを確認します。1.0.0 の Pod と 2.0.0 の Pod が混在していることがわかります。これは、ロールアウトが途中で一時停止していることを示しています。
for p in $(kubectl get pods -l app=fortune-app -o=jsonpath='{.items[*].metadata.name}'); do echo $p && curl -s http://$(kubectl get pod $p -o=jsonpath='{.status.podIP}')/version; echo; done
-
Ctrl+C キーを押してループを終了します。
ローリング アップデートを再開する
-
resume コマンドを使用してロールアウトを続行します。
kubectl rollout resume deployment/fortune-app-blue
- ロールアウトの完了後に
status コマンドを実行すると、次のように表示されます。
kubectl rollout status deployment/fortune-app-blue
更新をロールバックする
新しいバージョンでバグが検出されたと仮定します。
-
rollout コマンドを使用して、以前のバージョンにロールバックします。
kubectl rollout undo deployment/fortune-app-blue
注: ロールバックが完了するまでしばらくかかることがあります。
- すべての Pod がバージョン 1.0.0 にロールバックされていることを確認します。
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
ここまで、Kubernetes Deployment のローリング アップデートを行う方法について学びました。
タスク 4. カナリア デプロイを行う
本番環境で一部のユーザーを対象に新しいデプロイメントをテストする場合は、カナリア デプロイを行います。
カナリア デプロイ Deployment を作成する
- まず、
fortune-app-canary.yaml ファイルを使用して、新しいバージョン用の Deployment を作成します。
cat deployments/fortune-app-canary.yaml
- カナリア デプロイ Deployment を作成します。
kubectl create -f deployments/fortune-app-canary.yaml
- 完了すると、2 つの Deployment が存在する状態になります。次のコマンドで確認します。
kubectl get deployments
fortune-app Service には app: fortune-app のセレクタがあり、これは fortune-app-blue(本番環境)と fortune-app-canary の両方の Deployment の Pod に一致します。
カナリア デプロイを確認する
- Service にリクエストを送信して、提供されているバージョンを確認します。
for i in {1..10}; do curl -s http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version; echo;
done
- これを数回実行すると、ほとんどのリクエストがバージョン 1.0.0 によって処理され、ごく一部が 2.0.0 によって処理されることがわかります。
完了したタスクをテストする
下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。カナリア デプロイの Deployment が正常に作成されている場合は、評価スコアが表示されます。
カナリア デプロイ
タスク 5. Blue/Green デプロイ
Blue/Green デプロイでは、2 つの別々の Deployment を作成し、Service セレクタを更新してそれらの間でトラフィックを切り替えます。
Service
- まず、Service を更新して「blue」バージョン(1.0.0)のみを指すようにします。
kubectl apply -f services/fortune-app-blue-service.yaml
Blue/Green デプロイを使用して更新する
- 次に、バージョン 2.0.0 の新しい「Green」Deployment を作成します。
kubectl create -f deployments/fortune-app-green.yaml
- 「Green」Deployment が稼働を開始したら、現在提供されているバージョンがまだ 1.0.0 であることを確認します。
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
- 次に、新しい「Green」バージョンを指すように Service を更新します。
kubectl apply -f services/fortune-app-green-service.yaml
- Service が更新されると、すぐに「Green」Deployment が使用されるようになります。常にバージョン 2.0.0 が提供されていることを確認します。
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
Blue/Green ロールバック
- ロールバックするには、「Blue」Deployment の Service マニフェストを再適用します。
kubectl apply -f services/fortune-app-blue-service.yaml
- Service が更新されたら、ロールバックは完了です。バージョン 1.0.0 が使用されていることを確認します。
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
これで完了です。Blue/Green デプロイについて、そしてバージョンを一度に切り替える必要があるアプリケーションにアップデートをデプロイする方法について学びました。
Blue/Green デプロイ
お疲れさまでした
このラボでは、kubectl コマンドライン ツールと、YAML ファイル内のさまざまなスタイルの構成を活用して、Deployment をリリース、更新、スケールしました。
Google Cloud トレーニングと認定資格
Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。
マニュアルの最終更新日: 2025 年 8 月 18 日
ラボの最終テスト日: 2025 年 8 月 18 日
Copyright 2025 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。