【ITニュース解説】TERRAFORM ACTIONS : The HashiConf '25 Drop We’ve All Been Waiting For!!!!

HashiConf '25というイベントで、HashiCorp社から「Terraform Actions」という新機能が発表された。これは、Terraformを使ったインフラ管理に大きな変化をもたらす重要な機能である。これまで多くのエンジニアが感じていた課題を解決するものと期待されている。

Terraformは、コードを使ってインフラを構築・管理するためのツールだ。その基本的な考え方は、「不変なインフラ」というもので、一度作成したインフラは変更せず、もし変更が必要なら、現在のインフラを破棄し、新しい設定で再作成するという方針を意味する。このアプローチにより、インフラの状態が予測しやすくなり、手作業によるミスが減るというメリットがあった。Terraformの主要な操作は「apply」（インフラの作成・変更）と「destroy」（インフラの削除）の二つであり、この間に特別な操作を行うことは推奨されていなかった。

しかし、実際の運用現場では、インフラの作成や削除の間に特定の操作が必要となる場面が頻繁に発生する。例えば、新しいデータベースインスタンスをデプロイした後には、データの移行作業が必要になるかもしれない。あるいは、システムを停止させずにセキュリティに関わるパスワードや認証情報（シークレット）を定期的に更新したい場合もある。また、インフラの設定ファイル（.tfファイル）を直接変更せずに、一時的に設定を調整したり、特定のサービスを呼び出したり、EC2インスタンスを停止したり、キャッシュを無効にしたりといった作業が必要になることもあった。

これまでのTerraformでは、これらの「インフラ作成・削除以外の操作」を行うための公式な手段が限られていた。エンジニアたちは、このような要求に対応するために、いくつかの工夫を凝らしてきた。例えば、「プロビジョナー」という機能を使う方法があった。これは、インフラが作成された後などに、仮想マシン上でスクリプトを実行するといった操作を可能にするものだった。しかし、HashiCorpの公式ドキュメントでさえ、「できるだけ使用しないように」と推奨しないほど、プロビジョナーは扱いにくいとされてきた。インフラのコードに直接関係のないスクリプトが混在したり、エラー発生時のデバッグが困難だったり、インフラのライフサイクルに密接に結合されてしまうため、柔軟性に欠けるという問題があった。これらは、一時しのぎの解決策と感じられていた。

また、既存のLambda関数を呼び出す例で考えてみよう。dataブロックでLambda関数を呼び出す方法は、Terraformの設定適用時に毎回実行されてしまい、必要な時にだけ呼び出す柔軟性に欠けた。また、resourceブロックとして定義する方法は、インフラ作成時に一度だけ実行され、その後の再実行は難しいため、オンデマンドな操作には向かなかった。いずれの方法も特定のリソースのライフサイクルに縛られ、意図しない実行や、実行したい時の不実行という課題があった。

そこで登場したのが「Terraform Actions」である。これは、HashiCorpが、これらの操作を公式にサポートする方法を提供しようと認めたかのような新機能だ。Terraform Actionsは、Terraformの設定言語であるHCLの中に、新しい「action」ブロックとして定義できるようになった。このブロックを使うことで、インフラが作成されてから削除されるまでの間に、どのような操作を実行すべきかを明確に記述できるようになる。

具体的な用途は多岐にわたる。例えば、新しいデータベースインスタンスをデプロイした直後に、データベースのスキーマ移行スクリプトを実行できる。これは、インフラのデプロイとアプリケーションのデプロイの連携をスムーズにする。また、システム全体を停止することなく、APIキーやデータベースのパスワードなどのシークレットを安全に更新することも可能になる。これまで難しかった、インフラの不変性という原則を保ちながら、安全にインフラの設定を微調整するといった操作もできるようになる。さらに、AWS Lambda関数の呼び出し、AWS EC2インスタンスの停止、AWS CloudFrontのキャッシュ無効化など、クラウドプロバイダが提供する様々な「特定の操作」をTerraformの管理下で行えるようになる。

Terraform Actionsはまだベータ版であり、Terraform v1.14.0-beta2というプレリリースバージョンで提供され始めたばかりだ。AWSプロバイダでは、執筆時点では aws_lambda_invoke（Lambda関数の呼び出し）、aws_cloudfront_create_invalidation（CloudFrontキャッシュの無効化）、aws_ec2_stop_instance（EC2インスタンスの停止）の3つのアクションが初期的に利用できる。今後、さらに多くのアクションが各クラウドプロバイダから提供されることが期待される。

では、実際に新しいTerraform Actionsを使うとどうなるのか。Lambda関数を呼び出す例で考えてみよう。これまでは、前述のようにデータブロックやリソースブロックを使ったり、プロビジョナーで外部コマンドを実行したりと、様々な工夫が必要だった。しかし、Terraform Actionsを使えば、action "aws_lambda_invoke" "test" { ... } のように、独立したactionブロックとして定義できる。

このactionブロックは、他のリソースのように常に実行されるわけではない。必要に応じてTerraform CLI（コマンドラインインターフェース）から明示的にトリガーできる。具体的には、terraform apply -invoke=action.aws_lambda_invoke.test のように、-invokeフラグを使って実行したいアクションのアドレスを指定するだけだ。これにより、インフラの作成・削除というメインのライフサイクルとは独立して、特定の操作をオンデマンドで実行できるようになる。もちろん、必要であれば、このアクションを特定のリソースのライフサイクルに紐付けることも可能だ。

Terraform Actionsが大きな進歩だと感じられる理由はいくつかある。第一に、これまで「応急処置」で対応していた様々なタスクを、Terraformの内部でクリーンかつネイティブに実行できるようになることだ。これにより、外部のシェルスクリプトやSSHコマンドを無理やり組み込む必要がなくなる。第二に、特定のタスク（Lambda関数の呼び出し、シークレットのローテーション、EC2インスタンスの起動/停止など）を、インフラ全体の「作成・削除」というライフサイクルから切り離して、必要な時にだけ実行できる柔軟性が得られる。第三に、これらの操作がTerraformの設定ファイル内に明示的に記述されるため、インフラの設定と一緒に管理され、誰でもその内容を確認できる。これにより、隠れたスクリプトによる操作がなくなり、監査性が向上する。最後に、Terraform ActionsはCI/CD（継続的インテグレーション・継続的デリバリー）パイプラインに自然に組み込むことができるため、より安全で、簡単に、そして従来の方法よりもはるかに安定した形で、これらの操作を実行できるようになる。

Terraform Actionsは、プロバイダによって定義される。これは、AWSやGCPといったクラウドプロバイダが、Terraformの通常のCRUD（作成、読み取り、更新、削除）モデルの枠外にある、特定の「命令的な」操作（例：Lambda呼び出し、CloudFrontキャッシュ無効化）を、actionブロックとして提供することを意味する。ユーザーはこれらのアクションを設定し、リソースのライフサイクルに合わせてトリガーするか、あるいはCLIの-invokeフラグを使って手動でトリガーするかを選択できる。

Terraform Actionsはまだベータ版で、利用可能なアクションも限られているが、これまでの課題解決に向けた重要な一歩である。インフラ管理をより洗練されたものにすることが期待される。