（公式の）リポジトリでCentOSパッケージバージョンを使用する必要がありますか、それともパッケージの最新の安定バージョンを使用する必要がありますか？
これは自由形式の質問ですが、このトピックについて建設的で役立つ議論をしたいと思います。
したがって、質問を明確にするために：CentOS 7（またはその他のLinuxディストリビューション/バージョン）を実行しているサーバーでは、Base/EPELリポジトリのパッケージバージョンを使用するのが最善ですか、それとも最新の安定バージョンを入手しても問題ありません。パッケージサイトを形成しますか？この場合、私はnginx、MariaDB、PHP 7などのパッケージをより具体的に参照しています。たとえば、EPELバージョン1.6.3にnginx1.8.0をインストールすることの長所と短所は何でしょうか。どちらの方法でも、パフォーマンスの違いやセキュリティリスクはありますか？
すべての議論と経験は大歓迎です、リソースと事実を引用してみてください。
一般的に、私はシステムのデフォルトパッケージを使用するように一生懸命努力しています。
ただし、これが不可能な場合もあります。知識に基づいた選択を行うには、次の質問に答える必要がありました。
- ディストリビューションのパッケージは、必要な機能を提供しますか？もしそうなら、あなたは必要さえありません他のパッケージを検索します。システムリポジトリが提供するパッケージを使用するだけです。
- 公式のサポートが必要ですか、および/または特定のポリシーに準拠する必要がありますか？もしそうなら、あなたは非公式のリポジトリを使用することはできません。この場合、ソフトウェアプロジェクトに間違ったディストリビューションを使用している可能性があります。
- 前の質問に対する答えが「いいえ」の場合は、より新しいソフトウェアバージョンを検索する必要がありました。必要なパッケージを含むよく認識されているリポジトリは存在しますか？もしそうなら、それを使用してください。
- 特定の信頼できるリポジトリが存在しない場合は、アップストリームソフトウェアを使用する必要がありました。この場合、プレーンなtar.gz（または同様のもの）ではなく、パッケージソフトウェアを使用するのに非常に苦労します（例：RPM、DEB、ecc）。
Matthew Ifeとshodanshokの回答は一般的な問題をカバーしていますが、私が管理しているのはまさにこの種のシステムであるため、問題をコンテキストに入れて特定の懸念に対処したいと思います。
PHP/MySQLWebアプリをデプロイするための現在のビルドは次のとおりです。
まず、特定のディストリビューションまたはパッケージセットを選択する理由を考えてみましょう。最新の機能よりも安定性を重視するか、安定性よりも最新の機能を重視します。ソフトウェアの安定化にはバグの修正に時間がかかり、新しい機能を追加するとバグが発生し、不安定になるため、通常、両方を同じディストリビューションに含めることはできません。
原則として、アプリケーションが実行されるオペレーティングシステムは可能な限り安定しているが、適度に最新の機能セットを備えている必要があります。したがって、現時点ではかなり古いCentOS6ではなくCentOS7を選択します。これは動作しますが、それほど多くはありません。サポートライフサイクルの残り時間なので、新しいプロジェクトには使用しません。
しかし、CentOSに含まれているnginxのバージョンが古すぎて古く、必要な機能やバグ修正がいくつかないという問題に遭遇しました。したがって、私は代替パッケージを探しに行きましたが、nginx.orgが独自のパッケージを配布していることがわかりました。私はほとんどすぐにそれらに切り替えました、そしてそれらが長期にわたって完全に安定しているのを見つけました。
次に、PHPがあります。歴史から、CentOSに同梱されているPHPのバージョンは、これまでに入手できる唯一のバージョンであり、セキュリティ更新のみを入手します。新機能やバグ修正はありません。したがって、一度リリースされるとアップストリームのサポートでは、これらのパッケージを使用すると、最終的に最新のPHP Webアプリケーションを実行できなくなります。したがって、これらも置き換える必要があります。
長い経験から、私が実行するWebアプリケーションも更新され、それらのバグ修正が必要になるため、リリースを一時的にフリーズしてセキュリティ修正のみを行うのではなく、PHPでバグ修正リリースを追跡することが最善であることがわかりました。そのため、PHPパッケージのさまざまなセットを評価した後、レミのパッケージに落ち着きました。レミはたまたまRed Hatの従業員であり、PHPパッケージの責任も負っています。 RHEL/CentOSで。したがって、彼のパッケージは高品質であり、高品質であることがわかっています。これらはシステムパッケージのドロップイン代替品であり、完全に機能します。
最後に、MariaDBにアクセスします。あなたはここにシステムパッケージを保持することを選択でき、悪影響を受けません。 CentOSに同梱されている5.5バージョンでは利用できないTokuDBやその他のパフォーマンス拡張機能を利用するために、MariaDBの10.0パッケージに切り替えることを選択しました（まもなく10.1に移行します）。
全体として、基本システムの安定性が必要ですが、Webアプリは、たとえば基幹業務ソフトウェアよりもはるかに急速に変化し、サーバーはそれに追いつく必要があります。したがって、私は、パッケージをアップグレードすることで、追加の管理オーバーヘッド（別名作業）がほとんどなくても明確なメリットが得られるターゲットポイントを選択しました。
簡単に言うと、システムリポジトリが提供するものを常に使用してください。 非常に注意してくださいどのリポジトリもインストールします。いくつかは単に悪いです。
システムパッケージを新しいバージョンで書き直すべきではありません。Redhatは非常に注意深く設計および調整されており、そうすると奇妙なバグや問題が発生する可能性があります。
問題を引き起こす可能性のある考慮事項と注意事項には、次のものがあります。
- 一部のリポジトリは、単にメンテナンスが不十分です。パッケージのセキュリティ修正で更新されません。
- 人々は悪いRPMを書く傾向があり、設定ファイルを設定ファイルとしてマークしません。これは、更新するたびに設定を上書きし、問題を引き起こす可能性があります。私は以前にこの問題を見たことがあります。
- それらは、依存関係を適切に宣言していません。これは以前にも見たことがあり、
phpパッケージがシステムに配置されましたが、問題が発生したpearパッケージは更新されませんでした。 - すべて同じパッケージ名を提供する複数のリポジトリをインストールすると、システムに予期しない依存関係の問題が発生する可能性があります。
- 一部のパッケージは、他のパッケージが依存している、または存在すると予想されるシステム構成ファイルを上書きまたは書き換えます。これは、予期しない他のパッケージの問題につながります。
Neverソースからパッケージをビルドし、そこにあるパッケージの上にインストールします。これにより、システムパッケージの整合性が損なわれ、unresolved symbolまたはundefined referenceメッセージの受信などの奇妙なABI問題が発生する可能性があります。すべてが適切に機能することを保証するために、システムが特定のシステムに展開されているソフトウェアに関して信頼できる正確なインデックスを維持することは非常に重要です。これが、最初にRPMを使用する理由です。
これを解決するための実行可能な（そしてRedhatに祝福された）方法は、ソフトウェアコレクションを使用することです。
それはそれ自身のルートにソフトウェアとその「新しい」依存関係をインストールします。これにより、環境にパッケージを適用するのが少し難しくなる可能性がありますが、システムを奇妙なエラーや問題から保護します。また、パッケージを独自の名前空間にインストールし、パッケージの複数のバージョンを並行してインストールできるようにします。
Webサイトには、これらのパッケージをインストールしてアクティブ化する方法が記載されており、古いバージョンのCentOSおよびRedhat（特にEL6）で見逃されているもののほとんどが含まれています。私がこのウェブサイトからうまく使ったいくつかのもの。
- MySQL5.6およびMySQL5.7、MariaDB。
- PHP5.5およびPHP 5.6
- Apache 2.4
この問題に関するデフォルトの位置は、Redhatリポジトリーがプッシュしているものから調整するべきではないことに注意してください。代わりに、パッケージの更新バージョンが本当に必要かどうか、特に特定の要件、修正する必要のある問題、およびパッケージがもたらすリスクについて評価します。
原則として、常に更新されたソフトウェアが必要な場合や、同じパッケージの複数の並列バージョンが必要な場合は、通常、何か問題が発生していることを示しています。