Terraformのループ記法を基礎から学ぶ

Terraform のコーディングにおいて、似た構成の複製をどのように表現するかは結構重要な課題です。放っておくと汚いコピペだらけになっていくからです。

色々な目的とやり方があると思いますので、その表現を実現するためのパーツにでもなればと思い、学習用教材的に書いてみるやつでございます。




目次

説明はそんなに多くないですが、コードのせいで縦長になったので目次を置いておきます。Terraform バージョンは v1.5.7 で動作確認しています。



単体の複製

あるリソースに対して、単体の場合は count や for_each を使うことで、list や map の値を使いつつ複数のリソースを作成することができます。

count

直に数値を指定したり、list の数だけ作成できます。


リソースは 0 から始まる数値で管理されるので、同じ数だけ作る関連リソースでは、数値を合わせるように参照します。


for_each

map を指定して、その key の数ぶんを作成でき、each で key / value を利用可能です。


リソースはキー名で管理されるため、参照する場合もキーを指定します。


for_each はリソース内のアイテムを複数指定するのにも使えますが、今回は別の話なのでオマケの紹介です。



セットの複製

複数のリソースでセットを作る場合、2つ目以降を作るのにコードを丸っとコピペしていると煩雑になっていくため、module で一括りに利用できるようにします。

module

module 用のディレクトリとコードを作成し、


source と variable を指定して利用できます。新しい module 利用の前には、terraform init を実行する必要があります。


count + module

module を利用する際にも count や for_each で複数セットを作ることが可能です。



条件分岐

三項演算子があるので、複製構造と合わせて使うことで、より柔軟な構成をすることが可能になります。

三項演算子

フラグを仕込んでコード丸ごと削除やコメントアウトしないでよくしたり、


実行環境ごとに作るか作らないかを制御できます。


入れ子

入れ子構造にすることも可能です。( ) は無くても動きます。



ループ構造

list や map のループ処理として for があります。ただし、処理中に何かを作成することはできなく、list や map として変数を作り直すための機能です。

for

list を処理したり、


map を list で返したり、


map を編集した map で返したり、


ちょっと使いづらいけど、入れ子も可能。


ワンライナーじゃなく、改行で整えることも可能。


入れ子の反対方向の出し子も可能で、型の扱いが少し異なります。詐欺みたいですが使い道はあります。



複製の方法

基本的には以上の方法を駆使して表現していくわけですが、リソース作成を実現するだけなら、どのような方法でも可能です。

単にリソースの作成/削除をするにも、フラグで制御するのか、コメントアウトするのか、コードや .tf ファイル丸ごと消すのか、といった選択肢があります。

複数のリソース管理では、count, for_each, module, コードや .tf ファイルの丸ごとコピペ といった選択肢があります。

コーディングの基本として、同じ構成の処理は極力書かない、というものがありますので、少なくともコピペは避けたいところですが、module だらけにするのもコーディングしづらいものがあり、リソース間の細かい違いを吸収しつつコードを重複させないバランス感覚はなかなか難しかったりします。

Terraform 自体がコーディングしやすいよう進化し続けているのもあり、私も構成としては既に三代目に突入しており、for と for_each があることでようやくマシになってきた感触があります。

それにより運用自体は設定の編集だけで済むようになりましたが、代わりに resource の記述は黒魔術気味になりました。続けて、その黒魔術部分を分解して理解を深めておきたいと思います。


階層構造

設定値でリソース作成を済ますということは、設定が複雑になっても大丈夫ということで、階層構造をいかに実現するかという話になります。

Pythonの入れ子ループ

階層構造の設定を以下のように作成した場合、2段のループを行うことで3回の結果を得ることができます。


結果はこうで、簡単すぎてアクビがでちゃいます。


こんな初歩中の初歩をあえて書いたのは、terraform では急に難しくなるからです。

Terraform の入れ子ループ

同じように Terraform で設定を書くとこうなります。


ゴールとしては、for_each に map を渡すことになりますが、素直な方法では設定内容の値を余すことなく使うことはできません。

それは for_each の中で for_each を使うような入れ子構造にできないことが大きな理由です。for_each には最下層の3個がキーとなる map を渡さなくてはなりません。


色々試しましたが、まず最下層から無理やり3個の list として取り出すしかありません。こうしてから……


こうじゃ!見事に3個になりました。


でもこれだと、肝心のキーが2階層分、消失してしまうので無理やり継続利用できるように埋め込みます。


だいぶ雰囲気が出てきましたが、まだ map になっていないので、キーをユニークにした map に編集してあげます。


これで resource の for_each に渡してあげれば、キーが管理名になり、each.key や each.value[“name”] で値を思う存分に使うことができます。ね、簡単でしょう?


続・階層構造

ここまででも、わりと気持ち悪い感じのコードになりましたが、さらなる発展例で泥沼に潜り込みます。

最下層の設定に、schedules を追加しました。Autoscaling 用のイメージで、各Roleごとに複数のスケジュールを登録できるようにします。


さきほどのままの map だと、スケジュール個数分の map になっていないので、ここからさらに絞り上げる必要があります。

schedules が存在する設定に絞り込み、かつキー情報を引き継いでいって、最終的にユニークなキーの map に仕上げます。


name はこのスケジュール・リソース用の名前で、target はそれを登録する Autoscaling リソースの名前って感じです。これに cron 形式の情報などを追加すれば、あとは for_each に渡していかようにでもヤリクリできます。

複雑なように見えますが、同じことを2回やっているだけです。map を同列に組み直すために flatten() を使い、merge() で情報を引き継ぎ、最後に key / value に仕上げています。設定に項目を書かなくても大丈夫なように if contains() を使ったり、小賢しいこともわりと組み込んでいけるので、不可能なことはそうない気がします。



できるだけ設定値だけでリソース管理をしようとすると、その分は resource 側が複雑になりますし、逆に設定側の手間を増やせば resource 側をシンプルにできるので、それは目的とお好み次第です。

今回はわりと汚らしい例まで踏み込んでみましたが、このくらいやるべきって話ではなく、どのような表現が可能なのかを知っておくことで、無駄のある構成を回避したり、構成を諦めたりしなくて済むようにしておきたいですねって感じです。

キレイにまとまったと思いますが、これでもだいぶ苦労しましたし、これを書きながらも理解を深めて修正もしたので、やはりシステムはただ動けばいいやってモノじゃないってのを実感した回でした:-)