（公式の）リポジトリでCentOSパッケージバージョンを使用する必要がありますか、それともパッケージの最新の安定バージョンを使用する必要がありますか？

これは自由回答形式の質問ですが、このトピックについて建設的で役立つ議論をしたいと思います。

したがって、質問を明確にするために：CentOS 7（またはその他のLinuxディストリビューション/バージョン）を実行しているサーバー上で、Base / EPELリポジトリのパッケージバージョンをそのまま使用するのが最善ですか、それとも最新の安定バージョンを入手しても問題ありませんか。パッケージサイトを形成しますか？この場合、私はnginx、MariaDB、PHP 7などのパッケージをより具体的に参照しています。たとえば、EPELバージョン1.6.3の上にnginx 1.8.0をインストールすることの長所と短所は何ですか？パフォーマンスの違いやセキュリティ上のリスクはありますか？

議論や経験は大歓迎です。資料や事実を引用してみてください。

一般に、私はシステムのデフォルトパッケージを使用するために一生懸命努力しています。

ただし、これが不可能な場合もあります。知識豊富な選択をするには、次の質問に答える必要がありました。

1. ディストリビューションのパッケージは必要な機能を提供していますか？もしそうなら、他のパッケージを探す必要すらありません。システムリポジトリによって提供されるパッケージを使用するだけです。
2. 正式なサポートが必要ですか、特定のポリシーに準拠する必要がありましたか？その場合、非公式リポジトリを使用することはできません。この場合、ソフトウェアプロジェクトに間違ったディストリビューションを使用している可能性があります。
3. 前の質問に対する答えが「いいえ」の場合、より新しいソフトウェアバージョンを検索する必要がありました。必要なパッケージを備えた、よく知られているリポジトリは存在しますか？その場合は、それを使用してください。
4. 特定の信頼できるリポジトリが存在しない場合は、上流のソフトウェアを使用する必要がありました。この場合、プレーンなtar.gz（または同様のもの）ではなく、パッケージ化されたソフトウェア（例：RPM、DEB、ecc）を使用するように非常に頑張ってください。

Matthew Ifeとshodanshokの回答は一般的に問題をカバーしていますが、私が管理しているのはまさにこれらの種類のシステムであるため、問題を具体的に説明することで、特定の懸念に対処したいと思います。

PHP / MySQL Webアプリをデプロイするための現在のビルドは次のとおりです。

• CentOS 7.x
• nginxが提供する nginx 1.8.x
• remiが提供する PHP 7またはPHP 5.6（アプリケーションによって異なる）
• MariaDBが提供する MariaDB 10.0.x

まず、特定のディストリビューションまたはパッケージセットを選択する理由を考えてみましょう。最新の機能よりも安定性を重視するか、安定性よりも最新の機能を重視するかのどちらかです。ソフトウェアを安定させるにはバグを修正する時間が必要であり、新しい機能を追加するとバグが発生して不安定になるため、通常は両方を同じディストリビューションに含めることはできません。

原則として、アプリケーションが実行されるオペレーティングシステムはできるだけ安定している必要がありますが、合理的に最新の機能セットを備えています。したがって、私は、この時点でかなり古いですCentOSの6、上のCentOS 7]を選択します、そして、それはなりながら仕事私は新しいプロジェクトのためにそれを使用しませんので、それは、そのサポートライフサイクルに残って多くの時間として持っていません。

しかし、その後、CentOSに含まれているnginxのバージョンが古すぎて、必要な機能やバグ修正が含まれていないという問題に遭遇しました。したがって、代替パッケージを探しに行ったところ、nginx.orgが独自のパッケージを配布していることがわかりました。私はほとんどすぐにそれらに切り替えました、そして彼らは長期にわたって完全に安定していることがわかりました。

次に、PHPがあります。CentOSに同梱されているPHPのバージョンは、これまでに入手した唯一のバージョンであり、セキュリティアップデートのみを取得することを歴史から知っています。新機能やバグ修正はありません。したがって、アップストリームのサポートが終了すると、これらのパッケージを使用すると、最終的に最新のPHP Webアプリケーションを実行できなくなります。したがって、これらも同様に置き換える必要があります。

私が実行するWebアプリケーションも更新され、それらのバグ修正が必要になるため、長い経験から、PHPでバグ修正リリースを追跡するのが最善であり、ある時点のリリースでフリーズしてセキュリティ修正のみを取るのが最善であることを学びました。それで、PHPパッケージの多くの異なるセットを評価した後、私はレミのパッケージに落ち着きました。レミはたまたまRed Hatの従業員であり、RHEL / CentOSのPHPパッケージも担当しています。だから私は彼のパッケージが高品質になることを知っています。これらはシステムパッケージのドロップイン代替品であり、完全に機能します。

最後に、MariaDBに到達します。ここでシステムパッケージを保持することを選択でき、悪影響はありません。私は、MariaDBの10.0パッケージに切り替えて（すぐに10.1に移動します）、CentOSに同梱されている5.5バージョンでは利用できないTokuDBとその他のいくつかのパフォーマンス強化を利用することを選択しました。

全体として、ベースシステムの安定性が必要ですが、Webアプリは、たとえば基幹業務ソフトウェアよりもはるかに急速に変化するため、サーバーは維持する必要があります。したがって、パッケージをアップグレードすることで追加の管理オーバーヘッド（作業）がほとんどなく、明確なメリットが得られるターゲットポイントを選択しました。

短い答えは、常にシステムリポジトリによって提供されるものを使用することです。インストールするリポジトリも非常に注意してください。いくつかはただひどく悪いです。

システムパッケージを新しいバージョンで上書きしないでください。Redhatは非常に慎重に設計およびオーケストレーションされており、変更すると奇妙なバグや問題が発生する可能性があります。

問題の原因となる可能性がある考慮事項と注意事項がいくつかあります。

1. いくつかのリポジトリは単にメンテナンスが不十分です。パッケージのセキュリティ修正で更新されません。
2. 人々は悪いRPMを書く傾向があり、設定ファイルを設定ファイルとしてマークしないため、更新するたびに設定が上書きされ、問題が発生する可能性があります。以前にこの問題を見たことがあります。
3. それらは十分に依存関係を適切に宣言していません。これも以前に見たことがありphpます。パッケージがシステムに配置されましたが、パッケージが更新pearされず、問題が発生しました。
4. すべて同じパッケージ名を提供する複数のリポジトリをインストールすると、システムで予期しない依存関係の問題が発生する可能性があります。
5. 一部のパッケージは、他のパッケージが依存している、または存在すると予期しているシステム構成ファイルを上書きまたは書き換えます。これにより、予期しない他のパッケージで問題が発生します。

ソースからパッケージをビルドして、そこにあるパッケージの上にインストールしないでください。これにより、システムパッケージの整合性が損なわれ、受信unresolved symbolやundefined referenceメッセージなどの奇妙なABI問題が発生する可能性があります。所定のシステムにどのソフトウェアが展開されているかについて、システムが信頼性のある正確なインデックスを維持し、すべてが適切に連携することを確認することが非常に重要です。これが、最初にRPMを使用する理由です。

これを解決するための実行可能な（そしてRedhatに恵まれた）方法は、ソフトウェアコレクションを使用することです。

www.softwarecollections.org

インストールされるのはソフトウェアであり、独自のルートに「新しい」依存関係があります。これにより、パッケージを環境に適用するのが少し難しくなりますが、システムを奇妙なエラーや問題から保護します。また、独自の名前空間にパッケージをインストールするため、パッケージの複数のバージョンを並行してインストールできます。

Webサイトでは、これらのパッケージをインストールしてアクティブ化する方法について説明しています。CentOSとRedhatの古いバージョン（特にEL6）で見逃しているものがほとんど含まれています。私がこのウェブサイトからうまく使ったいくつかのこと。

• MySQL 5.6およびMySQL 5.7、MariaDB。
• PHP 5.5およびPHP 5.6
• Apache 2.4

この問題に関するデフォルトの位置は、Redhatリポジトリーが押しているものから調整するべきではないことに注意してください。代わりに、パッケージの更新バージョンが本当に必要かどうか、特に特定の要件、パッケージが修正する予定の問題、パッケージがもたらすリスクについて評価してください。

一般的なルールとして、更新されたソフトウェアが常に必要である場合や、同じパッケージの複数の並列バージョンが機能するために必要な場合は、通常、何か問題があることを示しています。