このチュートリアルでは、Anthos Config Management のベスト プラクティスに従って、開発環境と本番環境の 2 つの環境で Google Kubernetes Engine（GKE）の Config Sync を設定する方法について説明します。
このシナリオでは、Foo Corp のプラットフォーム管理を例にして説明します。このプラットフォーム管理チームでは、Foo Corp アプリケーションを GKE にデプロイし、リソースを dev と prod の 2 つのプロジェクトに分割しています。dev プロジェクトには開発環境用の GKE クラスタが含まれ、prod プロジェクトには本番環境用の GKE クラスタが含まれています。プラットフォーム管理者は、両方の環境が Foo Corp のポリシーを遵守し、両方の環境で基本レベルのリソース（Kubernetes の Namespace やサービス アカウントなど）の整合性を維持することを目標としています。
次の図は、このチュートリアルで設定する環境の概要を示しています。
上の図のように、このチュートリアルでは次のリソースを作成します。
- 2 つの Google Cloud プロジェクト（開発環境用と本番環境用）。
- 各プロジェクトに 2 つの GKE クラスタ（
devとprod）。 - 3 つの GitHub リポジトリ（
foo-config-source、foo-config-dev、foo-config-prod）。これらは、Foo Corp の YAML 構成ファイルを含む Config Sync の非構造化リポジトリです。 - Config Sync。両方のクラスタにインストールします。
devクラスタがfoo-config-devリポジトリに、prodクラスタがfoo-config-prodリポジトリに同期されます。 - Git ユーザー名と開発者トークンを含む Secret Manager シークレット。Cloud Build は、これらのシークレットを使用して GitHub リポジトリに commit します。
foo-config-sourceリポジトリに push される Cloud Build パイプライン。このパイプラインでは、kustomize buildを使用します。foo-config-sourceのベースとオーバーレイを使用して、YAML 構成ファイルでカスタマイズされたfoo-config-devリポジトリとfoo-config-prodリポジトリをレンダリングします。これらの Kustomize オーバーレイはconfig-source/フォルダにあります。
目標
- スクリプトを実行して、Config Sync で使用するクラスタとリポジトリの作成と構成を行い、環境を準備します。
- Kustomize を使用して 2 つの異なる環境の構成を自動的にレンダリングするため、Cloud Build トリガーを作成します。
- 2 つの別々の環境でレンダリングされた構成を同期するように Config Sync を設定します。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
このチュートリアルを開始する前に、次の手順が完了していることを確認してください。
Google Cloud コンソールのプロジェクト セレクタページで、2 つの Google Cloud プロジェクトを選択または作成します。
GitHub アカウントを作成するか、アカウントへのアクセス権を取得します。
GitHub で、
repoとdelete_repoのスコープを持つ個人用のアクセス トークンを作成します。トークンの値をクリップボードにコピーします。これは後の手順で必要になります。
環境の準備
次の手順を行い、このチュートリアルで使用する環境を準備します。
Cloud Shell を開きます。
Google Cloud コンソールに移動します。
Console の右上隅にある [Cloud Shell をアクティブにする] ボタン
をクリックします。
Cloud Shell には
nomosツールとkubectlツールがプリインストールされています。これらのツールは、このチュートリアルで必要になります。Anthos Config Management のサンプル リポジトリのクローンを作成します。
git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.gitこのチュートリアルに必要なリソースが含まれているフォルダに移動します。
cd anthos-config-management-samples/multi-environments-kustomize/このチュートリアルで使用するスクリプトを実行できるように、次の変数を設定します。
export DEV_PROJECT="DEV_PROJECT_ID" export PROD_PROJECT="PROD_PROJECT_ID" export DEV_CLUSTER_ZONE="DEV_CLUSTER_ZONE" export PROD_CLUSTER_ZONE="PROD_CLUSTER_ZONE" export GITHUB_USERNAME="GITHUB_USERNAME" export GITHUB_TOKEN="GITHUB_TOKEN" export GITHUB_EMAIL="GITHUB_EMAIL" export CM_CONFIG_DIR="cloud-build-rendering"次のように置き換えます。
DEV_PROJECT_ID: 開発環境プロジェクトとして使用する Google Cloud プロジェクトのプロジェクト IDPROD_PROJECT_ID: 本番環境プロジェクトとして使用する Google Cloud プロジェクトのプロジェクト IDDEV_CLUSTER_ZONE: 開発環境クラスタを作成する Compute Engine ゾーン。例:us-central1-cPROD_CLUSTER_ZONE: 本番環境クラスタを作成する Compute Engine ゾーンGITHUB_USERNAME: GitHub のユーザー名GITHUB_TOKEN: 始める前にで作成した個人用のアクセス トークンGITHUB_EMAIL: GitHub メールアドレス
GitHub のユーザー名とパスワードを使用するように、ローカルの Git 環境を構成します。
git config --global user.name $GITHUB_USERNAME git config --global user.email $GITHUB_EMAIL git config --global credential.helper store git config --global credential.helper cache
リソースの作成
複数の環境用に Config Sync を構成する際に必要となるワークフローに集中できるように、Config Sync の構成を自動化するスクリプトが multi-environments-kustomize ディレクトリに用意されています。
クラスタを作成して登録する
./create-clusters.shスクリプトを実行して、2 つのクラスタを作成します。./create-clusters.shこのスクリプトを実行すると、dev プロジェクトに
devという名前の GKE クラスタが作成され、prod プロジェクトにprodという名前の GKE クラスタが作成されます。また、GKE と Anthos API が有効になり、devクラスタとprodクラスタに接続します。これにより、kubectlで API にアクセスできるようになります。出力例:
kubeconfig entry generated for dev. Fetching cluster endpoint and auth data. kubeconfig entry generated for prod. ⭐️ Done creating clusters.register-clusters.shスクリプトを実行して、クラスタを 2 つの Anthos フリートに登録します。./register-clusters.shこのスクリプトを実行すると、Anthos クラスタ登録用に Google Cloud サービス アカウントとキーが作成されます。このアカウントとキーが作成されたら、
gcloud container fleet memberships registerコマンドを使用して、それぞれのプロジェクトでdevクラスタとprodクラスタが Anthos に登録されます。出力例:
Waiting for Feature Config Management to be created...done. ⭐️ Done registering clusters.
GitHub リポジトリを作成する
3 つの GitHub リポジトリを作成するには、
create-repos.shスクリプトを実行します。./create-repos.shこのスクリプトは、
foo-config-source、foo-config-dev、foo-config-prodの 3 つの GitHub リポジトリを作成します。ユーザーが構成ファイルをソース リポジトリに commit します。CI パイプライン（数ステップで作成）は、devとprod固有の値を使用して、残りの 2 つのリポジトリに構成ファイルをレンダリングします。それ以降は、devクラスタがfoo-config-devから同期され、prodクラスタがfoo-config-prodから同期されます。出力例:
# Output omitted 😸 Creating foo-config-prod repo... { "id": 364312792, "node_id": "MDEwOlJlcG9zaXRvcnkzNjQzMTI3OTI=", "name": "foo-config-prod", ... } Cloning into 'foo-config-prod'... warning: You appear to have cloned an empty repository. [main (root-commit) b681a3d] Initialize 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 211 bytes | 211.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/askmeegs/foo-config-prod.git * [new branch] main -> main
シークレットを作成する
Git 認証情報を使用して本番環境プロジェクトに Secret Manager のシークレットを作成するには、
secret-manager-git.shスクリプトを実行します。./secret-manager-git.shこの方法でシークレットを作成すると、Cloud Build が GitHub に push できるようになります。次に設定する Cloud Build パイプラインでは、Secret Manager から直接 GitHub 認証情報を取得します。
予想される出力:
🔐 Creating secret manager secrets in prod project... Created secret [github-username]. Created version [1] of the secret [github-username]. Created secret [github-email]. Created version [1] of the secret [github-email]. Created secret [github-token]. Created version [1] of the secret [github-token]. ✅ Granting Cloud Build secret manager access... Project number is: ######## Updated IAM policy for project [project-id]. # Output omitted
Cloud Build トリガーの作成
環境の構成が完了したので、Cloud Build パイプラインについて確認してみましょう。
次のコマンドを実行して、Cloud Build パイプラインを表示します。
cat foo-config-source/cloudbuild.yaml
このパイプラインでは Kustomize を使用しています。base/ ディレクトリのマニフェストを使用して、開発環境リポジトリと本番環境リポジトリのマニフェストをレンダリングしています。
予想される出力:
steps:
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
id: Render foo-config-dev
entrypoint: 'bash'
args:
- '-eEuo'
- 'pipefail'
- '-c'
- |-
git clone https://github.com/$$GITHUB_USERNAME/foo-config-dev && \
cd foo-config-dev
git config user.email $$GITHUB_EMAIL
git config user.name $$GITHUB_USERNAME
git remote set-url origin https://$$GITHUB_USERNAME:$$GITHUB_TOKEN@github.com/$$GITHUB_USERNAME/foo-config-dev.git
cd ..
kustomize build overlays/dev --output foo-config-dev/
cd foo-config-dev
rm README.md
echo "Update: ${SHORT_SHA}" > README.md
git add . && \
git commit -m "Rendered: ${SHORT_SHA}
Built from commit ${COMMIT_SHA} of repository foo-config-source - main branch
Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
git push origin main
secretEnv: ['GITHUB_EMAIL', 'GITHUB_USERNAME', 'GITHUB_TOKEN']
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
id: Render foo-config-prod
...
GitHub の foo-config-source/ リポジトリに移動すると、base/ マニフェスト、このパイプラインで使用される dev/ と prod/ Kustomize オーバーレイを確認できます。
このリポジトリの各ディレクトリには kustomization.yaml ファイルが含まれています。このファイルには、Kustomize が管理してクラスタに適用する必要があるファイルが記述されています。dev/kustomization.yaml と prod/kustomization.yaml では、一連のパッチが定義されています。これらのパッチは、特定の環境用の base/ リソースを操作します。
たとえば、foo-config-dev リポジトリの RoleBinding は、すべての Foo Corp のデベロッパーに、開発環境クラスタへの Pod のデプロイを許可しています。foo-
config-prod リポジトリの RoleBinding は、継続的デプロイ エージェントである deploy-bot@foo-corp.com にのみ本番環境への Pod のデプロイを許可しています。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
patches:
# ServiceAccount - make name unique per environ
- target:
kind: ServiceAccount
name: foo-ksa
patch: |-
- op: replace
path: /metadata/name
value: foo-ksa-dev
- op: replace
path: /metadata/namespace
value: foo-dev
# Pod creators - give all Foo Corp developers access
- target:
kind: RoleBinding
name: pod-creators
patch: |-
- op: replace
path: /subjects/0/name
value: developers-all@foo-corp.com
commonLabels:
environment: dev
トリガーを作成する
このセクションでは、ソースコードの変更で自動的にビルドを開始するように Cloud Build トリガーを作成します。
Google Cloud Console で、本番環境プロジェクトを使用して Cloud Build トリガーのページに移動します。
[リポジトリを接続] をクリックします。
[リポジトリを接続] ウィンドウで、次の操作を行います。
- [ソースの選択] フィールドで、GitHub を選択したままにして [続行] をクリックします。
- [GitHub アカウント] フィールドで、以前に定義した
GITHUB_USERNAMEが選択されていることを確認します。 - [リポジトリ] プルダウン リストで、
foo-config-sourceリポジトリを選択し、[OK] をクリックします。 - チェックボックスをオンにして利用規約に同意します。
- [接続] をクリックします。
リポジトリが接続されたら、[トリガーを作成] をクリックします。
表示された [トリガーの作成] ページで、次のフィールドに入力します。
- [名前] フィールドに、
Foo-Config-Renderを追加します。 - 必要に応じて [説明] と [タグ] フィールドを構成します。このチュートリアルでは必須ではありません。
- [イベント] フィールドで [ブランチに push する] を選択したままにします。
- [リポジトリ] プルダウン リストから
foo-config-sourceを選択します。 - [ブランチ] フィールドは
^main$のままにします。 - [種類] フィールドで [自動検出] を選択したままにします。
- [ロケーション] フィールドで、[リポジトリ] を選択したままにします。
- [作成] をクリックします。トリガーの概要ページに戻ります。
- [名前] フィールドに、
トリガーを実行する
このトリガーを作成する前に foo-config-source リポジトリに push されているので、開発環境リポジトリと本番環境リポジトリのレンダリングを手動でトリガーできます。
- トリガーリストの
Foo-Config-Render行で、[実行] をクリックします。[トリガーの実行] ウィンドウが表示されます。 - [トリガーの実行] ウィンドウで、[ブランチ] フィールドが
mainであることを確認し、[トリガーの実行] をクリックします。 「ブランチメインでビルドが開始しました」というメッセージが表示されます。このメッセージの [表示] をクリックすると、[ビルドの詳細] ページが表示されます。
ビルドが正常に実行されると、Kustomize ビルドの出力がそれぞれ
foo-config-devリポジトリとfoo-config-prodリポジトリに書き込まれます。ビルドが完了したら、GitHub で開発環境リポジトリまたは本番環境リポジトリのいずれかを開きます。リポジトリを含む YAML ファイルが表示されます。README が更新され、このリポジトリの最後のビルドで使用された
foo-config-sourceリポジトリの commit SHA が表示されます。
Config Sync の設定
リポジトリに構成ファイルが追加されたので、次に Config Sync をインストールして、その結果を確認します。
Config Sync のインストール
Config Sync をインストールするには、開発環境クラスタと本番環境クラスタで、install-config-sync.sh スクリプトを実行します。
./install-config-sync.sh
予想される出力:
😺 Populating configmangement.yaml with your GitHub repo info...
🔁 Installing ConfigSync on the dev cluster...
Updated property [core/project].
Switched to context "DEV_CLUSTER".
Waiting for Feature Config Management to be updated...done.
🔁 Installing ConfigSync on the prod cluster...
Updated property [core/project].
Switched to context "PROD_CLUSTER".
Waiting for Feature Config Management to be updated...done.
これで Config Sync がリポジトリ内の構成ファイルと同期されました。
構成を確認する
このセクションでは、クラスタがリポジトリ内の構成ファイルと同期されていることを確認します。
nomos statusコマンドを実行して、Config Sync のインストール状態を確認します。nomos statusこれで、開発環境クラスタと本番環境クラスタの両方がそれぞれのリポジトリと同期されます。
gke_DEV_PROJECT_ID_us-central1-c_dev -------------------- <root> https:/github.com/GITHUB_USERNAME/foo-config-dev@main SYNCED 8f2e196f Managed resources: NAMESPACE NAME STATUS clusterrole.rbac.authorization.k8s.io/pod-creator Current namespace/default Current namespace/foo Current default rolebinding.rbac.authorization.k8s.io/pod-creators Current foo serviceaccount/foo-ksa-dev Current *gke_PROD_PROJECT_ID_us-central1-c_prod -------------------- <root> https:/github.com/GITHUB_USERNAME/foo-config-prod@main SYNCED c91502ee Managed resources: NAMESPACE NAME STATUS clusterrole.rbac.authorization.k8s.io/pod-creator Current namespace/default Current namespace/foo Current default rolebinding.rbac.authorization.k8s.io/pod-creators Current foo serviceaccount/foo-ksa-prod Current ```kubectlを使用して開発環境クラスタに切り替えます。kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"リソースが同期されていることを確認するため、名前空間を取得します。
foo-config-devリポジトリと同期されたfoo名前空間が表示されるはずです。kubectl get namespace出力例:
NAME STATUS AGE config-management-monitoring Active 9m38s config-management-system Active 9m38s default Active 47h foo Active 9m5s kube-node-lease Active 47h kube-public Active 47h kube-system Active 47h resource-group-system Active 9m30sこれで、複数の Google Cloud プロジェクトと環境で、開発環境と本番環境の構成ファイルが自動的にレンダリングされるようになりました。
クリーンアップ
このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。
すべてのリソースを削除する
このチュートリアルで作成したリソースを削除して、開発環境プロジェクトと本番環境プロジェクトの両方をそのまま保持するには、クリーンアップ スクリプトを実行します。
./cleanup.sh
プロジェクトを削除する
- Google Cloud コンソールで、[リソースの管理] ページに移動します。
- プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
- ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。
次のステップ
- Anthos Config Management を使用した安全なロールアウトについて学習する。
- CI パイプラインで会社のポリシーに基づいてアプリを検証する方法について学習する。
- Anthos Config Management と GitLab を使用したポリシー管理のベスト プラクティスを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud Architecture Center をご覧ください。