Config Controller と Google Forms で Google Cloud プロジェクトを自動で作ってみる — 前編 : 概要紹介 -
みなさん、こんにちは。本ブログ記事は Google Cloud のサービス紹介というよりは「〇〇 やってみた」系の内容です。具体的には、Google Cloud の組織管理者の業務が少しでも楽になるように、Google Cloud におけるリソース管理の仕組みであるフォルダやプロジェクトをガバナンスを効かせつつ自動でデプロイする仕組みを作ってみたという内容です。まずは前編として概要をご紹介し、次回の後編で実際の構築手順についてご紹介します。あくまでもひとつの案になりますが、少しでもご参考になれば幸いです。
TL; DR
- Google Cloud リソースは組織を最上位としてフォルダやプロジェクトで管理し、組織ポリシーを利用してガバナンスを効かせることをおすすめしています
- フォルダやプロジェクトの作成プロセスが手間になると組織に属さない野良プロジェクトが増え、ポリシーの適用外 (ガバナンスが効かせられない状態) となってしまいます
- 管理者と利用者の双方にとって手間のかからないフォルダやプロジェクトのデプロイ方法を試してみたのでご紹介します
1. はじめに
Google Cloud をご利用いただく場合、組織リソースを作成し、その配下にフォルダやプロジェクトを作成してリソースを管理いただくことをおすすめしています。この理由としては、例えばユーザーやリソース管理がシンプルになること、Google Cloud では組織が存在することを前提とした機能があること、さらには組織ポリシーを利用してガバナンスを効かせられることなどが挙げられます。
しかし、せっかく組織ポリシーを設定しているにも関わらず、管理者の関知していないところで組織に属さない (= 組織ポリシーの管理下となっていない) 野良プロジェクトが増えてしまっているというケースをよく耳にします。この要因は一概にひとつではありませんが、プロジェクトの作成手順が管理者やユーザー双方にとって手間のかかるものになってしまっていることなどが考えられます。手間のかかる作成手順とは、例えばプロジェクトを作成するために申請書を書いて管理者に提出、管理者は承認プロセスに則って承認するなどです。プロジェクトの作成に手間がかかるのでユーザーは野良プロジェクトを作ってしまい、ガバナンスが効かなくなります。
今回は、こんな課題を解決するためのひとつのシステム案をご紹介してみます。ざっくりとした概要図はこちらのとおりです。
2. Config Controller のご紹介
少し話が逸れますが、上記のシステムの説明の前に今回の主役となる Config Controller について簡単にご紹介します。Config Controller は、Configuration as Data (CaD) という考え方で Google Cloud のリソースをデプロイ、管理するためのサービスです。Google Cloud のリソースには、Compute Engine や Kubernetes Engine といったサービスのみならず、組織ポリシー、フォルダやプロジェクト、IAM なども含まれるので、今回はフォルダやプロジェクトのデプロイに Config Controller を利用しています。
Config Controller の特徴は、リソースをデプロイするだけではなく、リソースが本来あるべき状態 (管理者が定義) となっていない場合に自動で修復してくれる機能です。この機能により、例えば組織ポリシーが意図せず変更されてしまった場合でも本来の設定に自動で戻るため、セキュリティ インシデントを抑止することができたりします。
そのため、今回はフォルダやプロジェクトのデプロイのみならず、Config Controller で組織ポリシーの設定も行っています。自動修復の機能は設定変更による影響が大きくなりがちな組織ポリシーの管理には非常におすすめです。
Config Controller を紹介すると記事が長くなりますが、こちらのブログ記事で非常に詳しく紹介いただいていますので、ぜひ併せてご参照ください。
3. システム概要
話を戻し、今回作ってみたシステムのご紹介に移ります。このシステムは、Config Controller のチュートリアルとして用意されている以下の Blueprint を基に作成しています。
https://cloud.google.com/anthos-config-management/docs/tutorials/landing-zone
Blueprint は、組織ポリシーや共有 VPC、ロギングなど、Google Cloud を利用する上で非常に重要となるリソースや設定を Config Controller でデプロイするためのテンプレートです。ひとえにテンプレートと言っても単に組織ポリシーや共有 VPC、フォルダやプロジェクトなどのリソースの定義ファイルのテンプレートだけではなく、Cloud Build や Source Repositories など、リソースのデプロイ パイプラインに利用されるリソースも含めたテンプレートとなっています。
特徴的なのは、本来はひとつのみ必要な Source Repositories がふたつ存在することと Cloud Build を利用することです。 Blueprint では、kpt の仕組みを利用してリソースの定義ファイルを生成するよう構成されています。kpt を利用する場合、変数を含むテンプレート ファイルと、その変数に代入する値が key-value のペアで定義された setters.yaml というファイルを用意します。そして、テンプレート ファイル内の変数に setters.yaml で定義された変数値を代入 (レンダリング) することで最終的なファイルを生成します。
ユーザーがひとつめの Source Repositories (Source repo) にファイルを Push すると、それをトリガーとして Cloud Build 内で kpt のレンダリングによる Config Controller 用の定義ファイルの生成が行われます。そして、Cloud Build で生成された定義ファイルがふたつめの Source Repositories (Deployment repo) に Push され、そのファイルを基に Config Controller が Google Cloud リソースをデプロイします。
今回は上記の一連のパイプラインの一部 (Cloud Build と Deployment repo) やガバナンスを効かせるための組織ポリシーは Blueprint のテンプレートをそのまま使いつつ、Source repo については GitHub リポジトリを利用するよう変更しています。また、フォルダやプロジェクトを作成するためのテンプレートも Blueprint のものではなくより簡易なものを利用しています。
それでは、それぞれのサービスの役割などについてご紹介します。
3–1. Google Forms と Google App Script
Google Forms はユーザーがフォルダやプロジェクト作成の申請を行うためのインターフェース、Google App Script は Google Forms に入力された内容の自動取得と後続処理 (GitHub Actions) のトリガーの役割を担います。
Config Controller を利用する上で Google Forms の利用は必須ではなく、Git リポジトリへ直接定義ファイルを Push することでもリソースのデプロイは可能です。しかし、ユーザーが簡単にフォルダやプロジェクトの利用申請を行うことができ、また管理者が過去の申請情報を簡単に管理できる仕組みとするために今回は Google Forms を利用しました。(Google Forms では Submit された回答を Spreadsheet にエクスポートできるため、それをそのまま管理台帳として利用できます)
3–2. GitHub
GitHub Actions では Google App Script から送信されたデータ (ユーザーが Google Forms に入力したデータ) の取得や、そのデータを基に kpt 用の setters.yaml ファイルを生成します。この他、ユーザーが入力したデータを管理者が承認 / 却下する仕組みも必要なので Pull request の作成も行います。
また、GitHub リポジトリ自体は上述の通り Blueprint の Source repo の役割を担います。管理者が Pull request を承認すると生成されたファイルが main ブランチへマージされ、Cloud Build のパイプラインがトリガーされます。
3–3. Cloud Build
Source repo のファイルを基に kpt のレンダリングを行い、Config Controller がリソースのデプロイに利用するための定義ファイルを生成します。そして、生成した定義ファイルを Source Repositories (Deployment repo) に Push します。
3–4. Source Repositories
Cloud Build 内で生成された定義ファイルが格納される Git リポジトリです。Config Controller はこのリポジトリを定期的に確認し、現環境 (Config Controller が管理しているリソース群) の構成と差異が生じている場合にはその差異を修正します。
なお、Config Controller を利用して Google Cloud リソースをデプロイする方法として次の 2 つの方法があります。
a. kubectl apply コマンドで Config Controller クラスターへ定義ファイルを適用する (手動でのデプロイ)
b. Git リポジトリに定義ファイルを保存し、リポジトリと Config Controller を Sync させる (GitOps でのデプロイ)
簡単なテストでは手動でのリソース デプロイでも問題ないと思いますが、実際の環境では管理者の作業を減らすこと、リソース管理を一元化 (唯一の信頼できるソースとして Git リポジトリを利用) できることを理由として GitOps の利用をおすすめしています。
4. まとめ
概要紹介は以上となります。続いての後編では実際にサンプルを利用しながら一連のパイプラインの構築手順についてご紹介します。
https://medium.com/google-cloud-jp/configcontroller-selfdeploymentsample-part2-f1f8ebc3ce47
冒頭では野良プロジェクトの作成によってガバナンスが効かせられなくなるというユースケースをご紹介しましたが、例えば検証用のサンドボックス環境を作りたい場合でも有用な方法かと思いますので、少しでも参考になりましたら幸いです。
