По зову сердца и работе в 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.
Про Alpine
Чем может очаровать Alpine, особенно после CentOS? Отчаянным минимализмом!
Ну и, конечно, отсутствием необходимости сертификации «Linux Systemd Certified Voldemort».
Что сделали авторы:
- Понизили число используемых базовых компонентов;
- Выбрали модули поменьше и попрозрачнее;
- Упростили процесс конфигурирования системы.
А именно:
- Чрезвычайно лаконичный процесс установки с использованием консольной утилиты setup-alpine;
- В качестве загрузчика взят extlinux из состава проекта syslinux;
- Небольшой инструмент сборки mkinitfs для создания временной файловой системы, используемой при загрузке;
- Система инициализации openrc с определением зависимостей между сервисами, уровнями запуска и щепоткой скриптования;
- Замена стандартной библиотеки GNU libc на более легковесную musl libc;
- Вместо пакета GNU coreutils большинство стандартных системных утилит в несколько урезанном исполнении входят в состав пакета busybox, который может быть Вам знаком по встраиваемым решениям;
- По умолчанию используется командный интерпретатор ash в составе busybox. Само собой, никто не мешает при необходимости поставить bash
, ну и systemd; - Собственный пакетный менеджер apk и собственная инфраструктура распространения пакетов.
Кроме того, авторы реализовали ряд мер, ориентированных на повышение уровня защищенности базовой системы:
Применили патчи ядра grsecurity/PaX (про их эффективность мнения расходятся, но все же);Уже нет, спасибо коллеге из комментариев. Как раз 26 июня вышла версия 3.8.0.- Собрали пакеты с использованием режимов, снижающих вероятность эксплуатации ряда возможных уязвимостей.
В итоге мы получаем систему, снабженную рядом дополнительных механизмов защиты, позволяющую решить имеющуюся задачу и занимающую около 130 МБ. В запущенной системе установлен 41 пакет и выполняется 13 пользовательских процессов, можно стучаться по ssh.
И больше ничего. Осталось добавить то, что нужно вам (да и iptables с возможностью восстановления конфигурации при старте поставьте).
Приоткроем крышку
Обратите внимание – Alpine может пригодиться как учебная площадка при ознакомлении с ОС Linux! Увидеть логику работы компонентов субъективно проще, чем пытаться охватить сходу CentOS или Ubuntu:
- Загрузчик нашей установленной системы прост, его конфигурация влезает в 12 строк:
- Да и в /boot не слишком многолюдно:
- А вот и запущенный загрузчик без модных обоев:
- Ядро загружается, подхватывает initramfs, отрабатывает собственные шаги инициализации и вызывает команду init (которая, на самом деле, тоже идет в составе busybox). Init использует файл /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.
Как видите, это не всегда эти ваши нелюбимые "портянки":
Переменные, используемые при выполнении скрипта, определяются в соответствующем файле /etc/conf.d/syslog. В нашем случае, в файле определена переменная SYSLOGD_OPTS="-Z".
Обратите внимание — в скрипте декларативно определены зависимости данного сервиса.
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).
Итог
Дистрибутив Alpine не идеален, но его лаконичность меня действительно впечатлила, особенно в роли контейнера (всего 6 процессов — init, 4*getty, syslogd). Для меня он выглядит так, как должна выглядеть минимальная серверная операционная система (прости меня, CentOS!).
Кроме того, он вполне подходит на роль учебной площадки, позволяющей увидеть, из чего состоит современный дистрибутив, не погружаясь сразу в пучину whateverd-сервисов и многократного дублирования функциональности в великолепно-многоуровнево-конфигурируемых-средствах на все случаи жизни.
Комментарии (100)
Akuma
26.06.2018 13:04+8Про Alpine узнал после знакомства с Docker. Очень удобно строить на его основе контейнеры: весят чрезвычайно мало. Правда иногда приходится погеммороить с, вроде бы, известными пакетами, а то и вовсе вернутся на debuan/ubuntu контейнеры.
kei Автор
26.06.2018 13:06+5Действительно, контейнеры на основе Alpine — это отдельная песня. Особенно, если после использования lxc-контейнеров на основе CentOS взять и завести Alpine. C большими глазами и вопросами «А где все??», «А что, так можно??»
de1m
26.06.2018 13:30Да, для докер alpine хорош, помню года два назад делал образы для докера на убунту. Сейчас только на Alpine и потихоньку ещё и старые меняю.
mezantrop
26.06.2018 13:38А посмотрите еще FreeBSD может понравится.
jt3k
27.06.2018 10:36А tinycore linux для таких целей не канает? Где-то меньше десяти мегабайт весит, и кажется дефолтный вариант внутри vagrant
mezantrop
27.06.2018 11:25+2Логичноеразвитие серии «Юникс на одной дискете». Как же, помню такие проекты и даже сам в них отмечался когда-то из-за любви к изящным вещицам. Но все дело в балансе, верно?
Ха, коммент мгновенно ушел в минус. Ох, это все из-за упоминания FreeBSD в теме для серьезных админов Linux? :)eugenebb
27.06.2018 22:52Это когда всё в один исполняемый файл статически линкуется и создаются символические ссылки на него. И в зависимости от имени выбирается что работает.
Помню делал FreeBSD на 1.44MB дискете. После загрузки на сервере создавался RAM диск и всё от туда работало, без HDD.mezantrop
27.06.2018 23:26Да-да, а самый известный проект таких малюток назывался PicoBSD. Даже был написан скрипт, который собирал такую дискетку автоматически man picobsd(1), а исполняемый файл собирался при помощи crunchgen. Были времена :)
port443
28.06.2018 00:43Немного из другой оперы, но была ещё прекрасная дискета с QNX, с гуями, браузером, и драйверами (модема или сетевой карты).
zabbius
26.06.2018 13:43+7Авторы дистрибутива сделали свою собственную надстройку над iptables под названием «Alpine Wall». И она не висит постоянно отдельным процессом в системе;
Ну вот, и тут начались дистрибо-специфичные костыли.
ИМХО минимальная установка Арча решит все заявленные проблемы.kei Автор
26.06.2018 13:49Это опциональный пакет, для тех, кому не хочется определяться с правилами iptables.
Ziptar
27.06.2018 13:30Может мне кто-нибудь объяснить как можно не любить логичный, лаконичный и простой как табуретка iptables, и хотеть пользоваться чем-то другим вместо него?
kei Автор
27.06.2018 13:38Из iptables торчит много специфики обработки пакетов, которую люди могут бояться — опасаясь что-либо сломать, им нравится просто сказать «открой порт tcp/NN» и топать дальше.
Ziptar
27.06.2018 13:47Не правда, не торчит. В простейших случаях ему можно сказать "открой порт tcp/NN" и закрой всё остальное, а если вы про цепочки обработки пакетов — ну… Как работает input output и forward надо знать в любом случае, а остальное в простейших случаях знать необязательно, и больше того — остального не видно, если не лезть специально в доки.
kei Автор
27.06.2018 13:57Ну чуть-чуть торчит, вроде:
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
против:
firewall-cmd --add-service httpZiptar
27.06.2018 14:11Ну и что там торчит, кроме input chain и connection state, который не то что бы строго обязателен в простейшем случае?
Не знаю, видимо я «с рождения» микротиком по голове ударенный. Не люблю слепые методы, как второй.kei Автор
27.06.2018 14:17Да я тоже не очень люблю такие штуки — просто предполагаю, что может пугать людей. "--add-service" для них может быть более понятно и успокаивающе, чем "-p -m --state -m -dport -j".
win0err
26.06.2018 14:00+1У Дебиана есть Debootstrap, из коробки он минимальнее Арча.
Ну и Арч на сервере — странно, если честно.
zabbius
26.06.2018 14:10+3Арч на проде — странно, просто на сервере — нормально. Но обычно, когда речь идет о проде и LTS, вариантов совсем немного: RHEL, CentOS или SLES. Может быть еще что-то еще, типа Дебиана, но я не встречал.
SlyFoxMan
27.06.2018 13:07+1Ubuntu Server LTS используется чаще «обычного» Debian'a в продакшене, т.к. он более Enterprise дистрибутив.
ProFfeSsoRr
28.06.2018 12:39А что странного? Репозиторий у себя заморозь на тот день, когда инсталлился, и раскатывайся с него какое-то время. Набежит апдейтов — обновил репо и потом через Ansible например все машины обновил. Так без проблем все живет у нас, например. На проде тоже. Арч чем чаще обновляешь — тем он стабильнее, условно говоря (меньше в будущем всплывет проблем при обновлении).
GreamDesu
26.06.2018 13:46+1А в чем проблема, если уж совсем хочется, собрать себе свой дистрибутив генту?
kei Автор
26.06.2018 13:50+2Так если оно уже есть, то зачем собирать?
slonopotamus
26.06.2018 14:29Потому что то что есть может не полностью совпадать с тем что нужно. Ну и Alpine же тоже как-то собирают, а не в двоичных кодах пишут.
Forked
26.06.2018 15:09+9Вообще alpine использует не glibc, а musl-libc. Имеется небольшая несовместимость с glibc — иногда некоторый софт не собирается или не работает (падает).
Разработчики дистра такой софт патчат. Но если Вам нужно самим собрать свежую версию чего-либо из исходников, то можно напороться на проблемы.kei Автор
26.06.2018 15:14Да, это входит в ту самую упомянутую «неидеальность». Если задумали собирать и развертывать нечто специфическое — придется быть готовым к приключениям.
miramir
27.06.2018 10:59Единственную проблему, которую так и не смог победить в контейнерах с alpine это oracle-instantclient и php-oci8. Если это нужно то лучше использовать debian
elve
26.06.2018 15:10+4Увидел только одно преимущество — размер базовой установки. А жизнь без systemd и других не очень обязательных штук есть и в других дистрибутивах, но при этом удобнее из-за развитых сообществ и внушительных репозиториев.
kei Автор
26.06.2018 15:22Конечно, жизнь есть вокруг!
Но Alpine, как мне кажется, достоен того, чтобы его пощупать — а вдруг это как раз то, что пригодиться Вам завтра? Или еще ужаснее — вдруг через десяток лет это станет одной из немногих альтернатив Microsoft Enterprise Winlinuxd?
usego
26.06.2018 15:44А как него ставится стандартное барахло типа LAMPа? Так же через package manager можно или всё руками собирать?
kei Автор
26.06.2018 15:59+2Ну, с Linux у нас уже все хорошо,
Соответственно, ставится все штатным apk. Само собой, и postgresql с nginx тоже есть.
porn
27.06.2018 10:49В Alpine Linux нет расширения PHP для MSSQL и не планируется.
kei Автор
27.06.2018 10:56Честно говоря, никогда не рассматривал LAMP в таком виде, в сочетании с Microsoft SQL Server.
porn
27.06.2018 11:47Там был LEMP (да, MySQL тоже нужен был), но это не важно. Все контейнеры сделали на alpine, но вот с PHP пришлось остановиться на Debian.
kei Автор
27.06.2018 11:53В репо есть модуль php-mssql, вы про него?
porn
27.06.2018 12:01Не уверен, но, возможно, он не работает с MS SQL 13. Надо снова проверять. Я ставил msodbcsql, unixodbc, pdo_sqlsrv. В Дебиане кроме самого расширения пришлось ставить libssl1.0.0, который вообще-то уязвим, но обновить сервера не было возможности.
VolCh
26.06.2018 16:51+1Мне, как разработчику, философия Alpine импонирует, но докер-образы на его базе я не рискнул предлагать админам/девопсам. Если их инициатива и их основная ответственность за то, что что-то ломается или не собирается, то возражать смысла не вижу.
Вот докер продвигать смысл вижу как разработчик, но базовый образ того дистра же, что по дефолту на серверах. Чтобы максимально задействовать их знания и опыт в диагностике и решении проблем.kei Автор
26.06.2018 17:08-1Скептически отношусь к любви разработчиков к докеру, но ведь можно сделать ход конем — и поставить Alpine на сервере! А если серьезно — конечно все зависит от наличия реального выигрыша, и готовности такое решение сопровождать.
Merifri
26.06.2018 23:32+2Нет, ну alpine на сервере это совсем не серьезно. Тут очень много причин, почему это довольно рискованная затея.
А вот для докера и правда очень удобно. Конечно, зависит в первую очередь от приложений, назначения образа. Тянуть 500+МБ не всегда хочется, и не всегда удобно.
К примеру, в докере могут храниться вспомогательные скрипты (не сильно требовательные к окружению) которые периодически будут запускаться в кластере. Для небольших С/Go/Rust/… приложений я бы также выбрал alpine, если нет желания собирать from scratch.kei Автор
26.06.2018 23:37+1Без иронии — подскажите минусы использования в качестве полноценной ОС на сервере, чтобы я не впал в фанатизм.
qrKot
27.06.2018 06:50+5Собственно, вы же сами назвали основную фишку Alpine — его простота и минималистичность. Она, по совместительству, является и его «ахиллесовой пятой».
Для «контейнера/сервера одного приложения», либо для ембедда/iot-устройств — оно мегафича. Для энтерпрайз-сервера уже скорее недостаток.
Экономия нескольких гигабайт места на диске в обмен на усечение пакетной базы, отсутствие LTS- поддержки, отказ от общепринятых и, соответственно, более обкатанных средств администрирования — ну, так себе идея для сколько-нибудь серьезного сервера.
uSasha
27.06.2018 16:47Никогда не понимал в чем проблема этих 500+МБ.
Они же хранятся слоями, т.е. 10 контейнеров на одном образе это не 500*10, а просто 500МБ + то что уникально для каждого контейнера.
densss2
26.06.2018 19:21-1$ holywar mode disable
Простите, у Вас ошибка в тексте. Вот как правильно:
$ holywar --mode-disable
Seboreia
26.06.2018 19:48+3А как там обстоят дела с jvm? Пару лет назад приходилось плясать с поиском и установкой «левого» пакета glibc (т.к. в оф. репозитории его нет) чтобы поставить oracle-jdk с java-приложением
symbix
26.06.2018 20:24openjdk есть в community repo
Seboreia
26.06.2018 21:11Что-то не находит: pkgs.alpinelinux.org/packages?name=jdk&branch=edge&repo=community (даже если бы был, как оно работает с musl-libc?)
Да и зачастую нужен оракловый jdkdos
26.06.2018 21:55+1neumeika
26.06.2018 22:28sun java — не проблема, проблемы начинаются, когда захочешь свои пакеты создать, или что-то «поинтерпрайзнее» поставить, какие-нибудь тулзы от HP/DELL, oracle client, там без glibc всё ооочень плохо
kei Автор
26.06.2018 23:41Вполне себе с полоборота запустился вполне себе «ынтерпрайзный» KeyCloak, но указанный Вами «интерпрайз» и правда не пойдет — он же у нас с листами совместимости ПО и ОС, небось? За него в нашем случае и браться не стоит.
Paskin
26.06.2018 20:58На сервере оно наверное неплохо — а на встроенных системах Alpine очень не хватает нормального UDEV.
RolexStrider
26.06.2018 22:36На сервере (вообще тут не понятно, что имеется в виду «на сервере»?) может и не хватает, но именно на встраиваемых системах — чего именно не хватает в том же mdev из busybox?
Paskin
28.06.2018 08:25Мне нужно было подключить несколько разных устройств с FTDI-конверторами, которым китайцы не удосужились поменять VID:PID. В Убунту это решилось простым UDEV-правилом по Serial (ЕМНИП), содержавшим название устройства. В Alpine же Serial не доступен в качестве критерия — как минимум в той конфигурации что у меня была.
SergeyD
27.06.2018 00:31+1Один маленький недостаток Alpine — все пакеты собраны с
-Osпо-умолчанию.
А это примерно -20% скорости работы.iproger
27.06.2018 01:29Что такое -0s?
FeNUMe
27.06.2018 01:33+3Ключ компилятора отвечающий за тип оптимизации. Конкретно этот оптимизирует по объему.
Читать подробнее
celebrate
27.06.2018 09:29+1Сражаться за каждый процесс при запуске оправдано на ноуте «два ядра два гига». На современных серверах в этом мало смысла. И уж точно никто не будет ставить туда малоизученный alpine или обожаемые генту или арч. Вендоры даже слушать не станут.
Однако, в качестве основы для контейнеров alpine безусловно очень хорош.sol77
27.06.2018 10:44да тут полностью согласен, всетаки LTS еще никто не отменял да это пожалуй и самое главное в современных дистрах
suprimex
27.06.2018 10:30Что у нас с поддержкой NAS-ов/ armv5? С ходу ненашёл…
kei Автор
27.06.2018 10:47Собственно, актуальный список поддерживаемых архитектур:
Насколько я понимаю, под armhf подразумевается armv7, но могу ошибаться.
zedroid
27.06.2018 17:22Судя по реализациям нормальная поддержка есть таки только под raspberry. В arm чаще всего приходится патчить ядро и u-boot, чтобы система запустилась на конкретной плате. Поэтому я не уверен что generic arm образ взлетит на чем-то из коробки.
vox_araneae
27.06.2018 10:30+1Применили патчи ядра grsecurity/PaX (про их эффективность мнения расходятся, но все же);
В свежем релизе поддержка grsecurity (неофициальных патчей от Матиаса Краузе и самого проекта Alpine) прекращена.
Собрали пакеты с использованием режимов, снижающих вероятность эксплуатации ряда возможных уязвимостей.
Неплохо, но реализация malloc в musl менее защищена от повреждения внутренних структур данных, чем в glibc или OpenBSD libc. К сожалению, в сети практически никто об этом не пишет. Встречаются даже заблуждения об обратном.
demimurych
27.06.2018 12:12+1Странное послевкусие от всего этого, сильно напоминающее — мне заплатили за пиар.
Автор продемонстрировал что «на ты с консолью», и при этом, например, мягко обошел такие вещи как, в той же убунте есть серверные дистрибутивы, которые в том числе есть и без системд.
То есть выбрал факторы удобные ему для рассказа о его дистрибутиве, и пропустил неудобные.kei Автор
27.06.2018 12:24+1Я же не утверждаю, что это единственно верный подход, а просто рассказываю о том, что мне понравилось. И Natanael Copa меня наверняка пошлет за предложение за это платить :D И я ни в коем случае не против, если вы подскажете неудобные факторы, это очень дополнит рассказ!
demimurych
27.06.2018 18:06Давайте условимся в том, что я никого ни в чем не обвиняю. Мне просто что-то показалось странным. А именно — Вы как автор произвели впечатление человека погруженного в тему, а вовсе не новичка который не смог пойти дальше стартовой страницы того же сайта Убунты.
А значит, если верить моей паранойе, прекрасно знаете и про ubuntu-server и про то что она существует в версии 14.04 где по умолчанию нет никакого systemd и о том что при старте этого дистрибутива количество процессов окажется на уровне описываемого вами дистрибутива.
Словом, дело то ваше конечно, но если уж сравнивать — то попробовать это сделать объективно. Подобное с подобным.kei Автор
27.06.2018 18:29+1Так 14.04 скоро закончится же, мое сравнение включает в себя только последние версии. И специально упомянул — мир широк, вариантов много, рассматриваемый объект не идеален, но обладает симпатичными качествами.
Ну вы уж совсем паранойю включили, я же не единственно кошерную ОС впариваю.
vox_araneae
27.06.2018 12:24+1Последняя LTS-версия убунты без systemd — 16.04. Новых пока не обещают.
То есть выбрал факторы удобные ему для рассказа о его дистрибутиве, и пропустил неудобные.
Имхо, больше похоже на увлечённость/очарованность, нежели на пиар.
TrllServ
27.06.2018 18:00Странное послевкусие от всего этого, сильно напоминающее — мне заплатили за пиар.
Заплатили? За пиар мини дистра со специфичным использованием? Ещё и на рус, а не англ?
В управление человечеством электроволнами с колец Юпитера верится больше, чем в это.
jaroslavdextems
27.06.2018 15:39+1Ну не знаю, после танцев с настройками приложений в Alpine для себя решил, что Alpine буду использовать только для сборки контейнеров (где процессы как правило воспроизводимы и более-менее типичны), а вот сами контейнеры уже на машине с CentOS\RHEL\Ubuntu\чем-угодно-полноценным. По крайней мере пока.
В общем история про микроскоп и гвозди работает в обе стороны.
SirEdvin
27.06.2018 22:26+1На самом деле, alpine на сервере — это откровенно стремное решение, на мой взгляд, как минимум потому, что alpine — это большой и жирный болт на обратной совместимости.
Тот же musl и busybox содержат команды, которые не совместимые с стандартными GNU тулзами, что иногда очень сильно раздражает и приводит к багам (pycharm не мог нормально работать с docker контейнерами на alpine где-то до 2018 года, потому что у tar другие ключи, например).
В дополнение к этому, основная либа для apline — это libressl, разработчики которой тоже не поддерживают совместимость с openssl чисто из вредности.
Он вроде как неплох для контейнеров (хотя на самом деле, шаг влево, шаг в право и привет страдания), но просто ужасен для сервера.
Ну и еще добавлю, что даже не смотря на то, что многие приложения есть в альпин-версии контейнера, далеко не все компании их тестируют, что иногда приводит к крашам в alpine образах, например. Хотя на ubuntu-based образе все ок.
point212
28.06.2018 01:29Вот я и дожил до того момента, когда вижу как кто-то восхваляет простоту устройства дистрибутивов какими они были в 2000-м :)
ustas33
28.06.2018 21:11Действительно, зачем забивать гвозди микроскопом и изобретать велосипеды?
Есть SUSE Studio для минимизации, под контейнеры есть CoreOS, Red Hat Enterprise Linux Atomic Host.
immaculate
Есть еще вполне популярный дистрибутив Arch.
И что все так к несчастному systemd прицепились? Сколько копий уже было сломано. По своему опыту могу сказать, так как я в свое время очень много писал скриптов для init.d (реально много): определения unit'ов для systemd во много раз проще писать, отлаживать и использовать, чем эти несчастные init.d скрипты, которые легко и просто пишутся только в самой простой ситуации. Init.d скрипты легко ломаются и сложно отлаживаются. И в любой мало-мальски нетривиальной ситуации написать init.d скрипт сложнее, чем unit systemd.
kei Автор
Systemd неплох, просто его иногда слишком много, и он продолжает пожирать все вокруг. Само собой, это вкусовщина, не более.
Laney1
скорее не вкусовщина, а соответствие инструмента задачам. Нет смысла тянуть развесистый дистр в простенький контейнер с парой сервисов. Но точно также нет смысла отказываться от systemd в сложной системе с кучей сервисов, таймеров, контейнеров, логов и т.п.
celebrate
Не знаю, ходил в магазин за хлебом, не видел там systemd :)
maxzhurkin
Есть ниша, занимаемая в свое время Slackware. Потом её занимала Gentoo, теперь — Arch. Каждый раз приближаясь к мэйнстриму. Arch уже очень близок, но это, по прежнему, достойный наследник Slackware. Моё IMHO
firedragon
Зачем вообще нужен скрипт если есть
1. файл конфигурации
2. переменные среды
3. ключи запуска
4. selinux
…
n. Последнее ультимативное средство конфигурации всего через 42
?