数百のDebianサーバーでのアップグレードの管理

数十（数百ではないにしても）のdebianサーバーを最新の状態に維持するためのベストプラクティスは何だと思いますか？次のことに留意してください。

• サーバーのグループがあります（つまり、同一のWebサーバー、DBサーバーなど）。
• いくつかのDebianの問題が存在する可能性があります（lenny、etch）
• すべてのサーバーでループを実行し、apt-get update && upgradeを実行することは受け入れられません（現時点で私がやっていることだからです））これよりも良いはずです！

現在、私が最終的にすべてのアップグレードを完了すると、新しいセキュリティ更新プログラムが投稿され、もう一度やり直す必要があります。

事前にserverfaultコミュニティに感謝します！

私はapt-daterを使用して、すべてのDebianボックスのアップグレードを管理しています。十分にうまくやっているようです。ただし、数百のホストに拡張しようとはしていません。

Googleはdebmarshalでこれを解決しました。

http://code.google.com/p/debmarshal/

これにより、実稼働ホストにインストールするために、アップストリームリポジトリからパッケージを承認できます。

その後、cron-aptを完全自動モードで実行できます。

紹介ビデオは次のとおりです。

http://www.youtube.com/watch?v=L3hRToC23mQ

puppetを使用して、必須ではないパッケージのセキュリティ修正プログラムをアップグレードしてみました。apticronを実行してすべてのサーバーの更新プログラムのリストを電子メールで送信し、次にこれらの更新プログラムを各配布のパッケージとバージョンを提供するパペットマニフェストファイルにマージするスクリプトを毎日実行します。これにより、個々のサーバー上の一連のファイルが更新され、パッケージのアップグレードが必要になったときにアップグレードスクリプトが開始されます。これは適切に機能しましたが、私たちが望むほどテストしていません。このスキームは、複数の場所で同じリソースが定義されていないというPuppetの制限を回避しました。

また、MySQLやPostgreSQLのようなものの自動アップグレードを行うことに不安がありました。この場合、ランダムな更新によってサービスがシャットダウンされる可能性があり、場合によっては1日の途中で停止します。これらは依然として手動で更新する必要があります。

SpacewalkとDebmarshallは、私たちのパペットスキームに適した選択肢のように見えます。

どうやら、Spacewalkは現在Debianの予備サポートを持っています。それが、多分、パペットと一緒に、私の出発点になるでしょう。SpacewalkのDebianサポートを開発している人は、Debianサポートをより高いレベルに引き上げるのに協力してくれて、きっとあなたを愛してくれると確信しています。

Puppetのようなプルベースの構成システムには、bcfg2とcfengineもあります。どちらかがニーズに合っているかもしれません。現在、ラボでbcfg2を展開しています。

解はfuncで与えることができます

どんなタイプのソリューションを期待しているのかわかりません。おそらくcronジョブについて知っていますが、人間の介入が必要なため、盲目のシステムを更新しません（そして、それが彼らがこれを行うためにあなたに支払う理由ですよね？）

完全に同一のシステムがある場合、rsyncのようなものを使用して違いをもたらすことを検討するかもしれませんが、rsyncにしないファイルを見つけることは困難な場合があり、サービスの実行中はこれを行いません。少なくとも更新スクリプトは、サービスの再起動と構成ファイルの違いのマージを管理するように設定されています。

おそらく、apt-getコマンドを実行することの問題を説明すると、回避したいことがわかります。

問題が帯域幅とダウンロードの時間である場合は、おそらくローカルのDebianリポジトリとして機能するように1つのボックスをセットアップする必要があります。その方法に関するDebianガイドがあります。

更新する必要のあるものの数を最小限に抑える方法に関するヒントを次に示します。

Debianをインストールするとき、そのコンソールでXを本当に使用する必要がない限り、デスクトップをインストールしないでください。ほとんどのサーバーにはXをインストールする必要はありません。これにより、システム上のパッケージの数が大幅に減少する可能性があり、その後、多くのパッケージを更新する必要はありません。

sources.listに本当に必要なリポジトリのみが含まれていることを確認してください。いくつかのリポジトリを試してみて、それを忘れてしまった場合は、必要のない、または必要のないアップデートを持ち込む可能性があります。

本番サーバーで盲目的にアップデートを行うことに問題が発生した場合、メジャーアップデート（4.0から5.0）がある場合はDebianアップグレードガイドを参照してください。アップグレード手順に従えば、これらは非常にうまくいきます。apt-get dist-upgradeを実行して、立ち去るほど簡単ではありません。時々、説明書にはapt-getではなくaptitudeを実行するタイミングに関するポインタさえあります-それらには小さな違いがあります。

このツールは「ダンサーのシェル」ですか？私はそれが好きで、私はそれを使用しています。しかし、非常に多くのホストに使用できるかどうかはわかりません。たぶんあなたは試すことができます...

http://www.netfort.gr.jp/~dancer/software/dsh.html.en

そして彼はリポジトリにいます。

ClusterSSH。すべてのサーバーにログオンして、まったく同じコマンドを与えるため、ダイアログに反応することもできます。あるサーバーが追加の質問を受け取った場合は、そのサーバーをクリックするだけで応答します。

25のWebサーバーをetchからlennyにアップグレードするために使用しました。魅力のように働いた。

http://sourceforge.net/projects/clusterssh/

Cluster sshをお勧めします。

debmarshalはまだdebianの一部ではありません-それがパッケージになるかどうかさえわかりません-特殊なリポジトリを備えた完全に異なるシステムのようです。講演者が言ったように、これは現在ユーザーに敵対的であり、ユーザーフレンドリーではありません。

Spacewalkは、少なくともWebインターフェースではRedhat Networkのクローンのようです。Redhat Networkを使用してシステムを更新すると、悪い結果になりました。一時的にハングし、明白な理由もなく、サービスが停止しました。私はすぐにyumの更新を行いましたが、その罰金はうまく処理されたので、問題はRHN側で問題を起こしたものに起因すると推測できます。RHNの更新に関して私が気に入らないもう1つの点は、更新がいつ行われるかわからないことです。