構成ファイルを検証する

このチュートリアルでは、Google Kubernetes Engine（GKE）Enterprise エディションのクラスタを使用する際に、Cloud Build で構成ファイルを検証する方法について説明します。他のコンテナベースの CI / CD システム（CircleCI など）でも、最小限の変更を加えるだけで同じ設定を使用できます。

nomos vet コマンドを実行して、構成ファイルの有効性を検証することに加え CI / CD パイプラインの構成変更を検証することをおすすめします。

目標

  • リポジトリ内の構成ファイルで nomos vet を使用するように Config Sync に指示する Cloud Build 構成ファイルを作成します。
  • 開発ブランチが変更されるたびに構成ファイルを確認するように Cloud Build トリガーを作成します。

費用

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

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

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

始める前に

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the Cloud Build API.

    Enable the API

    5.

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

    Go to project selector

  6. Make sure that billing is enabled for your Google Cloud project.

  7. Enable the Cloud Build API.

    Enable the API

    8.
  8. Config Sync の要件を満たす GKE Enterprise クラスタを作成するか、該当するクラスタへのアクセス権を取得します。このようなクラスタを作成する詳しい方法については、Config Sync を使ってみるをご覧ください。

Cloud Build サービス アカウントに権限を付与する

GKE Enterprise クラスタに対するアクセス権を Cloud Build サービス アカウントに付与します。

gcloud

Kubernetes Engine Developer ロールを Cloud Build サービス アカウントに追加するには、次のコマンドを実行します。

PROJECT_ID=$(gcloud config get-value project)
PROJECT_NUM=$(gcloud projects list --filter="$PROJECT_ID" --format="value(PROJECT_NUMBER)")
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

コンソール

  1. Google Cloud コンソールで [IAM] ページを開きます。

    [IAM] ページに移動

  2. [メンバー] 列で、Cloud Build サービス アカウントの行を見つけます。

    PROJECT_NUMBER@cloudbuild.gserviceaccount.com

  3. その行の [プリンシパルを編集] をクリックします。

  4. [別のロールを追加] をクリックします。

  5. [ロールを選択] リストで Kubernetes Engine Developer を選択し、[保存] をクリックします。

Cloud Build の構成を作成する

Cloud Build 構成ファイルを作成し、構成ファイルを含むリポジトリのルート ディレクトリの下に保存します（例: my-repo/cloudbuild.yaml）。

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=ZONE'
  - 'CLOUDSDK_CONTAINER_CLUSTER=CLUSTER_NAME'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/config-management-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/POLICY_DIR']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

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

  • ZONE: クラスタが動作しているゾーン。
  • CLUSTER_NAME: クラスタの名前
  • POLICY_DIR: 同期するリポジトリの最上位レベルを表す Git リポジトリ内のパス。

この構成は 3 つのステップで行います。

  1. まず、kubectl config current-context を実行して kubeconfig ファイルを生成します。このファイルは、my-cluster GKE クラスタの認証で必要になります。このファイルは、root ユーザーが制限付きの権限で生成します。
  2. 次のステップでこのファイルを読み取れるように、chmod 444 /kube/config を実行します。
  3. Git リポジトリで nomos vet を実行します。これにより、/workspace にクローンが自動的に作成されます。非構造化リポジトリを使用している場合は、代わりに nomos vet --source-format=unstructured を実行します。

ビルドトリガーを作成する

次の例では、Cloud Source Repositories リポジトリのマスター ブランチに対する commit 時に実行されるトリガーを作成します。

  1. Google Cloud コンソールで [トリガー] ページを開きます。

    [トリガー] ページに移動

  2. [リポジトリを接続] をクリックします。

  3. GitHub（mirrored）を選択し、[続行] をクリックします。

  4. リポジトリを選択して、[リポジトリの接続] をクリックします。

  5. [トリガーを追加] をクリックします。

  6. 次の表で説明する各フィールドに、対応するエントリを入力するか選択します。

    項目 エントリ
    イベント ブランチに push する
    ブランチ ^master$
    構成 Cloud Build 構成ファイル（yaml または json）
    Cloud Build 構成ファイルの場所 / cloudbuild.yaml

  7. [作成] をクリックして、ビルドトリガーを保存します。

ビルドトリガーをテストする

トリガーを実行して設定を手動でテストします。

  1. Google Cloud コンソールで [トリガー] ページを開きます。

    [トリガー] ページに移動

  2. 作成したトリガーを選択して、[トリガーを実行] をクリックします。

    「Build started on master branch」というメッセージが表示されます。

  3. [表示] をクリックします。

    正常に設定されていると、Cloud Build のステップが緑色で表示されます。

無効な Cloud Build 構成

Cloud Build 構成ファイルが無効な場合、トリガーは実行できません。

これをテストするには、次のファイルを使用してリポジトリの Cloud Build 構成ファイルを更新します。6 行目に無効なインデントがあります。

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
  path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=ZONE'
  - 'CLOUDSDK_CONTAINER_CLUSTER=CLUSTER_NAME'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/nomos-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/POLICY_DIR']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

トリガーを再度手動で実行すると、6 行目の path: が正しくインデントされていないため、次のエラー メッセージが表示されます。

Failed to trigger build: failed unmarshalling build config cloudbuild.yaml:
unknown field "path" in cloudbuild_go_proto.BuildStep.

この構成ファイルを修正するには、6 行目の path: を 5 行目の name: と同じレベルにインデントします。Cloud Build 構成ファイルの構造については、基本的な Cloud Build 構成ファイルの作成をご覧ください。

クリーンアップ

プロジェクトを削除する

    Delete a Google Cloud project:

    gcloud projects delete PROJECT_ID

リソースを個別に削除する

リソースを個別に削除する手順は次のとおりです。

  1. Cloud Build 構成ファイルを削除します。
  2. 作成した Cloud Build トリガーを削除します。
  3. このチュートリアルで使用したクラスタを削除します。

次のステップ