多くのクライアントに対してほぼ同一のサーバーとVPSを常に設定しており、非常に時間がかかる場合があります。多くの場合、各展開間で変わる唯一のものは、提供される異なるWebサイトです。これをすべて自動化し、56台の同一サーバーをセットアップするという退屈な単調さをとる簡単な方法はありますか？
これまでに展開したサーバーはUbuntuのみでしたが、他のLinux OSまたはWindowsを使用し始める可能性があります。これまでのところ私はカピストラーノを見てきましたが、それは仕事をする小さなルビープログラムを書くことに焦点を当てているようで、私はまったく知識がありません
回答:
Puppetは、あなたがやろうとしていることに最適です。ただし、現時点では、Windowsのサポートはありません。
あなたの場合、マシン全体で同一のすべてのパッケージに関してサーバーノードを定義します。次に、個々のホストをサーバーから継承するノードとして定義し、特定の固有のものを設定します。
Puppetは宣言型です。各ボックスに必要なリソースの観点からボックスを説明できます。そのため、必要に応じsshて（そのリソースのクラスを記述します）、クラス内にFreeBSDとUbuntuでsshがわずかに異なる方法で呼び出されるロジックを含めることができます。また、yumRedhat内およびapt-getDebianベースのディストリビューション内、およびportsBSDで使用することも知っています。これで、サーバーノードに次のような行ができます-puppet include sshは正しいことを行い、マシンにSSHを配置します。これがUbuntuかRedhatかFreeBSDかを覚えておく必要はありません。
すばらしいのは、すべてのサーバーが1か所に存在することです。サーバーノード定義に追加した時点で、すべてのマシンがそれに応じて構成を更新します。
現時点では、Puppetを使用して3つのボックスのみを管理していますが、すでに報われています。実験で刺激の提示に使用するボックスのセットアップに1週間費やした後、グラフィックカードドライバーは、私がインストールしたUbuntuのバージョン（8.04）では古すぎることがわかりました。最新のUbuntu（9.04）をインストールする必要がありましたが、その後apt-getを実行してパペットを実行するだけで、1週間のセットアップに費やしたすべてが復元されました。
Puppetには少し学習曲線がありますが、Rubyの学習をうまく回避しました-それが使用されていることは知っています、それはpuppetが書かれているものだからです-しかし、今のところ私はRubyの例を修正することに成功していますwikiのドキュメントとレシピ。別の欠点は、人形が初めて物事を行うのに少し時間がかかるということです。利点は、すべてのマシンで変更したすべてが1か所に保存されることです（バージョン管理システムでパペット構成を維持するのが標準的な方法です）。これにより、過去を振り返ってサーバーのセットアップ方法を常に確認できます-または、失敗した変更をロールバックします。
最後に、簡単なパペットデモを行うクイックビデオを紹介します。
CobblerとPuppet を使用して、実マシンと仮想マシンの両方のビルドと構成の自動化を行います。
CobblerはDHCP、PXEブート、キックスタートを結び付けて、マシンプロファイルを追加して電源ボタンを押すだけで展開できるようにします。VMの場合、koan
コマンドは（私たちの場合は）インストールを開始するためのXenマジックを実行しますdom0。
koan --system vps.fqdn --server cobbler --no-gfx
次にvirsh console、VPSの建物を何も操作せずに見ます。
RHELを使用し、ディスクをパーティション分割し、ネットワークを構成し、さまざまなサーバークラスの基本パッケージをインストールするための一連のプロファイルを用意しています。CobblerはDebianとUbuntuの品種をサポートしていますが、私は試したことはありません。余談：Cobblerのその他の興味深い用途には、memtest ISOおよびHPファームウェアアップデートの実行が含まれます。
システムがCobbler Puppetで構築されると、アプリケーション、システムデーモンの設定、RHNへのボックスの登録などを引き継ぎます。Puppetは、システムの設定が定義済みのマニフェストと一致することを定期的にチェックするデーモンとして実行されます。すべてのサーバーに。また、保守のためにダウンしていたボックスが、ライブサービスに戻る前に正しい構成になっていることを確認するのに最適な方法です。
Puppetは本当に素晴らしいです。構成のすべての側面を制御する必要はありません-すべてのボックスで構成する必要がある単純なものを管理することから始めて（sudoers標準的な例です）、そこからそれを取ります。Puppetマニフェストもバージョン管理されていることを確認してください。何を調整するかを覚えなくても、既知の適切な構成に簡単にロールバックできることに勝るものはありません。
現在私が働いているところでは、サーバーファームのLinux部分を管理する必要があります。これは300を超えるLinuxサーバーです。これには、主にHP Proliantsが含まれ、その後にIBM 3850、一部のIBMブレード、VMware ESX、および内部管理サーバー用の一部のKVMが含まれます。
cobblerを調べましたが、問題はcobblerがRHEL / Red Hat固有であるということでした。少なくともRHELとSLESをサポートする必要があり、Ubuntuが次です。
私たちは人形を検討しましたが、Rubyに依存しているため、後で決定しました。つまり、Rubyのアップグレードは管理システムを破壊する可能性があることを意味します。
Hotwireは私たちが使用するもので（社内で開発されていますが、オープンソースです）、過去数年にわたってそうしています。最初に構築するシステムのインベントリを作成します。つまり、データセンター、ラック、ハードウェア、オペレーティングシステム、ネットワークなどのインベントリを作成し、次に迅速なビルドと展開を実行します。システムが構築されると、hotwireの自動インベントリは、cfengineが維持する間、インベントリの同期を維持します。Hotwireは、python-dmidecodeを介してBiosのSMBIOS / DMIデータと通信することにより、サーバーハードウェアを認識します。
ボーナスポイントは、インベントリとビルドプロセスが1つにまとめられているため、管理する手間が少なくなり、ライブインベントリ機能は、何かが正しくないかどうかがわかるように素晴らしいことです。
欠点は、ユーザーインターフェイスをまだ磨く必要があり、バグがあることですが、開発はまだ活発であり、報告されたバグは比較的迅速に修正されます。
cfengineを使用するのは、それとパペット以外には何もないからです。実際には優れたツールですが、ポリシーがどれだけ優れているかという関数としてのみ「優れた」ものです。危険なポリシーを設定すると、小さな間違いが多くの損害を引き起こす可能性があります。たとえば、ポリシーにより、ファイルを「変更」することはありません。ファイルを置き換えるか、または変更しません。また、置き換えられるすべてのファイルにはヘッダーがあり、編集者に次回の実行時に置き換えられることを知らせます（cronを1時間ごとに実行します）。
cfengineによってサーバーにプッシュされた構成およびすべてのファイルもSCMに保持され、可能な場合はポストコミットフックを使用して構文をチェックし、失敗した場合、コミットは拒否されます。これは、Apacheなどの優れたアプリケーションでは簡単ですが、ほとんどのエンタープライズアプリケーションではそれほど簡単ではありません。
私はPuppetで成功しました。 シェフは新しく登場しました。オプションのより長いリストと比較チャートについては、ウィキペディアの記事「Open source configuration management softwareの比較」を参照してください。
ターゲットシステムに応じてインストールを自動化する場合：
その上での構成管理については、パペットを使用することをお勧めします。
Puppetへの別の投票はこちら。すべてのサーバーおよびアプリケーションのインストールと構成管理を実行するために広範囲に使用します。200以上のノードとカウント。Windowsサポートは明らかに開発中ですが、どの状態にあるのかはわかりません。
私たちはまだ初期のOSブートストラップの側面を検討していますが、前述のようにCobblerは興味深いようです。現在、PXEブートとDebian / Ubuntuのpreseedを組み合わせて使用していますが、ほとんど最適ではありません。