このチュートリアルでは、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 (part of GKE Enterprise)
- Cloud Build
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
- 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.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Cloud Build API.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Cloud Build API.
- 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
コンソール
Google Cloud コンソールで [IAM] ページを開きます。
[メンバー] 列で、Cloud Build サービス アカウントの行を見つけます。
PROJECT_NUMBER@cloudbuild.gserviceaccount.com
その行の [
プリンシパルを編集] をクリックします。[別のロールを追加] をクリックします。
[ロールを選択] リストで
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 つのステップで行います。
- まず、
kubectl config current-context
を実行して kubeconfig ファイルを生成します。このファイルは、my-cluster
GKE クラスタの認証で必要になります。このファイルは、root ユーザーが制限付きの権限で生成します。 - 次のステップでこのファイルを読み取れるように、
chmod 444 /kube/config
を実行します。 - Git リポジトリで
nomos vet
を実行します。これにより、/workspace
にクローンが自動的に作成されます。非構造化リポジトリを使用している場合は、代わりにnomos vet --source-format=unstructured
を実行します。
ビルドトリガーを作成する
次の例では、Cloud Source Repositories リポジトリのマスター ブランチに対する commit 時に実行されるトリガーを作成します。
Google Cloud コンソールで [トリガー] ページを開きます。
[リポジトリを接続] をクリックします。
GitHub(mirrored)を選択し、[続行] をクリックします。
リポジトリを選択して、[リポジトリの接続] をクリックします。
[トリガーを追加] をクリックします。
次の表で説明する各フィールドに、対応するエントリを入力するか選択します。
項目 エントリ イベント ブランチに push する ブランチ ^master$ 構成 Cloud Build 構成ファイル(yaml または json) Cloud Build 構成ファイルの場所 / cloudbuild.yaml [作成] をクリックして、ビルドトリガーを保存します。
ビルドトリガーをテストする
トリガーを実行して設定を手動でテストします。
Google Cloud コンソールで [トリガー] ページを開きます。
作成したトリガーを選択して、[トリガーを実行] をクリックします。
「Build started on master branch」というメッセージが表示されます。
[表示] をクリックします。
正常に設定されていると、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
リソースを個別に削除する
リソースを個別に削除する手順は次のとおりです。
- Cloud Build 構成ファイルを削除します。
- 作成した Cloud Build トリガーを削除します。
- このチュートリアルで使用したクラスタを削除します。
次のステップ
- Cloud Build の詳細を確認する
- 構成ファイルの同期を一時的に停止する