多数のCentOSサーバーのパッケージ更新を管理するための良い習慣

私の仕事の一環として、メインセットアップにpuppetを使用して、数十台のCentOS 5サーバーを管理しています。サーバーの約半数は、さまざまなdjangoサイトをホストするための標準化されたセットアップを備えていますが、残りはアプリケーションのごちゃごちゃしたものです。

ホスティングプラクティスを段階的に整理し、OSレベルでセキュリティ更新プログラムを管理する方法を検討する段階に達しました。cronジョブを実行することには警戒していyum -y updateますが、各サーバーを時間内に巡回し、利用可能な更新があるすべてのパッケージを確認する必要もありません。これには時間がかかります。

関係するリスクを最小限に抑え、費やす必要のある時間を最小限に抑えるための適切なショートカットや作業方法があるかどうか疑問に思っています。別の言い方をすれば、多くの作業を自動化しながら制御を行うことができるツールやプラクティスがあります。

これまでに決めたステップ：

• すべてのサードパーティのリポジトリを無効にし、独自のリポジトリを設定して、そこでどの更新が行われるかを制御できるようにします。
• テストを行うことができる（ほとんどの）実稼働サーバー用のステージングサーバーがあります（ただし、テストはどれだけのテストで十分ですか？）

また、yumセキュリティプラグインを調べましたが、CentOSでは機能しません。

では、異種アプリケーションのアレイを実行している多数のCentOSサーバーの更新をどのように管理しますか？

私の環境のほとんどでは、通常、キックスタートとポストインストールスクリプトを使用して、その時点でメインシステムを最新の状態に更新します。通常、CentOSミラーと毎日または毎週同期するローカルリポジトリがあります。私は、インストール時の時点でカーネルパッケージをフリーズし、パッケージを個別に、または必要に応じて更新する傾向があります。多くの場合、サーバーにはカーネルバージョンに密接にリンクされたドライバーを備えた周辺機器があるため、これは考慮事項です。

CentOS 5は、定期的な更新が不要になるまで成熟しました。ただし、CentOS 5が縮小していることにも留意してください。更新の速度は多少遅くなり、更新の性質はバグ修正とよりインラインになり、主要な機能の変更については少なくなりました。

したがって、この特定の場合、最初にできることは、ローカルミラー/レポを構築することです。既存の構成管理を使用して、サードパーティのリポジトリへのアクセスを制御します。重要なサービスや公開サービス（ssh、http、ftp、dovecotなど）をyum更新するためのポリシーをスケジュールするかもしれません。

これに役立つツールはたくさんあります！一般に、パッケージシステムとどのパッケージがどこに行くかは、構成管理によって処理されます。これらのツールは通常、yumとrpmだけではなく、時間を節約し、多くの頭痛の種を防ぎます！

私が最もよく知っているツールは、環境内のほぼすべての構成を管理するために使用するパペットです。yumを具体的に管理するためのパペットの例を次に示します。

http://people.redhat.com/dlutter/puppet-app.html

現在利用可能な構成管理ツールがいくつかありますが、これらにはかなり大きなユーザーグループがあります。

• Cfengine http://cfengine.com/cfengine3
• Puppet http://puppetlabs.com/puppet/puppet-difference/
• Chef http://wiki.opscode.com/display/chef/Home（私が知っている少数の人々が最近これを実装し、気に入っています）

環境にこれらを実装すると、あなたの人生に何年も追加されます。適切に構成されていないシステムによる頭痛の種を減らし、簡単にアップグレード/更新できます。また、これらのツールのほとんどは、いくつかの監査レベルの機能も提供できます。これにより、構成ミスの修復時間を大幅に短縮できます。

テストに関するあなたの質問に関して、私は一部の顧客のロード先となるステージング環境を使用しています（通常はベータ顧客または実稼働トラフィックの小さなサブセット）。通常、このクラスターは、運用環境に展開する前に、少なくとも数日間、最大1週間（変更の重大度に応じて）新しいコードを実行させます。通常、このセットアップは、ほとんどのエラーを発見するのにかかる時間を試してみると最適に機能することがわかりました。頻繁に使用されるシステムでは、これは数時間かかる場合があります。ほとんどの環境では、1週間でステージング/ QAの珍しいバグを発見するのに十分な長さです。

テストに関する本当に重要な部分の1つは、データ/使用量の複製です。実稼働ハードウェアのほとんどのステージングバージョンがあると述べました。運用データの同一のコピーもありますか？それに対して本番負荷を再生できますか？トラフィックミラーリングを使用して、運用クラスタの一部にすることさえできますか？これは通常、ビジネスがテスト/ QAに費やす意思のあるリソースの量との間の直接的なトレードオフになります。テストが多ければ多いほど、（理由の範囲内で）自己制限しないようにし、ビジネスがサポートするものを確認します（そして、10％以上を行う方法を見つけます）。