構成の検証

nomos vet を手動またはローカルで pre-commit フックとして実行するだけでなく、CI / CD パイプラインで構成の変更を検証することをおすすめします。このガイドでは、GKE クラスタの使用時に Cloud Build で構成を検証する方法について説明します。他のコンテナベースの CI / CD システム(CircleCI など)でも、最小限の行うだけで同じ設定を使用できます。

始める前に

このガイドを実行するには、最初に Anthos Config Management のクイックスタートを完了する必要があります。

Cloud Build の構成

Cloud Build API を有効にする

gcloud

Cloud Build API を有効にするには、次のコマンドを実行します。

gcloud services enable cloudbuild.googleapis.com

コンソール

Cloud Build API を有効にする

GKE クラスタに対するアクセス権を 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

Console

  1. Cloud Console で Cloud IAM ページを開きます。

    Cloud IAM ページに移動

  2. [メンバー] 列で、Cloud Build サービス アカウントを探します。

    [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com

  3. その行の鉛筆アイコンをクリックします。

  4. [別の役割を追加] をクリックして Kubernetes Engine デベロッパーを選択し、[保存] をクリックします。

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 にクローンが自動的に作成されます。

ビルドトリガーの作成

次の例では、Cloud Source リポジトリのマスター ブランチに対する commit 時に実行されるトリガーを作成します。前のステップで作成した Cloud Build 構成ファイルを使用します。

  1. Cloud Console で [トリガー] ページを開きます。

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

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

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

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

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

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

    項目 エントリ
    イベント ブランチに push する
    ブランチ ^master$
    ビルド構成ファイルのタイプ Cloud Build 構成ファイル(yaml または json)
    Cloud Build 構成ファイルの場所 / cloudbuild.yaml
  7. [作成] をクリックして、ビルドトリガーを保存します。

ビルドトリガーのテスト

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

  1. Cloud Console で [トリガー] ページを開きます。

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

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

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

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

    正常に設定されていると、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 構成の作成をご覧ください。

次のステップ