# GitOps ## 定義 GitOps は、システムの構成を宣言的に記述して GitHub などのコードリポジトリに保存し、そのリポジトリをシステムの構築とデプロイにおける信頼できる唯一の情報源(single source of truth)として扱う運用アプローチである。構成の宣言には Helm Charts や Terraform テンプレートなどを用い、Python ファイルへのパッチも設定ファイルの更新も同じ「コードへの変更」として扱われる。コードリポジトリへの変更のたびに完全自動化された CI(継続的インテグレーション)/CD(継続的デプロイメント)のパイプラインが起動する。中核にある考え方は Configuration-as-Code であり、GitOps はこれを実運用のワークフローへ具体化したものといえる。プライベート 5G のエッジクラウドである [[Aether]] プロジェクトはこのモデルで構築されたクラウドネイティブなシステムの例であり、著者らはその経験から GitOps の威力を「絶大」と評する。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2) GitOps は決して銀の弾丸ではない。少なくとも三つの点を考慮する必要があり、いずれもクラウドネイティブなシステムの運用に必要な状態を本当にリポジトリベースの仕組みだけで管理しきれるのかという疑問に帰着する。 1. **開発者と運用者の分離**: ソフトウェアの開発者は、他人がそのソフトウェアをどう使うかの設計判断から遠いところにいることが多い。構成管理の変数には低レベル(実装寄り)なものも高レベル(アプリケーション寄り)なものもあり、極端な場合は設定を変えたいのが開発者でも運用者でもなくエンドユーザーであることもある(Aether の企業ユーザーがその例)。プルリクエストによる構成管理だけでは、こうしたきめ細かなアクセス制御の要求を単純化しすぎる。 2. **正本(オーソリテイティブ)の所在**: 構成管理の情報には複数のソースがあり(外部のソースを含む)、どれが正本でどれが写し(派生物)かを区別するのは厄介な問題である。正本はその情報を利用する個々の要素とは切り離された場所で管理すべきであり、各要素は「自分は正本ではない」という前提を設計に組み込むべきである。 3. **変更頻度と実行時への影響**: 構成管理の状態が変更される頻度と、それがコンテナ群の再起動・再デプロイを伴うかどうかを考慮する必要がある。初期化時に「一度だけ設定する」変数と、実行時に頻繁に変更されうる制御変数とでは、最もコスト効率のよい更新方法が異なる。 これら三点は、ビルド時の構成管理の状態と実行時の制御の状態とを区別することの重要性を示す。構成管理の方法に唯一の正解はなく、GitOps が提唱するリポジトリベースの手法も実行時の制御という代替手段も、それぞれに価値がある適材適所の問題である。(Source: ch.11 §11.2) ## 構成管理の状態 対 実行時の状態 構成管理の状態は比較的明確に定義できる。Kubernetes を例にとると、構成そのものは YAML ファイルで宣言的に記述され、GitOps のフレームワークと親和性が高い。対して実行時の状態はより動的な性質を帯び、ポッドの障害といったイベントに即時対処しなければならないコントローラによってハンドリングされる。障害でダウンしたポッドの再起動をいちいち GitOps のプルリクエストにすべきだと考える人はまずいない一方、「常にいくつのポッドを稼働させておくべきか」を宣言する YAML ファイルは構成管理の状態の好例である。この例では区別は明白だが、実際の運用現場ではもっと曖昧で連続的な境界になることが多い。(Source: ch.11 §11.2) 実行時の状態を適切に維持するには専用の制御メカニズムが必要不可欠である。Aether 向けに構築中の仕組みは、ネットワーク機器設定用のマイクロサービスという機能を仮想デバイス(ソフトウェアサービス)向けに転用するというアイデアを核とし、次の特性を持つ。(1) 宣言的な仕様記述言語として YANG を採用し、データモデルの定義・操作に関する豊富なツールセットを活用できる。(2) バージョニングに対応し、状態変更のロールフォワード・ロールバックが容易である。(3) 特定のデータ永続化方法に依存しないが、通常はクラウドネイティブなキーバリューストアと組み合わせて運用される。(4) ロールベースアクセス制御(RBAC)に対応し、主体ごとに制御変数・構成変数への可視性や操作権限をきめ細かく制御できる。YANG データモデルから自動生成される Control API は、RBAC を通じた最小権限の原則の実践と、変数の検証・セキュリティチェックの早期実施(ユーザーに近い場所でのエラー捕捉)という利点をもたらす。(Source: ch.11 §11.2) ## 信頼できる唯一の情報源(single source of truth)を確立する実践 構成管理の個々の変数について信頼できる唯一の情報源を確立することは、著者が繰り返し触れてきた教訓である。突き詰めると、(a) 人間が直接記述すべき変数と他の変数から自動的に導出される変数の区別、(b) 「ソース」となる変数を書き換える権限を誰に持たせるか、の二点を真剣に考える必要がある。ここから導かれるベストプラクティスには、変数をスクリプトに埋め込まず明示的に切り出すこと、ソース変数をバージョン管理下に置くこと、可能な限り多くを自動導出できるようにすること、スキーマやモデル定義自体も一種の構成管理の状態と認識すること、構成管理の状態への操作を冪等にすること、各要素に「自分は正本ではない」という前提を持たせること、が含まれる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.3) クラウドがエッジ環境に組み込まれるにつれ、この信頼できる唯一の情報源はエッジに固有の局所的な変数にまで広がる。実装手段の選択に影響する現実的な課題(変数が変更される頻度など)は数多くあるが、それらは正確性(意図した構成が毎回デプロイされること)や再現性(システムを継続的に更新・再デプロイできること)に比べれば二次的な問題である。ツールの選択自体が難問であり(DevOps関連のオープンソースプロジェクトは数十存在し機能の重複と暗黙の依存関係がある)、加えて変数の値が外部システムに由来する場合(5G対応エッジクラウドにおける周波数管理サービス(SAS)への問い合わせなど)は、どのようなツールを使っても解決できない課題として残る。(Source: ch.11 §11.3) ## 横断的知見 - **GitOps の「構成管理の状態 対 実行時の状態」という区別は、[[収束型システム管理]] が扱う収束理論の前提が崩れる条件を、宣言的インフラという別の語彙で言い換えたものである**: [[収束型システム管理]] concept は、Burgess(2000)の収束理論が「理想状態はゆっくり劣化する」ことを前提に補正コストの線形性を基礎づける一方、[[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] が動的スケーリング下でこの前提が崩れる実務例を報告することを記録している。本章の GitOps 論もまったく同じ構造の問題に別の角度から到達する——「常にいくつのポッドを稼働させておくべきか」という**理想状態の宣言**は GitOps のプルリクエストに馴染む(収束理論が想定する「ゆっくり劣化する理想状態」に対応する)が、ポッド障害への即時対応という**実行時の補正**はコントローラに委ねられ、GitOps のリポジトリ経由では扱われない。両者を並べると、収束理論が「理想状態への収束」を数理的に基礎づけたのに対し、GitOps 論は同じ二分法を「宣言的に記述できる状態(Git で管理)」対「専用の制御メカニズムが必要な状態(コントローラで管理)」という実装上の分岐点として再定式化しており、抽象度の異なる同型の問題であることがわかる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2, [[@2000__LISA__Theoretical System Administration]]) - **「semantic gap」(Zodiac, 2024)と「信頼できる唯一の情報源の所在」(本章)は、いずれも IaC/GitOps の抽象化が複雑さを隠すが除去しないことを示す別の症例である**: [[Infrastructure as Code]] concept が扱う semantic gap は、構文的に正しい IaC プログラムでもクラウドレベルの規約(リソース間の暗黙の制約)に違反してデプロイ時に失敗しうるという問題である。本章が指摘する「構成管理の情報には複数のソースがあり、どれが正本でどれが写しかを区別するのは厄介な問題だ」という論点は、対象こそ異なる(前者はリソース間制約、後者は情報の出所)が、いずれも「宣言的な記述の背後にある複雑さは、記述それ自体からは見えない」という共通の構造を持つ。GitOps/IaC いずれも、リポジトリや構成ファイルという単一の場所に「唯一の正しい状態」を投影しようとするが、実際のクラウド環境は複数のソース・複数のレイヤーにまたがる複雑さを持ち、その投影は常に不完全である。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2, [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **SSOTの所在は「デバイス外のリポジトリ」だけでなく「デバイス内のランタイムDB」もありうる**: 本章の GitOps は Git リポジトリという「デバイスの外」を SSOT に据え、CI/CD が一方向にシステムへ変更を伝播させる設計を前提とする。[[宣言的設定管理]] concept が扱う SONiC の設定管理(ch.6 §6.1.2)は対照的に、CONFIG_DB というデバイス内の Redis データベースを SSOT と定め、起動時読み込み用の `config_db.json` はその都度のスナップショットにすぎない——CLI によるランタイム変更は明示的な `save` を経て初めてファイルへ逆流するという、GitOps とは逆向きの伝播経路を持つ。両者を並べると、「唯一の信頼できる情報源」という同じ語が指す位置(リポジトリかデバイス内DBか)によって、変更の正しい伝播方向・運用上の落とし穴(save忘れ 対 正本の所在の混乱)がまったく異なることがわかる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2, [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] §6.1.2) ## 未解決の問い - 構成管理の状態と実行時の制御の状態の境界線は「実際の運用現場ではもっと曖昧で連続的」だと本章は認めるが、この境界をどちらに倒すべきかを判断する具体的な基準は示されない。[[収束型システム管理]] の収束/交換の対立軸や、[[Infrastructure as Code]] が扱う IaC ライフサイクルの知見と統合した判断枠組みは構築できるか。 - Aether の Control API(YANG ベース)が提供する RBAC・バージョニング・永続化非依存という特性は、GitOps のリポジトリベースの仕組みとどう連携するのか。本章はこの二つの仕組み(リポジトリと Control API)が同じシステム内でどう協調するかを明示しない。 - 本章が指摘する「変数の値が外部システムに由来する場合(5G の周波数管理サービスなど)」は GitOps の射程外とされるが、こうした動的な外部ソースを GitOps のパイプラインへ統合する標準的なパターンは確立されているか。 - [[ソフトウェア定義ネットワーク]] concept が未解決の問いとして残していた「GitOps・宣言的な単一情報源は SDN の集中管理の自然な延長か、異なる設計原理か」という問いに対し、本章は「SDN のコントロールプレーンによる集中管理」と「GitOps のリポジトリによる集中管理」を明示的には比較しない。両者の集中化の対象(ネットワークの振る舞い 対 構成の記述)がどう異なるかは今後の ingest で検討する余地がある。 ## 関連 - 概念: [[Infrastructure as Code]](semantic gap・IaC ライフサイクルとの比較対象) / [[収束型システム管理]](理想状態への収束という収束理論との対比) / [[クラウド管理モダリティ]](IaC・SDK・CLI・ClickOps という管理手段の相対化) / [[ソフトウェア定義ネットワーク]](コントロールプレーンの集中管理との比較) / [[ネットワーク自動化]](自動化全般との関係) / [[宣言的設定管理]](SSOTの所在がデバイス内かデバイス外かという対比) - 実体: [[Aether]] / [[Terraform]] / [[Larry Peterson]] - ソース: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] - 書籍: [[ネットワークシステムについて語るときに我々の語ること]] ## 出典 - Larry Peterson・Bruce Davie 著, 進藤資訓 訳, 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第11章 §11.2「GitOpsが解なのであれば、問いは何だったのか？」, §11.3「信頼できる唯一の情報源はエッジへと」.