構成ファイルを検証する

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

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

目標

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

費用

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

• Config Sync
• Cloud Build

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

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

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

始める前に

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.

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 (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Cloud Build API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

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 (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Cloud Build API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

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

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

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:$[e-mail] \
    --role=roles/container.developer

コンソール

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

   [IAM] に移動

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

   [e-mail]
   

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 構成ファイルの作成をご覧ください。

クリーンアップ

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

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.

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

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

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

次のステップ

• Cloud Build の詳細を確認する
• 構成ファイルの同期を一時的に停止する