YAML から JSON: 迷うことなく構成を変換

YAML から JSON への変換が実際に行うこと

YAML と JSON は同じ形状 (マップ、リスト、文字列、数値、ブール値、null) を表すため、変換は主に一方の構文をもう一方の構文として再シリアル化することになります。変化するのは表面です。インデントは中括弧になり、コメントは消え、アンカーはコピーになり、複数行の文字列は `\n` エスケープに折りたたまれます。これらの変換はどれも重要な意味で損失を伴うため、変換ステップを後付けの書式設定として扱うのではなく、意図的に実行する価値があります。

変換する実際的な理由は、次のツールが JSON を必要とするためです。 Kubernetes は YAML を受け入れますが、`kubectl`、jq パイプライン、API 呼び出し、および JavaScript はすべて JSON をより快適に話します。 1 回正しく変換すれば、2 つの形式を並行して手作業で編集するよりも優れています。

複数文書 YAML: 沈黙の最初の文書の問題

YAML ファイルには、`---` で区切られた複数のドキュメントを保持できます。ほとんどのコンバーターは、最初のものを静かに返し、残りを破棄します。そのため、Deployment、Service、ConfigMap を含むマニフェスト バンドルは、警告なしで 1 つのオブジェクトになります。正しい変換では、ドキュメントの配列が出力されるか、どれが必要かを明示的に尋ねられます。コンバーターがそのような制御を提供しない場合、データが失われます。

エラーは行と列を指す必要があります

YAML の空白に対する耐性はまさに、小さな間違いを見つけるのが難しい理由です。タブはインデントに使用できず、コロンがないとマッピングが文字列に変換され、重複キーは一部のパーサーでは受け入れられ、他のパーサーでは拒否されます。変換が失敗すると、行と列の名前を示し、問題のある部分の抜粋が表示される唯一の有益なメッセージが表示されます。

                spec:
  containers:
	- name: web      # tab used for indentation
error: line 3, column 0 — tabs cannot be used for indentation
              

重複キーは危険なケースです。YAML パーサーは通常、最後の値を保持し、何も言いません。 `replicas: 3` が 2 回表示される場合、取得される JSON は完全に有効であるように見えますが、数値は間違っています。

旅行中に生き残る引用ルール

JSON は YAML よりも文字列に関して厳密であるため、変換では裸の値の前後に引用符が追加されます。これは正常ですが、YAML の 2 つの癖が実際のバグを引き起こします。`yes`、`no`、`on` および `off` は、YAML 1.1 ではブール値ですが、JSON セマンティクスでは文字列であり、郵便番号や電話番号などの先行ゼロの値は、数値として扱われるとゼロが失われます。フィールドが変換全体にわたって文字列のままである必要がある場合は、ソース内でそのフィールドを引用符で囲みます。

特にクラスター構成の場合はローカルで実行します。

Kubernetes マニフェストは、`Secret` オブジェクト内の資格情報、ConfigMap 内の接続文字列、CI ファイル内のトークンを定期的に保持します。これらを Web サービスに貼り付けると、制御できないサーバーにそれらが渡されます。ブラウザベースのコンバータは、あなたが読んでいるのと同じタブで解析とシリアル化を行うので、何も送信されません。そして、ネットワークが切断されてもページが動作し続けることは、約束ではなくその証拠です。

賢明なワークフロー

1. 最初に YAML を検証し、報告された行、列、抜粋を修正します。
2. マルチドキュメント ファイルの処理方法 (配列または特定のドキュメント) を選択します。
3. コードベースのスタイルに一致するインデント (2 つまたは 4 つのスペース) で変換し、出力の差分を比較する場合はキーをソートします。
4. YAML を git 内の真実のソースとして保持し、JSON を生成されたアーティファクトとして扱います。コメントは YAML にのみ存在します。