Должен ли я использовать версию пакета CentOS в (официальных) репозиториях или последние стабильные версии пакетов?

Это открытый вопрос, но я хочу провести конструктивное и полезное обсуждение этой темы.

Итак, проясним вопрос: на сервере под управлением CentOS 7 (или в любом другом дистрибутиве / версии Linux) лучше ли придерживаться версии пакета в репозитории Base / EPEL или лучше получить последнюю стабильную версию сформировать пакет сайта? В этом случае я более конкретно имею в виду такие пакеты, как nginx, MariaDB и PHP 7. Например, каковы преимущества и недостатки установки nginx 1.8.0 поверх EPEL версии 1.6.3? Есть ли какие-либо различия в производительности или риски безопасности в любом случае?

Все обсуждения и опыт приветствуются, пожалуйста, попробуйте привести ресурсы и факты.

Как правило, я очень стараюсь использовать системные пакеты по умолчанию.

Однако иногда это невозможно. Чтобы сделать обоснованный выбор, вы должны были ответить на следующие вопросы:

1. пакеты дистрибутива предоставляют необходимые вам функции? Если это так, вам даже не нужно искать другие пакеты; просто используйте пакеты, предоставляемые системными репозиториями.
2. Вам нужна официальная поддержка и / или соблюдение определенных политик? Если это так, вы не можете использовать неофициальный репозиторий . В этом случае вы, вероятно, используете неправильный дистрибутив для своего программного проекта.
3. Если ответ на предыдущий вопрос был «нет», вам пришлось искать более новую версию программного обеспечения. Существует ли общепризнанное хранилище с необходимым пакетом? Если так, используйте это.
4. если не существует конкретных, уважаемых репозиториев, вам придется использовать вышестоящее программное обеспечение. В этом случае старайтесь использовать упакованное программное обеспечение (например, RPM, DEB, ecc) вместо простого tar.gz (или чего-то подобного).

Ответы Мэтью Ифе и Шоданшока охватывают проблемы в целом, но я хочу ответить на ваши конкретные вопросы, изложив их в контексте, поскольку именно такими системами я управляю.

Моя текущая сборка для развертывания веб-приложений PHP / MySQL:

• CentOS 7.x
• nginx 1.8.x предоставлено nginx
• PHP 7 или PHP 5.6 (в зависимости от приложения), предоставляемые remi
• MariaDB 10.0.x предоставлено MariaDB

Сначала давайте рассмотрим, почему мы выбираем конкретный дистрибутив или набор пакетов. Либо мы ценим стабильность по сравнению с последними функциями, либо мы ценим последние функции по сравнению со стабильностью. Как правило, их нельзя использовать в одном и том же дистрибутиве, поскольку для стабилизации программного обеспечения требуется время на исправление ошибок, а добавление новых функций приводит к появлению ошибок, что приводит к нестабильности.

Как правило, я хочу, чтобы операционная система, в которой работает приложение, была максимально стабильной, но с достаточно современным набором функций. Таким образом, я выберу CentOS 7 вместо CentOS 6, который на данный момент довольно старый, и хотя он будет работать , у него не так много времени осталось в жизненном цикле поддержки, поэтому я не буду использовать его для нового проекта. ,

Однако затем я столкнулся с проблемой, что версия nginx, включенная в CentOS, была слишком старой и не имела некоторых необходимых функций и исправлений ошибок. Таким образом, я пошел искать альтернативные пакеты и обнаружил, что nginx.org распространяет свои собственные. Я переключился на них почти сразу и нашел их совершенно стабильными в течение длительного времени.

Тогда есть PHP. Из истории я знаю, что версия PHP, поставляемая с CentOS, будет единственной версией, которую он получит, и будет получать только обновления безопасности; нет новых функций или исправлений ошибок. Таким образом, когда он выйдет из-под поддержки, я в конечном итоге не смогу запускать современные веб-приложения PHP, если буду использовать эти пакеты. Таким образом, необходимо также заменить их.

Из многолетнего опыта я узнал, что лучше отслеживать выпуски исправлений с помощью PHP, а не просто замораживать их в один момент и принимать только исправления безопасности, поскольку веб-приложения, которые я запускаю, также будут обновляться и будут нуждаться в этих исправлениях. Поэтому после оценки множества различных пакетов PHP я остановился на пакетах remi. Remi оказался сотрудником Red Hat и также отвечает за пакеты PHP в RHEL / CentOS. Так что я знаю, что его пакеты будут высокого качества, и они были. Они являются заменой системных пакетов и работают отлично.

Наконец мы добираемся до MariaDB. Вы можете оставить здесь системные пакеты и не испытывать никаких побочных эффектов. Я решил переключиться на пакеты 10.0 MariaDB (и скоро перейду на 10.1), чтобы воспользоваться преимуществами TokuDB и некоторыми другими улучшениями производительности, недоступными в версии 5.5, поставляемой с CentOS, и для которой он никогда не получит серьезных обновлений.

В целом, вам нужна стабильность в вашей базовой системе, но веб-приложения меняются гораздо быстрее, чем, скажем, программное обеспечение для бизнеса, и ваш сервер должен будет не отставать. Таким образом, я выбрал целевые точки, в которых обновление пакетов получит явные преимущества с небольшими дополнительными административными затратами (работа).

Краткий ответ: всегда используйте то, что предоставлено системными репозиториями. Будьте очень осторожны, какие репозитории вы тоже устанавливаете. Некоторые просто плохие.

Вы не должны переписывать системные пакеты с более новыми версиями, Redhat спроектирован и спроектирован очень тщательно, и вы можете столкнуться со странными ошибками или проблемами, если вы это сделаете.

Некоторые вещи, которые следует учитывать и искать, которые могут вызвать проблемы, включают в себя.

1. Некоторые репозитории просто плохо обслуживаются. Они не обновляются с исправлениями безопасности для пакетов.
2. Люди, как правило, пишут плохие RPM, они не помечают файлы конфигурации как файлы конфигурации, которые перезаписывают вашу конфигурацию при каждом обновлении, что может вызвать проблемы. Я видел эту проблему раньше.
3. Они недостаточно декларируют свои зависимости должным образом. Я видел это и раньше, когда phpпакет был помещен в систему, но не обновил pearпакет, который привел к проблемам.
4. Установка нескольких репозиториев с одинаковыми именами пакетов может привести к непредвиденным проблемам с зависимостями в вашей системе.
5. Некоторые пакеты перезаписывают или перезаписывают файлы конфигурации системы, которые зависят от других пакетов или ожидают их существования. Это приводит к проблемам с другими пакетами, которые вы можете не ожидать.

Никогда не создавайте пакеты из исходного кода и устанавливайте их поверх пакетов, которые там есть. Это нарушает целостность вашего системного пакета, что может привести к странным проблемам ABI, таким как получение unresolved symbolили undefined referenceсообщения. Очень важно, чтобы система поддерживала надежный и точный индекс того, какое программное обеспечение было развернуто в данной системе, чтобы гарантировать, что все это работает должным образом, поэтому мы в первую очередь используем RPM.

Жизнеспособный (и благословенный Redhat) способ решить эту проблему - использовать коллекции программного обеспечения.

www.softwarecollections.org

Он устанавливает программное обеспечение и его «новые» зависимости в своем корне. Это может немного усложнить применение пакета в вашей среде, но защищает вашу систему от странных ошибок или проблем. Он также устанавливает пакеты в собственном пространстве имен, позволяя вам устанавливать несколько версий пакета параллельно.

На сайте даны инструкции по установке и активации этих пакетов, он содержит большинство того, что люди упускают из старых версий CentOS и Redhat (в частности, EL6). Некоторые вещи, которые я успешно использовал на этом сайте.

• MySQL 5.6 и MySQL 5.7, MariaDB.
• PHP 5.5 и PHP 5.6
• Apache 2.4

Обратите внимание, что ваша позиция по умолчанию в этом вопросе не должна соответствовать тому, что выдвигают репозитории Redhat. Вместо этого оцените, действительно ли вам нужна обновленная версия пакета, в частности, каковы ваши конкретные требования, какие проблемы он должен решить и какие риски он представляет.

Как правило, если вам постоянно требуется обновленное программное обеспечение и / или требуется несколько параллельных версий одних и тех же пакетов для работы, обычно это показатель того, что вы делаете что-то не так.