本番環境の Ubuntu ボックスの更新に関する推奨事項と禁止事項

解決策 1:

Ubuntu 対 Windows、RHEL、CentOS、SuSE、debian などにパッチを適用することに特別なことはありません。

パッチ手順を設計する際に必要な基本的な心構えは、何かを想定することです。

パッチのセットアップを設計する際に私がよく使用する基本的なガイドラインの一部は次のとおりです。

常にローカルシステムを使用して、パッチのインストール元のネットワークを内部的に集中化します

これには、WSUS、または <your_os_here> のミラーの使用が含まれる場合があります内部パッチ管理マシンに。個々のマシンにインストールされているパッチのステータスを一元的に照会して知らせることができるものが望ましいです。

可能であれば、マシンへのインストールを事前に準備します。

可能であれば、パッチが公開されると、中央サーバーがそれらを個々のマシンにコピーします。これは本当に時間の節約になるので、ダウンロードしてインストールするのを待つ必要はありません。パッチ期間中にインストールを開始するだけで済みます。

パッチをインストールするための停止ウィンドウを取得します。再起動が必要になる場合があり、何かが壊れる可能性があります。それらのシステムの利害関係者が、展開されているパッチがあることを認識していることを確認してください。「これはうまくいかない」という電話に備えてください。

パッチを適用すると問題が発生するという私の基本的な理論に沿って、重大な問題のトラブルシューティングに十分な時間パッチを適用し、場合によってはパッチをロールバックするための停止ウィンドウがあることを確認してください。パッチ後にテストする人をそこに座らせる必要はありません。個人的には、監視システムに大きく依存して、すべてが最小限のレベルで機能していることを知らせてくれます。しかし、人々が仕事に取りかかるときに、ちょっとしつこい問題が持ち込まれることにも備えておきましょう。午前 3 時まで起きてボックスにパッチを当てている人ではなく、電話に出る準備ができている人を常にスケジュールに入れておく必要があります。

可能な限り自動化する

IT の他のすべてと同様に、スクリプト、スクリプト、さらにスクリプトを作成します。パッケージのダウンロード、インストールの開始、ミラーのスクリプトを作成します。基本的に、パッチウィンドウを、問題が発生した場合に備えてそこに人間が必要なだけのベビーシッターの割り当てに変えたいと考えています。

毎月複数の窓口を持つ

これにより、何らかの理由で「指定された夜」にパッチを適用できない場合に、一部のサーバーにパッチを適用しないことができます。夜 1 に実行できない場合は、夜 2 に無料にする必要があります。また、同時にパッチを適用するサーバーの数を正常に保つことができます。

最も重要なことは、パッチに遅れずについていくことです! そうしないと、追いついた時点に戻るためだけに、10 時間以上の非常に大きなパッチウィンドウを作成しなければならないことに気付くでしょう。問題が発生する可能性のあるさらに多くのポイントを紹介し、どのパッチが原因で問題が発生したかを見つけるのがさらに困難になります。
<ブロック引用>
この問題の別の部分は、パッチに遅れずについていくことは「良いこと」ですが、パッチはほぼ毎日リリースされることです。毎日新しいセキュリティパッチが利用できる場合、何回の計画停止を行う必要がありますか?

サーバーに月に 1 回または隔月に 1 回パッチを適用することは、私見ですが、非常に達成可能で受け入れ可能な目標です。それ以上に、サーバーに常にパッチを適用することになりますが、サーバーごとに数百のパッチを適用する必要がある状況に陥り始めます。

月にいくつのウィンドウが必要ですか?それはあなたの環境に依存します。サーバーはいくつありますか?サーバーに必要な稼働時間は?

9x5 の小規模な環境では、おそらく 1 か月に 1 つのパッチウィンドウで問題を解決できます。 24 時間 365 日の大規模な店舗では、2 つ必要になる場合があります。非常に大規模な 24 時間年中無休 365 日では、毎週異なるサーバーセットにパッチを適用するために、毎週ローリングウィンドウが必要になる場合があります。

あなたとあなたの環境に適した頻度を見つけてください。

心に留めておくべきことの 1 つは、100% 最新の状態にすることは 不可能 であるということです。到達する目標 - セキュリティ部門に別のことを言わせてはいけません。ベストを尽くしてください。遅れを取りすぎないようにしてください。

解決策 2:

すべきこと:
<オール>
バックアップを取る

復元可能なバックアップであることを確認してください (ただし、これら 2 つは一般的なポイントです)

アップグレード中は、トラフィックをプロダクションボックスから遠ざけるようにしてください。

すべてがうまくいかない場合に備えて、帯域外アクセス方法、KVM、シリアルコンソール、ローカルアクセス、またはリモートハンドを用意してみてください。

1 つのサーバーでテストし、すべてが機能することを確認してから、更新を複数のサーバーに展開する

複数のサーバーでバージョン番号が同じであることを確認できる場合は、puppet を使用します。 (アップグレードを強制するためにも使用できます)

テストサーバーで、構成ファイルのバージョンを新しい (更新プログラムがインストールされた) ファイルと比較し、重大な問題が発生しないことを確認します。現在インストールされているものとは異なる新しいバージョンをインストールする前に、dpkg が尋ねたことを思い出したようです。

避けるべきこと:
<オール>
更新は日中、月曜日の午前 9 時、または金曜日の午後 5 時に行います。 (ありがとう @3influence!)

非常に大きなデータベースサーバーでの MySQL のアップグレード (再起動には時間がかかる場合があります)

すべてのサーバーを一度に処理する (特にカーネル)

/etc/networks を変更する可能性のあることを行う (接続が失われる可能性があるため)

すべてをチェックするためにそこにいなくても、上記を実行できる自動更新は問題ありません。

解決策 3:

重要なもう 1 つのポイント:Windows に慣れている場合、Linux の更新のほとんどが そうでないことに驚くでしょう。ダウンタイムまたは再起動が必要です。カーネルの更新など、いくつかは行います。ただし、再起動やダウンタイムが必要な更新は通常そのようにフラグが立てられ、別のスケジュールで処理できます。

解決策 4:

私たちの Ubuntu マシンはすべて LTS リリースを実行しています。

すべての更新プログラムを自動的にインストールするだけです。これは「ベストプラクティス」ではありませんが、比較的小規模なショップであり、すべてのサービスのテスト/開発/運用環境を持っているわけではありません。 LTS の更新は、一般的に十分にテストされており、侵襲性が最小限に抑えられています。

新しいリリースへのアップグレードは明らかにもう少し複雑です。

解決策 5:

ubuntu LTS システムでは、次の方法で更新を処理します。
<オール>
ソフトウェアのすべてのクリティカルパスをチェックする一連の受け入れテストを維持する

毎朝 4 時に無人でセキュリティアップグレードをインストールし、すぐに受け入れテストを実行します。何か問題が発生した場合は、エンジニアが呼び出され、問題を修正したり午前 9 時までにロールバックしたりする十分な時間が与えられます。これまでのところ、これは 5 年間で 2 回しか発生していません。LTS は十分にテストされ、安定しています。

すべてのパッケージを最新バージョンに保つブルー/グリーンデプロイを使用して、毎週 (digitalocean で) インフラストラクチャ全体を自動的に再デプロイします。新しいデプロイが受け入れテストに失敗した場合、エンジニアが問題をデバッグできるようになるまで、デプロイは保留されます。

私たちにとって次の論理的なステップは、メモリ内セッション情報を排除することです。これにより、顧客に影響を与えずにインフラストラクチャを毎日、または 1 日に複数回再デプロイし、ステップ (2) を排除できるようになります。

このアプローチはメンテナンスの手間が少なく、メンテナンスウィンドウを完全に回避できます。