本番用Ubuntuボックスを更新すると、すべきこととしないことができます

頻繁に本番web / db / toolsボックスにログインして、典型的なメッセージを確認します。

30個のパッケージを更新できます。16個の更新はセキュリティ更新です。

私の質問は、すべての皆さんが本番用のUbuntuボックスの更新をどのように処理するかです。これらの更新を自動化しますか？ダウンタイムを設定していますか？問題は、更新によって既存の構成ファイルなどが壊れる可能性があることを決して知らないことです。

この問題の他の部分は、パッチに遅れないようにすることは「良いこと」ですが、パッチはほぼ毎日リリースされます。毎日利用可能な新しいセキュリティパッチがある場合、どれだけのスケジュールの停止を行う必要がありますか？

更新の管理方法に関する回答のスレッドは非常に便利だと思います。

Ubuntu、Windows、RHEL、CentOS、SuSE、debianなどにパッチを当てるのに特別なことはありません。

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

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

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

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

• 可能な場合、マシン上でインストールを事前設定します。

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

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

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

• 可能な限り自動化する

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

• 毎月複数のウィンドウがある

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

最も重要なのは、パッチについていくことです！そうでない場合、あなたは、あなたが追いつくポイントに戻るために、あなたの自己が非常に大きな10時間以上のパッチウィンドウをしなければならないことに気付くでしょう。物事がうまくいかない可能性のあるポイントをさらに紹介し、どのパッチが原因で問題を発行しているのかを見つけるのをより困難にします。

この問題の他の部分は、パッチに遅れないようにすることは「良いこと」ですが、パッチはほぼ毎日リリースされます。毎日利用可能な新しいセキュリティパッチがある場合、どれだけのスケジュールの停止を行う必要がありますか？

1か月に1回または1か月に1回サーバーにパッチを適用することは-私見-非常に達成可能で許容可能な目標です。それだけでなく、サーバーに常にパッチを適用し、サーバーにパッチを適用しなければならない状況に陥り始めます。

1か月にいくつのウィンドウが必要ですか？それは環境によって異なります。サーバーはいくつありますか？サーバーに必要なアップタイムはどれくらいですか？

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

あなたとあなたの環境に合った周波数を見つけてください。

心に留めておくべきことの1つは、最新の100％を達成することは不可能な目標であるということです。セキュリティ部門にそれ以外のことを言わせないでください。最善を尽くし、遅れを取りすぎないでください。

やる事：

1. バックアップを取る
2. 復元可能なバックアップであることを確認してください（ただし、これら2つは一般的なポイントです）
3. アップグレード中は、運用ボックスからトラフィックを遠ざけるようにしてください。
4. KVM、シリアルコンソール、ローカルアクセス、またはリモートハンドなど、すべてがうまくいかない場合の帯域外アクセス方法を用意してください。
5. 更新をより多くのサーバーに展開する前に、1つのサーバーでテストし、すべてが機能することを確認します
6. バージョン番号が複数のサーバーで同じであることを確認できる場合は、puppetを使用します。（強制的にアップグレードすることもできます）
7. テストサーバーで、構成ファイルのバージョンを新しい（更新プログラムがインストールされた）バージョンと比較し、深刻な事態を引き起こさないようにします。現在インストールされているものとは異なる新しいバージョンをインストールする前にdpkgに尋ねたのを思い出すようです。

避けるべきこと：

1. 1日の真ん中、または月曜日の朝の09:00、または金曜日の午後の5pmに更新を行います。（@ 3influenceに感謝！）
2. 大規模なデータベースサーバーでMySQLをアップグレードする（再起動に時間がかかる可能性があります）
3. すべてのサーバーを一度に実行する（特にカーネル）
4. / etc / networksを変更する可能性のあることをすべて行う（接続が失われる可能性があるため）
5. すべてをチェックするためにそこにいなくても上記を実行できる自動更新は問題ありません。

作成する価値があるもう1つのポイント：Windowsに慣れている場合、Linux更新のほとんどがダウンタイムや再起動を必要としないことに驚くでしょう。カーネルの更新など、一部の機能は実行します。ただし、通常、再起動またはダウンタイムが必要な更新にはそのようなフラグが付けられ、別のスケジュールで処理できます。

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

すべての更新プログラムを自動的にインストールするだけです。「ベストプラクティス」ではありませんが、比較的小規模なショップであり、すべてのサービスにテスト/開発/運用環境はありません。LTSの更新は、一般にかなりテストされており、とにかく低侵襲です。

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

私たちは、ubuntu LTSシステムの更新を次の方法で処理します。

1. ソフトウェアのすべてのクリティカルパスをチェックする一連の受け入れテストを実施します
2. 毎朝午前4時に無人でセキュリティアップグレードをインストールし、すぐに受け入れテストを実行します。何かが失敗した場合、エンジニアはページングされ、午前9時までに問題を修正したりロールバックしたりする十分な時間があります。これは、これまで5年で2回しか発生していません。LTSは十分にテストされ、安定しています。
3. ブルー/グリーン展開により、毎週デジタルインフラストラクチャ全体でインフラストラクチャ全体を自動的に再展開します。これにより、すべてのパッケージが最新バージョンに維持されます。新しい展開が受け入れテストに失敗した場合、エンジニアが問題をデバッグできるまで展開は保留されます。

次の論理的なステップは、インメモリセッション情報を排除することです。これにより、顧客に影響を与えることなく、インフラストラクチャを毎日、または1日に複数回簡単に再展開して、ステップ（2）を排除できます。

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

私が推奨することの1つは、パッケージのロールバックを処理することです。何かを壊すアップグレードの迅速な修正が必要になる場合があるため、その方法の提案についてはDebianでのトランザクションとロールバックを参照してください。