【ITニュース解説】Experimenting with Terraform in YAML

システムエンジニアを目指す皆さんにとって、現代のITインフラを効率的に管理する技術は非常に重要だ。その中でも「インフラストラクチャ・アズ・コード（IaC）」という考え方は、サーバーやネットワークといったITインフラの構成をコードとして記述し、自動的に構築・管理する手法として広く使われている。TerraformはそのIaCを実現するための代表的なツールの一つだ。

Terraformを使えば、手作業でインフラを構築するよりも、ミスを減らし、再現性を高め、チームでの作業を効率化できる。しかし、実際にTerraformを運用していくと、いくつかの課題に直面することがある。特に、開発環境、テスト環境、本番環境といった複数の環境を管理する際に、それぞれの環境で異なる設定を扱うのが「驚くほど難しい (surprisingly tricky)」と表現されるほど難しいという問題がある。例えば、データベースの名前やサーバーのスペックなど、環境ごとに少しずつ違う設定を効率的に管理するための工夫が必要になる。この課題に対して、Terragruntのようなツールが解決策の一つとして検討されてきた。

また、Terraformが採用しているHCL（HashiCorp Configuration Language）という専用の言語は、比較的直感的で学びやすいものだが、countやforといった少し複雑な構文を使いこなすにはある程度の練習が必要だ。そして、このHCLはTerraformのためだけに作られた「ドメイン固有言語（DSL）」であるため、Terraform以外の場所でその知識やコードを再利用することが難しいという側面も持っている。

そこで今回の記事では、これらの課題に対し、全く異なるアプローチを試みている。それは、Terraformのプロジェクト定義をYAML形式で記述し、さらにyispというツールと組み合わせる方法だ。YAMLは、人間が読み書きしやすいデータ記述言語で、Kubernetesの設定ファイルなど、他の多くのIT分野でも広く使われている。YAMLとyispを組み合わせることで、Terraformのモジュールをより柔軟に定義したり、異なる設定を組み合わせたりすることが可能になると考えられている。この方法が実用的かどうかはまだ検証段階だが、環境ごとの設定差分を扱う新しい道を開く可能性を秘めている。

Terraformは通常、HCL形式で書かれた.tfファイルを読み込むが、実はJSON形式の設定ファイルも受け入れることができる。例えば、HCLで書かれたプロバイダー設定やリソース定義は、JSON形式に書き換えることが可能だ。記事では、HCLでterraformブロック（必要なプロバイダーを指定）、providerブロック（プロバイダーの設定）、resourceブロック（実際に作成するリソース、ここではローカルファイル）を定義する例と、それに対応するJSON形式の例が示されている。HCLが構造的にブロックを記述するのに対し、JSONはキーと値のペアで階層的にデータを表現する。このJSONファイルを.tf.jsonという拡張子で保存すれば、Terraformは通常通りterraform applyコマンドでそれを適用できる。このJSON互換性が、今回の実験の基盤となる。

次に、この実験で重要な役割を果たすyispについて説明する。yispは、YAMLファイルの中に式を埋め込んで評価する（計算させる）ことができる小さなツールだ。例えば、mynumber: !yisp [- add, 5, 3]というYAMLがあった場合、yisp build .というコマンドを実行すると、mynumber: 8という結果が出力される。これは、YAMLファイルの中にプログラミング言語のような計算処理を埋め込むことができることを意味する。yispは、複数のYAMLファイルをインポートして内容を結合したり、オブジェクトをマージ（統合）したりする機能も持っている。今回の実験では、yispを使ってTerraformのJSON設定をYAMLで記述しやすくし、さらに複数のファイルから設定を読み込み、環境ごとの差分を効率的に管理するために活用される。

具体的な手順の最初のステップとして、Terraformの設定を複数のYAMLファイルに分割して記述する例が紹介されている。terraformブロック、providerブロック、resourceブロックそれぞれを独立したYAMLドキュメントとして記述し、それらを一つのindex.yamlファイルで結合する。index.yamlでは、!yisp - lists.reduce - [- include, tf.yaml] - maps.mergeというyispの構文を使い、tf.yamlに含まれる複数のYAMLドキュメントを読み込み、それらの内容を一つの大きなオブジェクトに結合している。この結合処理によって、最終的にTerraformが受け付ける一つのJSON構造が生成される仕組みだ。

Terraformのコマンドは、設定を直接標準入力から受け取ることができない。必ずファイルとして提供する必要がある。そこで、このワークフローをスムーズにするためにMakefileを利用する。Makefileは、makeコマンドで実行できる一連のタスクを定義するファイルだ。記事の例では、yisp build . -o json > rendered.tf.jsonというコマンドを使って、yispが生成したJSON出力をrendered.tf.jsonというファイルに保存するルールを定義している。これにより、make initやmake applyといったコマンドを実行するだけで、裏側でYAMLからJSONへの変換が自動的に行われ、その生成されたJSONファイルを使ってTerraformの処理が実行される。

さらに進んで、開発環境と本番環境のように、環境ごとの設定差分をモジュール化して管理する方法が示されている。ディレクトリ構造は、共通設定を置くbaseディレクトリと、環境固有の設定を置くenvディレクトリ（その中にdevとprod）に分かれている。base/core.yamlには、共通のプロバイダー設定など、どの環境でも変わらない基本的な設定が記述される。base/localfile.yamlでは、yispのlambda機能を使って、パラメータを受け取って動的にリソースを生成するモジュールが定義されている。このモジュールは、例えばnameというパラメータを受け取り、その値を使ってファイルの中身を生成する。

そして、env/dev/localfile.yamlでは、このbase/localfile.yamlで定義されたモジュールをimportし、name: "alice"という具体的なパラメータを渡して呼び出している。最後に、env/dev/index.yamlで、共通設定の../../base/core.yamlと、開発環境固有のlocalfile.yamlの内容をyispでマージしている。この一連のプロセスにより、開発環境ではHello: aliceという内容のローカルファイルが生成されるようなTerraformの設定が動的に組み立てられる。本番環境の場合でも、env/prodディレクトリ内の設定でパラメータを変更するだけで、同じモジュールを再利用しつつ、異なる内容のファイル（例えばHello: bob）を生成することが可能になる。このように、yispの柔軟な機能を利用することで、Terraformの設定における環境ごとの細かな違いを、よりシンプルかつ効率的に管理できる可能性が見えてくる。

今回の記事で試みられた、yispとYAMLを使ってTerraformの設定を定義し、環境ごとの差分をモジュール化して管理するアプローチは、まだ実用段階かどうかは不明な部分が多いものの、非常に興味深い発見を提供している。この方法は、Kubernetesの設定ファイルにおけるkustomizeのように、設定のバリエーションを管理するための新しいアイデアをTerraformにも応用できる可能性を示唆している。この実験的な試みは、将来的に、複雑なインフラストラクチャをコードで管理する上で、より柔軟で再利用性の高い方法を模索するきっかけとなるだろう。