Anthos による最新の CI / CD: CI / CD システムのビルド

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このリファレンス アーキテクチャでは、AnthosSkaffoldkustomizeArtifact RegistryGitLab などのツールを使用して、最新の継続的インテグレーション / 継続的デリバリー(CI / CD)システムをビルドするためのメソッドと初期インフラストラクチャを提供しています。

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

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

CI / CD ワークフロー

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

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

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

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

アーキテクチャ

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

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

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

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

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

コード リポジトリ

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

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

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

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

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

次の図は、このリファレンス アーキテクチャで使用されているランディング ゾーンの重要なコンポーネントを示しています。

GKE クラスタには、異なる環境とワークロードの 3 つの Namespace が含まれています。

各名前空間には、CI / CD システムが Pod や Service などの Kubernetes リソースをデプロイするために使用するサービス アカウントが含まれています。最小権限の原則に従って、サービス アカウントに独自の名前空間に対するアクセス権のみを付与することをおすすめします。サービス アカウント アクセスは Anthos Config Management で定義し、Kubernetes のロールベースのアクセス制御(RBAC)のロールとロール バインディングを使用して実装できます。このモデルを設定すると、チームは管理する名前空間に任意のリソースを直接デプロイできますが、他の名前空間のリソースの上書きと削除はできません。

目標

  • リファレンス アーキテクチャ インフラストラクチャをデプロイする。
  • インフラストラクチャを確認する。
  • コード リポジトリとパイプラインを確認する。
  • アプリケーション ランディング ゾーンの例を確認する。

費用

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

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

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

始める前に

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

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

  2. Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

  3. Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

    Cloud Shell をアクティブにする

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

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

    git clone https://github.com/GoogleCloudPlatform/solutions-modern-cicd-anthos.git
    cd solutions-modern-cicd-anthos
    
  2. このプロジェクトの環境変数を設定します。

    export PROJECT_ID=PROJECT_ID
    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format 'value(projectNumber)')
    export REGION="us-central1"
    
    gcloud config set compute/region ${REGION}
    gcloud config set core/project ${PROJECT_ID}
    

    PROJECT_ID をクラウド プロジェクト ID に置き換えます。

  3. Cloud Build、Anthos、Service Usage、Cloud Key Management Service(Cloud KMS)、Binary Authorization、Secret Manager、Container Analysis API を有効にします。

    gcloud services enable cloudbuild.googleapis.com
    gcloud services enable anthos.googleapis.com
    gcloud services enable serviceusage.googleapis.com
    gcloud services enable cloudkms.googleapis.com
    gcloud services enable binaryauthorization.googleapis.com
    gcloud services enable secretmanager.googleapis.com
    gcloud services enable containeranalysis.googleapis.com
    
  4. Cloud Build サービス アカウントの Identity and Access Management(IAM)のロールと権限を更新します。

    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
        --role roles/owner
    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
        --role roles/containeranalysis.admin
    
  5. Cloud Build を実行してクラスタをデプロイします。

    gcloud builds submit --substitutions=_PROJECT_ID=${PROJECT_ID}
    

    この処理には約 30 分かかります。終了したら、インフラストラクチャを確認します。

インフラストラクチャの確認

このセクションでは、インフラストラクチャ、コード リポジトリ、サンプルのランディング ゾーンなど、CI / CD システムの主なコンポーネントを確認します。

  • Google Cloud Console で、[Kubernetes クラスタ] ページに移動します。

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

    このページでは、開発(dev-us-west1)、共有ツール(gitlab)、アプリケーション環境(staging-us-west2prod-us-central1prod-us-east1)に使用されるクラスタを一覧表示しています。

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

開発クラスタ

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

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

共有ツールクラスタ

ソフトウェア デリバリー システムでは、ソフトウェア開発ライフサイクルをサポートするさまざまなツールが利用されています。最小権限の原則に従って、リファレンス実装は、ツールを保存するための専用クラスタ(gitlab)を提供します。各ツールは独自の名前空間にデプロイすることをおすすめします。

このリファレンス実装では、ソースコード管理と継続的インテグレーションに GitLab を使用します。GitLab on GKE Terraform モジュールを使用して、ツールクラスタに GitLab をインストールします。

アプリケーション環境クラスタ

リファレンス アーキテクチャにも、本番前(ステージング)環境と本番環境の両方のデプロイでアプリケーションを実行するクラスタ(staging-us-west2prod-us-central1prod-us-east1)があります。それぞれの環境で、少なくとも 1 つのクラスタにアプリケーションをデプロイする必要があります。地理冗長または高可用性(HA)システムでは、各環境に複数のクラスタを追加することをおすすめします。アプリケーションがデプロイされているすべてのクラスタでは、リージョン クラスタを使用することをおすすめします。このアプローチでは、アプリケーションをゾーンレベルの障害と、クラスタまたはノードプールのアップグレードによって生じる中断からアプリケーションを分離します。

名前空間、割り当て、RBAC などのクラスタ リソースの構成は、Anthos Config Management を使用して同期することをおすすめします。これらのリソースを管理する方法の詳細については、このドキュメントの後半の構成リポジトリとポリシー リポジトリをご覧ください。

コード リポジトリの確認

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

GitLab インスタンスにログインする

  1. Cloud Shell で GitLab の URL を取得します。

    echo "https://gitlab.endpoints.${PROJECT_ID}.cloud.goog"
    

    この URL は後の手順で使用するため、コピーしておいてください。

  2. Secret Manager に保存されている GitLab UserPassword を取得します。

    export GITLAB_USER=$(gcloud secrets versions access latest --secret="gitlab-user")
    export GITLAB_PASSWORD=$(gcloud secrets versions access latest --secret="gitlab-password")
    
    echo "User: ${GITLAB_USER}"
    echo "Password: ${GITLAB_PASSWORD}"
    

    これらの認証情報は後の手順で必要になるため、コピーしておいてください。

  3. ウェブブラウザで、先ほどコピーした GitLab URL に移動します。

  4. 先ほどコピーした UserPassword の認証情報を使用して、GitLab インスタンスにログインします。

    GitLab インスタンスの [プロジェクト] ページが表示されます。

オペレーター、スターター、構成リポジトリを確認する

オペレーター リポジトリ、スターター リポジトリ、構成リポジトリは、オペレーターとプラットフォーム管理者がプラットフォームをビルド、運用するための共通のベスト プラクティスを定義します。これらのリポジトリはすべて、platform-admins グループにあります。

  1. GitLab インスタンスで [グループ] をクリックし、[自分のグループ] を選択します。
  2. [platform-admins] をクリックします。

    リポジトリのリストが表示されます。

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

オペレーター リポジトリ

リファレンス アーキテクチャには、shared-kustomize-bases リポジトリと shared-ci-cd operator リポジトリが含まれています。

  • shared-kustomize-bases リポジトリには、プラットフォーム上の Kubernetes で実行されているアプリケーションの基本 Kubernetes マニフェストが含まれています。オペレーターは必要に応じてマニフェストを更新できます。アプリケーション チームが個々のアプリケーション構成を更新しなくても、更新されたマニフェストは自動的に取得されます。
  • shared-ci-cd リポジトリには、プラットフォームで CI と CD の手順を行うためのベスト プラクティスが保存されています。アプリケーション構成と同様に、オペレーターはベスト プラクティスを更新してステージを追加でき、個々のアプリケーション パイプラインは自動的に更新されます。

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

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

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

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

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

スターター リポジトリ

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

golang-template および java-template スターター リポジトリには、新しいアプリケーションの作成に使用できるボイラープレート コードが含まれています。golang-template-env リポジトリと java-template-env リポジトリには、CD に必要な基本構成が含まれています。デベロッパーやオペレーターは、新しいアプリケーションを作成するときに、このスターター リポジトリを使用します。

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

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

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

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

構成

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

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

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

ポリシー

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

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

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

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

Anthos Config Management を使用したポリシー管理の詳細については、Policy Controller の概要をご覧ください。

アプリケーション リポジトリを確認する

  1. GitLab インスタンスで [グループ] をクリックし、[自分のグループ] を選択します。
  2. [petabank] をクリックします。

    petabank アプリケーションのアプリケーション構成リポジトリとアプリケーション コード リポジトリを以下に示します。

    簡単な説明を含む 2 つのコード リポジトリの一覧表示。

このリファレンス アーキテクチャでは、各アプリケーションにはコード リポジトリと構成リポジトリという 2 つのリポジトリがあります。

アプリケーション コード リポジトリの内容は次のとおりです。

  • アプリケーションのソースコード
  • アプリケーションのビルド方法と実行方法を示す Dockerfile
  • オペレーターによってビルドされた共有タスクを使用する CI / CD パイプライン定義
  • 各アプリケーション環境の kustomize パッチ

アプリケーション構成リポジトリには、アプリケーションをデプロイするために必要な完全レンダリングされた Kubernetes マニフェストが含まれています。このリポジトリには、アプリケーションがデプロイされる各環境のブランチが含まれています。

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

リファレンス アーキテクチャ インフラストラクチャには、アプリケーションのランディング ゾーンの例も含まれています。このセクションでは、サンプルのランディング ゾーンについて確認します。ランディング ゾーンの詳細については、Anthos を使用した最新の CI / CD: ソフトウェア デリバリー フレームワークをご覧ください。

  1. Google Cloud コンソールで、GKEの [ワークロード] ページに移動します。

    [ワークロード] ページに移動

  2. [クラスタ] プルダウン メニューから [staging-us-west2] を選択します。

  3. [名前空間] プルダウン メニューから [petabank] を選択します。

    petabank アプリケーションの Kubernetes リソースのリストが表示されます。

    [ワークロード] セクションには、リファレンス アーキテクチャ用の 2 つの Deployment リソースが表示されます。

  4. petabank アプリケーションの Kubernetes Service リソースを表示するには、[Services と Ingress] をクリックします。

この名前空間には、petabank アプリケーションのリソース、CI / CD タスク用の GitLab ランナー、petabank アプリケーション用の Kubernetes Deployment と Service が含まれています。最小権限の原則に従って、RBAC とネットワーク ポリシーは、GitLab に保存されている anthos-config-management リポジトリで定義されます。Anthos Config Management を使用して構成とポリシーを適用できます。

リファレンス アーキテクチャの適用

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

クリーンアップ

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

プロジェクトの削除

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

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

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

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

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

    gcloud builds submit --substitutions=_PROJECT_ID=${PROJECT_ID} --config cloudbuild-destroy.yaml
    gcloud endpoints services delete gitlab.endpoints.${PROJECT_ID}.cloud.goog
    gcloud endpoints services delete registry.endpoints.${PROJECT_ID}.cloud.goog
    

次のステップ