HashiCorp Cloud Platform (HCP)は最近、TFEプロバイダーを使ったTerraformワークスペース作成の自動化とオンボーディングモジュールの構築について詳しく説明した。このアプローチは、手動によるワークスペース作成の課題を解決するもので、運用をスケーリングするチームのボトルネックとなっていた。
HashiCorpのスタッフソリューションアーキテクトであるEmmanuel Rousselle氏は、ブログ投稿でこのアプローチについて説明した。アプリケーションチームのHCP Terraformワークスペース作成を自動化する方法を説明するために、Rousselle氏は架空のテック企業HashiCupsを例に挙げた。
現実の一般的なシナリオを連想すると、HashiCupsはHCP Terraformを使って最初のクラウドランディングゾーンの構築に成功している。プラットフォームチームがアプリケーションチームのオンボーディングを開始すると、彼らはプロセスを簡素化する必要性を認識する。手作業でワークスペースを作成する従来の方法は非効率的でエラーが発生しやすいため、チームは自動化ソリューションを検討することになる。
プロセスは、要件の徹底的な評価から始まる。プラットフォームチームはアプリケーションチームとミーティングを行い、HCP Terraformのワークスペースに対する理解度、環境ランドスケープ、インフラストラクチャの設定を変更する権限を持つべき人物を把握する。HCP Terraformのワークスペースは、各チームが特定のインフラリソースを管理する隔離された環境であり、それぞれが変更を追跡するための状態ファイルを保持する。
アプリケーションチームは3つの環境ランドスケープを採用し、3つのワークスペースを作成する必要がある。プラットフォームチームは、HCP Terraformワークスペースのデフォルト設定に関する追加要件も概説する。各アプリケーションチームは、ワークスペースの管理を担当するグループと、ワークスペースの使用に必要な権限を持つグループの、二つの異なるグループに分かれる。
オンボーディングモジュールの作成は、主要な設定ファイルの開発から始まる。variables.tfファイルは、application_id、admin_team_name、user_team_name、environment_namesを含む重要な変数を定義する。environment_names変数は、組織の要件に合わせて、prod環境を含むように検証される。
次に、main.tfファイルを使用して、ワークスペースとチームの権限を定義する。
resource "tfe_workspace" "workspace" { for_each = toset(var.environment_names) name = "${lower(var.application_id)}-${lower(each.value)}" description = "Workspace for the ${each.value} environment of application ${var.application_id}" allow_destroy_plan = each.value == "prod" ? false : true } data "tfe_team" "admin_team" { name = var.admin_team_name} data "tfe_team" "user_team" { name = var.user_team_name} resource "tfe_team_access" "admin_team_access" { for_each = toset(var.environment_names) workspace_id = tfe_workspace.workspace[each.value].id team_id = data.tfe_team.admin_team.id access = "admin"} resource "tfe_team_access" "user_team_access" { for_each = toset(var.environment_names) workspace_id = tfe_workspace.workspace[each.value].id team_id = data.tfe_team.user_team.id access = "write"}main.tfファイルの例（出典）
本番環境では、ワークスペースは、組織のポリシーに従って計画の破棄を防ぐように構成される。ワークスペースの命名は、文字列補間を使用して特定の規約に従う。この構成はチーム情報を取得するためにデータソースを利用するほか、別のアプローチとして入力変数にチームIDを利用しコードを簡素化できるが、可読性が低下する可能性がある。
Terraformモジュールはハードコードされた値の代わりに変数フィールドを使って異なるチームの環境に対応できる。さらに、Rousselle氏は、環境名を検証し、一貫した命名規則を強制するために、testsディレクトリの下に存在するTerraformテストについて詳しく説明した。これらのテストは、ワークスペース名が小文字であること、本番環境のようなクリティカルな環境が常に含まれていることを確認した。
さらに、テストスイートはいくつかの重要な機能のために作成される。まず、有効なTFEプロバイダ構成を提供し、必要な前提条件がすべて整っていることを確認する。次に、テストは、prod環境の欠落やproductionのような不正確な名前の使用など、無効な環境ランドスケープが正しく検出され、プラン操作が失敗することを検証する。
ついでに、HashiCorpはHCP Terraformと共に使用可能なTerraform 1.11の一般提供も発表した。この最新バージョンでは、書き込み専用引数を導入し、特定のマネージドリソース引数でエフェメラルな値を利用できるようにし、柔軟性と機能性を高めている。
最後に、2つの重要なファイルがモジュールのドキュメントをサポートする。README.mdとCHANGELOG.mdである。README.mdファイルは、モジュールの目的、使用方法、入力変数、出力、特定の要件や依存関係についての詳細な指示をユーザーに与える。一方、CHANGELOG.mdファイルは、すべての重要な変更と時間の経過に伴うバージョンの更新を追跡し、将来のユーザーに対して透明性とメンテナンスの容易さを保証する。
作者について
