Config Controller を使用すると、Google Cloud のランディング ゾーンを宣言的にデプロイして管理できます。
このチュートリアルでは、組織管理者がランディング ゾーンのブループリントをデプロイして、本番環境対応のスケーラブルなエンタープライズ ワークロード向けに Google Cloud を設定する際に役立つ情報（ネットワーキング、セキュリティ、リソース管理のベスト プラクティスなど）を提供します。
目標
ランディング ゾーンのデプロイ プロセスでは、次のことを行います。
- Config Controller を設定し、Git リポジトリから Google Cloud 環境にリソースを同期するように構成します。
- 共有 VPC のデプロイなど、Google Cloud の一般的なデザイン パターンをキャプチャするブループリントを探します。
- Cloud Build に基づく独自のデプロイ パイプラインを作成します。ブループリントをカスタマイズして kpt 関数で変換し、Config Connector を使用してリソースをデプロイします。
これらのコンポーネントを組み合わせて、次の図のようなワークフローを構築します。
費用
始める前に
ランディング ゾーンを設定する前に、いくつかの準備を行う必要があります。-
Sign in to your Google Account.
If you don't already have one, sign up for a new account.
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
- Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
- Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
- Git がまだインストールされていない場合は、インストールします。
- 組織へのアクセス権を付与する際に使用する Google グループを作成します。特に、組織管理者のグループと課金管理者のグループが必要です。
- このチュートリアルで使用する Kubernetes ツール（
nomos、kubectl、kpt）をインストールします。各ページからコンポーネントを直接インストールすることもできます。gcloud components install pkg
- Kpt を使用するには、Docker バージョン 20.10.0 以降が必要です。Docker をまだインストールしていなければ、インストールします。root 以外のユーザーとして Docker を管理する場合は、インストール後の手順をご覧ください。
環境の準備
ランディング ゾーンのブループリントをデプロイする前に、いくつかの環境変数を設定する必要があります。
export PROJECT_ID=PROJECT_ID
export CONFIG_CONTROLLER_NAME=config-controller-1
export BILLING_ACCOUNT=$(gcloud alpha billing projects describe $PROJECT_ID \
'--format=value(billingAccountName)' | sed 's/.*\///')
export ORG_ID=$(gcloud projects get-ancestors ${PROJECT_ID} --format='get(id)' | tail -1)
gcloud config set project ${PROJECT_ID}
次のように置き換えます。
PROJECT_ID: Config Controller をホストするプロジェクト ID
Config Controller の設定
Config Controller は、クラウド リソースを構成するための Kubernetes ベースのマネージド コントロール プレーンを提供します。Config Controller には、Policy Controller、Config Sync、Config Connector がプリインストールされています。
- プロジェクトで、Config Controller API と、Config Controller が依存している GKE API を有効にします。
gcloud services enable krmapihosting.googleapis.com container.googleapis.com
- Config Controller を作成します。このオペレーションには 15 分以上かかることがあります。
gcloud anthos config controller create ${CONFIG_CONTROLLER_NAME} \ --location=us-central1 - Config Controller が正常に作成されたことを確認します。
gcloud anthos config controller list --location=us-central1
- 構成の適用を開始できるように、Config Controller を認証します。
gcloud anthos config controller get-credentials ${CONFIG_CONTROLLER_NAME} \ --location us-central1 - 管理プロジェクトの Google Cloud リソースを管理する権限を Config Controller に付与します。
export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \ -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)" gcloud projects add-iam-policy-binding "${PROJECT_ID}" \ --member "serviceAccount:${SA_EMAIL}" \ --role "roles/owner" \ --project "${PROJECT_ID}" - 組織レベルのリソースを管理する権限を Config Controller に付与して、ランディング ゾーンのブループリントをデプロイします。
gcloud organizations add-iam-policy-binding $ORG_ID \ --role=roles/resourcemanager.organizationAdmin \ --condition=None \ --member="serviceAccount:${SA_EMAIL}"
GitOps パイプラインの作成
Git リポジトリと同期するように Config Controller を設定すると、ランディング ゾーンの変更作業を共同で行い、堅牢な監査証跡を保持できます。
このステップでは、最初のブループリントをデプロイします。このブループリントには以下のものが含まれます。
- 2 つの Cloud Source Repositories: 変更を commit する source リポジトリと、Config Controller に適用される最終的な構成のコピーを含む deployment リポジトリ。
- source リポジトリで変更を監視し、それに含まれる kpt 関数を実行して、最終出力を deployment リポジトリに commit する Cloud Build トリガー。
- Config Controller をデプロイ リポジトリに接続する Config Sync 構成。
ブループリントをデプロイする
- プロジェクトで Cloud Source Repositories サービスを有効にします。
gcloud services enable sourcerepo.googleapis.com
- プロジェクトで Resource Manager サービスを有効にします。
gcloud services enable cloudresourcemanager.googleapis.com
- kpt を使用して、GitHub からローカルマシンに GitOps ブループリントをダウンロードします。
kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gitops@gitops-blueprint-v0.5.0 gitops
- このブループリントは、さまざまな
settersを使用してカスタマイズできます。gitops/setters.yamlファイルを開いて修正を行います。 - このブループリントをカスタマイズするには、上記のファイルで次のセッターを置き換えます。
cluster-name: Config Controller に選択した名前。これは次のコマンドで取得できます。echo ${CONFIG_CONTROLLER_NAME}project-id: Config Controller がデプロイされているプロジェクト IDproject-number: Config Controller がデプロイされているプロジェクトの番号。これは次のコマンドで取得できます。gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)'
- カスタマイズをすべてのリソースに反映するには、ブループリントをレンダリングします。
kpt fn render gitops/
- ブループリントを Config Controller クラスタに適用します。
kubectl apply --wait -f gitops/ --recursive
- ブループリントによってリポジトリが作成されるまで待ちます。
kubectl wait --for=condition=READY -f gitops/source-repositories.yaml
ブループリントを Git に保存する
ここでは、ブループリントが作成した Git リポジトリにブループリントを保存します。これにより、カスタマイズ内容を保存し、今後の変更を追跡できます。
- デフォルトのブランチを
mainに設定します。git config --global init.defaultBranch main
- ブループリントによって作成された Git リポジトリをチェックアウトします。
gcloud source repos clone source-repo
- GitOps のブループリントを Git リポジトリに移動します。
mv gitops source-repo/
- Git リポジトリを開きます。
cd source-repo/
- ブループリントを Git に commit し、変更を push します。
git add gitops/ git commit -m "Add GitOps blueprint" git push
成功を検証する
上記のブートストラップ プロセスが正常に完了したことを確認します。
- Config Connector が正常にインストールされたことを確認します。
kubectl wait -n cnrm-system --for=condition=Ready pod --all
- Cloud Source Repositories が正常に作成されたことを確認します。
gcloud source repos list
- Config Controller で必要なリソースが作成されていることを確認します。
kubectl get gcp -n config-control -o yaml \ | grep "^ name: \\|message"
出力は次のようになります。name: source-repo-cicd-trigger message: The resource is up to date name: allow-configsync-sa-read-csr message: The resource is up to date name: configsync-sa-workload-identity-binding message: The resource is up to date name: deployment-repo-cloudbuild-write message: The resource is up to date name: source-repo-cloudbuild-read message: The resource is up to date name: config-sync-sa message: The resource is up to date name: cloudbuild.googleapis.com message: The resource is up to date name: sourcerepo.googleapis.com message: The resource is up to date name: deployment-repo message: The resource is up to date name: source-repo message: The resource is up to date - ビルドが成功したことを確認します。
gcloud builds list --project=${PROJECT_ID} \ --filter="source.repo_source.commit_sha=$(git rev-parse HEAD)" - ハイドレードされたマニフェストが Deployment リポジトリに push されたことを確認します。
BUILD_ID=$(gcloud builds list --project=${PROJECT_ID} --filter="source.repo_source.commit_sha=$(git rev-parse HEAD)" --format="value(id)") gcloud builds log --project=${PROJECT_ID} ${BUILD_ID}出力例:... Step #2 - "Push Changes To Deployment Repo": 7 files changed, 297 insertions(+) Step #2 - "Push Changes To Deployment Repo": create mode 100644 config/.gitkeep Step #2 - "Push Changes To Deployment Repo": create mode 100644 config/gitops/cloudbuild-iam.yaml Step #2 - "Push Changes To Deployment Repo": create mode 100644 config/gitops/configsync/config-management.yaml Step #2 - "Push Changes To Deployment Repo": create mode 100644 config/gitops/configsync/configsync-iam.yaml Step #2 - "Push Changes To Deployment Repo": create mode 100644 config/gitops/hydration-trigger.yaml Step #2 - "Push Changes To Deployment Repo": create mode 100644 config/gitops/services.yaml Step #2 - "Push Changes To Deployment Repo": create mode 100644 config/gitops/source-repositories.yaml Step #2 - "Push Changes To Deployment Repo": To https://source.developers.google.com/p/$PROJECT_ID/r/deployment-repo Step #2 - "Push Changes To Deployment Repo": * [new branch] main -> main Step #2 - "Push Changes To Deployment Repo": Step #2 - "Push Changes To Deployment Repo": Step #2 - "Push Changes To Deployment Repo": Latest deployment repo commit SHA: $SHA Finished Step #2 - "Push Changes To Deployment Repo" PUSH DONE
ランディング ゾーンの初期化
Config Controller が Git に接続されたところで、今度はランディング ゾーンのブループリントを初期化します。
このブループリントは、次のような組織全体の構成を設定して、ランディング ゾーンを準備します。
hierarchy、logging、networking、projects、policiesを管理するための別の名前空間を Config Controller 内に作成します。各名前空間には、異なる最小権限の Google Cloud サービス アカウントが割り当てられます。- 課金管理者グループに課金管理者ロールを割り当て、組織管理者グループに組織管理者ロールを割り当てます。
- 組織内のベスト プラクティスの組織のポリシーを有効にします。
ブループリントをデプロイする
上でクローンを作成したソース リポジトリから、ランディング ゾーンをデプロイします。
- ベース ランディング ゾーンのブループリントをダウンロードし、リポジトリに追加します。
kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/landing-zone@main ./landing-zone git add landing-zone/ git commit -m "Add landing zone"
- このブループリントには、ランディング ゾーンを構成するためのいくつかのセッターが含まれています。
landing-zone/setters.yamlファイルを開いて修正を行います。 - このブループリントをカスタマイズするには、上記のファイルで次のセッターを置き換えます。
org-id: ランディング ゾーンの組織の IDbilling-account-id: 新しいプロジェクトに使用するデフォルトの請求先アカウントmanagement-project-id: Config Controller がデプロイされているプロジェクト IDgroup-org-admins: 組織管理者 Google グループのメールアドレス（例:gcp-organization-admins@example.com）group-billing-admins: 課金管理者 Google グループのメールアドレス（例:gcp-billing-admins@example.com）
- ブループリントに対して行ったカスタマイズを確認します。
git diff
- 変更内容をリポジトリに push します。リポジトリでは、変更内容が Config Controller に自動的に同期され、適用されます。
git commit -a -m "Customize landing zone blueprint" git push
組織のポリシーを管理する
ランディング ゾーンのブループリントには、環境のセキュリティを強化するためのベスト プラクティスに対応する組織ポリシーの制約がいくつか含まれています。
| 制約 | 説明 |
|---|---|
compute.disableNestedVirtualization |
すべての Compute Engine VM に対するハードウェア アクセラレーションによりネストされた仮想化を無効にします。 |
compute.disableSerialPortAccess |
Compute Engine VM へのシリアルポート アクセスを無効にします。 |
compute.disableGuestAttributesAccess |
VM のゲスト属性への Compute Engine API アクセスを無効にします。 |
compute.vmExternalIpAccess |
外部 IP アドレスの使用が許可されている Compute Engine VM インスタンスのセットを制限します。 |
compute.skipDefaultNetworkCreation |
プロジェクトの作成時に、Google Cloud はデフォルト ネットワークと関連リソースの作成をスキップします。 |
compute.restrictXpnProjectLienRemoval |
共有 VPC プロジェクト リーエンを削除できる一連のユーザーを制限します。 |
sql.restrictPublicIp |
Cloud SQL インスタンス上のパブリック IP アドレスを制限します。 |
iam.disableServiceAccountKeyCreation |
ダウンロード可能なサービス アカウント キーの作成を無効にします。 |
storage.uniformBucketLevelAccess |
統一された IAM ベースのバケットレベルのアクセスを使用するために、バケットが必要です。 |
制約の削除
いずれかのデフォルトの制約が組織に問題を引き起こしている場合は、ソース リポジトリから関連する YAML ファイルを削除して、デフォルトの動作に戻します。
たとえば、シリアルポートへのアクセスを妨げる制約を削除する方法は次のとおりです。
- ファイルを削除します。
git rm ./landing-zone/policies/disable-serial-port.yaml
- 変更を commit して push します。
git commit -m "Remove serial port org policy" git push
成功を検証する
次の方法で、ランディング ゾーンが初期化されたことを確認できます。
- Cloud Build 実行パイプラインのステータスを確認します。
- Git リポジトリが Config Controller と同期されていることを確認します。
nomos status
- 名前空間
hierarchy、projects、policies、logging、networkingが存在することを確認します。kubectl get ns
- Config Controller で必要なリソースが作成されていることを確認します。
kubectl get gcp --all-namespaces -o yaml \ | grep "^ name: \|message"
- CLI を使用して組織のポリシーを一覧表示します。
gcloud resource-manager org-policies list --organization=$ORG_ID
リソース階層の設定
Google Cloud では、リソースはフォルダとプロジェクトに整理されます。
- プロジェクトには、仮想マシン、データベース、ストレージ バケットなどのクラウド リソースが含まれます。
- フォルダを使用してプロジェクトをグループ化し、ポリシー管理を簡素化します（IAM などを使用）。たとえば、財務部門や小売部門などの主要部門のフォルダを作成できます。本番環境と非本番環境などのフォルダを作成することもできます。フォルダを相互にネストしてリソース階層を形成できます。
Google では、さまざまな組織構造に合わせて 4 つの異なるリソース階層ブループリントを用意しています。
- シンプル:
environmentsを表す単一レイヤのフォルダが配置されたシンプルなブループリントです。 - チーム: このブループリントには、
teams -> environmentsの 2 つのレイヤのフォルダが配置されています。 - ビジネス ユニット: このブループリントでは、組織を自律的なビジネス ユニット
divisions -> teams -> environmentsに焦点を当てて、3 つのレベルのフォルダに分割します。 - 環境: このブループリントでは、環境中心のポリシー
environments -> divisions -> teamsに焦点を当てて、3 つのレベルのフォルダを配置します。
ブループリントをデプロイする
優先するリソース階層を選択したら、適切な手順でデプロイします。
シンプル
このブループリントは、クラウドを管理する目的で環境ごとに一連の簡単なポリシーを必要とする組織に適していますが、すべてのチームが均一に扱われます。
- ブループリントをダウンロードします。
kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/simple@main ./landing-zone/hierarchy/
- 目的の組織構造が反映されるように
landing-zone/hierarchy/hierarchy.yamlファイルを編集します。これらの値は
hierarchy.yamlで更新する必要があります。spec.config: 目的の環境。最上位のフォルダになります。spec.parentRef.external: 組織 ID に合わせてこの値を更新します。
- フォルダの命名規則に従って、
landing-zone/hierarchy/policies/naming-constraint.yamlに含まれる命名規則の制約を編集します。この命名規則は正規表現として定義されます。特に、この表現を調整して、定義した他の環境を含める必要があります。 - 階層を追加して、git リポジトリに push します。
git add ./landing-zone/hierarchy/ git commit -m "Add resource hierarchy and update folder naming convention." git push
チーム
このブループリントは、各チームが独自のクラウド運用を担当し、クラウドの使用方法に関するカスタム ポリシーを設定する権限を付与されているシンプルな組織に適しています。
- ブループリントをダウンロードします。
kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/team@main ./landing-zone/hierarchy/
- 目的の組織構造が反映されるように
landing-zone/hierarchy/hierarchy.yamlファイルを編集します。これらの値は
hierarchy.yamlで更新する必要があります。spec.config: 目的のチーム。最上位のフォルダになります。spec.subtrees.environments: 目的の環境。各チームのサブフォルダになります。spec.parentRef.external: 組織 ID に合わせてこの値を更新します。
- フォルダの命名規則に従って、
landing-zone/hierarchy/policies/naming-constraint.yamlに含まれる命名規則の制約を編集します。この命名規則は正規表現として定義されます。特に、この表現を調整して、定義した他の環境を含める必要があります。 - 階層を追加して、git リポジトリに push します。
git add ./landing-zone/hierarchy/ git commit -m "Add resource hierarchy and update folder naming convention." git push
ビジネス ユニット
このブループリントは、各ビジネス ユニットまたは部門が独自のクラウド運用の大部分を担う、規模が大きく複雑な組織に適しています。各ビジネス ユニットがすべてのチームに適用するポリシーを簡単に設定できるようにする一方で、個別のチームが（それらの最上位の制約の中で）独自の環境を担当することになります。
- ブループリントをダウンロードします。
kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/bu@main ./landing-zone/hierarchy/
- 目的の組織構造が反映されるように
landing-zone/hierarchy/hierarchy.yamlファイルを編集します。これらの値は
hierarchy.yamlで更新する必要があります。spec.config: 目的の組織構造。これには部門の下にネストされているチームを含めることができます。たとえば、ブループリントは、アプリおよびデータのサブフォルダを含む小売部門から始まります。spec.subtrees.environments: 目的の環境。各チームのサブフォルダになります。spec.parentRef.external: 組織 ID に合わせてこの値を更新します。
- フォルダの命名規則に従って、
landing-zone/hierarchy/policies/naming-constraint.yamlに含まれる命名規則の制約を編集します。この命名規則は正規表現として定義されます。特に、この表現を調整して、定義した他の環境を含める必要があります。 - 階層を追加して、git リポジトリに push します。
git add ./landing-zone/hierarchy/ git commit -m "Add resource hierarchy and update folder naming convention." git push
環境
このブループリントは、環境ポリシーに対する強力で一貫した制御（例: 本番環境のリソースへのアクセス制限）を表しつつ、部門やチームごとの詳細なポリシーを柔軟に設定する必要がある大規模な組織に適しています。
- ブループリントをダウンロードします。
kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/env-bu@main ./landing-zone/hierarchy/
- 目的の組織構造が反映されるように
landing-zone/hierarchy/hierarchy.yamlファイルを編集します。これらの値は
hierarchy.yamlで更新する必要があります。spec.config: 目的とするトップレベル環境フォルダ（それぞれに環境サブツリーの完全なコピーが含まれます）spec.subtrees.environment: 各環境でミラーリングする、望ましい部門とチームの階層。たとえば、ブループリントは、アプリおよびデータのサブフォルダを含む小売部門から始まります。spec.parentRef.external: 組織 ID に合わせてこの値を更新します。
- 階層を追加して、git リポジトリに push します。
git add ./landing-zone/hierarchy/ git commit -m "Add resource hierarchy and update folder naming convention." git push
成功を検証する
リソース階層が正常に作成されたことを確認するには、次の操作を行います。
- 組織内のフォルダを一覧表示します。
gcloud resource-manager folders list --organization=$ORG_ID
- クラスタの階層名前空間からフォルダのステータスを直接取得します。
kubectl get folders -n hierarchy -o yaml \ | grep "^ name: \|message"
ネットワーク接続を確立する
ランディング ゾーンの一部として、共有 VPC ネットワーク アーキテクチャをデプロイすることをおすすめします。提供されているネットワーキング ブループリントを使用してネットワークを設定し、ハイブリッド接続用の Cloud VPN を確立します。
ホスト プロジェクトを作成する
ネットワークをデプロイする前に、ネットワークをホストするプロジェクトを作成する必要があります。これは、付属のプロジェクト ファクトリーのブループリントを使用して、環境ごとに 1 回行う必要があります。
- プロジェクト ブループリントをランディング ゾーンにダウンロードして、ホスト プロジェクトを作成します。
export NET_PROJECT_ID="NETWORK_PROJECT_ID" export ENVIRONMENT="ENVIRONMENT" kpt pkg get \ https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@main \ ./landing-zone/projects/${NET_PROJECT_ID}次のように置き換えます。
ENVIRONMENT: 共有 VPC を構成する環境（devなど）。NETWORK_PROJECT_ID: ネットワーキング プロジェクトに割り当てる ID。
landing-zone/projects/NETWORK_PROJECT_ID/setters.yamlファイルを開きます。このブループリントをカスタマイズするには、次のセッターを置き換えます。 次のように値を設定します。project-id: 選択した ID。folder-name: ネットワーク プロジェクトを格納するフォルダの ID。フォルダには接頭辞として親フォルダの名前が付加されます。たとえば、dev環境内のsharedフォルダにはdev.sharedの ID が割り当てられます。
- ブループリントを追加して、プロジェクトを共有 VPC ホスト プロジェクトにします。
kpt pkg get \ https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/shared-vpc@main \ ./landing-zone/projects/${NET_PROJECT_ID}/host-project - 変更を commit してプロジェクトの作成をトリガーします。
git add ./landing-zone/projects/${NET_PROJECT_ID}/ git commit -m "Add networking host project" git push
ネットワークを作成する
ホスト プロジェクトが完成したため、ネットワーキング ブループリントを使用して共有 VPC を作成できます。
- ネットワークのブループリントをランディング ゾーンに追加します。
kpt pkg get \ https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network@main \ ./landing-zone/network/${ENVIRONMENT}/ landing-zone/network/ENVIRONMENT/setters.yamlファイルを開きます。次のセッターを置き換えて、このブループリントをカスタマイズします。 次のように値を設定します。network-name: ネットワークに使用する名前（例:dev-network-shared）region: 最初のサブネットをデプロイするリージョン（例:us-east4）project-id: ネットワークがホストされるプロジェクト ID（NETWORK_PROJECT_ID）
- Cloud VPN で使用される事前共有キー用のシークレットを作成します。この値は機密性が高いため、Git リポジトリに commit しないでください。代わりに、Config Controller に直接送信します。
kubectl create secret generic vpn-shared-secret \ --from-literal=vpn-shared-secret="SECRET_VALUE" \ -n networking
- カスタマイズされたブループリントを commit して、ネットワークをデプロイします。
git add ./landing-zone/network/ git commit -m "Add network setup" git push
ネットワークのデプロイを確認する
次の方法で、ネットワークが正常に作成されたことを確認できます。
- プロジェクトが正常に作成されたことを確認します。
kubectl describe project ${NET_PROJECT_ID} -n projects - クラスタ内のネットワーク名前空間からネットワークのステータスを直接取得します。
kubectl get gcp \ -n networking -o yaml \ | grep "^ name: \|message"
- Cloud Console を介してネットワークを検査します。
ロギングデータのエクスポート
エンタープライズ企業向けの Google Cloud のベスト プラクティスの 1 つは、監査ログを詳細にモニタリングして保持することです。
ランディング ゾーンのブループリントには、ログのエクスポートと保持を管理するための複数のオプションが含まれています。
以下の手順に沿って、ブループリントをデプロイします。これにより、組織から BigQuery にすべてのログがエクスポートされ、長期的な保持と分析が可能になります。
ホスト プロジェクトを作成する
ログを BigQuery にエクスポートする場合は、ログをホストするプロジェクトが必要です。組織全体のログをエクスポートするため、このプロジェクトを本番環境に配置する必要があります。これは、ブループリントを使用して作成できます。
- プロジェクト ブループリントをランディング ゾーンにダウンロードして、ホスト プロジェクトを作成します。
export LOGGING_PROJECT_ID="LOGGING_PROJECT_ID" kpt pkg get \ https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@main \ ./landing-zone/projects/${LOGGING_PROJECT_ID}次のように置き換えます。
LOGGING_PROJECT_ID: ネットワーキング プロジェクトに割り当てる ID。
landing-zone/projects/LOGGING_PROJECT_ID/setters.yamlファイルを開きます。次のセッターを置き換えて、このブループリントをカスタマイズします。次のように値を設定します。project-id: ログのエクスポートを保存するために選択したプロジェクト ID（LOGGING_PROJECT_ID）folder-name: ロギング プロジェクトを格納するフォルダの ID。フォルダには接頭辞として親フォルダの名前が付加されます。たとえば、dev環境内のsharedフォルダにはdev.sharedの ID が割り当てられます。
- 変更を commit してプロジェクトの作成をトリガーします。
git add ./landing-zone/projects/${LOGGING_PROJECT_ID}/ git commit -m "Add logging project" git push
ログを BigQuery にエクスポートする
ログを BigQuery にエクスポートすると、後で分析するためにログを保持できます。このブループリントでは、ログを保存する BigQuery データセットを作成し、そのデータセットへのエクスポートを構成します。
- ロギングのブループリントをランディング ゾーンに追加します。
kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/log-export/org/bigquery-export@main ./landing-zone/logging/bigquery-export
landing-zone/logging/bigquery-export/setters.yamlファイルを開きます。プロジェクト ID を置き換えて、このブループリントをカスタマイズします。次のように値を設定します。project-id: ログの保存用に選択したプロジェクト ID（LOGGING_PROJECT_ID）
- ブループリントを commit してログのエクスポートを作成します。
git add ./landing-zone/logging/ git commit -m "Add log export to BigQuery" git push
ログのエクスポートを確認する
次の方法で、ログのエクスポートが正常に構成されていることを確認します。
- プロジェクトが正常に作成されたことを確認します。
kubectl describe project ${LOGGING_PROJECT} -n projects gcloud projects describe ${LOGGING_PROJECT_ID} logging名前空間内のリソースのステータスを取得します。kubectl get bigquerydatasets,iampolicymembers,logginglogsinks -n logging -o yaml \ | grep "^ name: \|message"
- gcloud CLI を使用してログのエクスポートのステータスを取得します（新しいシンクがリストに表示されます）。
gcloud logging sinks list --organization=${ORG_ID} - シンクが構成されてから少し経過してから、ログが BigQuery に送信されていることを確認します。
# List tables bq ls --project_id ${LOGGING_PROJECT_ID} bqlogexportdataset # Query a table # Change this to a result of "bq ls" above so that the name matches one of your tables TABLE_OF_INTEREST=git_sync_20201130 bq query --project_id ${LOGGING_PROJECT_ID} "SELECT * FROM bqlogexportdataset.${TABLE_OF_INTEREST} LIMIT 2"
トラブルシューティング
デフォルト ネットワーク
Config Controller を作成する際に、デフォルト ネットワークを使用できないというエラーが表示される場合があります。
Error 400: Project "" has no network named "default"., badRequest\n\n on main.tf line 35, in resource "google_container_cluster" "acp_cluster"
このエラーは、Config Controller がデフォルト ネットワークがあることを前提としているため発生します。この問題を解決するには、新しいデフォルト ネットワークを作成する必要があります。
gcloud compute networks create default --subnet-mode=auto
ハイドレーションと Cloud Build
GitOps のブループリントの一部として、ソース リポジトリをモニタリングして変更を確認する Cloud Build トリガーを作成しました。
- これらの変更の内容を kpt 関数を使用して検証します。
- 最終的なハイドレートされた構成を生成します。この構成は Deployment リポジトリに保存され、Config Sync によってクラスタに適用されます。
この Cloud Build パイプラインは、Console または gcloud からモニタリングできます。この gcloud コマンドを使用して、最新のビルド ステータスを取得できます。
FILTER="source.repo_source.commit_sha=$(git rev-parse HEAD)"
# You can poll on this command until status is either SUCCESS or FAILURE
gcloud builds list --project=${PROJECT_ID} --filter=${FILTER}
BUILD_ID=$(gcloud builds list --project=${PROJECT_ID} --filter=${FILTER} --format='get(id)' | head -n 1)
# View logs for your run. You can use this to debug errors
gcloud builds log --project=${PROJECT_ID} $BUILD_ID
Git メインブランチが作成されていない
使用する git クライアントとクライアントのローカル構成によっては、最初に gitops ブループリントを git に保存しようとしたときに、メインブランチが作成されないことがあります。この問題を解決するには、Git リポジトリにメインブランチを作成するか、使用する代替ブランチ名を ConfigManagement オブジェクトの syncBranch フィールドに指定してから、ブループリントを再適用します。
ローカルでの実行
Cloud Build パイプラインによって送信されるよりも早く問題のフィードバックを送信する必要がある場合は、kpt を使用して次のコマンドを実行し、パイプラインをローカルで実行することもできます（ソース リポジトリのルートから実行します）。
kpt fn render ./landing-zone/
変更不可のフィールドとリソース
プロジェクト ID や VPC ネットワークの名前など、基盤となる Google Cloud リソースのフィールドには、変更できないものがあります。Config Connector は、そのようなフィールドの編集をブロックし、変更を有効にすることはできません。こうした変更不可フィールドの 1 つを編集する必要がある場合は、まず（Git で）元のリソースを削除し、続いて優先する新しい値で追加し直す必要があります。
Deployment と Config Sync
deployment リポジトリには、ランディング ゾーンを定義する完全にハイドレートされたリソースが含まれています。これらのリソースは、Config Sync を使用して Config Controller に同期されます。この同期プロセスのエラーは、nomos コマンドで確認できます。
nomos status
課金
ランディング ゾーンのブループリントでは、組織内で請求を管理するための適切な課金権限が自動的に設定されます。プロジェクトを請求先アカウントに関連付けることができない場合は、請求先アカウントが組織外に存在する可能性があります。このため、請求先アカウントを管理する権限を、projects サービス アカウントに直接付与する必要があります。
export PROJECTS_SA="$(kubectl get ConfigConnectorContext -n projects -o jsonpath='{.items[0].spec.googleServiceAccount}')"
gcloud alpha billing accounts add-iam-policy-binding $BILLING_ACCOUNT \
--role=roles/billing.admin \
--member="serviceAccount:${PROJECTS_SA}"
クリーンアップ
ランディング ゾーンの使用を停止する場合は、作成したすべてのリソースをクリーンアップする必要があります。Config Controller 自体を削除する前に、まず Config Controller からリソースを削除する必要があります。
または、宣言型ワークフローを放棄してランディング ゾーンのリソースを保持する場合は、必要に応じて Config Controller の削除の処理に直接進むことができます（ただし、これはおすすめしません）。
リソースの削除
リソースは、関連付けられているファイルをランディング ゾーンの Git リポジトリから削除するだけで削除できます。この方法は、個別のリソースまたはパッケージ全体で有効です。
ただし、ランディング ゾーン全体を一度に削除することはできません（誤って削除されることを回避するためです）。代わりに、以下の手順でランディング ゾーンのリソースを破棄する必要があります
# Delete downstream resources
git rm -rf ./landing-zone/logging/
git rm -rf ./landing-zone/network/
git commit -m "Delete downstream resources"
git push
# Confirm Config Sync successfully applies
# Delete projects
git rm -rf ./landing-zone/projects/
git commit -m "Delete projects"
git push
# Confirm Config Sync successfully applies
# Delete folders and organization policies, but leave the policy template (see below for why)
git rm -rf ./landing-zone/hierarchy/
find ./landing-zone/policies/ -type f -not \( -name 'folder-naming-constraint-template.yaml' \) -delete
git add ./landing-zone/
git commit -m "Delete hierarchy and organization policies"
git push
# Confirm Config Sync successfully applies
# Delete landing zone except for 1 cluster-scoped resource
# (folder-naming-constraint-template.yaml) and 1 empty namespace (projects.yaml).
# See /anthos-config-management/docs/reference/errors#knv2006
find ./landing-zone/ -type f -not \( -name 'folder-naming-constraint-template.yaml' -or -name 'projects.yaml' \) -delete
cat <<EOF > ./landing-zone/namespaces/projects.yaml
apiVersion: v1
kind: Namespace
metadata:
name: projects
EOF
git add ./landing-zone/
git commit -m "Delete all landing zone resources except 1 cluster-scoped resource and 1 namespace"
git push
# Confirm Config Sync successfully applies
# Delete remaining resources
git rm -rf ./landing-zone/
git commit -m "Delete remaining resources"
git push
Config Controller の削除
gcloud anthos config controller delete --location=us-central1 ${CONFIG_CONTROLLER_NAME}