YAML構文マスター_Why_What_How

内部学習ノート ｜ うさう さ研修工房 YAML構文マスター Why・What・How で自分の言葉として理解し、使いこなす Why YAML Ain't Markup Language ／ Ver.1.2 準拠 What How

学習フレームワークの全体像 「暗記」ではなく「腹落ち」で使いこなすための3段構成 Why What なぜ学ぶのか 何であるか どう使いこなすか YAMLが生まれた理由と、 キー・値、リスト、ネスト、特殊 検証・実践・チェックリストを通 JSON/XMLではなくYAMLが選ば 記法まで、YAMLの文法要素を じて、書ける・読める・間違いに れる場面を理解する。目的が 構造として正確に把握する。 気づける状態まで引き上げる。 分かれば構文の必然性が見え る。 YAML構文マスター ｜ Why・What・How 02

Why｜なぜYAMLを学ぶのか 設定ファイルは「人が読み書きする」ことが前提。YAMLはその可読性を最優先に設計された。 観点 YAML JSON XML 可読性 ◎ 記号最小・インデント構造 ○ 括弧が多く人には冗長 △ タグの開閉が冗長 コメント ◎ # で自由に書ける × 仕様上不可 ○ <!-- --> で可能 データ型 ○ 文字列/数値/真偽/null等 ○ 同様に表現可能 △ すべて文字列扱い 主な用途 設定ファイル・IaC定義 API・データ交換 文書・レガシー連携 要点：YAMLはJSONの上位互換に近い記法を持ちつつ、コメントと省略記法で「設定ファイルとしての書きやすさ・読 みやすさ」を追求した形式。 Why ｜ YAML誕生の背景 03

Why｜現場のどこで YAMLに出会うか コンテナ／構成管理 構成自動化 Docker Compose、Kubernetes マニフェスト Ansible Playbook、Chef／SaltStack 定義 CI/CD パイプライン アプリ設定 GitHub Actions、GitLab CI、CircleCI 設定 Spring Boot、Serverless Framework 等の設定 ファイル IaC／CI基盤の事実上の標準記法 ― クラウドネイティブ領域を扱うなら避けて通れない。 Why ｜ ユースケース 04

What｜基本構造：キーと値、インデント 5つの基本ルール # サーバー設定の例 ✦ 「key: value」— コロンの直後に半角スペース必須 server: ✦ 階層はインデント（字下げ）の深さで表現する ✦ インデントは半角スペースのみ。タブ文字は使用 不可 ✦ スペース数は自由だが、同じ階層では必ず統一す る ✦ ファイルの拡張子は .yml または .yaml What ｜ 基本構文 host: 192.168.1.10 port: 8080 name: "web-01" database: engine: postgres timeout: 30 05

What｜3つのデータ構造 スカラー シーケンス マッピング 単一の値 リスト（配列） 入れ子（辞書） name: 太郎 fruits: user: age: 28 - apple name: 太郎 active: true - banana roles: memo: null - orange 3構造の組み合わせだけで、 YAMLはどんなに複雑な設定も表現できる。 と自問する。 What ｜ データ構造 - admin 迷ったら「これは値？リスト？辞書？」 06

What｜覚えておきたい特殊構文 複数行文字列 base: &defaults | は改行を保持（リテラル）、 > は改行をスペー スに変換（フォールド） retries: 3 timeout: 30 service_a: <<: *defaults アンカー & エイリアス name: api &name で定義した内容を *name で再利用し、 重複記述を防ぐ desc: | 1行目そのまま 2行目も保持される summary: > # ドキュメント区切りは --- と ... ／ コメントは # 折り返しは スペースになる What ｜ 特殊構文 07

What｜つまずきやすい落とし穴 タブ文字インデント パーサーがエラーを出す／黙って解釈が崩れる。エディタで “空白を可視化”設定を必ず有効に。 コロン・ハイフンの後のスペース漏れ key:value のようにスペースを省くと、値ではなく1つの文字列と して誤解釈される。 What ｜ よくある誤り 暗黙の型変換（Norwayの問題） no / yes / on / off / true が真偽値に解釈される。国名コード "NO" が false になる事例が有名。 数値に見える文字列 バージョン番号 "1.20" などはクォートしないと数値として丸めら れることがある。 08

How｜正しさを検証するワークフロー 「読める」だけでなく「壊れていないと機械的に確認できる」状態を作る 1. 記述 → エディタの YAML 拡張機能で インデントガイドを表示 2. Lint → yamllint 等で 構文・スタイルを機械チェック 3. スキーマ検証 JSON Schema / kubeval 等で 意味的な妥当性を検証 → 4. CI組み込み コミット前・PR時に 自動実行して事故を防止 $ pip install yamllint $ yamllint config.yml config.yml:12:3: error expected 4 but found 2 wrong indentation: How ｜ 検証プロセス (indentation) 09

How｜自分を鍛える実践ロードマップ 1 写経フェーズ 基本構文（スカラー／シーケンス／マッピング）を手で書き写し、 Lintを通す 2 破壊フェーズ 意図的にタブ・型変換の罠を仕込み、エラーメッセージと挙動を観察する 3 読解フェーズ 実際のK8sマニフェストや Ansible Playbookを読み、構造を図解してみる 4 資産化フェーズ 自作テンプレートを Lint・Schemaとセットでリポジトリ化し、講座教材に転用する How ｜ トレーニング計画 10

How｜習得レベルの自己チェックリスト インデント崩れを見た瞬間に、原因（タブ混入／階層のズレ）を特定できる スカラー・シーケンス・マッピングを組み合わせて任意の構造を書ける アンカー／エイリアスで重複記述を排除できる no/yes/on/off 等の暗黙の型変換の罠を他人に説明できる yamllint やスキーマ検証をCIパイプラインに組み込める 他人が書いたYAML設定ファイル（K8s／Ansible等）を読んで構造を説明できる How ｜ 自己評価 11

まとめ： Why・What・Howの往復で定着させる Why 可読性優先の設計思想と、IaC/CI領域での事実上の標準という立ち位置を理解した What スカラー・シーケンス・マッピングの3構造と、アンカー等の特殊構文、代表的な落とし穴を整理した How Lint／スキーマ検証をワークフロー化し、写経から資産化までの実践ロードマップを設計した 次の一歩： 手元のYAML設定ファイルを 1つ選び、本資料のチェックリストで自己採点してみる。 参考： YAML Specification 1.2 (yaml.org) ／ うさうさ研修工房 内部学習ノート