# プル型構成配布 Navigation: [[index]] ## 定義 プル型構成配布とは、構成や変更の適用をサーバー側から能動的に送り込む(push)のではなく、各クライアントが自分のタイミングでサーバーへ接続し、必要な変更を自ら取得して適用する(pull)方式を指す。[[@1998__LISA__Bootstrapping an Infrastructure]] は、この設計原則を実運用の障害事例に基づいて明確に主張した初期の文献である——r-command(rsh/rcp/rdist)ベースのpush型スクリプトは、対象ホストが30台を超えると必ずダウンしているホストが出て、タイムアウト処理・リトライ・ソケット枯渇対策などの複雑なラッパーコードが必要になり実用に耐えなくなる一方、SUP・CVSup・[[cfengine]]のようなpull型ツールでは各クライアントが自律的に自分のリビジョンレベルを維持する責任を負うため、個々のホストの可用性に配布全体が引きずられない。 ## 未解決の問い - push型とpull型は排他的な二択なのか、それとも(例えばオーケストレータがpullのトリガーだけを軽量にpushする等の)ハイブリッド方式が実務でどの程度使われているか。 - pull型配布の間隔(ポーリング周期)の選択が、変更の即時性とサーバー負荷のトレードオフにどう影響するか。同論文はcronによる周期実行と、緊急時のみアドホックツールでpullを強制する`rabbit`のような折衷策を報告しているが、他のソースでの一般化が必要。 - 現代のGitOps・Kubernetesのreconciliation loopは同じpull型原則の延長線上にあるか、それとも異なる設計動機(宣言的状態収束)から独立に到達したものか。 ## 未編纂の観察 - [実装例] cfengineベースのソフトウェア/パッチ配布システムを「smart client, dumb server」の思想で設計し、pull型配布を要件として最初から明確に掲げた実装例が存在する——サーバー側の一時的な喪失や侵害による被害範囲を局所化する動機で選ばれている。(Source: [[@2000__LISA__Use of Cfengine for Automated, Multi-Platform Software and Patch Distribution]]) ## 関連 - [[@1998__LISA__Bootstrapping an Infrastructure]] — push対pullの実運用比較とゴールドサーバーモデルの提唱元 - [[cfengine]] — pull型配布の代表的な実装例 - [[イミュータブルインフラストラクチャ]] — ホスト置換ベースの復旧・移行と関連 - [[べき等性]] — pull型の反復適用が安全であるための前提条件 - ソース: [[@2000__LISA__Use of Cfengine for Automated, Multi-Platform Software and Patch Distribution]] ## 出典 - [[@1998__LISA__Bootstrapping an Infrastructure]] — push vs pullセクション、r-commandベースpushの障害事例、SUP/CVSup/cfengineによるpull型運用の実績