# 宣言的設定管理 ## 定義 宣言的設定管理とは、システムのあるべき設定を宣言的な記述(構造化されたファイルやデータベースエントリ)として表現し、その記述を単一の信頼できる情報源(Single Source of Truth、SSOT)として扱う運用モデルである。SONiCはCONFIG_DBという実行時データベースをSSOTと定め、起動時には`/etc/sonic/config_db.json`というファイルからCONFIG_DBへ読み込む形でこのモデルを実装する。各アプリケーションはCONFIG_DBをsubscribeし、変更を検知すると自身の形式に変換して利用するため、設定の入り口を1箇所に集約しながら複数コンポーネントへ変更を伝播できる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] §6.1.2) ## SONiCにおける実装パターン SONiCの宣言的設定管理は、次の4つの操作の組み合わせで構成される。(1) **読み込み**: `config load`(既存設定への上書き。ファイルに記載の無い設定は削除しない)と`config reload`(現在の設定を削除してから読み込む全体置き換え)。(2) **永続化**: CLIなどによるCONFIG_DBへの変更は自動的にはファイルへ反映されず、`save`コマンドで明示的に`config_db.json`へ書き戻す必要がある。(3) **スナップショット**: `config checkpoint`で現在のCONFIG_DBの内容を`/etc/sonic/checkpoints/<name>.cp.json`として保存する。(4) **復元**: `config rollback`で、Config Rollbacker(全体制御)→Config Replacer(差分生成)→Patch Applier(JSON Patch適用)という処理チェーンにより、現在設定とチェックポイント設定の差分だけを適用する。著者は checkpoint/rollback について「既存設定および変更しようとしている設定によっては上手く動作しない場合もある」と留保を付けており、機構としては洗練されている一方、運用への組み込みには自環境での検証を要する未成熟さも併記されている。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] §6.2.1, §6.2.2) ## 横断的知見 - **SSOTの所在は「デバイス内のランタイムDB」と「デバイス外のリポジトリ」の2通りに大別でき、いずれも「唯一の真実の情報源」を明示的に指定する点は共通するが、変更の伝播方向が逆転する**: SONiCの宣言的設定管理(ch.6 §6.1.2)は、CONFIG_DBというデバイス内のRedisデータベースをSSOTと定め、起動時に`config_db.json`というファイルから読み込む一方、CLIによるランタイム変更は明示的な`save`を経て初めてファイルへ逆流する——SSOTは「デバイスの中」にあり、外部ファイルはその都度のスナップショットにすぎない。対照的に[[GitOps]]([[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2)は、Gitリポジトリという「デバイスの外」をSSOTと定め、CI/CDパイプラインによってリポジトリの変更が一方向にシステムへ伝播する設計を前提とする。同じ「単一の信頼できる情報源」という言葉が指す位置が逆転しており、SONiCのモデルは「デバイスが真実を持ち外部ファイルは写し」、GitOpsは「リポジトリが真実でデバイスは写し」という対照的な設計思想を体現する。SONiC側の`save`忘れによる設定消失リスクは、SSOTがデバイス内にあるモデル特有の運用上の落とし穴であり、GitOps側の「正本の所在をどう区別するか」という悩み(GitOps定義部を参照)とは異なる種類の課題である。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] §6.1.2, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2) - **ロールバック機構の成熟度も「特定用途のあと付けコマンド」対「設計に組み込まれた第一級機能」で対照的**: SONiCの`config checkpoint`/`config rollback`(ch.6 §6.2.2)はJSON Patchによる差分適用という洗練された実装を持つが、著者自身が動作しない場合があると留保しており、外部の共有状態を管理する専用機構としてではなく個々のコマンドの組み合わせとして提供されている。一方、GitOpsが紹介するAether向け実行時状態管理(ch.11 §11.2)は、宣言的な仕様記述言語(YANG)を採用した時点で「バージョニングに対応し、状態変更のロールフォワード・ロールバックが容易である」ことを設計要件として明示しており、ロールバックは後付けのコマンドではなく制御APIの設計原則として組み込まれている。同じ「設定を巻き戻せるようにする」という目的に対し、SONiCは既存のコマンド体系へ機能を追加する形で、GitOps/Aetherはデータモデルの選定段階から要件として組み込む形で到達しており、後発の設計ほどロールバックが一級市民として扱われる傾向がうかがえる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] §6.2.2, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2) - **CONFIG_DBを唯一の入口とするSSOTモデルには、CLI/スキーマが未整備の新機能を先行利用するための「バイパス経路」が併存する**: 第6章のSSOTモデル(ch.6 §6.1.2)は、設定変更はCONFIG_DBという単一の入口を通り、各アプリケーションがそれをsubscribeして自身の形式へ変換するという一方向の構造を前提にしている。ところが第10章のSRv6設定(ch.10 §10.1.1, §10.2.1, §10.2.5)は、CLIも`*mgrd`系モジュールも存在しない機能について、コントローラーや`swssconfig`がAPPL_DBへ直接エントリを投入する経路を示す。これはCONFIG_DBという「入口」を経由せず、CONFIG_DBの下流にあるはずのAPPL_DBへ直接書き込むものであり、SSOTモデルの外側にもう1つの設定注入点が存在することを意味する。この経路が使われる理由は運用上の都合ではなく、CLIやCONFIG_DBスキーマの整備がデータプレーン機能の実装に追いつくまでの「先行提供」であり、宣言的設定管理モデルは実装上完全に閉じてはおらず、新機能ほど下位レイヤーへの直接アクセスに頼る傾向があることが2つの章を突き合わせて見える。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] ch.6 §6.1.2, [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]] ch.10 §10.1.1, §10.2.1, §10.2.5) ## 未解決の問い - APPL_DBへ直接投入された設定(第10章のSRv6エントリなど)はCONFIG_DBを経由しないため、CONFIG_DBをSSOTとする`save`/`config checkpoint`/`config rollback`の対象に含まれない。CONFIG_DB経由の設定とAPPL_DB直接投入の設定が同一デバイス上に混在する場合、設定の一貫性・可視性(「今何が設定されているか」の単一の把握手段)はどう担保されるのか、本書は明示していない。 - SONiCのCONFIG_DBと`config_db.json`の非対称性(saveを忘れると変更が再起動で失われる)は、他のネットワークOS(Cisco IOS-XRやJunosの「running-config/startup-config」モデルなど)の設計とどこまで同型で、どこが異なるか。 - `config checkpoint`/`config rollback`が「上手く動作しない場合がある」と著者が述べる具体的な失敗パターン(どのテーブル・どのような変更でJSON Patch生成/適用が破綻するか)は何か。CONFIG_DBの内部スキーマやYANG検証を扱う後続章の内容と合わせて再検討する。 - GitOpsのようなデバイス外SSOTモデルをSONiC運用に重ねる場合(`config_db.json`をGitで管理しCI/CDで配布する等)、CONFIG_DBとファイルの非対称な反映経路(save忘れ問題)はどのように解消・回避されるか。 - SONiCのCONFIG_DBモデルと[[収束型システム管理]]が扱う「理想状態への収束」は、いずれも「あるべき状態を宣言し実際の状態をそこへ近づける」という点で類似して見えるが、SONiCのload/reloadは冪等な一括適用であり、収束理論が想定する反復的な補正(convergence)とは適用のタイミング・粒度が異なるように見える。両者は同じ問題への異なる解法なのか、それとも別の問題を扱っているのか。 ## 関連 - source: [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]] - entity: [[SONiC]] - concept: [[GitOps]] / [[収束型システム管理]] / [[Infrastructure as Code]] / [[SRv6]] - 関連 MOC: [[Network - MOC]] ## 出典 - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第 6 章, §6.1.2, §6.2, 第10章, §10.1.1, §10.2.1, §10.2.5. - Larry Peterson・Bruce Davie 著, 進藤資訓 訳, 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第11章 §11.2.