Kubernetes と CI における YAML

本番の YAML の多くの問題は Kubernetes マニフェスト と CI ワークフローファイル から来ます—おもちゃの例ではありません。

Kubernetes マニフェスト

Deployment は通常次を組み合わせます。

• トップレベルの API メタデータ（apiVersion、kind、metadata）
• spec.template 下のネストした Pod テンプレート
• ポート、環境変数、プローブを含むコンテナ配列

インデントエラーは 3〜4 段深い ところに現れやすく、汎用の「invalid YAML」より行/列パーサーヒントが重要です。

GitHub Actions ワークフロー

ワークフローファイルはマッピングとシーケンスを組み合わせます。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

よくある問題:

• steps のインデントミスでステップが jobs の兄弟になる
• | や > ブロックスカラーなしで複数行シェルを貼り付け
• ブロックスタイルファイル内に JSON 風 { } フローコレクションを混在

Docker Compose

Compose はサービスマップと依存グラフを重視します。"8080:80" のようなポート文字列は、YAML が : を特別に解釈しうる曖昧な文脈では引用符で囲む必要があります。

実践的な習慣

1. apply 前に validate — 構文エラーをローカルで捕捉
2. PR 前に format — 安定したインデントでレビューノイズを減らす
3. 必要ならキーをソート — チームが順序に合意すれば diff がきれいに
4. 共有リンクに秘密を入れない — チャットに送る例はプレースホルダーを使う

有効な YAML は必要ですが十分ではありません。リソース名、namespace、RBAC はクラスタ固有のレビューが依然必要です。