GKE による最新の CI / CD: CI / CD システムを構築する

このリファレンス アーキテクチャでは、Google Kubernetes Engine、Cloud Build、Skaffold、kustomize、Config Sync、Policy Controller、Artifact Registry、Cloud Deploy などのツールを使用して、最新の継続的インテグレーション / 継続的デリバリー（CI / CD）システムをビルドするためのメソッドと初期インフラストラクチャを提供します。

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

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

CI / CD ワークフロー

最新の CI / CD システムをビルドするには、まずシステムの主要機能を実行するツールやサービスを選択する必要があります。このリファレンス アーキテクチャは、次の図に示す CI / CD システムのコア機能の実装に重点を置いています。

さまざまなチームが CI / CD システムを管理、または CI / CD システムに対する責任を共有しています。

このリファレンス実装では、コンポーネントごとに以下のツールを使用します。

  • ソースコード管理: GitHub
    • アプリケーションと構成コードを保存します。
    • 変更を確認できます。
  • アプリケーション構成管理: kustomize
    • アプリケーションに必要な構成を定義します。
    • 構成プリミティブまたはブループリントを再利用して拡張できます。
  • 継続的インテグレーション: Cloud Build
    • ソースコードをテストして検証します。
    • デプロイ環境が使用するアーティファクトをビルドします。
  • 継続的デリバリー: Cloud Deploy
    • 環境間でのコードのロールアウト プロセスを定義します。
    • 失敗した変更のロールバックを提供します。
  • インフラストラクチャ構成: Config Sync
    • クラスタとポリシーの構成を一貫して適用します。
  • ポリシーの適用: Policy Controller
    • 組織のポリシーに基づいて、特定の環境での実行が許可されている内容の定義に使用できるメカニズムを提供します。
  • コンテナ オーケストレーション: Google Kubernetes Engine
    • CI 中にビルドされたアーティファクトを実行します。
    • ワークロードのスケーリング、ヘルスチェック、ロールアウトの方法を指定します。
  • コンテナ アーティファクト: Artifact Registry
    • CI 中にビルドされたアーティファクト（コンテナ イメージ）を保存します。

アーキテクチャ

このセクションでは、このリファレンス アーキテクチャ（インフラストラクチャ、パイプライン、コード リポジトリ、ランディング ゾーン）を使用して実装する CI / CD コンポーネントについて説明します。

CI / CD システムのこうした全般的な説明については、GKE を使用した最新の CI / CD: ソフトウェア デリバリー フレームワークをご覧ください。

リファレンス アーキテクチャのバリアント

リファレンス アーキテクチャには、次の 2 つのデプロイモデルがあります。

  • 分離境界を改善し、本番環境デプロイにより近いマルチプロジェクト バリアント
  • デモンストレーションに便利な単一プロジェクトのバリアント

マルチプロジェクトのリファレンス アーキテクチャ

リファレンス アーキテクチャの multi-project バージョンは、本番環境と同様のシナリオをシミュレートします。これらのシナリオでは、さまざまなペルソナが適切な分離境界を使用してインフラストラクチャ、CI / CD パイプライン、アプリケーションを作成します。これらのペルソナまたはチームは、必要なリソースにのみアクセスできます。

詳細については、GKE による最新の CI / CD: ソフトウェア デリバリー フレームワークをご覧ください。

このバージョンのリファレンス アーキテクチャをインストールして適用する方法については、ソフトウェア デリバリー ブループリントをご覧ください。

単一プロジェクトのリファレンス アーキテクチャ

リファレンス アーキテクチャの single-project バージョンは、単一の Google Cloud プロジェクトでソフトウェア デリバリー プラットフォーム全体を設定する方法を示しています。このバージョンは、昇格した IAM ロールを持たないユーザーがプロジェクトのオーナーロールだけでリファレンス アーキテクチャをインストールして試す際に役立ちます。このドキュメントでは、単一プロジェクト バージョンのリファレンス アーキテクチャについて説明します。

プラットフォーム インフラストラクチャ

このリファレンス アーキテクチャのインフラストラクチャは、開発、ステージング、本番のアプリケーション環境をサポートする Kubernetes クラスタで構成されています。次の図は、クラスタの論理レイアウトを示しています。

さまざまなプラットフォーム ワークロードをサポートするクラスタ レイアウト。

コード リポジトリ

このリファレンス アーキテクチャを使用して、オペレーター、デベロッパー、プラットフォーム、セキュリティ エンジニアのリポジトリを設定します。

次の図は、さまざまなコード リポジトリのリファレンス アーキテクチャの実装と、運用チーム、開発チーム、セキュリティ チームが相互にリポジトリを操作する方法を示しています。

ベスト プラクティスや、アプリケーションとプラットフォームの構成に関するものを含むリポジトリ。

このワークフローでは、オペレーターは、オペレーターのリポジトリ内で CI / CD とアプリケーション構成のベスト プラクティスを管理できます。デベロッパーが開発リポジトリでアプリケーションをオンボーディングできるようになると、アプリケーションのベスト プラクティス、ビジネス ロジック、アプリケーションを正常に動作させるために必要な特別な構成が自動的に取得されます。一方、運用チームとセキュリティ チームは構成とポリシー リポジトリでプラットフォームの整合性とセキュリティを管理できます。

アプリケーションのランディング ゾーン

このリファレンス アーキテクチャでは、アプリケーションのプロビジョニング時にアプリケーションのランディング ゾーンが作成されます。このシリーズの次のドキュメント、GKE による最新の CI / CD: デベロッパー ワークフローを適用するでは、独自のランディング ゾーンを作成する新しいアプリケーションをプロビジョニングします。次の図は、このリファレンス アーキテクチャで使用されているランディング ゾーンの重要なコンポーネントを示しています。

GKE クラスタには、アプリケーションごとに異なる Namespace が 3 つあります。

各 Namespace には、GKE 用 Workload Identity 連携が Kubernetes コンテナの外部のサービス（Cloud Storage や Spanner など）にアクセスするために使用するサービス アカウントが含まれています。Namespace には、他の Namespace やアプリケーションと境界を分離または共有するためのネットワーク ポリシーなどの他のリソースも含まれます。

Namespace は CD 実行サービス アカウントによって作成されます。CD 実行サービス アカウントが必要な Namespace にのみアクセスできるように、最小権限の原則に従うことをおすすめします。

サービス アカウント アクセスは Config Sync で定義し、Kubernetes のロールベースのアクセス制御（RBAC）のロールとロール バインディングを使用して実装できます。このモデルを設定すると、チームは管理する Namespace に任意のリソースを直接デプロイできますが、他の Namespace のリソースの上書きと削除はできません。

目標

  • 単一プロジェクトのリファレンス アーキテクチャをデプロイする。
  • コード リポジトリを確認する。
  • パイプラインとインフラストラクチャを確認する。

費用

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

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

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

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

始める前に

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    リファレンス アーキテクチャをデプロイする

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

      gcloud config set core/project PROJECT_ID

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

    2. Cloud Shell で Git リポジトリのクローンを作成します。

      git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
cd software-delivery-blueprint/launch-scripts
git checkout single-project-blueprint

    3. GitHub で、次のスコープを使用して個人用のアクセス トークンを作成します。

      • repo
      • delete_repo
      • admin:org
      • admin:repo_hook

    4. software-delivery-bluprint/launch-scripts フォルダの下に vars.sh という名前の空のファイルがあります。このファイルに次の内容を追加します。

      cat << EOF >vars.sh
export INFRA_SETUP_REPO="gke-infrastructure-repo"
export APP_SETUP_REPO="application-factory-repo"
export GITHUB_USER=GITHUB_USER
export TOKEN=TOKEN
export GITHUB_ORG=GITHUB_ORG
export REGION="us-central1"
export SEC_REGION="us-west1"
export TRIGGER_TYPE="webhook"
EOF

      GITHUB_USER は、GitHub ユーザー名に置き換えます。

      TOKEN は、GitHub の個人用のアクセス トークンに置き換えます。

      GITHUB_ORG は、GitHub 組織の名前に置き換えます。

    5. bootstrap.sh スクリプトを実行します。Cloud Shell で承認を求められたら、[承認] をクリックします。

      ./bootstrap.sh

      このスクリプトは、ソフトウェア デリバリー プラットフォームをブートストラップします。

    コード リポジトリを確認する

    このセクションでは、コード リポジトリについて確認します。

    GitHub にログインする

    1. ウェブブラウザで github.com にアクセスし、アカウントにログインします。
    2. インターフェースの上部にある写真のアイコンをクリックします。
    3. [Your organizations] をクリックします。
    4. vars.sh ファイルに入力として指定した組織を選択します。
    5. [Repositories] タブをクリックします。

    スターター、オペレーター、構成、インフラストラクチャのリポジトリを確認する

    スターター リポジトリ、オペレーター リポジトリ、構成リポジトリ、インフラストラクチャ リポジトリでは、オペレーターとプラットフォーム管理者がプラットフォーム上でのビルドと運用に関する共通のベスト プラクティスを定義します。これらのリポジトリは、リファレンス アーキテクチャがブートストラップされるときに、GitHub 組織の下に作成されます。

    リスト内の各リポジトリには簡単な説明が含まれています。

    スターター リポジトリ

    スターター リポジトリは、CI / CD の導入、インフラストラクチャ、プラットフォーム全体の開発のベスト プラクティスを支援します。詳細については、GKE による最新の CI / CD: ソフトウェア デリバリー フレームワークをご覧ください。

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

    アプリケーション スターター リポジトリでは、オペレーターがアプリケーションの CI / CD、指標の収集、ロギング、コンテナ ステップ、セキュリティなどのベスト プラクティスを体系化して文書化できます。リファレンス アーキテクチャに含まれているのは、Go、Python、Java のアプリケーションのスターター リポジトリの例です。

    app-template-python、app-template-java、app-template-golang のアプリケーション スターター リポジトリには、新しいアプリケーションの作成に使用できるボイラープレート コードが含まれています。新しいアプリケーションの作成に加えて、アプリケーションの要件に基づいて新しいテンプレートを作成できます。リファレンス アーキテクチャで提供されているアプリケーション スターター リポジトリには次のものが含まれます。

    • kustomize ベースとフォルダ k8s にあるパッチ。

    • アプリケーションのソースコード。

    • アプリケーションのビルドと実行の方法を示す Dockerfile

    • CI ステップのベスト プラクティスが記述された cloudbuild.yaml ファイル。

    • デプロイ手順が記述された skaffold.yaml ファイル。

    このシリーズの次のドキュメント、GKE による最新の CI / CD: デベロッパー ワークフローを適用するでは、app-template-python リポジトリを使用して新しいアプリケーションを作成します。

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

    インフラストラクチャ スターター リポジトリでは、オペレーターとインフラストラクチャ管理者が、CI / CD パイプライン、IaC、指標の収集、ロギング、インフラストラクチャのセキュリティなどのベスト プラクティスを体系化して文書化できます。リファレンス アーキテクチャには、Terraform を使用したインフラストラクチャ スターター リポジトリの例が含まれています。infra-template インフラストラクチャ スターター リポジトリには、Terraform 用のボイラープレート コードが含まれています。これにより、アプリケーションに必要なインフラストラクチャ リソース（Cloud Storage バケット、Spanner データベースなど）を作成できます。

    共有テンプレートのリポジトリ

    共有テンプレート リポジトリでは、インフラストラクチャ管理者とオペレーターがタスクを実行するための標準テンプレートを提供します。リファレンス アーキテクチャが用意されている terraform-modules という名前のリポジトリがあります。リポジトリには、さまざまなインフラストラクチャ リソースを作成するためにテンプレート化された Terraform コードが含まれています。

    オペレーター リポジトリ

    リファレンス アーキテクチャでは、オペレーター リポジトリはアプリケーション スターター リポジトリと同じです。オペレーターは、アプリケーション スターター リポジトリで CI と CD の両方に必要なファイルを管理します。リファレンス アーキテクチャには、app-template-python、app-template-java、app-template-golang リポジトリが含まれています。

    • これらはスターター テンプレートであり、プラットフォーム上の Kubernetes で実行されるアプリケーションのベース Kubernetes マニフェストが含まれています。オペレーターは必要に応じてスターター テンプレートのマニフェストを更新できます。更新は、アプリケーションの作成時に取得されます。
    • これらのリポジトリの cloudbuild.yaml ファイルと skaffold.yaml ファイルには、プラットフォームで CI と CD を実行するためのベスト プラクティスがそれぞれ保存されています。アプリケーション構成と同様に、オペレーターはベスト プラクティスを更新して手順を追加できます。個々のアプリケーション パイプラインは、最新のステップを使用して作成されます。

    このリファレンス実装では、オペレーターは kustomize を使用して、スターター リポジトリの k8s フォルダの基本構成を管理します。デベロッパーは、リソース名や構成ファイルなどのアプリケーション固有の変更を行い、マニフェストを自由に拡張できます。kustomize ツールは、データとして構成をサポートしています。この方法では、kustomize 入出力が Kubernetes リソースとなります。マニフェストの任意の変更の出力を使用して、別の変更を行うことができます。

    次の図は、Spring Boot アプリケーションの基本構成を示しています。

    アプリケーション構成は、別々のチームで管理されている複数のリポジトリで行われます。

    kustomize のデータモデルとしての構成には大きなメリットがあります。オペレーターが基本構成を更新すると、更新は次の実行時にデベロッパーのデプロイ パイプラインによって自動的に使用され、デベロッパー側で変更を行う必要がありません。

    kustomize を使用して Kubernetes マニフェストを管理する方法の詳細については、kustomize のドキュメントをご覧ください。

    構成リポジトリとポリシー リポジトリ

    リファレンス アーキテクチャには、Config Sync と Policy Controller を使用する構成とポリシー リポジトリの実装が含まれています。acm-gke-infrastructure-repo リポジトリには、アプリケーション環境クラスタにデプロイする構成とポリシーが含まれています。これらのリポジトリでプラットフォーム管理者が定義して保存する構成は、そのプラットフォームが運用チームと開発チーム向けに一貫した外観を持つようにすることが重要です。

    以降のセクションでは、リファレンス アーキテクチャによる構成リポジトリとポリシー リポジトリの実装方法について詳しく説明します。

    構成

    このリファレンス実装では、Config Sync を使用してプラットフォーム内のクラスタ構成を一元管理し、ポリシーを適用します。一元管理をすることで、システム全体に構成変更を反映できるようになります。

    Config Sync を使用すると、組織はクラスタを登録して、Git リポジトリ（GitOps と呼ばれるプロセス）から構成を同期できます。新しいクラスタを追加すると、クラスタは自動的に最新の構成と同期し、帯域外での変更が加えられた場合に備えて、クラスタの状態と構成を継続的に調整します。

    Config Sync の詳細については、ドキュメントをご覧ください。

    ポリシー

    このリファレンス実装では、Open Policy Agent に基づく Policy Controller を使用して、プラットフォーム内の Kubernetes クラスタに対するリクエストをインターセプトして検証します。Rego ポリシー言語を使用してポリシーを作成できます。これにより、クラスタに送信されるリソースのタイプに加えて、その構成も完全に制御できます。

    次の図のアーキテクチャは、Policy Controller を使用してリソースを作成するリクエスト フローを示しています。

    まずポリシールールが定義され、kubectl や API クライアントなどのさまざまなツールを使用して適用されます。

    Config Sync リポジトリでルールを作成して定義すれば、その変更がクラスタに適用されます。その後、CLI または API クライアントからの新しいリソース リクエストが、Policy Controller によって制約に照らして検証されます。

    ポリシーの管理の詳細については、Policy Controller の概要をご覧ください。

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

    リファレンスには、Terraform を使用したインフラストラクチャ リポジトリの実装が含まれています。gke-infrastructure-repo リポジトリには、開発環境、ステージング環境、本番環境用の GKE クラスタを作成し、acm-gke-infrastructure-repo リポジトリを使用して Config Sync を構成するための Infrastructure as Code が含まれています。gke-infrastructure-repo には、開発環境、ステージング環境、本番環境ごとに 1 つずつ、合計で 3 つのブランチがあります。また、各ブランチには dev、staging、production フォルダがあります。

    パイプラインとインフラストラクチャを確認する

    このリファレンス アーキテクチャでは、 Google Cloud プロジェクトにパイプラインを作成します。このパイプラインは、共有インフラストラクチャの作成を担当します。

    パイプライン

    このセクションでは、Infrastructure-as-Code パイプラインを確認し、それを実行して GKE クラスタを含む共有インフラストラクチャを作成します。パイプラインは、 Google Cloud プロジェクトの create-infra という名前の Cloud Build トリガーで、インフラストラクチャ リポジトリ gke-infrastructure-repo にリンクされています。Cloud Build Infra-As-Code パイプラインによる再現可能な大規模な GCP 環境の動画で説明されているように、GitOps の手法を使用してインフラストラクチャを作成します。

    gke-infrastructure-repo には、dev、staging、production の各ブランチがあります。リポジトリには、これらのブランチに対応する dev、staging、production の各フォルダもあります。リポジトリにはブランチ保護ルールがあり、コードを開発ブランチにのみ push できます。コードを staging ブランチと production ブランチに push するには、pull リクエストを作成する必要があります。

    通常、リポジトリにアクセスできるユーザーが変更を確認し、pull リクエストをマージして、意図した変更のみが上位ブランチに昇格されるようにします。個人がブループリントを試せるように、リファレンス アーキテクチャでブランチ保護ルールが緩和されたため、リポジトリ管理者はレビューをバイパスして pull リクエストをマージできます。

    gke-infrastructure-repo に対して push が行われると、create-infra トリガーが呼び出されます。そのトリガーは、push が発生したブランチを識別し、そのブランチのリポジトリ内の対応するフォルダに移動します。対応するフォルダが見つかると、そのフォルダ内のファイルを使用して Terraform が実行されます。たとえば、コードが dev ブランチに push されると、トリガーによって dev ブランチの dev フォルダで Terraform が実行され、dev GKE クラスタが作成されます。同様に、staging ブランチに push が発生すると、トリガーによって staging ブランチの staging フォルダで Terraform が実行され、staging GKE クラスタが作成されます。

    パイプラインを実行して GKE クラスタを作成します。

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

      [Cloud Build] ページに移動する

      • 5 つの Cloud Build Webhook トリガーがあります。create-infra という名前のトリガーを探します。このトリガーは、GKE クラスタを含む共有インフラストラクチャを作成します。

    2. トリガー名をクリックします。トリガーの定義が開きます。

    3. [エディタを開く] をクリックして、トリガーが実行するステップ手順を表示します。

      他のトリガーは、GKE による最新の CI / CD: デベロッパー ワークフローの適用でアプリケーションをオンボーディングする際に使用されます。

      Cloud Build トリガー。

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

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

      履歴ページでパイプラインを確認します。bootstrap.sh を使用してソフトウェア デリバリー プラットフォームをデプロイしたときに、スクリプトは、このパイプラインを開始する gke-infrastructure-repo リポジトリの dev ブランチにコードを push し、dev GKE クラスタを作成しました。

    5. staging GKE クラスタを作成するには、dev ブランチから staging ブランチに pull リクエストを送信します。

      1. GitHub にアクセスし、gke-infrastructure-repo リポジトリに移動します。

      2. [Pull requests]、[New pull request] の順にクリックします。

      3. [Base] メニューで [staging] を選択し、[Compare] メニューで [dev] を選択します。

      4. [Create pull request] をクリックします。

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

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

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

      プロジェクトで 2 つ目の Cloud Build パイプラインが開始されます。このパイプラインは、staging GKE クラスタを作成します。

    8. prod GKE クラスタを作成するには、staging ブランチから prod ブランチに pull request を送信します。

      1. GitHub にアクセスし、gke-infrastructure-repo リポジトリに移動します。

      2. [Pull requests]、[New pull request] の順にクリックします。

      3. [Base] メニューで [prod] を選択し、[Compare] メニューで [staging] を選択します。

      4. [Create pull request] をクリックします。

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

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

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

      プロジェクトで 3 つ目の Cloud Build パイプラインが開始されます。このパイプラインは、本番環境の GKE クラスタを作成します。

    インフラストラクチャ

    このセクションでは、パイプラインによって作成されたインフラストラクチャについて説明します。

    • Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

      [Kubernetes クラスタ] ページに移動

      このページには、開発（gke-dev-us-central1）、ステージング（gke-staging-us-central1）、本番環境（gke-prod-us-central1、gke-prod-us-west1）に使用されるクラスタが一覧表示されます。

      ロケーション、クラスタサイズ、合計コア数を含むクラスタの詳細。

    開発クラスタ

    開発クラスタ（gke-dev-us-central1）では、デベロッパーはアプリケーションの反復処理に使用できる Namespace にアクセスできます。チームには Skaffold のようなツールを使用することをおすすめします。Skaffold は、開発中のコードを積極的にモニタリングし、変更が加えられると開発環境に再適用することで、反復ワークフローを提供します。この反復ループは、ホットリロードに似ています。ただし、このループはプログラミング言語固有のものではなく、Docker イメージでビルドできるすべてのアプリケーションで動作します。ループは Kubernetes クラスタ内で実行できます。

    または、デベロッパーが開発環境で CI / CD ループに従うこともできます。こループにより、コードの変更を上位の環境に昇格させる準備が整います。

    このシリーズの次のドキュメント、GKE による最新の CI / CD: デベロッパー ワークフローを適用するでは、Skaffold と CI / CD の両方を使用して開発ループを作成します。

    ステージング クラスタ

    このクラスタは、アプリケーションのステージング環境を実行します。このリファレンス アーキテクチャでは、ステージング用の GKE クラスタを 1 つ作成します。通常、ステージング環境は本番環境の正確なレプリカです。

    本番環境クラスタ

    リファレンス アーキテクチャには、本番環境用に 2 つの GKE クラスタがあります。地理冗長または高可用性（HA）システムでは、各環境に複数のクラスタを追加することをおすすめします。アプリケーションがデプロイされているすべてのクラスタでは、リージョン クラスタを使用することをおすすめします。このアプローチでは、アプリケーションをゾーンレベルの障害と、クラスタまたはノードプールのアップグレードによって生じる中断からアプリケーションを分離します。

    Namespace、割り当て、RBAC などのクラスタ リソースの構成を同期するには、Config Sync を使用することをおすすめします。これらのリソースの管理方法の詳細については、構成リポジトリとポリシー リポジトリをご覧ください。

    リファレンス アーキテクチャを適用する

    リファレンス アーキテクチャの確認ができたため、この実装に基づくデベロッパー ワークフローを確認できます。このシリーズの次のドキュメント、GKE による最新の CI / CD: デベロッパー ワークフローを適用するでは、新しいアプリケーションを作成して機能を追加し、アプリケーションをステージング環境と本番環境にデプロイします。

    クリーンアップ

    このシリーズの次のドキュメント、GKE による最新の CI / CD: デベロッパー ワークフローの適用を試す場合は、このリファレンス アーキテクチャに関連付けられたプロジェクトやリソースを削除しないでください。それ以外の場合、リファレンス アーキテクチャで使用したリソースについて Google Cloudアカウントに課金されないようにするには、プロジェクトを削除するか、リソースを手動で削除します。

    プロジェクトを削除する

    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.

    リソースを手動で削除する

    • Cloud Shell で、インフラストラクチャを削除します。

        gcloud container clusters delete gke-dev-us-central1
  gcloud container clusters delete gke-staging-us-central1
  gcloud container clusters delete gke-prod-us-central1
  gcloud container clusters delete gke-prod-us-west1
  gcloud beta builds triggers delete create-infra
  gcloud beta builds triggers delete add-team-files
  gcloud beta builds triggers delete create-app
  gcloud beta builds triggers delete tf-plan
  gcloud beta builds triggers delete tf-apply

    次のステップ