インフラ定義ツール「Terraform」を活用し、顧客との環境を構築
続いて、顧客に対する取り組みとして、Cloud Build、TFCを利用した業務環境の共有について紹介された。
grasysでは、顧客とのコミュニケーションはリモートツールを使うことが基本となっており、以下のツールが日常的に使われている。
- 作業依頼や障害連絡 ⇒ Slack、Chatwork
- 定例会議 ⇒ Google Meet、Amazon Chime
- 議事録 ⇒ Google Docs
- 作業証跡 ⇒ Backlog、Jooto
- ナレッジ ⇒ DocBase
また、コミュニケーションツールだけでなく、顧客の業務環境もクラウドを利用して、完全に共有している。例えば、GCPを利用した場合は以下のツールが使われている。
- 業務インフラ ⇒ GKE、GCE
- インフラの構築 ⇒ Terraform、Terraform Cloud
- リソース管理は ⇒ CSR、GCR、GS
- CI/CD環境の実現 ⇒ Cloud Build
顧客に提供する業務環境には、まずインフラの構築が必要となる。業務環境は、開発、テスト、本番など複数の環境を構築する必要があり、同じ構成であることが望ましい。ただし、複数の同じ環境を構築するには、構築手順や必要なパラメータなどを管理することが重要だ。
もしこれが不十分だった場合、構築する担当で異なった構成の環境が作成されてしまう可能性もある。そのため、環境の構築手順やパラメータを一元管理し、管理されたデータをもとに、環境を自動的に構築するツールの導入が望まれる。
HashiCorp社が開発する「Terraform」はこのような環境構築の要望に応える、同一構成のインフラ構築を容易にするインフラ定義ツールだ。また、Terraformで使用するリソース定義ファイルなどをクラウドで管理し、インフラの構築作業を共有できるクラウドサービス「Terraform Cloud」もある。
Terraformには、定義ファイルに構築したいリソース、例えばネットワーク、VM（Virtual Machine）、Kubernetesクラスターなどのパラメータを定義し、インフラ環境を自動的に構築する機能がある。
佐藤氏は、Terraformの基本構成について、リソースの定義ファイル作成や構築に必要なパラメータ、リソース定義、パラメータ設定などの解説を行った。
作成したリソース定義ファイルをTerraformで実行する前に、使用するTerraformのバージョン指定と、リソース作成先であるGCPなどの環境との連携を設定する必要がある。
「TerraformはHashiCorp社にて、逐次機能の追加と改良が行われ、Terraformのバージョンにより、リソース定義ファイルの文法が異なる場合があります。そのため、作成したリソース定義ファイルの文法に適合するTerraformのバージョンを指定する必要があります」（佐藤氏）
Terraformは、以下の3ステップで簡単に実行することができる。
- terraform init ⇒ 初期化およびプラグインなどの取得およびロードを実行
- terraform plan ⇒ リソース定義ファイルや変数定義ファイルなどのチェック、構築されるリソースを確認
- terraform apply ⇒ リソースの構築
このように便利なTerraformだが、ローカル環境で実行されるため、リモート環境下では注意が必要だ。複数人で定義ファイルや実行履歴を管理するには、共用サーバーや共用ストレージを用いるなどTerraform以外のリソースが必要となる。そこで登場するのがTerraform Cloudだ。
Terraform Cloudは、リソース定義ファイルと構築の実行の管理を「Workspace」と呼ばれる単位で管理する。それぞれのWorkspace内に、Version Controlとして、リソース定義ファイルの履歴を管理するリポジトリと、Terraformを自動的に実行するトリガーの設定が可能だ。さらに、Terraformの実行時に、パラメータの変数値として読み込まれる、.tfvarsファイルの指定や、GCPなどのリソース作成先にアクセスする権限の登録も可能となる。
Terraform、Terraform Cloudから実行するメリットの一つは、Terraformの実行履歴の保存が可能なこと。個々の実行履歴には、terraform init、terraform plan、terraform applyの実行ログが保存され、簡単に参照することができる。
また、Terraform Cloudには、.tfstateファイルも用意されているため、リソース先でのリソースの削除も、ワンクリックで簡単に実行することが可能だ。Terraform Cloudの利点をまとめると以下の3つが挙げられる。
- Workspaceにより、各担当者別に構築されたリソースを一括して管理できる
- Terraformの並行実行を容易に管理できる
- Terraformの実行ログや、リソース定義ファイルの履歴管理が容易にできる
Cloud BuildによるCI/CDの実行
Cloud BuildはGCPが提供するCI/CD環境で、多種多様なリポジトリやクラウドストレージからソースコードを取得し、ビルド構成仕様に合わせてビルドすることができる。
「DockerコンテナやJavaアーカイブなどのアーティファクトの自動生成が可能であり、GKEやAppEngine、CloudFunctionといったGCPのインフラ環境や、他のクラウドサービスのインフラ環境への自動デプロイが可能です。以下の図は、私が実際に業務で利用したCloud Buildの構成図になります」（佐藤氏）
佐藤氏は、トリガー起動設定やビルド／デプロイを実行する手順などの説明を行い、Cloud Buildについて以下のように述べた。
「Cloud Build実行時のファイルやスクリプトの一時保存スペースとして、Workspaceが利用可能です。Cloud Buildの実行を起動するためには、リポジトリへのpushなどのトリガーによる自動実行以外に、GCPコンソールからのトリガーの手動実行や、gcloud build submitコマンドでの実行も可能。gcloud build submitコマンドでの実行の場合は、実行の作業エリアがWorkspaceではなく、gcloudコマンドを実行するローカルマシンの環境を使用することになります」（佐藤氏）
また、リモートワークでCloud BuildとTerraform Cloudを使用するメリットとして、最初の定義やトリガーの設定などを一度実行してしまえば、構築する環境のパラメータを設定するだけで、同一構成のインフラ環境および、開発対象のコンテナイメージのビルドやデプロイが可能であることを挙げた。
さらに、インフラの構築およびソフトウェアのビルド・デプロイの完全自動化が可能となり、ほぼワンクリックで実行できること。開発したソースファイルや設定ファイルなどは、共用リポジトリなどで管理が可能となり、ビルドやデプロイの履歴管理およびブランチ作成による個人用の個別開発環境の作成も容易に実施できることが説明された。
最後に佐藤氏は、新型コロナ感染症の感染拡大が収束しても、ニューノーマルと言われるリモートワークは継続する可能性が高いことから、地方に住む優秀なエンジニアの採用や、環境の共有が容易なクラウドを活用していきたいと語り、セッションを締めた。
Google Cloud INSIDE Games & Apps 登壇情報
4月13日に開催されるオンラインイベント「Google Cloud INSIDE Games & Apps」に、grasysのエンジニアが登壇します。
