ISconf

コンピューティングにおいて、ISconf はサーバーのネットワークを管理するためのソフトウェア ツールです。

ISconf はプル モデルで動作します。つまり、変更が行われた時点で起動していないサーバーであっても、再起動すると変更が受信されます。バージョン 4 では、ISconf は中央サーバーを必要としませんが、すべてのサーバーが同じように起動することが期待されます。これは、中央サーバーを必要とする可能性のある何らかの自動インストールを使用して実現するのが最も簡単です。

ISconf は、現在DevOps領域を構成している OS 側の背景 (理論上) のほとんどを作成し、定義した「インフラストラクチャ管理」運動から生まれました。これは、サーバーの分岐を防ぐ最善の方法は、同じ操作セットを同じ順序で適用することであるという考えに基づいています。

これは、システム自動化の「収束」理論とは対照的です。システム自動化の「収束」理論では、「このセット以外のパッケージがインストールされている場合は、それをアンインストールする」、「パッケージ X がインストールされていない場合は、それをインストールする」、「デーモン X が実行されていない場合は、それを起動する」などの一連のルールを使用して、任意の状態から既知の状態にサーバーを「収束」させようとします。Steve Traugott によると、特定のルール セットが実際に特定の状態から収束できることを保証する方法はありません。

ISconf は、ISconf を通じて発行されたコマンドのみがシステムの状態を変更すると想定して、操作の順序を強制します。その結果、パッケージまたはファイルをシステムに手動でインストールすると、そのまま残り、最終的にはバージョンの競合などの問題が発生する可能性があります。ISconf は、構成を同一に保つ必要がある環境を対象としています。このような環境では、通常、少数のシステム管理者にのみホストへのルート アクセスを与えます。これにより、少人数のグループに ISconf を通じてのみ変更を行うようにトレーニングするのが簡単なので、手動による変更のリスクが最小限に抑えられます。

ISconf は Makefile にヒントを得て、当初は Makefile として実装されました。ただし、Makefile は依存関係を指定するものであり、操作の全体的な順序を指定するものではありません。ISconf バージョン 1 では、各操作を前の操作に依存させることでこの問題に対処していましたが、これは面倒で Make には適していませんでした。ISconf の最近のバージョンでは、単純な追加専用のジャーナルが使用されています。

一般的に使用されているメジャー バージョンは ISconf2 と ISconf3 のようですが、ISconf4 は非常に長いベータ期間に留まっていました。実際には完成しており、より大規模な環境で使用されていましたが、遅延のためコミュニティでの採用は限られていました。

• ISconf 1 (メイクファイル)
• ISconf 2 (200x 初期?) Steve Traugott 著
• ISconf 3 (2002) は、Luke Kanies によるバージョン 2 の書き直しでした。
• ISconf 4 は主に原作者の Steve Traugott によって書かれました。

Luke Kanies はその後CFengine2に切り替え、最終的にPuppet を作成してリリースしました。その結果、ISconf は Puppet の祖先であると考えることができますが、CFengine と Puppet はどちらも構成管理の「収束」モデルを実装しており、これは少なくとも ISconf バージョン 1、2、および 4 で実装されている「操作順序」モデルとは本質的に逆です。

• オープンソース構成管理ソフトウェアの比較

• ISconfのウェブサイト
• インフラストラクチャのブートストラップ、Steve Traugott と Joel Huddleston による LISA '98 論文。ISconf のきっかけとなったアイデアについて書かれています (ISconf 自体より前のものです)
• Lukes による ISconf 3 の理論的背景と目標の説明
• システム管理自動化の理論セクションとメーリングリストのアーカイブ
• ISconf4 の Github リポジトリ