時々、本番環境の Web/DB/ツール ボックスにログインすると、次のような典型的なメッセージが表示されます。
30 個のパッケージを更新できます。16 個の更新はセキュリティ更新です。
私の質問は、皆さんは本番環境の Ubuntu ボックスのアップデートをどのように処理していますか? これらのアップデートは自動化していますか? ダウンタイムを設定していますか? 問題は、アップデートによって、既存の構成ファイルなどがいつ壊れるかわからないことです。
この問題のもう 1 つの側面は、パッチを適用することは「良いこと」ですが、パッチはほぼ毎日リリースされるということです。毎日新しいセキュリティ パッチが利用可能になると、計画的な停止を何回行う必要があるでしょうか。
アップデートをどのように管理するかについての回答のスレッドは非常に役立つと思います。
答え1
Ubuntu と Windows、RHEL、CentOS、SuSE、debian などのパッチ適用には特別な点はありません。
パッチ手順を設計する際に必要な基本的な心構えは、何かを想定することです。意思壊す。
パッチ設定を設計するときに私がよく使用する基本的なガイドラインは次のとおりです。
- パッチをインストールするネットワークを内部的に集中管理するには、常にローカルシステムを使用してください。
これには、WSUS の使用や、内部パッチ管理マシンへのミラーリングが含まれる場合があります<your_os_here>。個々のマシンにインストールされているパッチのステータスを集中的に照会して知らせてくれるものが望ましいです。
- 可能な場合は、マシン上でインストールを事前に準備します。
可能であれば、パッチがリリースされると、中央サーバーがパッチを個々のマシンにコピーします。これは、ダウンロードとインストールを待つ必要がなくなり、パッチ適用期間中にインストールを開始するだけで済むため、時間の節約になります。
- パッチをインストールするための停止時間を設けてください。再起動が必要になる可能性があり、おそらく何かが壊れるでしょう。それらのシステムの利害関係者がパッチが展開されていることを認識していることを確認してください。「これは機能しない」という要求に備えてください。
パッチは物事を壊すという私の基本的な理論に従って、重大な問題のトラブルシューティングと、場合によってはパッチのロールバックを行うのに十分な時間、パッチを適用するための停止ウィンドウを確保してください。パッチ適用後に必ず人員を配置してテストを行う必要はありません。個人的には、すべてが最低限のレベルで機能していることを確認するために、監視システムに大きく依存しています。しかし、人々が仕事に取り掛かるときに、小さな問題が呼び出されることに備えておくことも必要です。電話に出る準備を常に誰かにしておく必要があります。できれば、午前 3 時までボックスにパッチを当てていた人ではなく、電話に出る人が望ましいです。
- 可能な限り自動化する
IT の他のすべてと同様に、スクリプト、スクリプト、そしてさらにスクリプトを作成します。パッケージのダウンロード、インストールの開始、ミラーリングをスクリプト化します。基本的に、パッチ ウィンドウを、障害が発生した場合に備えて人間が必要なベビーシッターの割り当てに変えたいと考えています。
- 毎月複数のウィンドウを開く
これにより、何らかの理由で「指定された夜」にパッチを適用できない場合、一部のサーバーにパッチを適用しないことができます。 1 日目の夜にパッチを適用できない場合は、2 日目の夜にサーバーを空ける必要があります。 また、同時にパッチを適用するサーバーの数を適切な数に保つこともできます。
最も重要なことパッチを適用し続けてください!そうしないと、追いついた時点に戻るために 10 時間以上のパッチ ウィンドウを実行する必要が生じます。問題が発生する可能性のあるポイントがさらに増え、どのパッチが問題を引き起こしたのかを特定するのがさらに困難になります。
この問題のもう 1 つの側面は、パッチを適用することは「良いこと」ですが、パッチはほぼ毎日リリースされるということです。毎日新しいセキュリティ パッチが利用可能になると、計画的な停止を何回行う必要があるでしょうか。
月に 1 回または 2 か月に 1 回サーバーにパッチを適用することは、私見では、非常に達成可能で、許容できる目標です。それ以上になると、サーバーに常にパッチを適用することになり、それ以下になると、サーバーごとに適用する必要のあるパッチが何百もある状況に陥り始めます。
1 か月に何個のウィンドウが必要でしょうか? それは環境によって異なります。サーバーは何台ありますか? サーバーの稼働時間はどのくらい必要ですか?
9x5 の小規模な環境では、おそらく 1 か月に 1 回のパッチ ウィンドウでも十分でしょう。24x7 の大規模な環境では 2 回必要になる場合があります。24x7x365 の非常に大規模な環境では、毎週異なるサーバー セットにパッチを適用するために、毎週ローリング ウィンドウが必要になる場合があります。
あなたとあなたの環境に適した周波数を見つけてください。
覚えておいてほしいのは、100%最新の状態というのは不可能達成すべき目標 - セキュリティ部門にそうではないことを言われないようにしてください。最善を尽くし、あまり遅れを取らないようにしてください。
答え2
やる事：
- バックアップを取る
- 復元可能なバックアップであることを確認する（ただし、これら 2 つは一般的なポイントです）
- アップグレード中は、トラフィックを本番ボックスから遠ざけるようにしてください。
- 万が一問題が発生した場合に備えて、KVM、シリアル コンソール、ローカル アクセス、またはリモート ハンドなどの帯域外アクセス方法を用意してください。
- 1 台のサーバーでテストし、すべてが機能することを確認した後、更新プログラムを他のサーバーに展開します。
- 可能であれば、複数のサーバー間でバージョン番号が同じになるように puppet を使用してください。(強制的にアップグレードするためにも使用できます)
- テスト サーバーで、構成ファイルのバージョンを新しい (更新がインストールされた) 構成ファイルと比較し、重大な問題がないことを確認します。現在インストールされているバージョンと異なる新しいバージョンをインストールする前に、dpkg が確認を求めてきたように思います。
避けるべきこと:
- 日中に更新したり、月曜日の午前 9 時や金曜日の午後 5 時に更新したりします。(@3influence に感謝します!)
- 非常に大きなデータベース サーバーで MySQL をアップグレードする (再起動には長い時間がかかる可能性があります)
- すべてのサーバーを一度に実行する（特にカーネル）
- /etc/networks を変更する可能性のある操作を行う（接続が失われる可能性があるため）
- 自動更新により、ユーザーがその場にいなくても、すべてが正常であるかどうか確認することなく、上記の処理を実行できます。
答え3
もう一つの注目すべき点は、Windowsに慣れている人なら、Linuxのアップデートのほとんどがないダウンタイムや再起動が必要なものもあります。カーネルの更新など、必要なものもあります。ただし、再起動やダウンタイムが必要な更新には通常、そのようにフラグが付けられ、別のスケジュールで処理できます。
答え4
Ubuntu LTS システムの更新は次のように処理します。
- ソフトウェアのすべてのクリティカルパスをチェックする一連の受け入れテストを維持します
- 毎朝 4 時にセキュリティ アップグレードを無人でインストールし、すぐに受け入れテストを実行します。何か問題が発生した場合、エンジニアに呼び出しがかかり、午前 9 時までに問題を修正するかロールバックする十分な時間があります。これは、5 年間でこれまでに 2 回しか発生していません。LTS は十分にテストされ、安定しています。
- 当社では毎週、ブルー/グリーン デプロイメントを使用してインフラストラクチャ全体を (digitalocean 上で) 自動的に再デプロイし、すべてのパッケージを最新バージョンに維持しています。新しいデプロイが受け入れテストに合格しない場合は、エンジニアが問題をデバッグするまでデプロイは保留されます。
私たちにとっての次の論理的なステップは、メモリ内のセッション情報を排除することです。これにより、顧客に影響を与えることなく、インフラストラクチャを毎日、または 1 日に複数回再展開し、ステップ (2) を排除できるようになります。
このアプローチはメンテナンスが少なく、メンテナンス ウィンドウを完全に回避します。