【ITニュース解説】Mastering Terraform Stacks: Post-GA Command References Part 1

Terraform Stacksは、インフラストラクチャのデプロイをより効率的かつ抽象的に管理するための新しいツールである。これは、インフラをコードとして扱い、そのデプロイプロセスをより洗練された方法で制御することを目的としている。システムエンジニアを目指す初心者にとって、これはインフラの自動化と管理の未来を理解する上で非常に重要な概念だ。HashiCorpが提供するHCP Terraformというクラウドサービス上で動作し、コマンドラインインターフェース（CLI）を通じてさまざまな操作を行う。

このツールを使うためには、まずHCP Terraformの環境を整える必要がある。具体的には、HCP Terraformの組織を作成し、その中にプロジェクト（例えば「Default Project」など）を設定する。そして、スタックの操作に必要な権限を持つAPIトークンを生成する。これらの情報は、コマンド実行時にオプションとして渡すか、あるいは環境変数（TF_STACKS_ORGANIZATION_NAME、TF_STACKS_PROJECT_NAME、TF_STACKS_STACK_NAME、TF_TOKEN_app_terraform_ioなど）として設定することで、Terraform Stacks CLIに認識させる。

基本的な操作として、terraform stacks initコマンドは、Terraformの設定ファイルを準備する役割を果たす。これは、ローカルの作業ディレクトリをスタックが使える状態にするための初期設定だ。次にproviders-lockコマンドは、利用するプロバイダ（AWSやAzureなど、インフラを管理するためのプラグイン）のバージョンを固定し、異なる環境での一貫性を保つ。そしてvalidateコマンドは、デプロイ前に設定ファイルの構文が正しいか、間違いがないかをチェックする。これらのコマンドは、より高度な操作を行うための土台となる。

Terraform Stacksには、主要なコマンドとサブコマンドが用意されている。主要コマンドには、init、providers-lock、validateの他に、create（新しいスタックの作成）、list（既存スタックの一覧表示）、version（スタックプラグインのバージョン表示）、fmt（設定ファイルの整形）がある。 さらに、特定の機能に特化したサブコマンドとして、configuration（スタックの設定管理）、deployment-group（デプロイグループの管理）、deployment-run（デプロイ実行の管理）がある。これらはスタックの複雑なデプロイロジックを細かく制御するために使われる。

スタックの重要な構成要素として、いくつか定義がある。Componentsとは、スタックの一部となるインフラストラクチャのまとまり、つまりインフラの構成要素を意味する。Deploymentsは、スタック内のインフラをどこに、何回デプロイするかを定義する。Deployment Groupsは、複数のデプロイターゲットをまとめてグループ化し、それぞれのグループに対して特定の承認ルールを設定できるようにする。そしてConfigurationは、Terraformのバージョンやロックファイルなど、スタック全体を構成するすべての設定を指す。

実際にスタックを作成するには、tf stacks createコマンドを使う。例えば、tf stacks create -organization-name ne-devops -project-name "Default Project" -stack-name "manu-option1"のように、組織名、プロジェクト名、スタック名を指定して実行する。tfはterraformコマンドのエイリアスとして使われている。with-templateオプションを指定すると、ひな形の設定ファイルを自動生成する機能があるが、現状ではUI上での大きな変化は見られない。jsonオプションを使うと、コマンドの実行結果をJSON形式で出力できる。これは、他のシステムとの連携や自動化を行う際に非常に便利だ。スタック作成時には、バージョン管理システム（VCS）との連携が自動的に行われないため、手動でVCS接続を設定する必要がある点が今後の改善点として挙げられている。

作成したスタックの一覧を確認するには、tf stacks listコマンドを使う。このコマンドは、HCP Terraformの組織名を指定しないとエラーになるため、-organization-nameオプションが必須だ。実行すると、スタック名、ID、作成日時などが表形式で表示される。-jsonオプションを使えば、結果をJSON形式で取得できるが、現在のところJSON出力にはプロジェクト名が含まれていない。プロジェクト名でスタックを絞り込むことも可能だが、すべてのスタックがデフォルトプロジェクトに属している場合、フィルタリングしても表示内容は変わらない。

スタックを作成しただけでは、まだ何のインフラもデプロイされない。実際にインフラをプロビジョニングするには、configurationサブコマンドを使って設定ファイルをスタックにアップロードする必要がある。tf stacks configuration listコマンドで確認すると、初期状態ではスタックに設定アイテムは関連付けられていない。 設定ファイルをアップロードする前に、作業ディレクトリには.terraform-versionファイルが必要であり、tf stacks initコマンドを実行して初期化しておく必要がある。これらの準備が整った後、tf stacks configuration upload -stack-id st-31HY1439bDRVawexのようにスタックIDを指定して設定ファイルをアップロードする。アップロードが成功すると、その設定IDとシーケンス番号が付与され、HCP Terraform UIでデプロイの状況を確認できるURLが表示される。 speculativeオプションを付けてアップロードすると、実際のデプロイはトリガーされず、その設定がデプロイされた場合にどうなるかの計画（プラン）のみが実行される。これは、変更がインフラに与える影響を事前に確認したい場合に有用だ。 tf stacks configuration watchコマンドを使うと、アップロードされた設定に基づくデプロイの進行状況を、コマンドラインでリアルタイムに監視できる。これは、HCP TerraformのUIを開かなくても、デプロイの状態をすぐに把握できるため非常に便利だ。

多くのコマンドオプションを毎回入力する手間を省くために、TF_STACKS_ORGANIZATION_NAME、TF_STACKS_PROJECT_NAME、TF_STACKS_STACK_NAMEといった環境変数を設定することも可能だ。これは、CI/CD環境での自動化など、繰り返し同じ設定を使う場合に特に役立つ。

まとめとして、Terraform Stacksは、HCP Terraform組織に対して直接デプロイを管理するための統一されたCLIを提供し、従来のVCSベースのデプロイワークフローに代わる選択肢を提供する。これは、プラットフォームチームが開発チームの基盤となるインフラを管理する上で、新しいアプローチをもたらす可能性がある。しかし、現在の実装にはまだいくつかの制限がある。例えば、AWSのOU（Organizational Units）ベースのデプロイのようなシナリオでは、Terraform Stacksの採用が難しい場合がある。また、一つのスタックで最大20のデプロイ、デプロイグループあたり単一のデプロイという現在の制限も存在する。これらの制約が将来的に解消され、より広範な用途で利用できるようになることが期待される。