GKE による最新の CI / CD: デベロッパー ワークフローを適用する

Last reviewed 2023-09-11 UTC

Standard

---

このチュートリアルでは、最新の継続的インテグレーション / 継続的デリバリー（CI / CD）の手法を使用して Google Kubernetes Engine（GKE）で新しいアプリケーションをオンボーディングし、アプリケーションの機能を開発して本番環境にデプロイする方法について説明します。

このドキュメントはシリーズの一部です。

• GKE による最新の CI / CD: ソフトウェア デリバリー フレームワーク
• GKE による最新の CI / CD: CI / CD システムをビルドする（リファレンス アーキテクチャ）
• GKE による最新の CI / CD: デベロッパー ワークフローを適用する（このドキュメント）

このチュートリアルでは、アプリケーションの開発、ビルド、デプロイに、Skaffold、kustomize、Artifact Registry、Config Sync、Cloud Build、Cloud Deploy などのツールを使用します。

このドキュメントは、企業の設計者とアプリケーション デベロッパーのほか、IT セキュリティ、DevOps、サイト信頼性エンジニアリング（SRE）チームを対象としています。自動化されたデプロイツールとプロセスの経験があると、このドキュメントのコンセプトを理解するうえで役立ちます。

アーキテクチャ

このチュートリアルでは、新しいアプリケーションをオンボーディングした後、新機能を開発してから、アプリケーションを開発環境、ステージング環境、本番環境にデプロイします。リファレンス アーキテクチャには、次の図に示すワークフローで新しいアプリケーションをオンボーディングしてリリースするために必要なインフラストラクチャとツールが含まれています。

CI のコード リポジトリから開始する場合、ワークフローの手順は以下のようになります:

1. アプリケーション リポジトリを介してアプリケーションのソースコードを共有します。

2. コードを commit してアプリケーション リポジトリに push すると、Cloud Build で CI パイプラインが自動的にトリガーされます。この CI プロセスにより、コンテナ イメージが作成されて Artifact Registry に push されます。

3. CI プロセスにより、Cloud Deploy 内にアプリケーションの CD リリースも作成されます。

4. CD リリースは skaffold を使用して、完全にレンダリングされた Kubernetes マニフェストを開発環境用に生成し、開発 GKE クラスタにデプロイします。

5. CD リリースが開発環境からステージング ターゲットに昇格します。完全にレンダリングされたステージング マニフェストが生成され、ステージング GKE クラスタにデプロイされます。

6. CD リリースがステージングから本番環境に昇格します。完全にレンダリングされた本番環境マニフェストが生成され、本番環境の GKE クラスタにデプロイされます。

このワークフローで使用されるツールとインフラストラクチャの詳細については、GKE による最新の CI / CD: CI/CD システムをビルドするをご覧ください。

目標

• 新しいアプリケーションをオンボーディングする。

• アプリケーションを開発環境にデプロイする。

• 新しい機能を開発し、開発環境にデプロイする。

• 新機能をステージング環境に昇格させてから、本番環境にリリースする。

• アプリケーションの復元性をテストする。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

• Google Kubernetes Engine
• Google Kubernetes Engine (GKE) Enterprise edition for Config Sync
• Artifact Registry
• Cloud Build
• Cloud Deploy

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。 新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

• このチュートリアルでは、このシリーズのリファレンス アーキテクチャをデプロイします。

環境を準備する

1. GKE による最新の CI / CD: CI / CD システムをビルドするから続ける場合は、次のセクションに進みます。ただし、新しいセッションを使う場合やセッションが期限切れになった場合は、Cloud Shell を開き、リファレンス アーキテクチャ インフラストラクチャをインストールしたプロジェクトを設定します。

   gcloud config set core/project PROJECT_ID

   PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

新しいアプリケーションをオンボーディングする

リファレンス アーキテクチャにはアプリケーション ファクトリーが含まれています。このファクトリーは、application-factory-repo という名前の Git リポジトリと、次の Cloud Build トリガーのコレクションです。

• create-app
• tf-plan
• tf-apply
• create-team

アプリケーション ファクトリーを使用して、スターター リポジトリから新しいアプリケーションをオンボーディングします。アプリケーションのオンボーディングは次の手順で構成されます。

1. アプリケーション定義を作成する: Terraform ファイル内でアプリケーション定義を作成し、アプリケーション カタログとして機能する application-factory-repo に保存します。

2. アプリケーション インフラストラクチャを作成する: アプリケーション定義ファイルで Terraform を実行して、アプリケーション インフラストラクチャを作成します。アプリケーション インフラストラクチャは次の要素で構成されます。

   1. 新しいアプリケーションのランディング ゾーン。これには、acm-gke-infrastructure-repo リポジトリにおける Namespace、サービス アカウント、基本ポリシーの定義が含まれます。新しいアプリケーションをオンボーディングする際、ランディング ゾーンは開発 GKE クラスタでのみ作成されます。これにより、デベロッパーは自由に開発環境を使用してイテレーションを開始できます。ステージング クラスタと本番環境クラスタのランディング ゾーンは、GitOps アプローチを使って作成します。このアプローチは、このドキュメントの後半に、これらのクラスタにリリースを昇格させる準備ができた段階で説明します。

   2. インフラストラクチャ スターター リポジトリから取得されたインフラストラクチャ リポジトリ。Cloud Build の CI パイプライン、Cloud Deploy の CD パイプライン、アーティファクトの保存用の Artifact Registry リポジトリを作成するためのコードをホストします。

   3. インフラストラクチャ Cloud Build トリガー。インフラストラクチャ リポジトリ内のコードを受け取り、その定義に基づいてリソースを作成します。

   4. アプリケーション スターター リポジトリから取得されたアプリケーション リポジトリ。アプリケーションのソースコードをホストします。

3. アプリケーションの CI / CD リソースを作成する: アプリケーション インフラストラクチャを使用して、アプリケーションの CI / CD リソースを作成します。

注: リファレンス アーキテクチャを使用すると、アプリケーションのオンボーディングとデプロイのステップ全体を自動化できます。アーキテクチャをより深く理解できるように、このドキュメントではこれらの手順を詳しく説明します。

アプリケーションの定義を作成します。

create-app トリガーを実行して、application-factory-repo にアプリケーション定義ファイルを生成します。定義ファイルには、アプリケーションの作成に必要なリソースの宣言型定義が含まれています。

1. Google Cloud コンソールで、Cloud Build ページに移動します。

   Cloud Build ページに移動する

2. create-appトリガーをクリックします。

3. [URL プレビューを表示] をクリックすると、Webhook の呼び出しに必要な URL が表示されます。

4. Cloud Shell で、前の手順で取得した URL に対して curl リクエストを行い、パラメータをペイロードとして渡してトリガーを呼び出します。

   curl "WEBHOOK_URL" -d '{"message": {"app": "sample","runtime": "python","trigger_type": "webhook","github_team": ""}}'

   上記のコードサンプルで、

   • WEBHOOK_URL は、トリガーから取得した URL に置き換えます。

   • "app": "sample" は、アプリケーションの名前を指定します。

   • "runtime": "python" は、Python テンプレートを使用してアプリケーション リポジトリを作成するようにアプリケーション ファクトリーに指示します。

   • "trigger_type": "webhook" は、アプリケーションの CI / CD パイプラインのタイプを指定します。

   • "github_team": "" は、アプリケーション用に作成されるリポジトリに関連付けられる、GitHub のチームです。まだ GitHub チームを作成していないため、空の文字列として渡します。

5. パイプラインで create-app トリガーを確認します。

   Cloud Build の履歴ページに移動する

   create-app トリガー用の新しいパイプラインがあります。完了すると、アプリケーション定義が application-factory-repo に作成されます。

6. アプリケーション定義ファイルを確認します。

   1. ウェブブラウザで GitHub にアクセスし、アカウントにログインします。

   2. 画像アイコンをクリックし、Your organizations をクリックして組織を選択します。

   3. リポジトリ application-factory-repo をクリックしてフォルダ apps/python に移動し、create-app トリガーによって作成された sample.tf という名前の新しいファイルを開きます。新しいアプリケーションを作成するための Terraform コードがこのファイルに含まれていることを確認してください。

アプリケーション インフラストラクチャを作成します。

アプリケーション定義を作成したら、tf-apply トリガーを実行してアプリケーション インフラストラクチャを作成します。

1. Google Cloud コンソールの場合

   Cloud Build ページに移動する

   tf-applyトリガーをクリックします。

2. [URL プレビューを表示] をクリックすると、Webhook の呼び出しに必要な URL が表示されます。

3. トリガーを呼び出します。

   curl "WEBHOOK_URL" -d '{}'

   上記のコードサンプルで、

   • WEBHOOK_URL は、トリガーから取得した URL に置き換えます。

4. tf-apply トリガー用のパイプラインを確認します。

   Cloud Build の履歴ページに移動する

   tf-apply トリガー用の新しいパイプラインがあります。完了するまで待ってください。

このトリガーにより、アプリケーション インフラストラクチャが作成されます。

アプリケーション インフラストラクチャを確認します。

アプリケーション インフラストラクチャのさまざまなコンポーネントを確認します。

ランディング ゾーン

1. Cloud Shell に移動し、プロジェクトを設定します。

   gcloud config set core/project PROJECT_ID

   PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

2. 開発 GKE クラスタの認証情報を取得します。

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

3. アプリケーションの Namespace を確認します。Namespace にはアプリケーションの名前（sample）が付けられています。

   kubectl get namespaces sample
   

   出力は次のようになります。

   NAME     STATUS   AGE
   sample   Active   15m
   

4. Namespace のサービス アカウントを確認します。

   kubectl get serviceaccounts -n sample
   

   デフォルト以外のサービス アカウントもあります。出力は次のようになります。

   NAME         SECRETS   AGE
   default      0         15m
   sample-ksa   0         15m
   

インフラストラクチャ リポジトリ

ウェブブラウザで GitHub にアクセスし、アカウントにログインします。画像アイコンをクリックした後、Your organizations をクリックして組織を選択し、sample-infra リポジトリをクリックします。

このリポジトリには、cicd-trigger、dev、staging、prod の 4 つのブランチがあり、cicd-trigger、dev、staging、prod の 4 つのフォルダも含まれています。デフォルトのブランチは cicd-trigger で、このブランチにはコードを push できます。他のブランチには保護ルールがあるため、コードを直接 push することができず、コードを push するには pull リクエストを作成する必要があります。cicd-trigger フォルダには、アプリケーションの CI / CD リソースを作成するためのコードがあります。dev、staging、prod フォルダには、アプリケーションのさまざまな環境用のインフラストラクチャを作成するためのコードがあります。

インフラストラクチャ トリガー

• Google Cloud コンソールの場合

  Cloud Build ページに移動する

  deploy-infra-sample という名前の新しいトリガーがあります。

• このトリガーはリポジトリ sample-infra に接続されており、このリポジトリに対してコードの push が行われると呼び出され、push が行われたブランチを識別します。その後、そのブランチの対応するフォルダに移動して Terraform を実行します。たとえば、コードが cicd-trigger ブランチに push されると、このトリガーは cicd-trigger ブランチの cicd-trigger フォルダで Terraform を実行します。同様に、dev ブランチへの push が発生すると、dev ブランチの dev フォルダで Terraform を実行します。

アプリケーション リポジトリ

• GitHub にアクセスし、組織のリポジトリを pull します。sample という名前の新しいリポジトリがあります。このリポジトリは、Dockerfile でコンテナをビルドするソースコードとステップ、アプリケーションに必要な構成を記述する kustomize 構成、Cloud Deploy で使用する CD 用デプロイ ステップを定義する skaffold.yaml をホストします。

アプリケーションの CI / CD リソースを作成する

アプリケーションのスケルトンを作成できたので、deploy-infra-sample トリガーを実行して CI / CD リソースを作成します。このトリガーは、Webhook URL を使用して手動で呼び出すか、Git リポジトリ sample-infra に対して commit を行うことで呼び出すことができます。

1. この Cloud Build トリガーを呼び出すため、リポジトリ内のファイルに新しい行を追加した後で変更を push します。

   1. Cloud Shell で Git を初めて使用する場合は、名前とメールアドレスを使用して Git を構成します。Git はこの情報を使用して、Cloud Shell で作成する commit の作成者を識別します。

      git config --global user.email "GITHUB_EMAIL_ADDRESS"
      git config --global user.name "GITHUB_USERNAME"

      次のように置き換えます。

      • GITHUB_EMAIL_ADDRESS: GitHub アカウントに関連付けられているメールアドレス
      • GITHUB_USERNAME: GitHub アカウントに関連付けられているユーザー名

   2. Git リポジトリ sample-infra のクローンを作成します。

      git clone https://github.com/GITHUB_ORG/sample-infra
      
      cd sample-infra

      次のように置き換えます。

      • GITHUB_ORG は GitHub 組織に置き換えます。

      デフォルトのブランチ cicd-trigger がチェックアウトされます。

   3. env/cicd-trigger/main.tf ファイルに新しい行を追加し、変更を commit して push します。

        echo "" >> env/cicd-trigger/main.tf
      

   4. 変更を commit して push します。

      git add .
      git commit -m "A dummy commit to invoke the infrastrucutre trigger"
      git push
      cd ..
      

      変更が push されると、すぐに Cloud Deploy トリガー deploy-infra-sample が開始されます。

2. トリガーのステータスをモニタリングします。

   Cloud Build の履歴ページに移動してパイプラインを表示し、完了するまで待ちます。

アプリケーションの CI / CD リソースを確認する

アプリケーション用に作成されたさまざまな CI / CD リソースを確認します。

1. Google Cloud コンソールの場合:

   Cloud Build ページに移動して、deploy-app-sample トリガーを表示します。

   これは CI パイプラインのトリガーであり、アプリケーション コード リポジトリ sample に接続されています。このアプリケーション リポジトリへの push が行われると呼び出され、トリガー構成で定義されているビルドステップを実行します。このトリガーが呼び出されたときに実行するステップを表示するには、トリガー名をクリックして、[エディタを開く] ボタンをクリックします。

2. Artifact Registry ページに移動して、sample という名前の新しいリポジトリを表示します。

   このアーティファクト リポジトリに、アプリケーションのアーティファクトが保存されています。

3. Cloud Deploy パイプライン ページに移動し、sample という名前のパイプラインを表示します。これは、GKE クラスタにアプリケーションをデプロイする継続的デプロイ パイプラインです。

アプリケーションを開発環境にデプロイする

deploy-app-sample トリガーは、sample という名前のアプリケーション リポジトリに接続されています。このトリガーを、Webhook URL を使用して手動で呼び出すか、アプリケーション リポジトリへの push によって呼び出すことができます。

1. sample リポジトリ内のファイルに新しい行を追加し、変更を push して Cloud Build トリガーを呼び出します。

   1. Git リポジトリ sample のクローンを作成します。

      Cloud Shell で次のコマンドを実行します。

      git clone https://github.com/GITHUB_ORG/sample
      
      cd sample

      GITHUB_ORG は GitHub 組織に置き換えます。

   2. skaffold.yaml ファイルに新しい行を追加します。

        echo "" >> skaffold.yaml
      

   3. 変更を commit して push します。

      git add .
      git commit -m "A dummy commit to invoke CI/CD trigger"
      git push
      

   4. 変更が push されると、すぐに Cloud Deploy トリガー deploy-app-sample が開始されます。

2. トリガーのステータスをモニタリングします。

   Cloud Build の履歴ページに移動してパイプラインを表示し、完了するまで待ちます。

   トリガーの構成で定義されているステップが実行されます。最初のステップで、リポジトリ sample 内のアプリケーション コードから Docker イメージがビルドされます。最後のステップで、アプリケーションを開発 GKE クラスタにデプロイする Cloud Deploy パイプラインが開始されます。

3. 開発クラスタでデプロイを確認します。

   Cloud Deploy パイプライン ページに移動

   sample パイプラインをクリックすると、開発 GKE クラスタへのデプロイが開始されたことがわかります。完了するまで待ってください。

アプリケーションのデプロイが成功したことを確認します。

1. 開発クラスタの認証情報を取得します。

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

2. GKE クラスタへのトンネルを作成します。

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
   

3. Cloud Shell ツールバーで

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

   次のような出力が表示されます。

   Hello World!
   

4. Cloud Shell で、CTRL+C を押してポート転送を終了します。

アプリケーションに新しい機能を追加する

新しい機能を開発する際は、テストとイテレーションのために変更内容を開発環境に迅速にデプロイする必要があります。このチュートリアルでは、アプリケーション コード リポジトリに変更を加えて開発環境にデプロイします。

1. Cloud Shell で、ディレクトリを sample リポジトリのクローンに切り替えます。

2. 別のメッセージを出力するようにアプリケーションを更新します。

     sed -i "s/Hello World/My new feature/g" main.py
   

3. 変更を commit して push します。

   git add .
   git commit -m "Changed the message"
   git push
   

   コードが GitHub リポジトリに push されるとすぐに、Webhook トリガー deploy-app-sample が開始されます。

4. Cloud Build の履歴ページでトリガーのステータスをモニタリングし、完了するまで待ちます。

5. Cloud Deploy パイプライン ページに移動

   sample パイプラインをクリックすると、開発 GKE クラスタへのデプロイが開始されたことがわかります。完了するまで待ってください。

アプリケーションのデプロイが成功したことを確認します。

1. 新しい Cloud Shell を開いた場合は、開発クラスタの認証情報を取得します。

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

2. GKE クラスタへのトンネルを作成します。

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
   

3. Cloud Shell ツールバーで

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

   

   次のような出力が表示されます。

   My new feature!
   

4. Cloud Shell で、CTRL+C を押してポート転送を終了します。

変更をステージング クラスタと本番環境クラスタに昇格させる

アプリケーションをステージング環境と本番環境に昇格させる前に、アプリケーション用のランディング ゾーンをそれぞれの環境の GKE クラスタに作成する必要があります。アプリケーションをオンボーディングした際は、dev ブランチで acm-gke-infrastructure-repo にコードを追加することで、開発用のランディング ゾーンが開発 GKE クラスタで自動的に作成されました。

ランディング ゾーンをステージング環境と本番環境の GKE クラスタに作成する

1. ランディング ゾーンをステージング環境の GKE クラスタに作成する: acm-gke-infrastructure-repo で dev ブランチから staging ブランチへの pull リクエストを作成し、マージする必要があります。

   1. GitHub にアクセスし、acm-gke-infrastructure-repo リポジトリに移動します。[Pull requests]、[New pull request] ボタンの順にクリックします。[ベース] メニューで [staging] を選択し、[比較] メニューで [dev] を選択した後、[Create pull request] ボタンをクリックします。

   2. 意図した変更のみがステージング環境に昇格するよう、通常はリポジトリにアクセスできるユーザーが変更を確認して pull リクエストをマージしますが、リファレンス アーキテクチャでは個人が試せるようにブランチ保護ルールが緩和されているため、リポジトリ管理者はレビューをバイパスして pull リクエストをマージできます。リポジトリの管理者である場合は、この pull リクエストをマージしてください。それ以外の場合は、管理者にマージを依頼してください。

   acm-gke-infrastructure-repo リポジトリの staging ブランチに到着した変更が Config Sync によってステージング GKE クラスタと同期され、ステージング GKE クラスタにアプリケーション用のランディング ゾーンが作成されます。

2. ランディング ゾーンを本番環境の GKE クラスタに作成する: staging ブランチから prod ブランチへの pull リクエストを作成してマージする必要があります。

   1. [Pull requests]、[New pull request] ボタンの順にクリックします。[ベース] メニューで [prod] を選択し、[比較] メニューで [staging] を選択します。[Create pull request] ボタンをクリックします。

   2. リポジトリの管理者である場合は、この pull リクエストをマージしてください。それ以外の場合は、管理者にマージを依頼してください。

   acm-gke-infrastructure-repo リポジトリの prod ブランチに到達した変更が Config Sync によって本番環境の GKE クラスタと同期され、本番環境の GKE クラスタにアプリケーション用のランディング ゾーンが作成されます。

変更を開発環境からステージング環境に昇格させる

ステージング環境と本番環境の GKE クラスタでアプリケーション用のランディング ゾーンを作成できたので、アプリケーションを開発環境からステージング環境に昇格させます。

1. 最新のリリース名を見つけ、環境変数として保存します。

     export RELEASE=$(gcloud deploy targets describe dev --region=us-central1 --format="json" | jq -r '."Active Pipeline"[0]."projects/PROJECT_ID/locations/us-central1/deliveryPipelines/sample"."Latest release"' | awk -F '/' '{print $NF}')
    

   PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

   この環境変数が設定されたことを確認します。

     echo $RELEASE
     

2. Cloud Shell で次のコマンドを実行して、開発環境からステージング環境へのリリースの昇格をトリガーします。

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=staging --quiet
    

3. ステージング環境へのデプロイを確認します。

   Cloud Deploy パイプライン ページに移動

   sample パイプラインをクリックすると、ステージング GKE クラスタへのデプロイが開始されたことがわかります。完了するまで待ってください。

4. ステージング環境へのデプロイが正常に行われたことを確認します。

   1. ステージング クラスタの認証情報を取得します。

      gcloud container clusters get-credentials gke-staging-us-central1 --zone us-central1-a
      

   2. GKE クラスタへのトンネルを作成します。

      gcloud container clusters get-credentials gke-staging-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
      

   3. Cloud Shell ツールバーで

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

      

      次のような出力が表示されます。

      My new feature!
      

   4. Cloud Shell で、CTRL+C を押してポート転送を終了します。

変更をステージング環境から本番環境に昇格させる

リリースをステージング環境から本番環境に昇格させます。本番環境クラスタは 2 つあり、それぞれについて Cloud Deploy に prod1 と prod2 という名前のターゲットがあります。

1. Cloud Shell で次のコマンドを実行して、ステージング クラスタから prod1 クラスタへのリリースの昇格をトリガーします。

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod1 --quiet
    

2. 本番環境クラスタへのリリースには承認が必要なため、承認されるまでロールアウトは待機状態になります。状態を表示するには:

   Cloud Deploy パイプライン ページに移動

   sample パイプライン をクリックします。prod1 へのロールアウトには承認が必要であり、ロールアウトを承認するには clouddeploy.approver ロールが必要です。プロジェクトのオーナーであるため、リリースを承認するためのアクセス権があります。

3. prod1 へのリリースを承認します。

   次のコマンドを実行して、承認待ちのロールアウトの名前を取得し、環境変数に保存します。

    export ROLLOUT=$(gcloud deploy targets describe prod1 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
    

   リリースを承認します。

    gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
    

4. 承認が完了すると、prod1 へのリリースが開始されます。Cloud Deploy パイプライン ページで進行状況をモニタリングしてください。

5. prod1 デプロイが完了したら、prod2 へのリリースを開始します。

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod2 --quiet
    

6. prod2 へのリリースにも承認が必要なため、prod2 クラスタへのリリースを承認します。

   次のコマンドを実行して、承認待ちのロールアウトの名前を取得し、環境変数に保存します。

    export ROLLOUT=$(gcloud deploy targets describe prod2 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
    

   リリースを承認します。

    gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
    

   注: Cloud Deploy では複数の GKE クラスタへの並行デプロイが可能であり、複数の本番環境クラスタに同時にデプロイできます。詳しくは、Cloud Deploy による並行デプロイをご覧ください。

7. 承認が完了すると、prod2 へのリリースが開始されます。Cloud Deploy パイプライン ページで進行状況をモニタリングしてください。

8. Cloud Deploy パイプラインが prod1 と prod2 で完了した後、本番環境クラスタへのデプロイが成功したことを確認します。

   1. 本番環境クラスタにはマルチクラスタ Ingress が作成されており、ロードバランサを使用して本番環境アプリケーションにアクセスします。このマルチクラスタ Ingress 構成は、sample リポジトリ内の YAML ファイル k8s/prod/mci.yaml と k8s/prod/mcs.yaml を使用して作成されます。ロードバランサの IP アドレスに送信したリクエストは、マルチクラスタ Ingress により、2 つの異なる GKE クラスタで実行されている 2 つのアプリケーション インスタンスのいずれかに転送されます。

   2. ロードバランサに関連付けられている転送ルールを一覧表示して、IP アドレスを確認します。

      gcloud compute forwarding-rules list

   3. 出力は次のようになります。

      NAME: mci-qqxs9x-fw-sample-sample-ingress
      REGION:
      IP_ADDRESS: 34.36.123.118
      IP_PROTOCOL: TCP
      TARGET: mci-qqxs9x-sample-sample-ingress
      

   4. ウェブブラウザを開き、次の URL を入力します。

      http://IP_ADDRESS:80

      IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。

      次のような出力が表示されます。

      My new feature!
      

      これにより、アプリケーションが本番環境クラスタに想定どおりにデプロイされたことを確認できます。

アプリケーションの復元性をテストする

このセクションでは、本番環境で実行されているアプリケーションの復元性をテストするため、アプリケーションに影響を与えずに 2 つの本番環境 GKE クラスタノードのいずれかを再起動します。

本番環境のアプリケーションはマルチクラスタ Ingress を使用しており、ロードバランサの IP によってアクセスできます。この IP を使ってアプリケーションにアクセスすると、マルチクラスタ Ingress により、2 つの異なる GKE クラスタで実行されている 2 つのアプリケーション インスタンスのいずれかにルーティングされます。一方の GKE クラスタに異常があり、そのクラスタで実行中のアプリケーション インスタンスに到達できない場合は、マルチクラスタ Ingress により、もう一方の GKE クラスタで実行中の正常なアプリケーション インスタンスに対してトラフィックの送信が継続されます。これにより、クラスタの停止はエンドユーザーに認識されず、アプリケーションはリクエストを継続的に処理できます。

復元力をテストするには:

1. us-west1 で実行されている本番環境 GKE クラスタのノードプールを見つけます。

    gcloud container clusters describe gke-prod-us-west1 --zone=us-west1-a --format=json | jq ".nodePools[0].instanceGroupUrls[]" | tr '"' ' ' |  awk -F '/' '{for(i=NF-2; i<=NF; i=i+2) printf ("%s ",$i); print  ""}'

2. 出力は次のようになります。

   us-west1-b gke-gke-prod-us-west1-node-pool-01-6ad4e1ed-grp
   us-west1-c gke-gke-prod-us-west1-node-pool-01-98407373-grp
   

   出力には 2 つの列があります。1 列目はゾーンであり、2 列目は us-west1 リージョンにある本番環境 GKE クラスタのノードプールに関連付けられたインスタンス グループの名前です。

3. ノードプールに対応するインスタンス グループを再起動します。

    gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_1  --zone=ZONE_1 --max-unavailable=100%
   
    gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_2  --zone=ZONE_2 --max-unavailable=100%

   INSTANCE_GROUP_1 は、最初のインスタンス グループの名前に置き換えます。

   ZONE_1 は、最初のインスタンス グループのゾーンに置き換えます。

   INSTANCE_GROUP_2 は、2 番目のインスタンス グループの名前に置き換えます。

   ZONE_2 は、2 番目のインスタンス グループのゾーンに置き換えます。

4. インスタンス グループのステータスを確認します。

   [インスタンス グループ] ページに移動

   2 つのインスタンス グループは再起動中ですが、他のグループには緑色のチェックマークが付いています。

   

5. ウェブブラウザを開き、次の URL を入力します。

   http://IP_ADDRESS:80

   IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。

   2 つの GKE クラスタのいずれかが停止しても、アプリケーションは使用可能で、出力は次のようになります。

    My new feature!
    

   これは、アプリケーションの復元性と高可用性を示しています。

アプリケーションの管理

アプリケーション ファクトリーからこのアプリケーションを作成したときに、アプリケーション用に個別の Git リポジトリ、インフラストラクチャ、CI / CD パイプラインが作成されました。これらのリソースを使用して、アプリケーションをデプロイし、新機能を追加しました。アプリケーションの今後の管理はこれらの Git リポジトリとパイプラインを操作するだけで行うことができ、アプリケーション ファクトリーを更新する必要はありません。要件に基づいてアプリケーションのパイプラインと Git リポジトリをカスタマイズできます。アプリケーション オーナーは、誰がアプリケーションのパイプラインや Git リポジトリにアクセスできるかを定義して管理できます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにする手順は次のとおりです。

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。
• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

• ID 連携の設定に関するベスト プラクティスについて確認する。
• Kubernetes と継続的ソフトウェア デプロイメントの課題を読む。
• ハイブリット クラウドとマルチクラウドのモニタリングおよびロギング パターンについて確認する。
• Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。