CI / CD パイプラインを使用してコンテナ化されたアプリを開発、デプロイする

Last reviewed 2022-11-18 UTC

このデプロイガイドでは、 Google Cloud ツールの統合セットを使用して、開発、継続的インテグレーション（CI）、継続的デリバリー（CD）システムを設定し、使用する方法について説明します。このシステムを使用すると、アプリケーションを開発し、Google Kubernetes Engine（GKE）にデプロイできます。

このガイドでは、コンテナ化されたアプリを開発して配信するためのデプロイ パイプラインで説明しているアーキテクチャを作成する方法について説明します。

このデプロイガイドは、ソフトウェア デベロッパーとオペレーターの両方を対象としており、完了するとご自身が以下に示す役割を担います。

  • まず、CI / CD パイプラインを設定するオペレーターとして操作します。このパイプラインの主要なコンポーネントは、Cloud Build、Artifact Registry、Cloud Deploy です。
  • 次にデベロッパーとして、Cloud Code を使用してアプリケーションを変更します。デベロッパーとして機能すると、このパイプラインが提供する統合されたエクスペリエンスが表示されます。
  • 最後に、オペレーターとして、アプリケーションを本番環境にデプロイする手順を実施します。

このデプロイガイドでは、Google Cloud で gcloud コマンドを実行することと、アプリケーション コンテナを GKE にデプロイする方法を理解していることを前提としています。

アーキテクチャ

次の図は、このデプロイガイドで使用するリソースを示しています。

システムの開発とデプロイには、Cloud Code、Cloud Build、Artifact Registry、Cloud Deploy、GKE を使用します。

このアーキテクチャで使用されるコンポーネントの詳細については、コンテナ化されたアプリを開発して配信するためのデプロイ パイプラインをご覧ください。

目標

オペレーターとして、次の操作を行います。

  • CI パイプラインと CD パイプラインを設定します。この設定には以下の作業が含まれます。
    • 必要な権限を設定する。
    • ステージング環境と本番環境用の GKE クラスタを作成する。
    • ソースコード用のリポジトリを Cloud Source Repositories に作成する。
    • アプリケーション コンテナ用のリポジトリを Artifact Registry に作成する。
    • メインの GitHub リポジトリに Cloud Build トリガーを作成する。
    • Cloud Deploy デリバリー パイプラインとターゲットを作成する。ターゲットは、ステージング環境と本番環境です。
  • ステージング環境にデプロイする CI / CD プロセスを開始し、本番環境に昇格させる。

デベロッパーとして、アプリケーションに変更を加えます。これを行う方法は次のとおりです。

  • 事前構成された開発環境と連携するように、リポジトリのクローンを作成する。
  • デベロッパー ワークスペース内でアプリケーションを変更する。
  • 変更を構築およびテストする。このテストには、ガバナンスの検証テストが含まれています。
  • 開発環境クラスタで変更を表示して検証する。このクラスタは minikube で実行されます。
  • メイン リポジトリに変更を commit する。

費用

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

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

新規の Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

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

始める前に

  1. Google Cloud コンソールのプロジェクト セレクタページで、 Google Cloud プロジェクトを選択または作成します。

    プロジェクトの選択または作成に必要なロール

    • プロジェクトを選択する: プロジェクトの選択に特定の IAM ロールは必要ありません。ロールが付与されているプロジェクトであれば、どのプロジェクトでも選択できます。
    • プロジェクトを作成する: プロジェクトを作成するには、resourcemanager.projects.create 権限を含むプロジェクト作成者ロール（roles/resourcemanager.projectCreator）が必要です。詳しくは、ロールを付与する方法をご覧ください。

    プロジェクト セレクタに移動

  2. Google Cloud プロジェクトに対して課金が有効になっていることを確認します。

  3. Artifact Registry、Cloud Build、Cloud Deploy、Cloud Source Repositories、Google Kubernetes Engine、Resource Manager、Service Networking の各 API を有効にします。

    API を有効にするために必要なロール

    API を有効にするには、serviceusage.services.enable 権限が必要です。プロジェクトを作成した場合は、オーナーロール（roles/owner）を介してこの権限がすでに付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール（roles/serviceusage.serviceUsageAdmin）を介してこの権限を取得できます。ロールを付与する方法をご覧ください。

    API を有効にする

  4. Google Cloud コンソールで Cloud Shell をアクティブにします。

    Cloud Shell をアクティブにする

    Google Cloud コンソールの下部にある Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

環境を準備する

このセクションでは、アプリケーション オペレーターとして、次の処理を行います。

  • 必要な権限を設定する。
  • ステージング環境と本番環境用の GKE クラスタを作成する。
  • ソース リポジトリのクローンを作成する。
  • ソースコード用のリポジトリを Cloud Source Repositories に作成する。
  • コンテナ アプリケーション用のリポジトリを Artifact Registry に作成する。

権限を設定する

このセクションでは、CI / CD パイプラインの設定に必要な権限を付与します。

  1. Cloud Shell エディタの新しいインスタンスで作業している場合は、このデプロイガイドに使用するプロジェクトを指定します。

    gcloud config set project PROJECT_ID

    PROJECT_ID は、このデプロイガイドで選択または作成したプロジェクトの ID に置き換えます。

    ダイアログが表示された場合は、[承認] をクリックします。

  2. デフォルトの Compute Engine サービス アカウントに、Cloud Deploy でジョブを実行して Artifact Registry からコンテナを pull できる十分な権限が付与されていることを確認します。Cloud Build と Cloud Deploy は、このデフォルトのサービス アカウントを使用します。

    このサービス アカウントにはすでに必要な権限が付与されている場合があります。 このステップにより、プロジェクトに必要な権限が付与され、デフォルトのサービス アカウントに対するロールの自動付与が無効化されます。

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/clouddeploy.jobRunner"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/artifactregistry.reader"

  3. Cloud Deploy を使用してデプロイを呼び出し、配信パイプラインとターゲットの定義を更新するための Cloud Build サービス アカウント権限を付与します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
    --role="roles/clouddeploy.operator"

    この IAM ロールの詳細については、clouddeploy.operator ロールをご覧ください。

  4. Cloud Build と Cloud Deploy のサービス アカウント権限を付与して GKE にデプロイします。

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/container.admin"

    この IAM ロールの詳細については、container.admin role のロールをご覧ください。

  5. Cloud Deploy オペレーションの呼び出しに必要な権限を Cloud Build サービス アカウントに付与します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
    --role="roles/iam.serviceAccountUser"

    Cloud Build が Cloud Deploy を呼び出すと、Compute Engine サービス アカウントを使用してリリースが作成されます。そのためにこの権限が必要です。

    この IAM ロールの詳細については、iam.serviceAccountUser role のロールをご覧ください。

これで、CI / CD パイプラインに必要な権限が付与されました。

GKE クラスタを作成する

このセクションでは、ステージング環境と本番環境（どちらも GKE クラスタ）を作成します（minikube を使用するため、ここで開発クラスタの設定を行う必要はありません）。

  1. ステージング環境と本番環境用の GKE クラスタを作成します。

    gcloud container clusters create-auto staging \
    --region us-central1 \
    --project=$(gcloud config get-value project) \
    --async

gcloud container clusters create-auto prod \
    --region us-central1 \
    --project=$(gcloud config get-value project) \
    --async

    ステージング クラスタでは、コードの変更をテストします。ステージング環境のデプロイがアプリケーションに悪影響を及ぼしていないことを確認したら、本番環境にデプロイします。

  2. 次のコマンドを実行して、ステージング環境のクラスタと本番環境クラスタの両方の出力が STATUS: RUNNING であることを確認します。

    gcloud container clusters list

  3. ステージング環境のクラスタと本番環境クラスタの kubeconfig ファイルの認証情報を取得します。

    gcloud container clusters get-credentials staging --region us-central1

gcloud container clusters get-credentials prod --region us-central1

    これらの認証情報を使用して GKE クラスタと情報を交換します。たとえば、アプリケーションが正しく実行されていることを確認します。

ステージング環境と本番環境の GKE クラスタが作成されました。

IDE を開いてリポジトリのクローンを作成する

リポジトリのクローンを作成して、開発環境でアプリケーションを表示するには、次の操作を行います。

  1. Cloud Shell に GitHub リポジトリのクローンを作成します。

    Cloud Shell で開く

  2. [確認] をクリックします。

    Cloud Shell エディタが開き、サンプル リポジトリのクローンが作成されます。

    Cloud Shell エディタでアプリケーションのコードを表示できるようになりました。

  3. このデプロイガイドに使用するプロジェクトを指定します。

    gcloud config set project PROJECT_ID

    ダイアログが表示された場合は、[承認] をクリックします。

これで、開発環境にアプリケーションのソースコードを用意できました。

このソース リポジトリには、CI / CD パイプラインに必要な Cloud Build ファイルと Cloud Deploy ファイルが含まれています。

ソースコード用のリポジトリとコンテナ用のリポジトリを作成する

このセクションでは、ソースコード用のリポジトリを Cloud Source Repositories に設定し、CI / CD パイプラインによってビルドされたコンテナを格納する Artifact Registry にリポジトリを設定します。

  1. Cloud Source Repositories で、ソースコードを格納するリポジトリを作成し、CI / CD プロセスにリンクします。

    gcloud source repos create cicd-sample

  2. Cloud Deploy 構成のターゲットが適切なプロジェクトであることを確認します。

    sed -i s/project-id-placeholder/$(gcloud config get-value project)/g deploy/*
git config --global credential.https://source.developers.google.com.helper gcloud.sh
git remote add google https://source.developers.google.com/p/$(gcloud config get-value project)/r/cicd-sample

  3. ソースコードをリポジトリに push します。

    git push --all google

  4. Artifact Registry にイメージ リポジトリを作成します。

    gcloud artifacts repositories create cicd-sample-repo \
    --repository-format=Docker \
    --location us-central1

これで、Cloud Source Repositories にソースコードのリポジトリが作成され、Artifact Registry にアプリケーション コンテナのリポジトリが作成されました。Cloud Source Repositories リポジトリを使用すると、ソースコードのクローンを作成して CI / CD パイプラインに接続できます。

CI / CD パイプラインを構成する

このセクションでは、アプリケーション オペレーターとして CI / CD パイプラインを構成します。パイプラインでは、CI には Cloud Build を、CD には Cloud Deploy を使用します。パイプラインの手順は、Cloud Build トリガーで定義されます。

  1. Cloud Build 用の Cloud Storage バケットを作成して artifacts.json ファイル（Skaffold によってビルドごとに生成されたアーティファクトを追跡）を保存します。

    gcloud storage buckets create gs://$(gcloud config get-value project)-gceme-artifacts/

    各ビルドの artifacts.json ファイルを一元管理できる場所に保存することをおすすめします。これにより、トレーサビリティが保たれ、トラブルシューティングが容易になります。

  2. cloudbuild.yaml ファイルを確認します。これは Cloud Build トリガーを定義し、クローン作成したソース リポジトリですでに構成されています。

    このファイルで、ソースコード リポジトリのメインブランチに対して新しい push が行われるたびに呼び出されるトリガーが定義されます。

    CI / CD パイプラインの次の手順は、cloudbuild.yaml ファイルで定義されています。

    • Cloud Build は、Skaffold を使用してアプリケーション コンテナをビルドします。

    • Cloud Build は、ビルドの artifacts.json ファイルを Cloud Storage バケットに配置します。

    • Cloud Build は、アプリケーション コンテナを Artifact Registry に配置します。

    • Cloud Build がアプリケーション コンテナでテストを実行します。

    • gcloud deploy apply コマンドは、Cloud Deploy サービスに次のファイルを登録します。

      • 配信パイプラインである deploy/pipeline.yaml
      • deploy/staging.yaml、deploy/prod.yaml（ターゲット ファイル）

      ファイルが登録されると、パイプラインとターゲットがまだ存在しない場合は Cloud Deploy によって作成されます。また、構成が変更された場合は、ファイルが再作成されます。ターゲットは、ステージング環境と本番環境です。

    • Cloud Deploy が、デリバリー パイプライン用の新しいリリースを作成します。

      このリリースでは、CI プロセスでビルドとテストが行われたアプリケーション コンテナが参照されています。

    • Cloud Deploy により、リリースがステージング環境にデプロイされます。

    デリバリー パイプラインとターゲットは Cloud Deploy によって管理され、ソースコードから分離されています。この分離により、アプリケーションのソースコードが変更されたときに、デリバリー パイプラインとターゲット ファイルを更新する必要がなくなります。

  3. Cloud Build トリガーを作成します。

    gcloud beta builds triggers create cloud-source-repositories \
    --name="cicd-sample-main" \
    --repo="cicd-sample" \
    --branch-pattern="main" \
    --build-config="cloudbuild.yaml"

    このトリガーは、ソース リポジトリを監視し、cloudbuild.yaml ファイルを使用してリポジトリの変更に対応するように Cloud Build に指示します。このトリガーは、メインブランチに新しい push が行われるたびに呼び出されます。

  4. Google Cloud コンソールの [Cloud Build] ページに移動します。

    Cloud Build に移動

    アプリのビルドがないことを確認します。

これで CI パイプラインと CD パイプラインが設定され、リポジトリのメインブランチでトリガーが作成されました。

デベロッパー ワークスペース内でアプリケーションを変更する

このセクションでは、アプリケーション デベロッパーとして操作します。

アプリケーションを開発する際には、開発ワークスペースとして Cloud Code を使用し、アプリケーションの変更と検証を繰り返します。

  • アプリケーションに変更を加えます。
  • 新しいコードを構築してテストします。
  • アプリケーションを minikube クラスタにデプロイし、ユーザー向けの変更を検証します。
  • メイン リポジトリに変更を送信します。

この変更がメイン リポジトリに commit されると、Cloud Build トリガーが CI / CD パイプラインを開始します。

アプリケーションを構築し、テストして実行する

このセクションでは、アプリケーションを構築、テスト、デプロイしてアクセスします。

前のセクションで使用したのと同じ Cloud Shell エディタのインスタンスを使用します。エディタを閉じた場合は、ブラウザで ide.cloud.google.com に移動して Cloud Shell エディタを開きます。

  1. ターミナルで minikube を起動します。

    minikube start

    minikube は Cloud Shell でローカル Kubernetes クラスタを設定します。この設定が完了するまでに数分かかります。完了すると、minikube プロセスは Cloud Shell インスタンスのバックグラウンドで実行されます。

  2. Cloud Shell エディタの下部にあるペインで、[Cloud Code] を選択します。

  3. ターミナルとエディタの間に表示されるシンパネルで、[Kubernetes で実行] を選択します。

    「Use current context (minikube) to run the app?」というメッセージが表示されたら、[はい] をクリックします。

    このコマンドは、ソースコードをビルドし、テストを実行します。この処理には数分かかることがあります。テストには、単体テストと、デプロイ環境に設定されたルールをチェックする構成済みの検証ステップが含まれています。これにより、開発環境で作業している場合でも、デプロイの問題に関して警告が表示されます。

    アプリケーションのビルドとデプロイの際、[出力] タブに Skaffold の進捗状況が表示されます。

    このセクションの最後まで、このタブは開いたままにします。

    ビルドとテストが完了すると、[出力] タブに Update succeeded と 2 つの URL が表示されます。

    アプリを構築してテストする際、Cloud Code は [出力] タブにログと URL をストリーミングで返します。開発環境で変更を加えてテストを実行するときに、開発環境のアプリのバージョンが表示され、正しく動作していることを確認できます。

    また、出力には Watching for changes... と表示され、これはウォッチモードが有効になっていることを表しています。Cloud Code がウォッチモードになっている間、サービスはリポジトリに保存された変更を検出し、最新の変更を反映してアプリを自動的に再ビルドして再デプロイします。

  4. Cloud Code ターミナルで、出力された最初の URL（http://localhost:8080）にポインタを合わせます。

  5. 表示されたツールチップで、[Open Web Preview] を選択します。

    Cloud Code は、バックグラウンドの minikube で実行されている cicd-sample サービスにトラフィックを自動的にポート転送します。

  6. ブラウザでページを更新します。

    [カウンタ] の横にある数字が増加し、アプリが更新に応答していることを示します。

    ローカル環境で変更を加える際にアプリケーションを表示できるように、ブラウザでこのページを開いたままにします。

これで、開発環境でのアプリケーションのビルドとテストが完了しました。アプリケーションを minikube で実行している開発クラスタにデプロイし、アプリケーションのユーザー向けの動作を確認しました。

変更する

このセクションでは、アプリケーションに変更を加えて、開発クラスタでのアプリの実行に合わせて変更を表示します。

  1. Cloud Shell エディタで index.html ファイルを開きます。

  2. 文字列 Sample App Info を検索し、タイトルで小文字が使用されるように sample app info に変更します。

    ファイルが自動的に保存され、アプリケーション コンテナの再構築がトリガーされます。

    Cloud Code が変更を検出して自動的に再デプロイします。[出力] タブに Update initiated が表示されます。この再デプロイが完了するまでに数分かかります。

    この自動再デプロイ機能は、Kubernetes クラスタで実行されている任意のアプリケーションで使用できます。

  3. ビルドが完了したら、アプリを開いているブラウザに移動してページを更新します。

    更新すると、テキストが小文字を使用していることがわかります。

この設定により、どのようなアーキテクチャのどのコンポーネントでも、自動的に再読み込みが行われます。Cloud Code と minikube を使用すると、Kubernetes で実行されているものすべてに、このホットコード リロード機能が備わっています。

Kubernetes クラスタにデプロイされたアプリケーションは、Cloud Code でデバッグできます。この手順は、このデプロイガイドでは説明されていませんが、詳細については Kubernetes アプリケーションのデバッグをご覧ください。

コードを commit する

アプリケーションに変更を加えたため、コードを commit できます。

  1. Git ID を構成します。

    git config --global user.email "YOU@EXAMPLE.COM"
git config --global user.name "NAME"

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

    • YOU@EXAMPLE.COM: GitHub アカウントに接続されているメールアドレス。
    • NAME: GitHub アカウントに接続されている名前。

  2. ターミナルからコードを commit します。

    git add .
git commit -m "use lowercase for: sample app info"

    ここでは、git push コマンドを実行する必要はありません。これは後で行います。

開発環境での作業で、アプリケーションを変更して変更をビルドしてテストし、これらの変更のユーザー向けの動作を確認しました。開発環境のテストにはガバナンス チェックが含まれています。これにより、本番環境での問題を引き起こす問題を解決できます。

このデプロイガイドでは、メイン リポジトリにコードを commit するときにはコードレビューを行いません。ただし、ソフトウェア開発で推奨されるプロセスは、コードレビューまたは変更承認です。

変更承認のベスト プラクティスについて詳しくは、変更承認の効率化をご覧ください。

本番環境に変更をデプロイする

このセクションでは、アプリケーション オペレーターとして、次の処理を行います。

  • リリースをステージング環境にデプロイする CI / CD パイプラインをトリガーします。
  • 本番環境へリリースを昇格させて承認します。

CI / CD パイプラインを開始してステージング環境にデプロイする

このセクションでは、Cloud Build トリガーを呼び出して CI / CD パイプラインを開始します。このトリガーは、メイン リポジトリに変更が commit されるたびに呼び出されます。手動トリガーで CI システムを開始することもできます。

  1. Cloud Shell エディタで、次のコマンドを実行してビルドをトリガーします。

    git push google

    このビルドには、cicd-sample に加えた変更が含まれています。

  2. Cloud Build ダッシュボードに戻り、ビルドが作成されたことを確認します。

  3. 右側のビルドログで [Running: cicd-sample - cicd-sample-main] をクリックし、各ステップの開始と終了を示す青色のテキストを探します。

    ステップ 0 は、cloudbuild.yaml ファイルからの skaffold build 手順と skaffold test 手順の出力を示します。ステップ 0（パイプラインの CI 部分）のビルドタスクとテストタスクに合格したため、ステップ 1（パイプラインの CD 部分）のデプロイタスクが実行されるようになりました。

    このステップが終了すると、次のメッセージが表示されます。

    Created Cloud Deploy rollout ROLLOUT_NAME in target staging

  4. Cloud Deploy デリバリー パイプラインのページを開き、cicd-sample delivery パイプラインをクリックします。

    アプリケーションはステージング環境にデプロイされますが、本番環境にはデプロイされません。

  5. アプリケーションがステージング環境で正常に動作していることを確認します。

    kubectl proxy --port 8001 --context gke_$(gcloud config get-value project)_us-central1_staging

    このコマンドにより、アプリケーションにアクセスするための kubectl プロキシが設定されます。

  6. Cloud Shell からアプリケーションにアクセスします。

    1. Cloud Shell エディタで、新しいターミナルタブを開きます。

    2. リクエストを localhost に送信して、カウンタをインクリメントします。

      curl -s http://localhost:8001/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter

      このコマンドは複数回実行でき、毎回カウンタ値が増分するのを確認できます。

      アプリを表示すると、変更したテキストが、ステージングにデプロイしたアプリケーションのバージョンにあることがわかります。

    3. この 2 つ目のタブを閉じます。

    4. 最初のタブで Control+C を押して、プロキシを停止します。

これで、Cloud Build トリガーを呼び出して CI プロセスを開始できました。これには、アプリケーションのビルド、ステージング環境へのデプロイ、ステージング環境でのアプリケーションの動作検証のテスト実行が含まれます。

コードのビルドとテストがステージング環境で合格すると、CI プロセスは成功します。CI プロセスが成功すると、Cloud Deploy で CD システムが開始されます。

リリースを本番環境に昇格させる

このセクションでは、ステージング環境から本番環境にリリースを昇格させます。本番環境ターゲットは承認を必要とするように事前構成されているため、手動で承認します。

独自の CI / CD パイプラインの場合は、本番環境への完全なデプロイを行う前に、デプロイを段階的に実行するデプロイ戦略を使用することをおすすめします。デプロイを段階的に実行すると、問題を簡単に検出でき、必要に応じて以前のリリースを復元できます。

リリースを本番環境に昇格させる方法は次のとおりです。

  1. Cloud Deploy デリバリー パイプラインの概要を開き、[cicd-sample] パイプラインを選択します。

  2. ステージング環境から本番環境にデプロイを昇格します。手順は次のとおりです。

    1. ページの上部にあるパイプライン図で、ステージング ボックスの青色の [昇格] ボタンをクリックします。

    2. 表示されたウィンドウで、下部にある [昇格] ボタンをクリックします。

    デプロイがまだ本番環境で実行されていません。必要な手動承認を待っている状態です。

  3. デプロイを手動で承認します。

    1. パイプラインの可視化で、ステージング ボックスと本番環境ボックスの間の [レビュー] ボタンをクリックします。

    2. 表示されたウィンドウで [レビュー] ボタンをクリックします。

    3. 次のウィンドウで [承認] をクリックします。

    4. Cloud Deploy デリバリー パイプラインの概要に戻り、[cicd-sample] パイプラインを選択します。

  4. パイプラインの可視化で prod ボックスが緑色で表示されたら（ロールアウトが成功したことを意味する）、アプリケーションへのアクセスに使用する kubectl プロキシを設定して、アプリケーションが本番環境で動作することを確認します。

    kubectl proxy --port 8002 --context gke_$(gcloud config get-value project)_us-central1_prod

  5. Cloud Shell からアプリケーションにアクセスします。

    1. Cloud Shell エディタで、新しいターミナルタブを開きます。

    2. カウンタを増分します。

      curl -s http://localhost:8002/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter

      このコマンドは複数回実行でき、毎回カウンタ値が増分するのを確認できます。

    3. この 2 つ目のターミナルタブを閉じます。

    4. 最初のタブで Control+C を押して、プロキシを停止します。

これで昇格して、本番環境へのデプロイが承認されました。最近変更したアプリケーションは、本番環境で動作するようになりました。

クリーンアップ

このデプロイガイドで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを保持して個別のリソースを削除します。

オプション 1: プロジェクトを削除する

  1. Google Cloud コンソールで [リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

オプション 2: 個別のリソースを削除する

  1. Cloud Deploy パイプラインを削除します。

    gcloud deploy delivery-pipelines delete cicd-sample --region=us-central1 --force

  2. Cloud Build トリガーを削除します。

    gcloud beta builds triggers delete cicd-sample-main

  3. ステージング クラスタと本番環境クラスタを削除します。

    gcloud container clusters delete staging

gcloud container clusters delete prod

  4. Cloud Source Repositories でリポジトリを削除します。

    gcloud source repos delete cicd-sample

  5. Cloud Storage バケットを削除します。

    gcloud storage rm -r gs://$(gcloud config get-value project)-gceme-artifacts/

gcloud storage rm -r gs://$(gcloud config get-value project)_clouddeploy/

  6. Artifact Registry でリポジトリを削除します。

    gcloud artifacts repositories delete cicd-sample-repo \
    --location us-central1

次のステップ