web-dev-qa-db-ja.com

Linuxの自動更新のベストプラクティス

RHEL/RHELベースのサーバーの自動更新を実行する方法に取り組んでいます。

最初のアイデア： Puppetを使用して、デフォルトのリポジトリを無効にし、独自のリポジトリをポイントします。次に、自動更新するパッケージにensure => latestを使用します。

問題：一部のサービスが更新後に再起動する（duh）ことがわかりました。

質問： Linuxの更新をより適切に自動化する方法や、サービスの自動再起動を軽減するための戦略について何かアドバイスはありますか？ Puppetを含むソリューションをお勧めしますが、別のサービスを使用する必要がある場合、それは取引を妨げるものではありません。

編集する

可能な解決策：私は、@ voretaq7と@ewwhiteの提案の多くを実装する解決策を提出しました。とりあえずこれが私が行くルートだそうです。他に提案がある場合は、コメントするか、回答を送信してください。

linuxyumpuppetbest-practices
11
Belmin Fernandez

あなたの一般的な更新戦略は健全です：あなたはローカルリポジトリ（私はあなたが開発環境でテストすると仮定します）を持っていて、あなたはその（私は既知の良いと仮定します）リポジトリに基づいてすべてを更新します。

サービスの再起動は不可避です。基盤となるコードが変更された場合、その変更を有効にするにはサービスを再起動する必要があります。そうしないと、結果が悪化する可能性があります（コードを実行すると、共有ライブラリと同期が取れなくなり、アプリケーションがクラッシュします）。
私の環境では、四半期ごとのパッチウィンドウは四半期ごとに「すべてのものを再起動してください！」と考えています。窓も。このようなポリシーの利点は、サーバーが再起動後に復旧することをknowであり、knowサーバーが正しく機能することです（定期的にテストするため） 。

ソフトウェアリリースのスケジュールを立て（多分これはパペットで「手動で」トリガーする必要があることを意味します）、計画されたメンテナンス/ダウンタイムをユーザーに通知することをお勧めします。
または、（またはこの一部として）環境に冗長性を構成して、いくつかのマシンまたはサービスを再起動し、エンドユーザーにサービスを提供することができます。これによって混乱が完全になくなるわけではありませんが、混乱を最小限に抑えることができます。

追加された冗長性は、ハードウェア障害が発生した場合にも保護します。ハードウェア障害は、十分な時間スケールで避けられません。

14
voretaq7

パッケージの更新後にサービスを再起動することに必ずしも問題がありますか？展開する前に小規模でテストして、問題があるかどうかを確認します。最近 DenyHosts のrpmforgeパッケージで醜い問題がありました。実際には、yumアップデートのリビジョン間で、構成と作業ディレクトリの場所が変更されました。それはまったく望ましくない動作です。通常、RHELの同じリビジョン内では、問題はそれほど多くありませんが、効果をテストして注意深く観察しないと、確信が持てません。

別のオプションは、サービスを選択的に更新することです。たとえば、常に最新のパッケージが必要ですか？これは、更新を実行する理由の理解に戻ります。本当の目標は何ですか？

独自のリポジトリを実行する利点は、リリースまたはロールアウトをステージングしてスケジュールを管理できることです。 RHEL 5.6を必要とするハードウェアペリフェラルまたはソフトウェアベンダーがあり、5.7で機能しない場合はどうなりますか？これは、独自のパッケージを管理することの利点の1つです。

5
ewwhite

@Beaming Mel-Bin

簡素化により、ssh for loopツールを使用してパペットを開始/停止する必要がなくなります。

まず最初に、マニフェストを変更して、値がENCから供給される「noop」と呼ばれる変数を含める必要があります。

したがって、クラスには次のようなものがあります。

noop => $noop_status

ENCでnoop_statusが設定されている場所。 noop_statusの値をtrueに設定すると、マニフェストはnoopモードでのみ実行されます。

数百または数千のホストがある場合は、ダッシュボードやフォアマンなどのENCを使用して、「ホストグループ」または「ドメイン」レベルで継承することにより、多くのホストのパラメーターを一括変更できます。次に、少数のテストホストの値を「false」に設定して、ホストグループの値を上書きできます。

これにより、変更は選択したホストにのみ適用されます。

中央の場所で1つのパラメーターを変更すると、ssh forループツールでパペットのオン/オフを切り替える必要なしに、任意の数のホストに影響を与える可能性があります。安全/管理のためにホストを複数のグループに分割できます。

また、マニフェストにパッケージのバージョン番号をハードコーディングする代わりに、それらをENCに入れることができます。また、上記と同様に、変更を選択的に適用し、ロールアウトを管理できます。

より細かく（そして複雑に）したい場合は、noop_status_apacheClassなどのクラスごとのパラメーターを設定することもできます。

他のクラスのクラスをincludeすると、これを管理するのが難しくなる可能性があります。

2
Not Now

@ voretaq7の答えに基づく可能な解決策：

  1. puppet内のパッケージのバージョン番号をハードコードして、パッケージを独自のリポジトリにマニフェストして維持します。

  2. パッケージの新しいバージョンが提供するもの（セキュリティの強化、お客様が必要とする機能など）を実行する必要がある場合は、パッケージをリポジトリにダウンロードします。

  3. 更新されたパッケージをテストサーバーでテストします。

  4. 更新がテストされたら、funcやpsshなどを使用して、影響を受けるノードのpuppetエージェントをシャットオフします。

  5. puppetマニフェストを更新して、影響を受けるノードに新しいバージョンのパッケージがインストールされていることを確認します。

  6. 最後に、funcまたはpsshを使用してサーバーでpuppet agent --onetime && rebootを実行します

コメントして、このソリューションの欠陥や、簡略化できる何かを見つけたらお知らせください。

1
Belmin Fernandez