CUE vs YAML: 型付き構成 vs 素の YAML
YAML は普遍的だが型もバリデーションもない素のデータ形式であり、CUE は制約を用いてデータを生成・検証する言語です。YAML はよりシンプルで、CUE は YAML では捕捉できないエラーを捕捉します。
これは対等な戦いではありません。YAML はシリアライズ形式であり、CUE は YAML を出力できる構成言語です。素の YAML が大規模でエラーを起こしやすくなったとき、チームは CUE を選びます。ここでは、それぞれがどのような場合に適切なツールかについて率直に比較します。
| CUE | YAML | |
|---|---|---|
| 何であるか | 構成言語 + バリデータ | データシリアライズ形式 |
| 型/制約 | ファーストクラス、強制される | なし (string、number、list、map) |
| 再利用/DRY | import、定義、統合 | anchor/alias (限定的) |
| バリデーション | 組み込み | 外部 (schema、linter) |
| 遍在性 | 成長中 | どこにでも |
| 最適な用途 | 大規模でエラーを起こしやすい構成 | 小規模でシンプルな構成 |
素の YAML で十分な場合
少数のファイルであれば、YAML が正しい選択です。誰もが読め、あらゆるツールが取り込め、学ぶことは何もありません。その欠点 (型がない、インデントを誤りやすい、anchor が扱いにくい) は大規模でしか効いてきません。できるからといって小さなプロジェクトに構成言語を追加してはいけません。
CUE が報われる場合
ほぼ同一の YAML ファイルが多数あり、環境ごとの override があり、コピペのミスが繰り返されるようになると、CUE はその価値を発揮します。schema を強制し、定義によって重複を排除し、無効な値で素早く失敗します。ツールが必要とする YAML は依然として出力しますが、記述と検証は CUE で行います。
CI で
YAML を維持する場合でも、バリデーションステップ (schema チェックまたは linter) を追加しましょう。CUE を採用する場合は、CI で cue vet/cue export を実行し、不正な構成が deploy 前に拒否されるようにします。目標は同じで、無効な構成が本番に到達しないことです。
結論
遍在性が勝る小規模でシンプルな構成には素の YAML を維持し、構成の量と正しさの要求が手編集の YAML を超えたら CUE を採用しましょう。CUE は依然として YAML を出力できるため、完全に置き換えるのではなく補強します。