はじめに 👋#
こんにちは、ニンバスです！ 7月になり暑い夏がやってきましたね。皆さんいかが過ごしいでしょうか？くれぐれも熱中症にはお気をつけくださいね。 今回は最近私がよく触っている「HCP Terraform」の概要について触れていこうと思います。この記事で少しでも「HCP Terraform」について知っていただけると嬉しいです。それでは、Let`s Dive in! 🦄
HCP Terraform とは？#
HCP Terraform の説明については Hashicorp 公式から解説されています。（以下、Google 翻訳）
HCP Terraform は、チームが Terraform を共同で使用できるようにするアプリケーションです。一貫性と信頼性のある環境で Terraform の実行を管理し、共有状態データやシークレットデータへの容易なアクセス、インフラストラクチャへの変更を承認するためのアクセス制御、Terraform モジュールを共有するためのプライベートレジストリ、Terraform 構成の内容を管理するための詳細なポリシー制御など、様々な機能を備えています。
これを私なりに解釈すると、「 HCP Terraform は Terraform の実行環境を提供する SaaS で、コミュニティ版 Terraform で実施していた State 管理や変数管理などの面倒くさいことを肩代わりしてくれるサービス 」です。
HCP Terraform の大きな特徴 🚀#
HCP Terraformの大きな特徴は、GitHub や GitLab といった Version Control Service（以下、VCS）と連携し、 PlanからApplyまでをGUI上の操作で完結できるワークフローを提供しているところだと思います。
コミュニティ版では、terraform コマンド(terraform plan や terraform apply など)を実行して、.tfファイルに記述したリソースを作成するかと思います。
このフローの直前には、VCS からリポジトリを clone したり、適切なブランチに切り替えたりといった作業があるかと思います。この作業は人間が実施することが多く、それを自動化するために GitHub Actions や AWS Codepipeline、Cloud Build などで独自のCI/CD パイプラインを構築・運用していたのではないかと思います。
HCP Terraform では VCSと連携することができ、連携したリポジトリ上で PR あるいは MR が行われたことをトリガーし、HCP Terraform上で terraform planが自動的に実行されます。また、main(master)ブランチにマージされると、それをトリガーして自動的にterraform planが行われ、承認プロセスを挟んでterraform applyが実行されます。このようにVCS上のリポジトリを信頼できるリソースとして、自動的にプロビジョニングができるワークフローを HCP Terraform が提供しているのです。
なぜ HCP Terraformを選ぶのか 🤔#
コミュニティ版でももちろんTerraformからリソースを作成することができます。ではなぜ、HCP Terraformを選ぶのでしょうか。それは、コミュニティ版にはない機能により、チーム開発や組織の生産性向上に寄与するとともに、ガバナンスを効かせることができるからです。
機能紹介#
全ての機能について紹介するとキリがないので、ここでは HCP Terraform ワークスペースの簡単な概要について触れたいと思います。
ワークスペース#
コミュニティ版においてもワークスペースという概念が存在しますが、HCP Terraformのワークスペースはそれとは似て非なるものです。 Hashicorp公式ではこのように説明しています。（以下、Google 翻訳）
ワークスペースとは、Terraform によって管理されるインフラストラクチャリソースのグループです。
少しわかりづらいかなと思いますので、図を用いて説明しようと思います。 例えば、以下のような Terraform プロジェクトがあったとします。
terraform
├── README.md
├── terraform.tf
├── main.tf
├── outputs.tf
├── providers.tf
├── static-web-hosting.tf
└── variables.tf
HCP Terraform のワークスペースでは、このプロジェクトの Terraform コードを実行することになります。つまり、一つのプロジェクトを一つのワークスペースとしてグルーピングされていて、個別ワークスペースはTerraform実行に必要なものが含まれています。そして、個別ワークスペースは作業ディレクトリのように機能します。ワークスペース内ではTerraformを実行するためのVMがリモートで起動し、そのVM上で Terraformが実行されます。
多くの場合、以下のようにリポジトリが論理的に分離されているかと思います。
- 本番用 Terraform プロジェクト
- テスト用 Terraform プロジェクト
- 開発用 Terraform プロジェクト
こういったケースに対して、ワークスペースもこのように作成することができます。
- 本番用 Terraform プロジェクト === 本番用 ワークスペース
- テスト用 Terraform プロジェクト === テスト用 ワークスペース
- 開発用 Terraform プロジェクト === 開発用 ワークスペース
変数（Variables）#
また、ワークスペースにはいくつか重要な機能がありますが、その一つが「変数（Variables）」です。
コミュニティ版ではAWS、GoogleCloudといったクラウドプロバイダーに対して何かしらのリソースを作成する際に、認証情報（クレデンシャル）を変数(.tfvarsなど)または環境変数に設定すると思います。HCP Terraformにおいても同様に認証情報（クレデンシャル）を設定しなければなりませんが、リポジトリに認証情報を含めることなくワークスペース内で「変数（Variables）」を設定することができます。
設定できる変数の種類は以下の通りです。
- Terraform variable …. 主に
.tfから参照する変数 - Environment variable …. Terraform が実行されるときに参照する環境変数
詳しくはHashicorp公式ドキュメントを参照すると良いでしょう。
各種プロバイダーの認証情報の設定方法はここでは詳しく触れませんが、Hashicorp公式からは動的クレデンシャル（Dynamic provider credentials）を利用することを推奨されています。
State管理#
もともとコミュニティ版 Terraform を触ったことがある方なら理解しやすいと思いますが、Terraform を実行すると同時に リソースの状態を記録する state ファイルが作成されます。この state ファイルは実行端末もしくはAmazon S3やGoogle Cloud Storageなどに保管されることが多いかと思います。しかし、HCP Terraformではこのstate ファイルをHCP Terraform上のワークスペースの中で暗号化し保管してくれます。
ポリシー#
Terraformの活用が進んでいるところであれば、Terraformのコード規約が作成されているのではないかと思います。また、AWS や Google Cloud といったクラウドプロバイダーの利用ガイドラインを組織の中で定めていたりすることもあると思います。そういった定められたルールを逸脱した Terraform コードがあった場合にどのようにルールを遵守させるのが良いでしょう。これまでは、厳格にコードレビューをしていたはずですが、あくまでもレビューするのは人間なのでどうしても全てを完璧にレビューすることは難しいです。
HCP Terraformでは「ポリシー」という機能を提供しています。Hashicorp 公式ドキュメントでは次のように説明しています。
このトピックでは、HCP Terraform のポリシーの概要について説明します。ポリシーとは、Terraform 実行のルールであり、Terraform プランがセキュリティルールとベストプラクティスに準拠していることを検証できます。
これだけだとわかりづらいので、少し補足します。コード規約やガイドラインなどで定めたルールをポリシーに落とし込むことができ、このポリシーはHCP Terraform上のワークスペースに適用することができます。ポリシーが適用されたワークスペース内でPlan/Applyが実行されたときに、HCP Terraformはその内容とポリシーを突き合わせます。ここで違反があった場合には、Plan / Applyを止めることができます。一言で言うと「ルールに違反しているコードは、実行させない」ということができるのです。
このポリシーを作成する際には、ポリシー言語である「Sentinel」もしくは「OPA」がサポートされています。
どちらの言語にもポリシーの適用レベルを設定することができます。
Sentinel であれば、適用レベルは以下の3つを設定することができます。
- Advisory … 推奨レベル
- Soft Mandatory … 必須だが承認があればその限りではない
- Hard Mandatory … 例外なく必須
OPA であれば、適用レベルは以下の2つを設定することができます。
- Advisory … 推奨レベル
- Mandatory … 例外なく必須
（私は柔軟に適用レベルを設定したかったのでSentinelを利用しています）
このポリシーを活用することで、Policy as Codeを実践することができ、組織やチームに対してガバナンスを効かせることができます。 私が現在いる組織では、「Terraformコード規約」や「クラウドコスト最適化ガイドライン」をポリシーに落とし込んで、ガバナンス強化とコスト最適化を実践しようとしています。（この話は、機会があればどこかで詳しく書きたいです😀）
料金体系#
HCP Terraformにはいくつか料金プランが用意されています。
無料プラン#
Hashicorp 公式ドキュメントでは次のように説明されています。
小規模なチームでは、リモート Terraform 実行、VCS 統合、プライベート モジュール レジストリ、シングル サインオン、ポリシー適用、タスク実行など、HCP Terraform のほとんどの機能を無料で使用できます。無料組織では、管理対象リソースは500個までに制限されています。詳細については、「管理対象リソースとは」をご覧ください。
個人開発で、手軽にTerraform実行環境を用意したい場合には無料プランで十分だと思います👍🏻
有料プラン#
無料プランでは開放されていない機能を利用したい場合は有料プランを検討してください。Hashicorpでは次のプランが用意されています。
- Standard
- Plus
- Premium
- Enterprise
各プランの比較については Hashicorp 公式ページに掲載されているので、下のリンクから参照ください。
私の知人によれば企業レベルになると、Plus以上を契約することが多いようです👀
まとめ 💡#
いかがでしたでしょうか？まだまだ紹介したい機能がたくさんありますが、少しでも HCP Terraformについて知ってもらえたのであれば嬉しいです。今後も HCP Terraformについて発信していきたいと思いますので、続報をお待ちいただければと思います。それでは、また次回お会いしましょう！See ya 👋🏻