適用前にふるい落とす三つ

一言でいうと

fmtは書式を、validateは構造を見ます。どちらも値は見られず、その隙間をconsoleが埋めます。

なぜこのような検査が別に必要だったのか

適用してみなければわからない事故は、高くつきます。プランを立てるには、プロバイダーを取得し、状態を読み、リモートなら、ロックまで取る必要があります。ところが、実際に起きるミスの相当数は、設定ファイルを読むだけでわかるものです。宣言していない変数を参照した、必須の引数を抜かした、文字列の場所にリストを入れた、といったものです。こうしたもののために、プランまで進むのは、無駄です。

書式は、性格が違います。間違っているのではなく、ばらばらなことが問題です。設定言語を使うチームが、インデントのルールを会議で決め始めると、その時間は戻ってこず、成果物であるレビューのdiffは、内容ではなく空白で埋まります。そこで、ツールが、正解を1つに決めておきました。議論の余地をなくしたことが、このコマンドの設計意図です。

どう動くのか

tofu fmtは、デフォルトでファイルを直します。判定だけをしたければ、確認モードを使い、このとき、終了コードが3つに分かれます。

tofu fmt -check -diff -recursive   # 고치지 않고 판정만
# 0 : 고칠 것이 없다
# 3 : 고칠 것이 있다
# 2 : 파일을 읽을 수조차 없다(문법 오류)

ゲートで使うときに、2と3を区別すると、メッセージがはるかに親切になります。3は「書式のコマンドを一度実行してください」で、2は「このファイルは、そもそもパースできません」です。サブディレクトリまで見るには、再帰オプションが必要です。なければ、ルートのファイルだけを見ます。

tofu validateは、プロバイダーのスキーマが必要なので、initを先に行う必要があります。初期化していないディレクトリで実行すると、プロバイダーがないと言います。捕まえてくれるのは、3種類です。

Reference to undeclared input variable   선언 안 한 var.xxx 참조
Missing required argument                필수 인자 누락
Incorrect attribute value type           스키마와 타입 불일치

機械が読む形式もあります。-jsonを与えると、valid、error_count、warning_countと診断の一覧が出るので、CIがそのまま判定したり、レビューに貼ったりできます。

重要なのは、捕まえられないものです。validateは、状態も実物も見ず、変数の値も知りません。そのため、次の設定は、何の問題もなく通過します。

variable "seed_path" { type = string }

resource "local_file" "out" {
  filename = "${path.module}/out.txt"
  content  = file(var.seed_path)
}

構造は完璧です。ところが、プランを立てようとすると、2か所で止まります。値を与えなければ、「変数が設定されていない」と言い、存在しないパスを与えれば、「そのパスにファイルがない」と言います。どちらも設定ファイルの外の事実なので、静的な検査は知ることができません。validateに通ったことは、適用してよいという意味ではありません。

3つ目のツールのtofu consoleは、現在のディレクトリの変数とlocalsを読んで、式を1行ずつ評価します。ファイルで流し込めば、非対話的にも使え、最初のエラーで止まり、0ではないコードで終了します。紛らわしい変換を確認するのに向いています。

"5" + 5      ->  10       산술에서는 문자열이 수로 변환된다
1 == "1"     ->  false    같다 비교에서는 변환되지 않는다

現場での姿

最もよくあるのは、ゲートの順序を逆に組んだCIです。構造の検査を先に回すと、文法が壊れたファイル1つのせいで、正体不明のエラーが大量に出て、肝心の原因である「括弧を閉じていない」が埋もれます。書式の判定を先に置けば、そのファイルをすぐに指してくれます。

2つ目は、ゲートがリポジトリを直してしまう場合です。直すモードをCIに入れておくと、検査は通過する代わりに、作業ツリーが静かに変わり、人は自分がコミットしていない変更を、あとから発見します。ゲートには、判定だけを行うモードを使います。

3つ目は、前に述べた誤解です。「検査は全部通ったのに、なぜapplyが爆発するのですか」という質問の半分は、値の問題です。静的な検査は、設定ファイルの文法と構造を保証するだけで、その値が指す世界については、何も言いません。そのため、検査に通ったあとにも、プランのレビューが残ります。

4つ目は、コンソールを使わないチームです。式が紛らわしくなるたびに、設定を直して適用して結果を見る往復を繰り返しますが、その1周が数分かかり、失敗すると、状態が中途半端になります。コンソールで1行で確認すれば、往復がなくなります。特に、変換が起きる場所、つまり、算術と比較、文字列と数値の間は、記憶に頼らず、その場で出力してみるほうが速いです。

次のラボですること

8つのステップを進めます。書式が乱れたツリーを作って、判定の終了コードを確認し、実際に直して、もう一度判定し、文法が壊れたファイルで、コードがまた変わるのを見ます。続けて、構造エラー2つを一度に捕まえる機械可読の出力を作り、逆に、構造は問題ないのに値のせいでプランが2回止まる場合を記録します。最後の2つのステップでは、コンソールで式を4つ確認して、そのうち1つを実際の設定に移して適用し、書式の判定と構造の検査を順番に束ねた、コミット前のゲートを自分で作ります。