# ネットワーク機器のブートストラップとイメージ配布 Navigation: [[../index|index]] | [[../overview|overview]] ## 定義 ネットワーク機器のブートストラップとイメージ配布とは、ホワイトボックススイッチのようなベンダー非依存ハードウェア上にネットワークOS(NOS)を導入・更新する仕組み全体を指し、大きく2つの関心事に分けられる。1つは「機器上でどうOSを起動・インストールするか」という**オンデバイスの実行フロー**(例: ONIEによるブートローダー→インストール環境→NOSという段階的な起動)であり、もう1つは「どのビルド・バージョンのイメージをどこから取得するか」という**イメージのビルドと配布経路**(例: 日次ビルドパイプラインとその成果物のダウンロードページ)である。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 5 SONiCの入手とインストール]] §5.2, §5.3) ## オンデバイス実行フロー(ONIEの例) SONiCの実機インストールで主に使われるONIE(Open Network Install Environment)は、「最初の起動」でブートローダーがONIE(インストール専用の実行環境)を起動し、ONIEがインストーラーを通じてネットワークOSを機器に書き込む。「2回目以降の起動」ではブートローダーが直接インストール済みのネットワークOSを起動し、ONIEは介在しない。この2段階の起動フローはONIE対応のネットワークOSであれば共通であり、SONiC以外の例としてOpen Network Linux(ONL)がある。アップグレード・ダウングレードも同じONIEインストーラーの再利用、または稼働中OS上のインストーラーコマンド(SONiCでは`sonic-installer`)経由の2通りで行える。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 5 SONiCの入手とインストール]] §5.3.1, §5.3.2, 図5.7) ## イメージのビルドと配布経路 SONiCのプリビルドイメージは日次のCI/CDパイプライン(Azure Pipelines)でプラットフォーム(ASIC種別)とリリース(ブランチ)の組み合わせごとにビルドされ、ビルド結果(成功/失敗)とビルド番号付きの成果物リンクとして公開される。最新版のみを追うSupported Platformsページと、特定ブランチ・特定ビルド日時を指定できるAzure Pipelinesページという2つの経路が使い分けられ、後者はビルド履歴のダッシュボードで複数プラットフォームの状況を俯瞰できる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 5 SONiCの入手とインストール]] §5.2.1, §5.2.3) ## 横断的知見 - 『実践SONiC入門』第5章は、この2つの関心事(オンデバイス実行フローとイメージ配布経路)を運用手順として明確に分離して説明する(§5.2でイメージ入手、§5.3でONIEによるインストールと、節そのものが分かれている)。一方 *Software-Defined Networks: A Systems Approach* 第4章は、ONIEを「BIOSに相当するファームウェア」としてベアメタルスイッチのハードウェア構成要素(NPU・制御プロセッサ・トランシーバと並ぶ1部品)に位置づけ、OCP(Open Compute Project)による全体仕様の標準化がこの分離を可能にしていると読める。すなわち、運用側の資料(実践SONiC入門)が「配布されたイメージをどう機器に届けるか」という手順を詳述するのに対し、アーキテクチャ側の資料(Systems Approach)は「なぜベンダーを問わず同じ手順が成立するか」というハードウェア標準化の土台を説明しており、両者は同じブートストラップ機構を運用と設計の異なる高度から補完的に描いている。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 5 SONiCの入手とインストール]] §5.3.1, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.1) - 第5章が配布経路として描く「日次CI/CDパイプライン(Azure Pipelines)がプラットフォーム×リリースごとにビルドする」プリビルドイメージは、[[@2025__Gihyo__実践SONiC入門 - Appendix 1 ソースコードからのビルド]]が詳述する多段ビルド(モジュールの.debパッケージ生成→Dockerイメージ生成→sonic-$(PLATFORM).binへの統合)を、パイプライン上で自動的に回した結果である。Appendix 1は、この同じビルド過程を手元で再現しようとした場合に「同じソースコードをもとにビルドを実施しても外部環境の変化でビルドが失敗する」課題が生じることを明かしており、SONiC Reproducible Buildのような改善文書が継続的に必要とされている。すなわち、第5章が配布側から見る「決まったビルド番号のイメージを確実に入手できるか」という再現性の問い(未解決の問い参照)は、Appendix 1が明かすビルド側の実情——同一ソースからの再ビルドさえ外部依存関係の変化で失敗しうる——と表裏の関係にあり、配布経路の安定性はビルドパイプライン自体の再現性に依存する。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 5 SONiCの入手とインストール]] §5.2.1, [[@2025__Gihyo__実践SONiC入門 - Appendix 1 ソースコードからのビルド]]) ## 未解決の問い - ONIE以外の(ベンダー独自の)ブートストラップ機構は、この「実行フロー」と「イメージ配布」の分離をどう扱っているか。ONIEほど明確に分離されているか、それとも統合されているか。 - ZTP(Zero Touch Provisioning)やコンテナイメージレジストリのようなより新しい配布モデルは、ONIE的なブートストラップとどう関係するか(競合するのか、上位レイヤーとして併存するのか)。 - イメージのビルド番号固定(Azure Pipelinesの「Copy Latest Static Link」の落とし穴)のような再現性の問題は、他のネットワークOSやCI/CDパイプラインでも同様に起きるか。Appendix 1はSONiC自身のソースビルドが外部依存関係の変化で失敗しうることを示すが、これがAzure Pipelines上の日次ビルドの成功率・再現性にどの程度影響しているかまでは述べていない。 ## 関連 - 実体: [[ONIE (Open Network Install Environment)]] / [[Open Network Linux (ONL)]] / [[SONiC]] - ソース: [[@2025__Gihyo__実践SONiC入門 - Chapter 5 SONiCの入手とインストール]] / [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] / [[@2025__Gihyo__実践SONiC入門 - Appendix 1 ソースコードからのビルド]] - 概念: [[ヘルメティックビルド]](ビルドの再現性・依存関係由来の失敗という論点はこちらが横断的に扱う) - 書籍: [[実践SONiC入門]] ## 出典 - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第 5 章、Appendix 1。 - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 4: Bare-Metal Switches.