YAMLはインフラのあらゆる場所に存在します——Kubernetesのマニフェスト、GitHub Actionsのワークフロー、Docker Composeのファイル、Ansibleのプレイブック。読みやすくコンパクトですが、インデントが曖昧になったり、スペースであるべき場所にタブが紛れ込んだり、JSONしか理解しないツールにデータを渡す必要が出てくるまでの話です。
手作業で両者を変換するのは機械的ですが面倒です。YAMLのインデントベースのネストはJSONの波括弧と角括弧になり、クォートされていないYAMLの文字列にはクォートが必要になり、YAMLのより寛容な構文(クォートされていないブール値、複数行文字列、アンカーと参照)は必ずしもJSONの厳格なルールにきれいに対応するとは限りません。
両方の形式が必要な理由
読みやすくバージョン管理しやすいという理由でKubernetesのマニフェストをYAMLで書くかもしれませんが、スクリプトやAPI呼び出し、JSON入力を期待するjqパイプラインに供給するためにJSONの同等物が必要になるかもしれません。あるいは、CIパイプラインのYAML設定が期待通りに解析されない理由をデバッグしていて、背後にあるJSON構造を見ることで、空白に敏感なYAMLでは時に曖昧な実際のネストが明確になるかもしれません。
形式を即座に変換
Bellowsには、41個の開発者ツールの1つとしてYAMLからJSONへのコンバーターが含まれています。YAMLを貼り付ければ、適切なネストと型を保持したまま、同等のJSON構造がすぐに得られます——手動での再整形も、インデントレベルの推測も不要です。
KubernetesとCI設定のデバッグ
マニフェストが予期しない動作をするとき、背後にあるJSON構造を見ることで、YAMLが実際にどうネストされたかについてのあいまいさがなくなります——配置がずれたインデントが、どのキーがどの親オブジェクトに属するかを静かに変えてしまったときに役立ちます。
スクリプトへの設定の供給
多くのスクリプティングや自動化ツールは、YAMLよりもJSONの方が自然に扱えます。設定ファイルを一度変換して、JSON出力を下流に渡す方が、パイプライン内のすべてのスクリプトにYAMLを直接解析させるよりもシンプルなことがよくあります。