Вопрос: Как ИТ-отдел должен выбрать стандартный дистрибутив Linux?


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

Предполагая, что мы пытались выбрать дистрибутив Linux для стандартизации (поскольку мы заинтересованы в том, чтобы наша среда была как можно более однородной), какие критерии важны и как вы определяете, насколько хорошо разные дистрибутивы соответствуют этим критериям?


70
2017-12-27 21:05


Источник


Я хотел бы, чтобы другие объяснили как они собираются выбрать один дистрибутив Linux для своей организации мне. Я в этой ситуации, и «общее знание» подскажет мне выбрать RHEL или CentOS, но, кроме коммерческой поддержки, я не слышал много фактических требований относительно того, почему один из них лучше другого. - wfaulk
serverfault.com/questions/53954/centos-vs-ubuntu - Iain


Ответы:


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

  1. история - Очевидно, что такие системы, как RedHat и Debian, уже давно существуют. Таким образом, для них можно использовать поговорку «если она не сломалась, не исправить». Модернизация становится проще, если программное обеспечение хорошо поддерживается в дистрибутиве.
  2. фамильярность - Подобно истории, однако у всех нас есть наши фавориты. Я порезал себе зубы на Debian и перешел на Ubuntu (жесткое решение в то время, потому что я склоняюсь к сообществу). И наоборот, больно вспоминать, как делать что-то на десятках разных дистрибутивов (не говоря уже о скрестах).
  3. Поддержка - Я переехал в Ubuntu главным образом потому, что я оценил, что они делают, предлагая платную поддержку. Это был пункт продажи, если клиент когда-либо беспокоился о долгосрочной перспективе системы. Подобно подходу RedHat (но в то время происходил аплодисментами RPM). По этой причине у нас есть несколько серверов RedHat.
  4. зависимости - Некоторые программные средства проще использовать на некоторых дистрибутивах просто потому, что зависимые пакеты более легко доступны или могут быть созданы. В качестве примера этого будет oVirt на RedHat. На некоторых дистрибутивах нет пакетов для некоторых программ. И вы можете скомпилировать его, но почему бы вам, если бы пакет был прямо на другом дистрибутиве?
  5. Зернистость - Distros, как Gentoo, предлагает более тонкий контроль над версиями и степенью детализации программного обеспечения. Другие дистрибутивы имеют «закрепление» в различных формах, но это все еще не так управляемо или надежно.
  6. переплет - Хотя на большинстве дистрибутивов можно компилировать исходный код, некоторые дистрибутивы лучше, чем другие. Это может сказаться, скажем, в том случае, если ваш проект исправляет существующие библиотеки для расширенной функциональности.
  7. Миловидность - Некоторые дистрибутивы просто выглядят лучше. Каждый выродка знает, что это просто пух (и вы могли бы, вероятно, уйти с этим в качестве веб-приложения в эти дни), но некоторые клиенты поражены этим материалом, и все мы это знаем.
  8. стабильность - Некоторые дистрибутивы «стабильные» версии программного обеспечения в отличие от «тестирования», «экспериментального» и т. Д. Это может означать много, если вы знаете, что версия, на которой вы строите, в конечном итоге достигнет консенсуса в отношении стабильности. Вы можете развиваться на «экспериментальном» знании, что к тому моменту, когда ваш проект будет завершен, он достигнет «стабильной» и будет хорошо полагаться.
  9. Управление пакетами - Если вы каждый день разрабатываете что-то, и каждый раз выходить на 1000 машин, вы, вероятно, хотите что-то, что упростит сбор, обслуживание и отслеживание пакетов в этих системах.
  10. консистенция - Это больше аргумент для одна и та же Дистрибутив. Меньше ошибок (и меньше ошибок в безопасности), когда люди могут сосредоточиться на одном дистрибутиве, а не на нескольких.
  11. Предсказуемый график выпуска - Если вы хотите быть уверенным, что ваше программное обеспечение поддерживается, запланированные обновления предлагают определенный тип стабильности.
  12. Безопасность - В некоторых дистрибутивах есть активные группы безопасности, задача которых заключается в немедленном реагировании на реальные угрозы безопасности в любом утвержденном пакете.

Это всего лишь несколько вещей, которые выходят из моей головы о причинах выбора каждой системы. В этом решении я не вижу ни одного направляющего света или предпочтения одного дистрибутива над другим. Разнообразие и выбор могут быть отличными и предложить вам действительно хорошие возможности для быстрого запуска проекта, но это также петля, которая может повесить вас. Убедитесь, что вы думаете о том, что вам нужно. Планируйте, каковы потребности системы, а также когда система будет обновляться или удаляться. Не думайте, что вы всегда будете поддерживать его.


58
2017-12-28 02:45



И # 7 Prettiness действительно является более важным фактором для тех установок, которые используют Linux на рабочем столе для общего сообщества пользователей. - Magellan
Я бы также добавил Предсказуемый график выпуска, Вы не хотите запускать проект развертывания нескольких серверов только для того, чтобы узнать, что на следующей неделе выйдет новая версия дистрибутива. Или запустите те же старые дистрибутивы с древними пакетами в течение многих лет (cough * rhel5 / centos5), не знайте дату обновления. Например: Ubuntu выпускает новую версию каждые 6 месяцев и версию LTS каждые 2 года в апреле. Знание этого помогает лучше планировать ваши проекты и ресурсы. - Mxx


Я поделюсь своим опытом работы в качестве технолога в нескольких разных областях ...

(Предостережение: это история о Red Hat и о том, как я профессионально вырос с ней)

Я начал работать с Linux профессионально в 2000-2002 годах. Это было во время широкого внедрения Red Hat и Red Hat Professional Editions (6.x, 7.x, 8.0), Они были доступны для бесплатной загрузки, а также упакованные в коробки. Их можно было легко найти в компьютерных магазинах.

Для меня это помогло привлекать любителей и домашних пользователей одна и та же продукт, который начал появляться на предприятии. Моя работа в это время состояла в том, чтобы перенести серверы клиентов из коммерческих Unices (HP-UX, AIX и SCO) на платформу Red Hat.

Экономия затрат была существенной! Замена серверов PA-RISC на 100 тыс. Долл. + HP9000 с 40 тыс. Долл. Серверы Compaq ProLiant Intel были абсолютным выигрышем по стоимости и производительности.

Итак, почему Red Hat?

Red Hat была первой на этом рынке, получив критически важную поддержку для бизнеса, поставщиков и оборудования. Видя, что крупные поставщики приложений используют Red Hat в качестве целевой платформы, опечатали сделку. Такие пользователи, как я, могли легко передавать навыки, оттачиваемые дома, в нашу рабочую среду. Сообщество росло. Slashdot, Свежее мясо а также Стек LAMP вынес решение! Это было хорошее время для Linux.

К этому моменту я отвечал за разработку и оценку дистрибутивов Linux как платформы для собственного программного обеспечения ERP. Я застрял с Red Hat. Каждый раз так, я бы попробовал другой дистрибутив (мандрагора, SuSE, Debian, Gentoo), но будут обнаружены проблемы с упаковкой, аппаратной поддержкой (серверами или периферийными устройствами), (размер) сообщества или другого нарушителя сделки.

Пример: я использовал оборудование Compaq / HP ProLiant, оснащенное Платы PCI-X с последовательным расширением Digi а также Программное обеспечение факсимильной связи Esker VSIfax, У последних двух была только поддержка драйверов для операционных систем Red Hat. В некоторых случаях программное обеспечение поставлялось только в бинарной или RPM-форме, что не позволяло легко использовать другие варианты Linux.

Актуальность вопроса в мире информационных технологий
Никто не хочет быть тем, кто рекомендует проигрыш решение или проект, который в конечном итоге становится сиротой, поэтому вы придерживаетесь безопасного выбора. Я управлял технологическим стеком, который должен был работать надежно и иметь несколько уровней поддержки. Выбор другого дистрибутива на тот момент был бы справедливым. было. безответственно.


Медовый месяц Red Hat закончился для меня в 2003 году с прекращение профессиональных выпусков программного обеспечения. Red Hat Enterprise Linux был заменой и пришел с довольно немного багажа ... Стоимость (дорогая модель на основе подписки), доступность (сокращение базы пользователей и сообщества) и общая путаница в будущем ...

Я начал искать альтернативы, переоценивая Gentoo, Debian и SuSE. Я не мог получить правильную поддержку для всех компонентов нашего технологического стека. Я был вынужден придерживаться экосистемы Red Hat ... Из-за дикой смены стоимости, связанной с Red Hat Enterprise Linux, я закончил работу с сильно модифицированной Red Hat 8.0 для лет после его окончания срока службы. Только до тех пор, пока клоны RHEL не созрели (Whitebox Linux, и позже, CentOS), что я подготовил реальный отход от своего стандарта.

Основным преимуществом производных Red Hat было и является двоичная совместимость с платной версией RHEL. Также возможно выполнить преобразования на месте между RHEL и CentOS и наоборот. Я продолжал работать с RHEL-подобными системами, пока не сделал следующий карьерный ход ...


Позже я оказался в высокочастотная финансовая торговля где я отвечал за разработку R & D и Linux для критически важных автоматизированных торговых систем. Акцент в этом мире был скорость, путем тщательного тестирования и настройки. Опять же, аппаратная поддержка была ключевой. У меня было бы конкретное сетевые карты, специализированное оборудование, серверные аппаратные или прикладные библиотеки, которые были сертифицированы только для RHEL или RHEL-подобных систем. Даже в тех случаях, когда вещи могут быть скомпилированы для других вариантов Linux, возникает фактор сообщества. Когда я был в точке, где мне нужно было исследовать проблему, часто возникала проблема, которая могла быть прослежена в примечаниях или комментариях в отчетах Red Hat Bugzilla, или иногда я просто представляю патч или запрос для следующей версии ,

Когда я начал разбираться в сетях с низким уровнем латентности и настройке ядра, я начал анализировать ядерные ядра RHEL и RHEL MRG Realtime Ядра. Я заметил, как много работает, когда в выпусках ... 200+ патчей к ядру vanilla kernel.org. Прочитайте комментарии и сделайте заметки. У вас могут быть такие мелочи, как sysctl введенные параметры или более нормальные значения по умолчанию. Red Hat платит людям за исправление, тестирование и устранение этих проблем. Я не видел того же обязательства от других дистрибутивов Linux ... Добавьте тот факт, что на корпоративной платформе гарантируется реальная безопасность, исправление ошибок и поддержка backport для лет,


Поэтому я, в конце концов, переехал в другую финансовую компанию, которая была почти все-Gentoo на сервере а также рабочий стол ... Это было катастрофой для меня. Исходя из мира Red Hat и CentOS, я столкнулся с многочисленными проблемами стабильности и управления с установкой Gentoo. Контроль версий был самой большой проблемой, но проблемы, связанные с поддержкой сообщества и отсутствием реального тестирования, также были проблемой. Я начал внедрять RHEL в среду, потому что некоторые из наших сторонних программ потребовали ...

Но была проблема ... Мои разработчики привыкли к Gentoo и имеют относительно простые пути обновления для основных библиотек и версий приложений. Они не могли приспособиться к тому, чтобы иметь стандартные версии, на которые стандартизируется Red Hat Enterprise Linux. Процесс разработки и выпуска был связан с вопросами о почему GLIBC 2.7 не может быть перенесен на RHEL 5.x или почему определенная версия компилятора или библиотеки недоступна. Когда сказали, что обновления между основными версиями RHEL / CentOS по существу потребовались полные перестройки, они потеряли большую уверенность в решении.

В этот момент я понял, что Red Hat слишком медленно продвигается для разработчиков, которые хотят быть на краю / передовом. RHEL 6.x был очень необходимым и приветствуемым обновлением, но эта тема стала более очевидной, как только я начал беседовать с стартапами и фирмами, которые подписались на Принципы DevOps,


Cегодня...
Все большее число разработчиков и пользователей Linux поступают из не-Red Hat, не SuSE, а не для корпоративных Linux-сред.

  • Они используют Ubuntu или Debian ...
  • Им не приходилось иметь дело с оборудованием старой школы или большой поддержкой поставщиков.
  • Они пишут свои собственные приложения с нуля (самоподдерживающиеся).
  • Виртуализация и облачные вычисления абстрагируют аппаратный уровень, поэтому беспокоиться о фанковых драйверах RAID-контроллера, периферийных устройствах PCI-X или двоичных распределенных агентах управления даже не на радаре.
  • Эти пользователи хотят, чтобы инструменты и пользовательские ресурсы были ими привыкли.

Итак, есть конфликт ... Эти пользователи не понимают, почему они будут ограничены версиями приложений или библиотек. Администраторы старой школы все еще приспосабливаются к новая парадигма, Аргументы, которые казаться чтобы укорениться в религии, на самом деле являются просто функциями того, как люди развивают свои навыки набора навыков.

Сегодня я нашел рекламную рекламу для очень старшего инженера DevOps Linux, который гласил:

Должен быть опытным специалистом в дистрибутивах на основе Debian   (Ubuntu и варианты в порядке. Red Hat проходимый, но не предпочтительно)

Поэтому я думаю, что это работает в обоих направлениях ... Я ушел от возможностей работы, потому что 800 CentOS-серверов, которые я бы управлял, были преобразованы в Ubuntu. Конечно, Linux - это Linux ... но я не чувствовал, что буду так же эффективен, как я мог бы ... Я возился с установками Debian и хотел, чтобы дистрибутив на основе RPM использовался. У меня были горячие споры о достоинствах различных платформ (как правило, размещение Gentoo в нижней части списка).

Итак, что подходит для вашей среды? Это зависит. Я был на предприятиях, где системные инженеры принимают решения, а также организации, в которых разработчики являются королями. Я считаю, что наилучшая договоренность заключается в том, что разработчики и люди, поддерживающие системы, соглашаются на платформе. Но вне этого, подумайте о долгосрочной поддержке, удобстве использования, общности и том, что максимально подходит вашему стеке приложений.

Талантливый разработчик должен иметь возможность работать в среде, подобной RHEL или подобной Debian. И хорошо, платформы разработки должны отражать производственную среду. Иди оттуда ...


69
2017-12-28 03:21



@dyasny Было бы интересно услышать точку зрения Debian. - ewwhite
@ewwhite, вы, вероятно, хотите, чтобы администратор из sourceforge подал заявку. Знаете ли вы? - dyasny
@dyasny Нет комментариев :) - ewwhite
Этот сэр, это лучший пост, который я до сих пор встречал в serverfault. Я думаю, что я возьму физическую копию этого и поставлю на полке и в своем рабочем кубе. Вы повторили заявление системных инженеров на протяжении всей эры. Удивительный, потрясающий пост. - Soham Chakraborty
@SohamChakraborty О, я просто чувствую себя старым ... но сегодня, прочитав объявление о работе на этом сайте, мне стало ясно, что мои причины использовать Red Hat в тот же день по той же причине, что люди запрашивают Ubuntu и т. Д. На своих систем сегодня. Это то, что они знают на рабочем столе! - ewwhite