Зачем забивать гвозди микроскопом, если есть 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.


    Про 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 не слишком многолюдно:

    вывод 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


    Переменные, используемые при выполнении скрипта, определяются в соответствующем файле /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-сервисов и многократного дублирования функциональности в великолепно-многоуровнево-конфигурируемых-средствах на все случаи жизни.

    Digital Design
    156,00
    Компания
    Поделиться публикацией

    Комментарии 106

      +16

      Есть еще вполне популярный дистрибутив Arch.


      И что все так к несчастному systemd прицепились? Сколько копий уже было сломано. По своему опыту могу сказать, так как я в свое время очень много писал скриптов для init.d (реально много): определения unit'ов для systemd во много раз проще писать, отлаживать и использовать, чем эти несчастные init.d скрипты, которые легко и просто пишутся только в самой простой ситуации. Init.d скрипты легко ломаются и сложно отлаживаются. И в любой мало-мальски нетривиальной ситуации написать init.d скрипт сложнее, чем unit systemd.

        +4
        Systemd неплох, просто его иногда слишком много, и он продолжает пожирать все вокруг. Само собой, это вкусовщина, не более.
          0
          Само собой, это вкусовщина, не более.

          скорее не вкусовщина, а соответствие инструмента задачам. Нет смысла тянуть развесистый дистр в простенький контейнер с парой сервисов. Но точно также нет смысла отказываться от systemd в сложной системе с кучей сервисов, таймеров, контейнеров, логов и т.п.

            –1
            Не знаю, ходил в магазин за хлебом, не видел там systemd :)
            +3
            Есть ниша, занимаемая в свое время Slackware. Потом её занимала Gentoo, теперь — Arch. Каждый раз приближаясь к мэйнстриму. Arch уже очень близок, но это, по прежнему, достойный наследник Slackware. Моё IMHO
              0
              Зачем вообще нужен скрипт если есть
              1. файл конфигурации
              2. переменные среды
              3. ключи запуска
              4. selinux

              n. Последнее ультимативное средство конфигурации всего через 42

              ?
              +8
              Про Alpine узнал после знакомства с Docker. Очень удобно строить на его основе контейнеры: весят чрезвычайно мало. Правда иногда приходится погеммороить с, вроде бы, известными пакетами, а то и вовсе вернутся на debuan/ubuntu контейнеры.
                +6
                Действительно, контейнеры на основе Alpine — это отдельная песня. Особенно, если после использования lxc-контейнеров на основе CentOS взять и завести Alpine. C большими глазами и вопросами «А где все??», «А что, так можно??»
                  0
                  Да, для докер alpine хорош, помню года два назад делал образы для докера на убунту. Сейчас только на Alpine и потихоньку ещё и старые меняю.
                  +1
                  А посмотрите еще FreeBSD может понравится.
                    0

                    А tinycore linux для таких целей не канает? Где-то меньше десяти мегабайт весит, и кажется дефолтный вариант внутри vagrant

                      +2
                      Логичноеразвитие серии «Юникс на одной дискете». Как же, помню такие проекты и даже сам в них отмечался когда-то из-за любви к изящным вещицам. Но все дело в балансе, верно?

                      Ха, коммент мгновенно ушел в минус. Ох, это все из-за упоминания FreeBSD в теме для серьезных админов Linux? :)
                        0

                        Они возможно не пробовали фряху) и переучиваться не желают

                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Да-да, а самый известный проект таких малюток назывался PicoBSD. Даже был написан скрипт, который собирал такую дискетку автоматически man picobsd(1), а исполняемый файл собирался при помощи crunchgen. Были времена :)
                              0
                              Немного из другой оперы, но была ещё прекрасная дискета с QNX, с гуями, браузером, и драйверами (модема или сетевой карты).
                      +7
                      Авторы дистрибутива сделали свою собственную надстройку над iptables под названием «Alpine Wall». И она не висит постоянно отдельным процессом в системе;

                      Ну вот, и тут начались дистрибо-специфичные костыли.

                      ИМХО минимальная установка Арча решит все заявленные проблемы.
                        0
                        Это опциональный пакет, для тех, кому не хочется определяться с правилами iptables.
                          0

                          Может мне кто-нибудь объяснить как можно не любить логичный, лаконичный и простой как табуретка iptables, и хотеть пользоваться чем-то другим вместо него?

                            0
                            Из iptables торчит много специфики обработки пакетов, которую люди могут бояться — опасаясь что-либо сломать, им нравится просто сказать «открой порт tcp/NN» и топать дальше.
                              0

                              Не правда, не торчит. В простейших случаях ему можно сказать "открой порт tcp/NN" и закрой всё остальное, а если вы про цепочки обработки пакетов — ну… Как работает input output и forward надо знать в любом случае, а остальное в простейших случаях знать необязательно, и больше того — остального не видно, если не лезть специально в доки.

                                0
                                Ну чуть-чуть торчит, вроде:
                                -A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
                                против:
                                firewall-cmd --add-service http
                                  0
                                  Ну и что там торчит, кроме input chain и connection state, который не то что бы строго обязателен в простейшем случае?
                                  Не знаю, видимо я «с рождения» микротиком по голове ударенный. Не люблю слепые методы, как второй.
                                    0
                                    Да я тоже не очень люблю такие штуки — просто предполагаю, что может пугать людей. "--add-service" для них может быть более понятно и успокаивающе, чем "-p -m --state -m -dport -j".
                                      0
                                      Да не то чтобы пугает… Я с синтаксисом ipchains/iptables еще в начале 00-х возился.
                                      Просто надоело писать вот эти -A INPUT bla-bla, когда можно просто ufw allow 1234/tcp && ufw limit 1234. А если хочется чего-то более интересного, никто магию iptables и не запрещает.
                              0
                              Я так-же про ipchains в свое время думал.
                            +1

                            У Дебиана есть Debootstrap, из коробки он минимальнее Арча.


                            Ну и Арч на сервере — странно, если честно.

                              +3
                              Арч на проде — странно, просто на сервере — нормально. Но обычно, когда речь идет о проде и LTS, вариантов совсем немного: RHEL, CentOS или SLES. Может быть еще что-то еще, типа Дебиана, но я не встречал.
                                +2
                                Ubuntu Server LTS используется чаще «обычного» Debian'a в продакшене, т.к. он более Enterprise дистрибутив.
                                0
                                А что странного? Репозиторий у себя заморозь на тот день, когда инсталлился, и раскатывайся с него какое-то время. Набежит апдейтов — обновил репо и потом через Ansible например все машины обновил. Так без проблем все живет у нас, например. На проде тоже. Арч чем чаще обновляешь — тем он стабильнее, условно говоря (меньше в будущем всплывет проблем при обновлении).
                              +2

                              А в чем проблема, если уж совсем хочется, собрать себе свой дистрибутив генту?

                                +2
                                Так если оно уже есть, то зачем собирать?
                                  0
                                  Потому что то что есть может не полностью совпадать с тем что нужно. Ну и Alpine же тоже как-то собирают, а не в двоичных кодах пишут.
                                    +1
                                    Оптимальный набор ключей?
                                      +1

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

                                      0
                                      У того, что есть — есть фатальный недостаток.
                                    +5
                                    +1 за debootstrap и не морочить себе голову экзотическими дистрибутивами.
                                    Правда, debootstrap по умолчанию поставит systemd, но есть способ заставить его использовать sysvinit.
                                      0
                                      Что-то я не вижу debootstrap на dockerhub.
                                        0
                                        При чём здесь docker? Debootstrap — прикладное приложение для генерирования минималистичного корневого каталога Debian.
                                      0
                                      del
                                        +9
                                        Вообще alpine использует не glibc, а musl-libc. Имеется небольшая несовместимость с glibc — иногда некоторый софт не собирается или не работает (падает).
                                        Разработчики дистра такой софт патчат. Но если Вам нужно самим собрать свежую версию чего-либо из исходников, то можно напороться на проблемы.
                                          0
                                          Да, это входит в ту самую упомянутую «неидеальность». Если задумали собирать и развертывать нечто специфическое — придется быть готовым к приключениям.
                                            0
                                            Единственную проблему, которую так и не смог победить в контейнерах с alpine это oracle-instantclient и php-oci8. Если это нужно то лучше использовать debian
                                            +4
                                            Увидел только одно преимущество — размер базовой установки. А жизнь без systemd и других не очень обязательных штук есть и в других дистрибутивах, но при этом удобнее из-за развитых сообществ и внушительных репозиториев.
                                              0
                                              Конечно, жизнь есть вокруг!
                                              Но Alpine, как мне кажется, достоен того, чтобы его пощупать — а вдруг это как раз то, что пригодиться Вам завтра? Или еще ужаснее — вдруг через десяток лет это станет одной из немногих альтернатив Microsoft Enterprise Winlinuxd?
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                А как него ставится стандартное барахло типа LAMPа? Так же через package manager можно или всё руками собирать?
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    +2

                                                    Ну, с Linux у нас уже все хорошо,



                                                    Соответственно, ставится все штатным apk. Само собой, и postgresql с nginx тоже есть.

                                                      0
                                                      В Alpine Linux нет расширения PHP для MSSQL и не планируется.
                                                        0

                                                        Честно говоря, никогда не рассматривал LAMP в таком виде, в сочетании с Microsoft SQL Server.

                                                          0
                                                          Там был LEMP (да, MySQL тоже нужен был), но это не важно. Все контейнеры сделали на alpine, но вот с PHP пришлось остановиться на Debian.
                                                            0

                                                            В репо есть модуль php-mssql, вы про него?

                                                              0
                                                              Не уверен, но, возможно, он не работает с MS SQL 13. Надо снова проверять. Я ставил msodbcsql, unixodbc, pdo_sqlsrv. В Дебиане кроме самого расширения пришлось ставить libssl1.0.0, который вообще-то уязвим, но обновить сервера не было возможности.
                                                    +1
                                                    Мне, как разработчику, философия Alpine импонирует, но докер-образы на его базе я не рискнул предлагать админам/девопсам. Если их инициатива и их основная ответственность за то, что что-то ломается или не собирается, то возражать смысла не вижу.

                                                    Вот докер продвигать смысл вижу как разработчик, но базовый образ того дистра же, что по дефолту на серверах. Чтобы максимально задействовать их знания и опыт в диагностике и решении проблем.
                                                      0
                                                      Скептически отношусь к любви разработчиков к докеру, но ведь можно сделать ход конем — и поставить Alpine на сервере! А если серьезно — конечно все зависит от наличия реального выигрыша, и готовности такое решение сопровождать.
                                                        +2
                                                        Нет, ну alpine на сервере это совсем не серьезно. Тут очень много причин, почему это довольно рискованная затея.
                                                        А вот для докера и правда очень удобно. Конечно, зависит в первую очередь от приложений, назначения образа. Тянуть 500+МБ не всегда хочется, и не всегда удобно.
                                                        К примеру, в докере могут храниться вспомогательные скрипты (не сильно требовательные к окружению) которые периодически будут запускаться в кластере. Для небольших С/Go/Rust/… приложений я бы также выбрал alpine, если нет желания собирать from scratch.
                                                          +1
                                                          Без иронии — подскажите минусы использования в качестве полноценной ОС на сервере, чтобы я не впал в фанатизм.
                                                            +7
                                                            Собственно, вы же сами назвали основную фишку Alpine — его простота и минималистичность. Она, по совместительству, является и его «ахиллесовой пятой».
                                                            Для «контейнера/сервера одного приложения», либо для ембедда/iot-устройств — оно мегафича. Для энтерпрайз-сервера уже скорее недостаток.
                                                            Экономия нескольких гигабайт места на диске в обмен на усечение пакетной базы, отсутствие LTS- поддержки, отказ от общепринятых и, соответственно, более обкатанных средств администрирования — ну, так себе идея для сколько-нибудь серьезного сервера.
                                                            0
                                                            Никогда не понимал в чем проблема этих 500+МБ.
                                                            Они же хранятся слоями, т.е. 10 контейнеров на одном образе это не 500*10, а просто 500МБ + то что уникально для каждого контейнера.
                                                              0

                                                              большую проблему доставляет то, что все это жрет оперативку

                                                                0
                                                                Дистрибутив же не лежит целиком в оперативке.
                                                                  0

                                                                  дистрибутив нет, а вот то, что его раздувает там работает — тот же systemd и прочее

                                                        0
                                                        Интересная штучка, а readonly root там можно малой кровью настроить?
                                                          0
                                                          $ holywar mode disable

                                                          Простите, у Вас ошибка в тексте. Вот как правильно:
                                                          $ holywar --mode-disable
                                                            +1
                                                            Странно, ошибка вроде была корректной.
                                                              0
                                                              Ну так-то да: ошибка была корректной)))
                                                              0
                                                              Вот так надо:
                                                              $ echo 0 > /proc/holywar
                                                                0
                                                                Хммм… Тоже вариант)
                                                              +3
                                                              А как там обстоят дела с jvm? Пару лет назад приходилось плясать с поиском и установкой «левого» пакета glibc (т.к. в оф. репозитории его нет) чтобы поставить oracle-jdk с java-приложением
                                                                0

                                                                openjdk есть в community repo

                                                                  0
                                                                  Что-то не находит: pkgs.alpinelinux.org/packages?name=jdk&branch=edge&repo=community (даже если бы был, как оно работает с musl-libc?)
                                                                  Да и зачастую нужен оракловый jdk
                                                                    +1
                                                                      0
                                                                      sun java — не проблема, проблемы начинаются, когда захочешь свои пакеты создать, или что-то «поинтерпрайзнее» поставить, какие-нибудь тулзы от HP/DELL, oracle client, там без glibc всё ооочень плохо
                                                                        0
                                                                        Вполне себе с полоборота запустился вполне себе «ынтерпрайзный» KeyCloak, но указанный Вами «интерпрайз» и правда не пойдет — он же у нас с листами совместимости ПО и ОС, небось? За него в нашем случае и браться не стоит.
                                                                0
                                                                На сервере оно наверное неплохо — а на встроенных системах Alpine очень не хватает нормального UDEV.
                                                                  0
                                                                  На сервере (вообще тут не понятно, что имеется в виду «на сервере»?) может и не хватает, но именно на встраиваемых системах — чего именно не хватает в том же mdev из busybox?
                                                                    0
                                                                    Мне нужно было подключить несколько разных устройств с FTDI-конверторами, которым китайцы не удосужились поменять VID:PID. В Убунту это решилось простым UDEV-правилом по Serial (ЕМНИП), содержавшим название устройства. В Alpine же Serial не доступен в качестве критерия — как минимум в той конфигурации что у меня была.
                                                                  +2

                                                                  Один маленький недостаток Alpine — все пакеты собраны с -Os по-умолчанию.
                                                                  А это примерно -20% скорости работы.

                                                                    +1
                                                                    Что такое -0s?
                                                                      +4
                                                                      Ключ компилятора отвечающий за тип оптимизации. Конкретно этот оптимизирует по объему.
                                                                      Читать подробнее
                                                                        0
                                                                        Спасибо, очень интересно.
                                                                      0

                                                                      Изначально Alpine проектировался для ембеддеда, так что это by design.

                                                                      +1
                                                                      Сражаться за каждый процесс при запуске оправдано на ноуте «два ядра два гига». На современных серверах в этом мало смысла. И уж точно никто не будет ставить туда малоизученный alpine или обожаемые генту или арч. Вендоры даже слушать не станут.

                                                                      Однако, в качестве основы для контейнеров alpine безусловно очень хорош.
                                                                        0
                                                                        да тут полностью согласен, всетаки LTS еще никто не отменял да это пожалуй и самое главное в современных дистрах
                                                                        0
                                                                        Что у нас с поддержкой NAS-ов/ armv5? С ходу ненашёл…
                                                                          0

                                                                          Собственно, актуальный список поддерживаемых архитектур:
                                                                          Архитектуры


                                                                          Насколько я понимаю, под armhf подразумевается armv7, но могу ошибаться.

                                                                            0
                                                                            Судя по реализациям нормальная поддержка есть таки только под raspberry. В arm чаще всего приходится патчить ядро и u-boot, чтобы система запустилась на конкретной плате. Поэтому я не уверен что generic arm образ взлетит на чем-то из коробки.
                                                                          +1
                                                                          Применили патчи ядра grsecurity/PaX (про их эффективность мнения расходятся, но все же);

                                                                          В свежем релизе поддержка grsecurity (неофициальных патчей от Матиаса Краузе и самого проекта Alpine) прекращена.

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

                                                                          Неплохо, но реализация malloc в musl менее защищена от повреждения внутренних структур данных, чем в glibc или OpenBSD libc. К сожалению, в сети практически никто об этом не пишет. Встречаются даже заблуждения об обратном.
                                                                            0
                                                                            Аааа! 26 июня анонс, ну е-мое. Спасибо, добавлю.
                                                                            0
                                                                            Странное послевкусие от всего этого, сильно напоминающее — мне заплатили за пиар.
                                                                            Автор продемонстрировал что «на ты с консолью», и при этом, например, мягко обошел такие вещи как, в той же убунте есть серверные дистрибутивы, которые в том числе есть и без системд.
                                                                            То есть выбрал факторы удобные ему для рассказа о его дистрибутиве, и пропустил неудобные.
                                                                              +1
                                                                              Я же не утверждаю, что это единственно верный подход, а просто рассказываю о том, что мне понравилось. И Natanael Copa меня наверняка пошлет за предложение за это платить :D И я ни в коем случае не против, если вы подскажете неудобные факторы, это очень дополнит рассказ!
                                                                                0
                                                                                Давайте условимся в том, что я никого ни в чем не обвиняю. Мне просто что-то показалось странным. А именно — Вы как автор произвели впечатление человека погруженного в тему, а вовсе не новичка который не смог пойти дальше стартовой страницы того же сайта Убунты.

                                                                                А значит, если верить моей паранойе, прекрасно знаете и про ubuntu-server и про то что она существует в версии 14.04 где по умолчанию нет никакого systemd и о том что при старте этого дистрибутива количество процессов окажется на уровне описываемого вами дистрибутива.

                                                                                Словом, дело то ваше конечно, но если уж сравнивать — то попробовать это сделать объективно. Подобное с подобным.
                                                                                  +1
                                                                                  Так 14.04 скоро закончится же, мое сравнение включает в себя только последние версии. И специально упомянул — мир широк, вариантов много, рассматриваемый объект не идеален, но обладает симпатичными качествами.
                                                                                  Ну вы уж совсем паранойю включили, я же не единственно кошерную ОС впариваю.
                                                                                +1
                                                                                Последняя LTS-версия убунты без systemd — 16.04. Новых пока не обещают.

                                                                                То есть выбрал факторы удобные ему для рассказа о его дистрибутиве, и пропустил неудобные.

                                                                                Имхо, больше похоже на увлечённость/очарованность, нежели на пиар.
                                                                                  0
                                                                                  16.04

                                                                                  Там же systemd? Или есть версия без?
                                                                                    0
                                                                                    systemd можно заменить на upstart-sysv.
                                                                                  +1
                                                                                  Странное послевкусие от всего этого, сильно напоминающее — мне заплатили за пиар.
                                                                                  Заплатили? За пиар мини дистра со специфичным использованием? Ещё и на рус, а не англ?
                                                                                  В управление человечеством электроволнами с колец Юпитера верится больше, чем в это.
                                                                                  +1
                                                                                  Ну не знаю, после танцев с настройками приложений в Alpine для себя решил, что Alpine буду использовать только для сборки контейнеров (где процессы как правило воспроизводимы и более-менее типичны), а вот сами контейнеры уже на машине с CentOS\RHEL\Ubuntu\чем-угодно-полноценным. По крайней мере пока.

                                                                                  В общем история про микроскоп и гвозди работает в обе стороны.
                                                                                    +2
                                                                                    На самом деле, alpine на сервере — это откровенно стремное решение, на мой взгляд, как минимум потому, что alpine — это большой и жирный болт на обратной совместимости.

                                                                                    Тот же musl и busybox содержат команды, которые не совместимые с стандартными GNU тулзами, что иногда очень сильно раздражает и приводит к багам (pycharm не мог нормально работать с docker контейнерами на alpine где-то до 2018 года, потому что у tar другие ключи, например).

                                                                                    В дополнение к этому, основная либа для apline — это libressl, разработчики которой тоже не поддерживают совместимость с openssl чисто из вредности.

                                                                                    Он вроде как неплох для контейнеров (хотя на самом деле, шаг влево, шаг в право и привет страдания), но просто ужасен для сервера.

                                                                                    Ну и еще добавлю, что даже не смотря на то, что многие приложения есть в альпин-версии контейнера, далеко не все компании их тестируют, что иногда приводит к крашам в alpine образах, например. Хотя на ubuntu-based образе все ок.
                                                                                      +3
                                                                                      Вот я и дожил до того момента, когда вижу как кто-то восхваляет простоту устройства дистрибутивов какими они были в 2000-м :)
                                                                                        –1

                                                                                        Действительно, зачем забивать гвозди микроскопом и изобретать велосипеды?
                                                                                        Есть SUSE Studio для минимизации, под контейнеры есть CoreOS, Red Hat Enterprise Linux Atomic Host.

                                                                                          +1
                                                                                          CoreOS — хост. А если внутри контейнера не статически слинкованный бинарник, то надо ж какой-то дистрибутив еще запихивать в сам контейнер.
                                                                                          0
                                                                                          Если руками зачистить всё, что можно и нельзя, то минимальный CentOS можно ужать в ~150 Мб (но это, конечно, боль). Если до такого же уровня ужимать Альпайн, можно получить что-то типа ~40-50 Мб — что с одной стороны в 3 раза лучше, а с другой — стоят ли того всего-то 100 метров, при терабайтах СХД?

                                                                                          А ещё у Альпайна плохо описан процесс подключения внешних компонентов, и особенно — «third-party» модулей ядра. Надо будет как-нить в свободное время заняться…
                                                                                            0
                                                                                            Вряд ли это борьба за СХД, вот размер образа контейнера — это важно с точки зрения времени от ничего до запущенного состояния на произвольных хостах или в процессе сборки.

                                                                                            PS Извините уж за мой однобокий взгляд на Alpine.
                                                                                            0
                                                                                            А кто щупал Intel ClearLinux?

                                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                            Самое читаемое