Операционная система для карманного хостинга
Так уж получилось, что за годы моей работы с unix-подобными ОС, раз за разом практика укрепляла меня в мнении о Debian GNU/Linux, как о лучшем Linux-дистрибутиве. Во всех смыслах лучшем: дома, на работе, на сервере, на лаптопе… и даже на личном планшете. Потому что, как бы не выли хейтеры, но в Debian много сделано ментейнерами для удобства пользователя. Которому нужно, чтобы работало, мозг не выносило, между релизами не ломалось и в поведении не менялось.
Но трудно также и отрицать тот факт, что "современные тенденции", а именно стремление Red Hat собрать свой собственный пул технологий, на базе которого можно осуществлять "вендорлок", попутно пропихнув эти технологии везде, где получится, касаются и Debian. Да, ментейнеры Debian проделали работу, разделив компоненты systemd на отдельные пакеты, установленный набор которых зависит от потребностей пользования, а не от мнения Red Hat’а на вопросы построения Linux-дистрибутива. Да, в Debian по-прежнему доступен SysV-init, а ещё доступны OpenRC и runit. Но использование последний двух — это опции для энтузиастов, для этого ничего в дистрибутиве не готово. А будущее SysV-init в Debian, будем откровенны, висит на волоске. Так как ощутимая часть пакетов уже идёт без init-скриптов, только с файлами под systemd. И трудно винить ментейнеров в этом, ибо всем не нравится делать двойную работу. Ведь основной системой инициализации таки стала systemd, а остатки SysV-init’а тащатся строго по инерции.
А чего это я так против systemd настроился, спрашивается? Тем более странно мой настрой мог бы выглядеть для человека, общавшегося со мной году так в 2016ом. Когда я был большим апологетом новой системы инициализации. Кстати, смотря на свой опыт могу отметить, что моё первоначальное позитивное отношение к systemd вызвано было именно низким уровнем мастерства shell-скриптинга. Трудно мне было написать init-файл. Не то, чтобы сейчас я прям в восторге от этого процесса… но он теперь мне даётся значительно проще. И, что самое главное, за годы, прошедшие с момента моего первого знакомства с systemd, у меня накопился целый ворох примеров, когда service-файл наполнялся shell-скриптотой, потому что главная "клиллер-фича" systemd, а именно формализованный конфиг, уменьшает возможную гибкость. И в Red Hat решили это просто — добавили интерфейс хуков для разных стадий запуска сервиса. То есть появилась возможность оформить команду, которая запускалась бы перед целевой команды. Хук ExecStartPre, например. И вот уже некоторые service файлы начинают содержать внутри себя куски shell-портянок. Притом в сильно более уродливом виде, чем оно было в классическом SysV-init (что обусловлено механизмом исполнения service хуков в systemd, когда приходится натурально извращаться, чтобы исполнить некоторое количество shell-команд в рамках одного интерпретатора). И нафига оно такое?
И да, ещё у меня была пара неприятных инцидентов, когда особенности работы systemd стали причиной перерывов в работе серверов. Самый нелепый случай был связан со встроенным в systemd механизмом монтирования, когда для отработки fstab’а при загрузке вызывается парсер, который преобразует записи в systemd unit’ы. А у меня взял, да и скончался один из дисков, притом тот, на котором был раздел с /boot. Казалось бы, что может быть проще? Особенно, когда на соседнем диске есть неразмеченное место, достаточно под новый (временный) /boot? Создание нового раздела, переустановка ядер и grub’а — действия не то, чтобы рутинные (сбой диска — не очень рутинная ситуация), но и совсем не сложные. Но всё сломалось во время монтирования нового раздела. Когда systemd раз за разом отмонтировала новый /boot сразу после его монтирования. Так как uuid нового смонтированного раздела отличался от того, который был прописан в сгенерированном при загрузке unit-файле. О как! Нет, конечно есть возможность заставить systemd заново сгененрировать unit-файлы. Но ведь для того, чтобы найти об этом информацию, необходимо знать, что искать. И проще оказалось перезагрузится и порешать вопросы с помощью live-cd. Яркий пример, когда слабо документированные особенности работы systemd сломали стандартное поведение системы, что вылилось в простой работы.
Нет, конечно systemd покрыт документацией в очень большой своей части. Возможно даже, что systemd обладает лучшей среди всех велосипедов Red Hat документацией. Но этот комбайн настолько усложнён, что мелочей, не покрытых документацией, а так же просто подводных камней, легко наберётся воз и маленькая тележка. Для сравнения если, выше упомянутый OpenRC покрыт документацией в значительно меньшей мере. Но он и проще. А ещё, самое главное, он не пытается контролировать и отменять действия пользователя!
Кстати, именно OpenRC я воспринимаю как оптимальную систему инициализации. По соотношению ряда факторов: достаточные возможности, без тенденций к разрастанию в комбайн, адекватные init-файлы, где простые задачи решаются просто, а решение сложных не выглядит как порнография. Ещё у меня есть большой опыт применения runit’а в качестве основного init’а. Но заниматься описанием всех сервисов не было желания, а дистрибутивы, где runit является базовой системой инициализации, — это всякая маргинальщина, типа Void Linux, который для применения в ответственных задачах, на мой взгляд, совсем не подходит.
Но есть же Gentoo Linux! Там OpenRC долгое время был основной системой инициализации. Нет, конечно systemd наступает и на этом фронте, но главной особенностью Gentoo, из-за которой, собственно, Gentoo и существует, является возможность выбора и настройки компонентов под себя. Выкинуть OpenRC, при таком позиционировании дистрибутива, не получится ещё очень долго. Да и мне Gentoo совсем не чужд: я применял этот дистрибутив переодически года так с 2009го. Кстати, вот эти строки я набираю на рабочей станции, которая работает под управлением Gentoo, между прочим. Но домашний компьютер это одно, а сервер, стоящий под рабочей нагрузкой, — это совсем другое.
А знаете, что самое смешное? Есть толпа народу, которая считает, что именно для серверов Gentoo подходит лучше всего. Мол для десктопа эта вся вариативность излишня, ведь очень она усложняет жизнь. Во-первых, когда речь заходит про конфигурацию графических приложений, особенно мультимедийных, то в USE-флагах (метод задачи желаемой конфигурации сборки компонентов системы в Gentoo) можно легко закопаться. Не мудрено, учитывая, сколько может быть даже у простого аудиоплеера возможностей и, как следствие, зависимостей от внешних библиотек. С серверными приложениями проще. А, во-вторых, время компиляции некоторых современных графических приложений, мягко говоря, может неприятно удивить. А вот тот же, условный, nginx компилируется буквально за секунды. Но нет. Это весьма ущербная логика.
От того, что Gentoo под условное серверное применение будет собираться не то, чтобы долго, а в совокупности USE-флагов, которые будут касаться набора софта для сервера, будет не так сложно разобраться, как в случае с Gentoo для десктопа, Gentoo не становится более подходящим дистрибутивом для сервера. Одна лишь мысль о том, что что-то будет собираться на рабочем сервере — это бред, достойный админа локалхоста. Но, в Gentoo есть механизм распространения через бинарные пакеты! И он, надо сказать, ужасен, если сравнивать с изначально пакетными дистрибутивами.
Механизм распространения через бинарные пакеты в Gentoo предназначен, в первую очередь, для компиляции Gentoo для рабочей группы, когда есть задача снарядить все компьютеры одинаковым ПО, притом нет смысла собирать это ПО отдельно на каждой машине. Данная методика была более чем актуальна для меня, когда я игрался с Gentoo Hardened дома. У меня эта сборка должна была крутится на роутере и СХД, которые у меня представлены в виде ARM SBC. То есть компилировать на них — идея весьма сомнительная. Так и пришлось познать особенности механизма пакетов в Gentoo. Что, в конце концов, вылилось в целый ворох костылей для portage, которые вносили исправления в концепцию организации работы, чтобы она стала чуть более адекватной для решения задачи распространения через пакеты. А, заодно, отладил цикл "сборка → тестирование → публикация".
И этот в целом положительный опыт стал определяющим при выборе дистрибутива для хостинга. Ведь anotherhosting.ru должен был работать на ОС, которая была бы максимальна подконтрольна мне, была бы построена на принципах минимализма (никакого systemd и вороха лишних зависимостей у ПО), не требовала бы работы вместо ментейнера (что отсекало возможность использования, например, Debian с OpenRC или runit). Ну и чтобы ОС была не из маргинальных, когда не понятно, что будет через год. Gentoo полностью подходила под эти требования, выбор на неё и пал. Благо методика превращения её в дистрибутив на бинарных пакетах, была отработана ранее. А развёртывание сборочной и тестовой инфраструктур на резервном оборудовании (да, у anotherhosting.ru был предусмотрен резерв оборудования) не заняло много времени.
Вот так, просто по причине того, что не хотелось потом, уже в процессе работы хостинга, менять ОС, я решил создать свою ОС. Нет, конечно, на самом деле получилась у меня адаптация Gentoo под пакетное распространение. Однако глубины проработки вопроса в этом деле было столько, что некоторые отечественные компании, имея подобную разработку, уже бы судорожно перебивали копирайты и готовились бы её продавать. Заявляя повсюду об уникальности ИХ операционной системы.