В сообществе существует множество мнений по поводу того, какие дистрибутивы Linux подходят для производственной серверной среды, а какие нет, однако большая часть этого мнения кажется религиозно обоснованной и редко представляется с подтверждающими доказательствами.
Предполагая, что мы пытались выбрать дистрибутив Linux для стандартизации (потому что мы заинтересованы в том, чтобы наши среды были как можно более однородными), какие критерии важны и как вы определяете, насколько разные дистрибутивы соответствуют этим критериям?
Я поделюсь своим опытом работы технологом в нескольких разных областях ...
(Внимание: это история о Red Hat и о том, как я профессионально с ней вырос)
Я начал профессионально работать с Linux в 2000-2002 годах. Это было во время широкого распространения Red Hat и Red Hat Professional Editions (6.x, 7.x, 8.0). Они были доступны для бесплатной загрузки, а также в коробках. Их легко можно было найти в компьютерных магазинах.
Для меня это помогло привлечь любителей и домашних пользователей к тем же продукт, который начал появляться на предприятии. Моя работа в то время заключалась в переводе клиентских серверных систем с коммерческих Unices (HP-UX, AIX и SCO) на платформу Red Hat.
Снижение затрат было существенным! Замена серверов HP9000 PA-RISC стоимостью более 100 тысяч долларов на серверы Compaq ProLiant Intel стоимостью 40 тысяч долларов была абсолютным выигрышем по стоимости и производительности.
Итак, почему Red Hat?
Red Hat первой вышла на этот рынок, получив критически важную поддержку бизнеса, поставщиков и оборудования. Сделка была заключена в том, что крупные поставщики приложений используют Red Hat в качестве целевой платформы. Пользователи-любители, такие как я, смогли с легкостью перенести навыки, отточенные дома, в нашу рабочую среду. Сообщество росло. Slashdot, Свежее мясо и Стеки LAMP правил! Это было хорошее время для Linux.
К этому моменту я отвечал за разработку и оценку дистрибутивов Linux как платформы для проприетарного программного решения ERP. Я придерживался Red Hat. Время от времени я пробовал другой дистрибутив (Мандрагора, 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 в реальном времени ядра. Я заметил, сколько работы в релизах ... 200+ патчей к ядру vanilla kernel.org. Прочтите комментарии и сделайте заметки. У вас могут быть такие мелочи, как sysctl выставлены параметры или применены более разумные значения по умолчанию. Red Hat платит людям за исправление, тестирование и исправление этих проблем. Я не видел такого же обязательства со стороны других дистрибутивов Linux ... Добавьте тот факт, что корпоративная платформа гарантированно имеет реальную безопасность, исправление ошибок и поддержку обратного порта для лет.
В конце концов я перешел в другую финансовую фирму, которая почти полностью работала на 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.
Итак, есть конфликт ... Эти пользователи не понимают, почему они ограничены в использовании версий приложений или библиотек. Администраторы старой закалки все еще приспосабливаются к новая парадигма. Аргументы, которые кажется быть укорененными в религии - это просто функция того, как люди развили свои соответствующие навыки.
Сегодня я увидел объявление о вакансии на должность очень старшего инженера DevOps Linux, в котором говорилось:
Должен быть экспертом в области дистрибутивов Linux на основе Debian (разрешены Ubuntu и его варианты. Red Hat сносный, но не предпочтительно)
Так что, полагаю, это работает в обоих направлениях ... Я отказался от вакансий, потому что 800 серверов CentOS, которыми я управлял, планировалось преобразовать в Ubuntu. Конечно, Linux - это Linux ... но я не чувствовал, что буду настолько эффективен, насколько мог ... Я возился с установками Debian и хотел, чтобы использовался дистрибутив на основе RPM. У меня были горячие споры о достоинствах различных платформ (обычно Gentoo помещается в конец списка).
Итак, что правильно для ВАШЕЙ среды? Это зависит. Я был в компаниях, где решения принимают системные инженеры, а также в организациях, где король разработчиков. Я думаю, что лучший способ - это когда разработчики и люди, поддерживающие системы, согласовывают платформу. Но помимо этого подумайте о долгосрочной поддержке, удобстве использования, сообществе и о том, что лучше всего подходит для вашего стека приложений.
Талантливый разработчик должен уметь работать в среде, подобной RHEL или Debian. Платформы разработки должны отражать производственную среду. Вы идете оттуда ...
В настоящее время я работаю в среде, в которой Linux используется более десяти лет. Все в офисе используют разные дистрибутивы на своих рабочих столах и на серверах. Таким образом, выбор распределения, как правило, вращается вокруг ряда вещей без определенного порядка:
Это всего лишь несколько вещей, которые приходят мне в голову относительно причин, по которым была выбрана каждая система. Я не вижу в этом решении какого-либо ориентира или предпочтения одного дистрибутива другому. Разнообразие и выбор могут быть огромными и предложить вам действительно хорошие возможности для быстрого запуска проекта, но это также петля, которая может вас повесить. Убедитесь, что вы заранее думаете о том, что вам нужно. Спланируйте, каковы потребности системы, а также когда система будет обновлена или выведена из эксплуатации. Не думайте, что вы всегда будете поддерживать его.