Technical Blog テクニカルブログ
  1. HOME
  2. テクニカルブログ
  3. Google FormsとTerraformを使ってGCPプロジェクトを自動作成するシステムを構築してみた その①

Google FormsとTerraformを使ってGCPプロジェクトを自動作成するシステムを構築してみた その①

投稿者:今井

Google FormsとTerraformを使ってGCPプロジェクトを自動作成するシステムを構築してみた その①

初めに

こんにちは、CI部の今井です。
今年もアドベントカレンダーの季節がやってきましたね。
今回、私が書いているこの記事はNI+C AdventCalendar GCP/GWS Team 2022 Advent Calendar 2022の2日目の記事となります。
本記事では「GCPプロジェクトの作成」をいろいろなサービスを組み合わせて自動化したことをお話しさせていただければと思います。

本記事はその①と題して、GCPプロジェクトの作成がどうして必要なのかからどういったサービスを選択したかを記載させていただきます。
そして後半のその②では利用したコード等のお話をさせていただきます。

GCPプロジェクト作成について

GCPプロジェクト作成が申請され作成されるまでの手順の大まかな流れが自動化されていない場合を考えてみましょう。

  1. GCPプロジェクト作成の申請が来る
  2. 申請された内容に問題はないか確認する
  3. GCPコンソールへログインし、プロジェクトを作成する

おおまかには上記のような流れで作成すると思いますが、GCPを触ってみたことがある人なら手作業の内容が多いとわかるはずです。
この部分からできる限り人の作業を減らすことが今回のGCPプロジェクト作成システムの目的となります。

GCPプロジェクトの自動化システムについて

GCPプロジェクトを作成する上で大事な要素がいくつか存在すると私は考えています。
その一つに申請された内容が正しいか人が判断したかどうかです。

当たり前ですが、GCPプロジェクトを作成する上で申請されたときにプロジェクト名の希望を聞くと思います。
そうするとプロジェクト名にはいくつかの制限があるため、申請されたプロジェクト名がその制限の中の名前かどうか確認する必要があるはずです。

ということで、この自動化システムの中に手動で申請内容の確認するステップが存在しなければならないことになります。
そしてその確認内容はできるだけ簡単に行えることも重要です。
次からはどんなシステムを構築したかについてをご説明していきたいと思います。

GCPプロジェクト自動化システムの構築について

今回は以下の画像のようなシステムを構築しました。
このシステムは「Config Controller と Google Forms で Google Cloud プロジェクトを自動で作ってみる」の記事をご参考にして構築させていただきました。

社内プロジェクト作成自動化システム-Page-1.drawio.png

構築に関しての詳細はその②にて詳しく説明させていただきます。
流れとしてはGCPプロジェクト作成の申請はGoogle Formsからされ、その申請をトリガーにGoogle Apps Script(GAS)が動き、GitLabにMRが作成されます。
このMRでは新しく作成されるGCPプロジェクトの情報が含まれているため、その内容をレビューします。
そして、そのレビューがマージされることでGitLab CIが動きGCPプロジェクトが自動で作成されます。

使用しているサービスについて

Google Forms

今回の自動化システムではGoogle Formsをプロジェクト作成申請のインターフェースに利用しています。
このサービスを利用している理由はGASやスプレッドシートとの親和性が大きいこと、Googleファミリーのサービスであることが挙げられます。
GASはGoogle Formsに申請があったときにそれをトリガーとして実行することができ、さらにその時の申請内容をレスポンスとして取得することもできます。
スプレッドシートはGoogle Formsの回答内容を蓄積することができるため、申請履歴を管理するために利用します。

Google Apps Script

今回のシステムではGoogle Formsの申請内容をもとにGitLabのMRとして起こす役割にGASを利用しています。
GASはGoogleファミリーとの親和性のあるサービスのため前段での説明でもあった通りの利用の仕方ができます。
そしてGitLabとの連携はAPIの呼び出しという形で行います。

GitLab

今回はGitHubとGitLabのどちらかを利用して申請内容のレビューを行いたいと考えました。
そのうえで、なぜGitLabを選択したかとなりますが、参考にさせていただいた記事がGitHubだったので真似はしたくないと考えたということと社内実績としてGitLabの知見が豊富だったことが理由として挙げられます。
結局は申請内容のレビューを行うことが大事なのでどちらのサービスを選んでもよいと思いますし、どちらでもないサービスを選んでもよいと思います。
今回はGitLabのGitLab CIやGitLab Runnerを利用したいと考えて選びました。

Terraform

今回、自動化を行う上でIaCのサービスを使いたいと考えてTerraformを利用しています。
このサービスを利用している理由としてこれまた前段の理由と被っていて、参考にしている記事ではこの部分にGCPのサービスであるConfig Controllerを利用して被りたくなかったということと社内実績があったことが挙げられます。
私はIaCに明るくなかったので社内に頼ることができるエンジニアの方がいて本当に良かったと思っています。
本当にありがとうございました。

Workload Identity

今回、GitLabとGCP間の認証にWorkload IdentityというGCPのサービスを利用しています。
このサービスは特定の条件でのみGCPのサービスアカウントに成り代わることができる認証情報を提供することができ、GitLab CIにてその認証の取得を行っています。
このサービスを利用することでGitLabに機密性のあるサービスアカウントのJSONキーの情報の登録といったことを行わなくてよくなるため、とてもセキュアにサービス間の連携を行うことができます。
この部分に関しては「秘密情報をGitLabに格納することなくGoogle Cloud / AWSに対して認証する」を大変参考にさせていただきました。

最後に

その①ではGCPプロジェクトの作成がどうして必要なのかからどういったサービスを選択したかを記載させていただきました。
手作業やヒューマンエラーを減らし、できるだけ労力をかけず、エンジニアが違うことに時間をさけられるようになれば、この記事の目標は達成できたことになります。

その②では実際にどうやって構築したかを記載できればと思います。
よろしくお願いいたします。

ページのトップへ