本番環境での制御された更新の計画

ソフトウェアとOSの更新は、最小限の停止時間が求められるミッション・クリティカルなアプリケーションがある複雑な本番環境で問題になることがあります。1つの解決策として、テスト済の単一のOracle Linuxリリースと更新レベルに環境をロックして、OSを頻繁に更新しないようにすることが考えられます。ただし、この方法ではセキュリティの脆弱性によるリスクが高まり、統合テストがより困難になる可能性があります。

ソフトウェア更新戦略を実装し、本番システム上のOSと基礎となるソフトウェアが頻繁に更新され、ソフトウェアの更新によるアプリケーションの破損のリスクを管理できるようにすることをお薦めします。

次のガイドラインは、ベスト・プラクティスに沿って、予期しない変更から本番システムを保護するソフトウェア更新戦略を実装するために役立ちます。

ローカルULNミラーを作成します。
システムに更新をロールアウトする際の課題の1つは、統合およびテスト環境で更新をテストしていたとしても、更新されたパッケージのソースを管理していないと、統合テストの期間と本番環境でパッケージの更新をロールアウトする時点までの間に、パッケージに変更が実施されている可能性があることです。

ローカルULNミラーを作成すると、チャネルをミラー・サーバーに同期するタイミングと頻度を制御できます。パッケージの選択は同期期間の間は静的であるため、パッケージのセットをテストしてから、本番環境を既知のワーキング・セットに更新する機会が得られます。

ミラー・サービスにULNを使用すると、Ksplice更新が含まれているチャネルをミラーリングできるため、オフラインのKspliceサービスを利用できます。オフラインKspliceを使用すると、インメモリー・カーネル更新を使用して再起動を回避できます。同時に、これらの更新をまず統合環境でテストしてから、本番環境に更新を適用できます。
リスクと脅威の軽減に基づいた段階的な更新戦略を検討します。
すべての更新が同じであるとはかぎりません。ULNミラー・チャネルの時間同期は、要件に応じて実行できます。これらの要件に基づいて、システムを異なるスケジュールで異なる更新タイプを実行するように構成できます。たとえば、次のような戦略で作業できます。
- カーネルおよびユーザー・スペースのOracle Ksplice更新を、少なくとも毎週実行するようにスケジュールします。必要に応じて、まず統合テスト環境内でこれらの更新を精査できます。
- セキュリティ関連のパッケージ更新については、毎月のメンテナンス・スケジュールに従い、セキュリティ・ツールからのアラートやエラッタ通知に沿って実行してください。これらのタイプの更新には、dnf update --securityコマンドを使用します。
- ULNミラー・スナップショットを使用するフル・パッケージ更新を実行するには、少なくとも四半期ごとのメンテナンス・スケジュールを適用します。これらの更新を本番サーバーに実装する前に、まず統合テスト環境で更新を精査してください。

アトミック更新を定期的に実行すると、統合の問題が発生したときの解決が容易になり、潜在的なセキュリティ問題からより適切に環境を保護できます。統合テスト環境とYumまたはULNミラーを使用することは、プラットフォームの安定性の維持と侵害からの保護のために重要です。