HCP TerraformのNo-code provisioningのリソースライフサイクルをまとめてみる
2025.01.28No-code provisioningとは
ざっくり説明すると、事前に用意したmoduleに対してHCP TerraformのGUI上から値を渡してリソースを作成できる機能です。
No-code provisioningを利用することで、Terraformに慣れていないユーザーも事前定義された構成でインフラリソースを作成できます。
No-code Moduleとは
HCP Terraformでは、Moduleを組織内で公開するPrivate Registryという機能があります。
Private RegistryにModuleを登録する際に、No-code provisioningを有効化するかどうかを選択できます。
No-code provisioningが有効化されたModuleはNo-code Moduleと呼ばれます。
登録・更新・削除の方法は、通常のModule(No-code provisioning無効)と同様です。
No-code Moduleに適しているModule
特定のユースケース向けに作成されたModuleに適しています。
HashiCorp社のドキュメントでは、3層Webアプリケーションに必要な全リソースや、リソースやリージョン制約があるDBインスタンス等が例に上がっていました。
- Deploying all resources needed for a three-tier web application
- Deploying a database with constraints on resource allocation and deployment region
Design no-code ready modules | HashiCorp Developerから引用。
個人的には、ユーザー側が設定する変数(variables)の数が少ないModuleが向いていそうです。
変数が多いとTerraformコードを読み解いて、どんなロジックになっているかを確認する必要があります。対象ユーザーはTerraformに慣れていないため、ハードルが高いです。
逆に向いていないパターンとしては、汎用性の高いModuleを挙げられそうです。
汎用性を高めるためには、どうしても変数やロジックの数が多くなってくるためです。
No-code provisioningで作成したリソースのライフサイクル
No-code provisioningを実行すると、Workspaceが作成されます。
このWorkspace上で、Terraformの実行やStatefileの管理が行われます。
これを念頭において、作成されたリソースのライフサイクルを見ていきます。
リソース作成
- No-code Moduleを選択し、No-code provisioningを実行
- Workspaceが作成される
- Workspace上で、Terraformが実行されリソースが作成される
「1.」でユーザーはVariablesやWorkspace作成先のProjectを設定して、No-code provisioningを実行します。
「1.」で設定したVariablesは、自動でWorkspaceにWorkspace Variablesとして登録されます。
以下は、VCSにGitHubを使ってAmazon RDSをNo-code provisioningで作る際の流れです。
リソース更新
No-code provisioningでは、通常のModule利用と違いModule呼び出しのコードが存在しません。
「コードがないならリソース更新はどうするの？」と疑問に思うかもしれません。
以下2つの方法で、リソース更新が可能です。
- Module更新
- Variables更新
Module更新
Private Registryに登録したModuleが更新されると、Workspace側で更新が可能になります。
「View Details」の部分を選択し、変更内容を確認すると、WorkspaceでPlan/Applyが行われます。
アップデートが可能なタイミングについて、もう少し補足します。
Moduleの新バージョンを公開後に、「No-code provisioning」の設定画面で、エンドユーザーが利用できるModuleを変更する必要があります。
変更しないと既存や新規Workspaceに反映できないため、ご注意ください。
Variables更新
No-code provisioning時に、Variablesにセットした値はWorkspace Variablesとして設定されます。
このVariablesはWorkspace作成後に更新可能です。
更新後に、WorkspaceからTerraform実行を手動でトリガーすることでリソースが更新されます。
リソース削除
こちらは、通常のWorkspaceと同様です。
Destroy Runでリソースを削除できます。
Tips: No-code provisioningで作成されたWorkspaceの設定を確認してみる
特徴的なのはOverviewの部分かと思います。
「Workspace provisioned via no-code workflow」の表示があり、No-code provisioningで作成されたことがわかります。
利用したModuleについても、表示されています。
ちなみに通常のWorkspaceは以下のような表示です。
ほとんどの設定はGUIからWorkspaceを作ったときのデフォルト設定と同様です。
「Auto-apply API, CLI, & VCS runs」が有効になっている点が特徴です。
これは、Apply前の手動承認をスキップする設定です。
デフォルトはAuto Applyが有効ですが、Provisioning時にManual Applyを選ぶこともできますし、Workspace作成後に変更することも可能です。
おわりに
No-code provisioningは名前からリソース作成に注目されることが多いと思います。
今回はリソース作成後の、更新方法についても調べてみました。
セルフサービスでインフラ構築できる一方、コードが無い分通常のリソースとは異なる運用が必要になります。
No-code provisioningの仕様も考慮して、Moduleを設計していきたいですね。
以上、AWS事業本部の佐藤(@chari7311)でした。)
