RHEL / RHELベースのサーバーの自動更新を実行する方法に取り組んでいます。
最初のアイデア： Puppetを使用して、デフォルトのリポジトリを無効にし、独自のリポジトリを指定します。次に、ensure => latest自動的に更新するパッケージに使用します。
問題：更新後に一部のサービスが再起動することがわかりました（当たり前）。
質問： Linuxの更新を自動化する方法や、サービスの自動再起動を緩和するための戦略に関するアドバイスはありますか？Puppetを含むソリューションをお勧めしますが、別のサービスを使用する必要がある場合、それは契約違反ではありません。
考えられる解決策： @ voretaq7と@ewwhiteが提案したものの多くを実装する解決策を提出しました。これが私が当分の間行っているルートであるようです。他に提案がある場合は、コメントするか回答を送信してください。
回答:
一般的な更新戦略は健全です。ローカルリポジトリ（dev環境でテストすることを想定しています）があり、それに基づいてすべてを更新します（既知の適切であると想定）。
サービスの再起動は避けられません。基盤となるコードが変更された場合、その変更を有効にするにはサービスを再起動する必要があります。そうしないと、結果が悪化する可能性があります（共有ライブラリと同期していないコードを実行すると、アプリケーションがクラッシュします）。
私の環境では、四半期ごとのパッチウィンドウは四半期ごとに「すべてを再起動してください」と考えています。窓も。このようなポリシーの利点は、再起動後にサーバーが復旧することを知っており、サーバーが正常に動作することを知っていることです（定期的にテストするため）。
あなたへの私の最善のアドバイスは、ソフトウェアリリースをスケジュールすることです（おそらく、これはパペットで「手動で」トリガーする必要があることを意味します）。
代わりに（またはその一部として）、いくつかのマシンまたはサービスを再起動し、エンドユーザーにサービスを提供できるように、環境に冗長性を構成できます。これにより、中断が完全になくなるわけではありませんが、最小限に抑えることができます。
追加された冗長性は、ハードウェア障害が発生した場合にも保護されます。ハードウェア障害は、長い時間スケールでは避けられません。
パッケージの更新後にサービスを再起動すると、必ずしも問題がありますか？展開する前に小規模でテストして、問題があるかどうかを確認します。最近、DenyHostsの rpmforgeパッケージにい問題がありました。実際に、yum更新からのリビジョン間で、構成と作業ディレクトリの場所を変更しました。それはまったく望ましくない動作です。通常、RHELの同じリビジョン内では、あまり多くの問題はありませんが、効果を綿密にテストおよび監視しなければ確認できません。
別のオプションは、サービスを選択的に更新することです。たとえば、常に最新のパッケージが必要ですか？これは、更新を実行する理由を理解することに戻ります。本当の目標は何ですか？
独自のリポジトリを実行する利点は、リリースまたはロールアウトをステージングし、スケジュールを管理できることです。RHEL 5.6を必要とするハードウェアペリフェラルまたはソフトウェアベンダーがあり、5.7未満の場合はどうなるでしょうか。これは、独自のパッケージを管理することの利点の1つです。
@ビーミングメルビン
単純化により、ssh for loopツールを使用してパペットを開始/停止する必要がなくなります。
まず、ENCから値が取得される「noop」という変数を含めるようにマニフェストを変更する必要があります。
したがって、クラスには次のようなものがあります。
noop => $noop_status
noop_statusENCで設定されている場所。値をnoop_statusに設定するtrueと、マニフェストはnoopモードでのみ実行されます。
ホストが数百または数千ある場合、ダッシュボードやフォアマンなどのENCを使用して、「ホストグループ」または「ドメイン」レベルでパラメータを継承することで、多くのホストのパラメータを一括変更できます。その後、少数のテストホストの値を「false」に設定して、Hostgroup値を上書きできます。
これにより、選択したホストのみに変更が適用されます。
中央の場所で1つのパラメーターを変更すると、ループツールのsshでパペットをオン/オフする必要なく、任意の数のホストに影響を与える可能性があります。安全/管理のために、ホストを複数のグループに分けることができます。
また、マニフェストにパッケージのバージョン番号をハードコーディングする代わりに、ENCにそれらを配置できることに注意してください。上記と同様に、選択的に変更を適用し、ロールアウトを管理できます。
より細かく（および複雑に）したい場合は、クラスごとのパラメータなどnoop_status_apacheClassを設定することもできます。
include他のクラスでクラスを作成する場合、これは管理が難しくなる場合があります。
可能なソリューションベースの@ voretaq7の答え：
puppetマニフェスト内のパッケージのバージョン番号をハードコードし、独自のリポジトリでパッケージを維持します。
パッケージの新しいバージョンが提供するものに対して行う必要がある場合（セキュリティの強化、お客様が必要とする機能など）、パッケージをリポジトリにダウンロードします。
テストサーバーで更新されたパッケージをテストします。
更新がテストされたら、funcまたはのようなものを使用して、影響を受けるノード上のエージェントpsshを停止しpuppetます。
puppetマニフェストを更新して、影響を受けるノードにパッケージの新しいバージョンがインストールされるようにします。
最後に、またはpuppet agent --onetime && rebootを使用してサーバーで実行しますfuncpssh
このソリューションの欠陥や、単純化できるものを見つけたらコメントしてください。