ソフトウェアの自動更新とアップグレードに欠点はありますか？ [閉鎖]

本番システムでは、サービス/システムの重要性と高可用性の設定方法に応じて、次のことができます。予約/無人自動アップグレードを望まない場合があります。

長年にわたって自動化されたアップグレードを実行している人のために、サービスが何度も中断されるのを見ました。

• 新しくアップグレードされたマイナーバージョンの構文がわずかに異なるため、Squidは破棄されます。
• ダイナミックルーティングデーモンがマイナーバージョンでsysVのサポートを停止したため、DNSサービスの実行が中断されました。
• テストされたパッケージのディスク容量が不足しているため、Apacheサービスがダウンしました。
• 基本ファイルを再生成するため、Apacheは再起動されません...
• Apache は再起動されますが、アップデートはサイトのホームページを Apache メインページに置き換えます。
• マイナーバージョンのバグにより、DHCP サービスが失敗します。
• 誰かがパッケージの公式バイナリの代わりにコンパイルされたバイナリを配置したため、Netflowサービスは数日間ダウンしました。
• rsyslogがいくつかの構文を変更し、誰かが自分が何をしているのかわからずにバックポートストアを設定したため、rsyslogは終了します。
• FreeRadiusサービスは、テストされていないバージョンがローカルストレージにプッシュされ、自動アップグレードでRadiusを設定したことがわかっている人がいない場合は終了します。

さらに、盲目的にメジャーバージョンのアップグレードを実行すると、ソフトウェアとバージョン間のソフトウェア/アプリケーションの非互換の問題が発生する可能性があります。

@pankiも正しく指摘したように、一般的にソフトウェアを盲目的にアップグレードすることはできません。中断が発生する可能性があります。

デスクトップ/ホームサーバーの設定では自動アップグレードは興味深いかもしれませんが、本番システムにもたらす不安定性の妥協のためにそれを使用することは正当化されません。私の考えでは、これが動作している間は多くの問題を解決してくれるようですが、失敗すると予測できない方法で実際に失敗することになることの一つだと思います。

アップグレードライフサイクルを軽減/管理する方法には、稼働時間要件/インフラストラクチャの規模に応じて使用できるいくつかの戦略があります。

• 手動で行います。
• プロセスを監督する人と半自動で行われます。
• すべてのサービスを監視し、プロセスを監督し、すべてのアップグレードログを変更した後、サービスの監視に注意を払う人員
• 盲目的に進むのではなく、どのアップグレードが重要で、どのアップグレードが重要ではないかを計画します。
• 冗長システムでさまざまなバージョンのLinuxを使用する（より多くの作業と発生する可能性があるより多くの問題...）
• サービス冗長性/テストベッドを使用し、段階的なアップグレードを実行します。
• たとえば、yumでサポートされている特定の時点の「ブックマーク」バージョンを使用します。
• Satellite/Katello/Spacewalk と同様に、制御/テスト/承認されたリリースをデプロイするには、ローカルストレージ/エージェントを使用するか、適切にDebian の場合;
• これらのポリシーをAnsibleなどのDevOpsツールと統合します。

また、本番システムで自分が所有していないシステムを管理するときは、更新する前に所有者に許可を求める官僚的な問題にも対処する必要があります。彼らのシステムそのため、自動更新サービスをアクティブに保つことはできません。

TDLR実稼働環境でオペレーティング・システムのアップグレードライフサイクルを管理することは決して簡単ではありません。オペレーティングシステムのアップグレードライフサイクルには、運用性、システム、バージョン管理、セキュリティ、人材、アプリケーションなど、さまざまな視点があります。

質問の特定の部分に戻って、自動化されたプログラムを保持することは、おそらく高い稼働時間/高い信頼性が必要な場合に最善の解決策ではありません。

PS。関連、Debian用

適切にこれは Debian リポジトリ管理の万能武器です。これにより、リモートリポジトリのミラーリング、ローカルパッケージリポジトリの管理、スナップショットの取得、新しいバージョンのパッケージと依存関係の抽出、Debianリポジトリへの公開などを実行できます。