構成ファイルを検証する

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

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

目標

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

費用

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

• Config Sync（GKE Enterprise の一部）
• Cloud Build

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

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

準備

1. Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

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

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

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

3. Google Cloud プロジェクトで課金が有効になっていることを確認します。

4. Cloud Build API を有効にします。

   API を有効にする

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

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

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

6. Google Cloud プロジェクトで課金が有効になっていることを確認します。

7. Cloud Build API を有効にします。

   API を有効にする

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:$[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）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

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

Google Cloud プロジェクトを削除します。

gcloud projects delete PROJECT_ID

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

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

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

次のステップ

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