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

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

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

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

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

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

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

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

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

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

Экономия была значительной! Замена серверов HP-9000 PA-RISC стоимостью 100 тыс. Долл. На серверы Intel Compaq ProLiant стоимостью 40 тыс. Долл. США - это абсолютный выигрыш в стоимости и производительности.

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

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

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

Пример: я использовал аппаратное обеспечение Compaq / HP ProLiant, оснащенное платами расширения Digi Serial PCI-X и программным обеспечением 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-подобными системами, пока не сделал следующий карьерный шаг ...

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

Когда я начал изучать сетевые технологии с низкой задержкой и настройку ядра, я начал анализировать стандартные ядра RHEL и ядра RHEL MRG Realtime . Я заметил, сколько работы в релизах ... 200+ патчей к ванильному ядру 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 .

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

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

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

Сегодня я увидел объявление о работе для очень старшего инженера в DevOps Linux, которое гласило:

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

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

Так что же подходит для ВАШЕЙ среды? По-разному. Я был в фирмах, где системные инженеры принимают решения, а также в организациях, где разработчики - король. Я думаю, что лучшее соглашение - это когда разработчики и люди, поддерживающие системы, договариваются о платформе. Но помимо этого, подумайте о долгосрочной поддержке, удобстве использования, сообществе и о том, что соответствует вашему стеку приложений наиболее подходящим образом.

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