Хабрахабр

Зачем забивать гвозди микроскопом, если есть Alpine Linux?

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

Так я и познакомился с Alpine Linux.

Неожиданное окно

Этот дистрибутив может вам понравиться по следующим причинам:

  • Если вы любите минимализм и инструменты, ориентированные на выполнение поставленной задачи без лишних свистелок и украшений;
  • Если вы заметили, что имеющиеся «мэйнстримные» дистрибутивы немного (?) раздуты и избыточны;
  • Если вы захотели решить имеющуюся задачу простым способом.

При их использовании, периодически, на границе восприятия, возникает колкая мысль – «а может быть можно проще?». Под «мэйнстримом» я подразумеваю тройку CentOS — Debian — Ubuntu (конечно же, ими мир не заканчивается), да простят меня все верующие в эти замечательные дистрибутивы.

$ holywar mode disable
Неужели для решения вашей небольшой задачи требуется все это:

  • Система инициализации (уже не совсем), которая может произвести впечатление системы управления шаттлом? Замечательная systemd.

    Ненене!

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

  • Подсистема журналирования / аудита, построенная на связке вроде journald → rsyslogd + auditd?

    Несомненно, это здорово!

    Можно догадываться, почему это сделано именно так, но действительно ли для моей простой задачи требуется такая цепочка?

  • Дублирование функциональности периодического выполнения задач как в systemd, так и в crond?

    Ох уж этот Cron!

    Возможно, его синтаксис может быть не совсем очевиден, но так ли очевидны таймеры в s-d? Неужели мне не хватает его классического механизма?

  • Сосуществование нескольких подсистем управления сетью в разных сочетаниях: классический networking / networkd / NetworkManager?

    Управлять сетью надо много!

    Хотя нет, давайте добавим сюда еще и netplan, «решающий» проблему конфигурации для перечисленных подсистем. Такое сочетание, да на серверной системе, да с несколькими интерфейсами управления на все вкусы. Вам свой сервис хочется завести, или часто менять орбиту за счет переконфигурирования сетевых интерфейсов?

  • Сервисы вида tuned и firewalld?

    Как же без них?

    В принципе, неплохо рассматривать firewalld как попытку сбежать от синтаксиса iptables, но в результате вы вместо одного синтаксиса будете разбираться в другом и недоумевать от размера команд firewall-cmd. Так ли они нужны для вашей задачи? Нет, я люблю python, но не в этом случае. И вам действительно в базовой системе нужен интерпретатор python и его процессы?

  • Вы точно будете его использовать? Локальный почтовый сервис.

Раз уж мы вспомнили про минимализм, можно очень грубо сравнить наши дистрибутивы-лидеры в их минимальном варианте установки:

  • Лидером избыточности по дисковому пространству и числу пакетов оказывается Ubuntu 18.04 (2,8 ГБ дискового пространства, 342 пакета, 31 активный сервис systemd, 15 процессов при входе). Семейство systemd тут представлено в максимальном объеме — systemd, networkd, timesyncd, resolved, logind, есть dbus.
  • CentOS 7.5.1804 проигрывает по диску и числу пакетов, но лидер по вероятно-избыточным сервисам (1.1 ГБ дискового пространства, 299 пакетов, 34 активных сервиса systemd, 19 процессов при входе, среди которых — NetworkManager, firewalld, tuned, postfix, polkitd, auditd, journald + rsyslogd, dbus).
  • Debian 9.4.0 пытались сильно не надувать: 940 МБ, 334 пакета, 25 активных сервисов systemd, 14 процессов при входе. Само собой, тут тоже есть systemd (а также journald, timesyncd и сопутствующий dbus), но без особого фанатизма в части управления сетью.

holywar: cannot change mode to ‘disable’: Permission denied

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

  • Как ни странно, загрузчик, который дотянет нас до ядра;
  • Само ядро ОС (в рассматриваемом случае — linux);
  • Система инициализации, которую ядро запустит по готовности. Желательно, по простоте недалеко ушедшая от топора;
  • Минимальный набор процессов, который запустит система инициализации. Ну например:
    • Окончательная инициализация устройств и определение дополнительных параметров ядра;
    • Обеспечение журналирования (можно с текстовыми журналами? Ну пожалуйста);
    • Конфигурация сети (хорошо бы, с меньшим числом управляющих прослоек);
    • Синхронизация времени (ntpd / chronyd);
    • Несколько локальных консолей;
    • Опционально — периодическое выполнение задач (сrond);
    • Опционально — удаленный доступ к системе (sshd);
    • Хорошо бы еще сохранять и восстанавливать конфигурацию межсетевого экрана.

Меньше исполняемого кода и конфигурации – меньше багов, меньше багов – меньше багов. И на этом почти все, остальное — дело менеджера пакетов. Идея выглядит неплохо, теперь посмотрим, насколько близок к ней дистрибутив Alpine Linux. А система все также запущена и доступна по сети.

Отчаянным минимализмом!
Ну и, конечно, отсутствием необходимости сертификации «Linux Systemd Certified Voldemort». Чем может очаровать Alpine, особенно после CentOS?

Что сделали авторы:

  • Понизили число используемых базовых компонентов;
  • Выбрали модули поменьше и попрозрачнее;
  • Упростили процесс конфигурирования системы.

А именно:

  • Чрезвычайно лаконичный процесс установки с использованием консольной утилиты setup-alpine;
  • В качестве загрузчика взят extlinux из состава проекта syslinux;
  • Небольшой инструмент сборки mkinitfs для создания временной файловой системы, используемой при загрузке;
  • Система инициализации openrc с определением зависимостей между сервисами, уровнями запуска и щепоткой скриптования;
  • Замена стандартной библиотеки GNU libc на более легковесную musl libc;
  • Вместо пакета GNU coreutils большинство стандартных системных утилит в несколько урезанном исполнении входят в состав пакета busybox, который может быть Вам знаком по встраиваемым решениям;
  • По умолчанию используется командный интерпретатор ash в составе busybox. Само собой, никто не мешает при необходимости поставить bash, ну и systemd;
  • Собственный пакетный менеджер apk и собственная инфраструктура распространения пакетов.

Кроме того, авторы реализовали ряд мер, ориентированных на повышение уровня защищенности базовой системы:

  • Применили патчи ядра grsecurity/PaX (про их эффективность мнения расходятся, но все же);
  • Собрали пакеты с использованием режимов, снижающих вероятность эксплуатации ряда возможных уязвимостей.

В запущенной системе установлен 41 пакет и выполняется 13 пользовательских процессов, можно стучаться по ssh. В итоге мы получаем систему, снабженную рядом дополнительных механизмов защиты, позволяющую решить имеющуюся задачу и занимающую около 130 МБ.

Осталось добавить то, что нужно вам (да и iptables с возможностью восстановления конфигурации при старте поставьте). И больше ничего.

Увидеть логику работы компонентов субъективно проще, чем пытаться охватить сходу CentOS или Ubuntu: Обратите внимание – Alpine может пригодиться как учебная площадка при ознакомлении с ОС Linux!

  • Загрузчик нашей установленной системы прост, его конфигурация влезает в 12 строк:

Конфигурация загрузчика

  • Да и в /boot не слишком многолюдно:

вывод ls /boot

  • А вот и запущенный загрузчик без модных обоев:

Запущенный bootloader

  • Ядро загружается, подхватывает initramfs, отрабатывает собственные шаги инициализации и вызывает команду init (которая, на самом деле, тоже идет в составе busybox). Init использует файл /etc/inittab:

Содержимое /etc/inittab

  • И тут в явном виде прописано, что нужно запустить для инициализации системы:
    • Запустить 6 процессов getty, ожидающих на 6 виртуальных консолях локального входа пользователя.
    • Запустить систему инициализации openrc для поочередного достижения требуемых уровней инициализации (openrc использует не классические уровни инициализации 0-6, а собственные уровни/группы sysinit — boot — default).

Далее состояние системы зависит от конфигурации openrc, а именно:

  • Переменных, заданных в файлах каталога /etc/conf.d;
  • Скриптов запуска, находящихся в каталоге /etc/init.d;
  • Привязки скриптов запуска к «группам инициализации»:

Демоны и их привязка к уровням

Осталось прочитать скрипты запуска и обработать их с учетом уровней запуска и зависимостей.
Можем на примере syslog (/etc/init.d/syslog) посмотреть, как выглядит скрипт запуска openrc.

Как видите, это не всегда эти ваши нелюбимые "портянки":

Пример конфигурационного файла openrc

В нашем случае, в файле определена переменная SYSLOGD_OPTS="-Z".
Обратите внимание — в скрипте декларативно определены зависимости данного сервиса. Переменные, используемые при выполнении скрипта, определяются в соответствующем файле /etc/conf.d/syslog.

Openrc честно перебирает в заданном порядке скрипты запуска, достигает уровня «default» — и вот она, рабочая система!

Как ни странно — набор задач и демонов, перечисленных ниже. Что же именно скрывается под скриптами запуска openrc?

  • Сначала, на уровне sysinit:

    • dmesg — выставляется уровень журналирования для сообщений от ядра;
    • devfs — монтируется и настраивается /dev;
    • mdev — запускается менеджер устройств;
    • hwdrivers — загружаются модули устройств на основе информации из /sys и /dev;

  • Следующим идет уровень boot:

    • modules — загружаются модули ядра, перечень которых определен в /etc/modules;
    • hwclock — настраиваются аппаратные часы реального времени;
    • sysctl — задаются параметры ядра, определенные нами в /etc/sysctl.conf;
    • swap — подключается swap-раздел;
    • bootmisc — очищаются временные каталоги;
    • urandom — настраивается генератор случайных чисел;
    • keymaps — инициализируется раскладка клавиатуры;
    • hostname — задается имя машины, которое определено в /etc/hostname;
    • networking — поиск и инициализация интерфейсов с использованием информации из /etc/network/interfaces;
    • syslog — запускается демон журналирования из состава busybox;

  • И наконец, уровень default:

    • chrony — запускается NTP-сервис;
    • crond — запускается сервис выполнения задач по расписанию;
    • acpid — запускается сервис отслеживания событий питания;
    • sshd — запускается сервис удаленного доступа.

Не забудем и про зависимости от перечисленных выше сервисов, которые были заданы в init.d файлах: Ура, после выполнения этих шагов система готова к работе!

  • sysfs — монтирование /sys;
  • fsck — проверка и исправление файловых систем;
  • root — монтирование корневой системы на запись/чтение;
  • localmount — монтирование всех файловых систем, перечисленных в /etc/fstab;
  • klogd — журналирование событий ядра.

Открываем одну из локальных консолей, где нас поджидает getty, вводим логин, после чего передаем пароль процессу login и получаем доступ к запущенному командному интерпретатору ash (при запуске которого выполняется содержимое файлов /etc/profile, /etc/profile.d/* и ~/.profile для подготовки пользовательского окружения).

Ура, никаких дополнительных сущностей (несомненно, полезных в ряде случаев, вроде PAM) — а мы в системе!

(Есть ли они там? Осталось воспользоваться пакетным менеджером apk, и поискать нужные нам для нашей задачи пакеты. Можно оценить это через веб-портал).

  • Авторы дистрибутива сделали свою собственную надстройку над iptables под названием «Alpine Wall». И она не висит постоянно отдельным процессом в системе;
  • Для тех, кто любит управлять сервером через веб-интерфейс, подготовлен пакет «Alpine Configuration Framework». Без PHP или Perl, но с Lua;
  • Для тех, кто желает рабочего стола, есть возможность установки графической среды (хотя это может оказаться больно в начале);
  • Для особых ценителей имеется «установка» Alpine в памяти с хранением конфигурации на внешнем хранилище (см. описание инструмента lbu).

Для меня он выглядит так, как должна выглядеть минимальная серверная операционная система (прости меня, CentOS!). Дистрибутив Alpine не идеален, но его лаконичность меня действительно впечатлила, особенно в роли контейнера (всего 6 процессов — init, 4*getty, syslogd).

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть