多くのクライアントに対してほぼ同じサーバーとVPSを常に設定しているので、非常に時間がかかることがあります。多くの場合、各デプロイメント間で変更される唯一のものは、提供される異なるWebサイトです。これらすべてを自動化し、56台の同一のサーバーを設定するという退屈な単調さを取る簡単な方法はありますか?
これまでに展開したサーバーはUbuntuだけでしたが、他のLinux OSやWindowsを使い始めた可能性もあります。これまでのところ、カピストラーノを見てきましたが、仕事をするための小さなRubyプログラムを書くことに焦点が当てられているようで、まったく知識がありません
Puppet 何をしようとしているかに最適なように聞こえますが、現時点では、Windowsはサポートされていません。
あなたのケースでは、マシン全体で同一であるすべてのパッケージに関してサーバーノードを定義します。次に、個々のホストをサーバーから継承するノードとして定義し、それに固有の固有のものを設定します。
パペットは宣言型です-各ボックスが持つべきリソースの観点からボックスを説明することができます。したがって、ssh
が必要な場合は、そのリソースのクラスを作成し、そのクラス内に、FreeBSDとUbuntuでsshがどのように呼び出されるかについてのロジックを含めることができます。また、Redhat内ではyum
を、Debianベースのディストリビューション内ではapt-get
を、BSDではports
を使用することも認識しています。これでサーバーノードにinclude ssh
のような行が表示されます。puppetは正しいことを行い、SSHをマシンに配置します。UbuntuかRedhatかFreeBSDかを覚える必要はありません。
何がいいのかと言うと、すべてのサーバー要素が1か所に存在し、サーバーノード定義にいずれかの時点で追加すると、すべてのマシンがそれに応じて構成を更新します。
現在、私はPuppetを使用して3つのボックスを管理しているだけですが、既に完済しています。実験で刺激の提示に使用するボックスのセットアップに1週間を費やした後、グラフィックカードドライバーが、私が装着したUbuntuのバージョン(8.04)では古すぎることがわかりました。最新のUbuntu(9.04)をインストールする必要がありましたが、その後はapt-getを実行してパペットを実行するだけで済み、セットアップに1週間費やしていたものがすべて復元されました。
Puppetには少し学習曲線がありますが、私は学習を回避することに成功しましたRuby-私はそれを使用していることを知っています、それはそれがPuppetが書かれているものだからです-しかし、これまでのところ ドキュメントの例とwikiのレシピ を変更するだけで成功しました。もう1つの欠点は、パペットが最初に行うのに少し時間がかかることです。すべてのマシンが1か所に保存されます-バージョンコントロールシステムにパペットの設定を保存するのが標準的な方法です。過去を振り返り、過去にサーバーを設定した方法を常に確認したり、失敗した変更をロールバックしたりできます。 。
最後に、ここに クイックビデオ を示します。これにより、簡単に始められた簡単な人形のデモが行われます。
We 使用 Cobbler および Puppet は、実マシンと仮想マシンの両方のビルドと構成の自動化に使用します。
CobblerはDHCP、PXEブート、Kickstartを結び付けて、マシンプロファイルを追加して電源ボタンを押すだけで導入を行います。 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は、システムの構成が定義されたマニフェストと一致することを定期的にチェックするデーモンとして実行されます。更新が行われたことがわかります。すべてのサーバーに。また、メンテナンスのためにダウンしているボックスが正しい構成になっていて、実際のサービスに戻す前に、これを確認することもできます。
人形は本当に素晴らしいです。構成のすべての側面を制御下に置く必要はありません。まず、すべてのボックスで構成する必要がある単純なものを管理して(sudoers
は標準的な例です)、そこから取得します。 。 Puppetマニフェストもバージョン管理されていることを確認してください。何を調整するかを覚えておかなくても、簡単に既知の正常な構成にロールバックできることよりも良いことはありません。
現在私が取り組んでいるのは、サーバーファームのLinux部分である300台を超えるLinuxサーバーを管理することです。これには主にHP Proliantsが含まれ、続いてIBM 3850、一部のIBMブレード、VMware ESX、一部のKVM当社の内部管理サーバー用)が続きます。
コブラーを調べましたが、コブラーは非常にRHEL/Red Hat固有であるという問題がありました。少なくともRHELとSLESをサポートする必要があります。次はUbuntuです。
私たちは人形について検討しましたが、Rubyに依存しているため、後で反対に決定しました。つまり、Rubyのアップグレードにより、管理システムが破壊される可能性があります。
Hotwireは私たちが使用しているもの(内部で開発されていますが、オープンソースです)であり、過去数年にわたってそうしています。まず、構築するシステムのインベントリを作成します。つまり、データセンター、ラック、ハードウェア、オペレーティングシステム、ネットワークなどのインベントリを作成し、次に、迅速な構築と展開を実行します。システムが構築されると、hotengineの自動インベントリがインベントリを同期させ、cfengineがそれらを維持します。 Hotwireは、 python-dmidecode を介してBIOSのSMBIOS/DMIデータと通信することにより、サーバーハードウェアを認識します。
ボーナスポイントは、インベントリとビルドプロセスが1つにまとめられているため、管理が少なくて済み、ライブインベントリ機能は、何かが正しくない場合にわかるように優れています。
不利な点は、ユーザーインターフェイスを磨く必要があり、バグが散在していることですが、開発はまだ熱く、報告されたバグは比較的速く修正されます。
Cfengineを使用するのは、それとパペット以外には何もないためです。それは実際にはは良いツールですが、「良い」というのは、ポリシーがどれだけ良いかという関数だけです-危険なポリシーを設定した場合、小さな間違い多くの損傷を引き起こす可能性があります。たとえば、ポリシーにより、ファイルを「変更」することはありません。ファイルを置き換えるか、または置き換えません。また、置換されたすべてのファイルにはヘッダーがあり、編集者は次回実行時に置換されることを認識できます(毎時cron経由で実行されます)。
Cfengineによってサーバーにプッシュされた構成とすべてのファイルもSCMに保持され、可能な場合はコミット後フックを使用して構文を確認し、失敗した場合はコミットを拒否します。これは、ApacheなどのNiceアプリケーションでは簡単ですが、ほとんどのエンタープライズアプリケーションでは簡単ではありません。
Puppet で成功しました。 Chef は新しく登場するものです。オプションの詳細なリストと比較表については、Wikipediaの記事オープンソース構成管理ソフトウェアの比較を参照してください。
ターゲットシステムに応じてインストールを自動化する場合:
その上での構成管理については、人形を使用することをお勧めします。
ここで人形への別の投票。すべてのサーバーとアプリケーションのインストールと構成管理を実行するために、これを幅広く使用しています。 200以上のノードとカウント。 Windowsのサポートは明らかに開発中ですが、どのような状態かはわかりません。
まだ初期OS bootstrapの側面を調べていますが、上記のように、Cobblerは興味深いようです。現在、PXEブートとDebian/Ubuntuプレシードを組み合わせて使用していますが、ほとんど最適な。
Puppet で多くの成功を収めていますが、多くの設定を作成する必要があります。