Comments 111
Есть еще вполне популярный дистрибутив Arch.
И что все так к несчастному systemd прицепились? Сколько копий уже было сломано. По своему опыту могу сказать, так как я в свое время очень много писал скриптов для init.d (реально много): определения unit'ов для systemd во много раз проще писать, отлаживать и использовать, чем эти несчастные init.d скрипты, которые легко и просто пишутся только в самой простой ситуации. Init.d скрипты легко ломаются и сложно отлаживаются. И в любой мало-мальски нетривиальной ситуации написать init.d скрипт сложнее, чем unit systemd.
Systemd неплох, просто его иногда слишком много, и он продолжает пожирать все вокруг. Само собой, это вкусовщина, не более.
Есть ниша, занимаемая в свое время Slackware. Потом её занимала Gentoo, теперь — Arch. Каждый раз приближаясь к мэйнстриму. Arch уже очень близок, но это, по прежнему, достойный наследник Slackware. Моё IMHO
Зачем вообще нужен скрипт если есть
1. файл конфигурации
2. переменные среды
3. ключи запуска
4. selinux
…
n. Последнее ультимативное средство конфигурации всего через 42
?
1. файл конфигурации
2. переменные среды
3. ключи запуска
4. selinux
…
n. Последнее ультимативное средство конфигурации всего через 42
?
А можно пример, когда systemd init сильно лучше простого init.d скрипта. Допускаю, что весь этот огород в systemd нагородили не от хорошей жизни. Тем не менее не перевариваю сложного, systemd бесит. Не могу сказать, что очень часто туда приходится ходить, но хорошо помню случай, когда я битый час просто искал откуда вызывается служба в systemd. Alpine очень полюбил, хотя он для десктопа пока слабо пригоден, тем не менее в качестве рабочего верстака использую именно этот дистрибутив. На одноплатных компьютерах для systemd вообще нет места.
Про Alpine узнал после знакомства с Docker. Очень удобно строить на его основе контейнеры: весят чрезвычайно мало. Правда иногда приходится погеммороить с, вроде бы, известными пакетами, а то и вовсе вернутся на debuan/ubuntu контейнеры.
Действительно, контейнеры на основе Alpine — это отдельная песня. Особенно, если после использования lxc-контейнеров на основе CentOS взять и завести Alpine. C большими глазами и вопросами «А где все??», «А что, так можно??»
Да, для докер alpine хорош, помню года два назад делал образы для докера на убунту. Сейчас только на Alpine и потихоньку ещё и старые меняю.
А посмотрите еще FreeBSD может понравится.
А tinycore linux для таких целей не канает? Где-то меньше десяти мегабайт весит, и кажется дефолтный вариант внутри vagrant
Логичноеразвитие серии «Юникс на одной дискете». Как же, помню такие проекты и даже сам в них отмечался когда-то из-за любви к изящным вещицам. Но все дело в балансе, верно?
Ха, коммент мгновенно ушел в минус. Ох, это все из-за упоминания FreeBSD в теме для серьезных админов Linux? :)
Ха, коммент мгновенно ушел в минус. Ох, это все из-за упоминания FreeBSD в теме для серьезных админов Linux? :)
Они возможно не пробовали фряху) и переучиваться не желают
UFO just landed and posted this here
Да-да, а самый известный проект таких малюток назывался PicoBSD. Даже был написан скрипт, который собирал такую дискетку автоматически man picobsd(1), а исполняемый файл собирался при помощи crunchgen. Были времена :)
Немного из другой оперы, но была ещё прекрасная дискета с QNX, с гуями, браузером, и драйверами (модема или сетевой карты).
Авторы дистрибутива сделали свою собственную надстройку над iptables под названием «Alpine Wall». И она не висит постоянно отдельным процессом в системе;
Ну вот, и тут начались дистрибо-специфичные костыли.
ИМХО минимальная установка Арча решит все заявленные проблемы.
Это опциональный пакет, для тех, кому не хочется определяться с правилами iptables.
Может мне кто-нибудь объяснить как можно не любить логичный, лаконичный и простой как табуретка iptables, и хотеть пользоваться чем-то другим вместо него?
Из iptables торчит много специфики обработки пакетов, которую люди могут бояться — опасаясь что-либо сломать, им нравится просто сказать «открой порт tcp/NN» и топать дальше.
Не правда, не торчит. В простейших случаях ему можно сказать "открой порт tcp/NN" и закрой всё остальное, а если вы про цепочки обработки пакетов — ну… Как работает input output и forward надо знать в любом случае, а остальное в простейших случаях знать необязательно, и больше того — остального не видно, если не лезть специально в доки.
Ну чуть-чуть торчит, вроде:
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
против:
firewall-cmd --add-service http
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
против:
firewall-cmd --add-service http
Ну и что там торчит, кроме input chain и connection state, который не то что бы строго обязателен в простейшем случае?
Не знаю, видимо я «с рождения» микротиком по голове ударенный. Не люблю слепые методы, как второй.
Не знаю, видимо я «с рождения» микротиком по голове ударенный. Не люблю слепые методы, как второй.
Я так-же про ipchains в свое время думал.
У Дебиана есть Debootstrap, из коробки он минимальнее Арча.
Ну и Арч на сервере — странно, если честно.
Арч на проде — странно, просто на сервере — нормально. Но обычно, когда речь идет о проде и LTS, вариантов совсем немного: RHEL, CentOS или SLES. Может быть еще что-то еще, типа Дебиана, но я не встречал.
А что странного? Репозиторий у себя заморозь на тот день, когда инсталлился, и раскатывайся с него какое-то время. Набежит апдейтов — обновил репо и потом через Ansible например все машины обновил. Так без проблем все живет у нас, например. На проде тоже. Арч чем чаще обновляешь — тем он стабильнее, условно говоря (меньше в будущем всплывет проблем при обновлении).
UFO just landed and posted this here
+1 за debootstrap и не морочить себе голову экзотическими дистрибутивами.
Правда, debootstrap по умолчанию поставит systemd, но есть способ заставить его использовать sysvinit.
Правда, debootstrap по умолчанию поставит systemd, но есть способ заставить его использовать sysvinit.
del
Вообще alpine использует не glibc, а musl-libc. Имеется небольшая несовместимость с glibc — иногда некоторый софт не собирается или не работает (падает).
Разработчики дистра такой софт патчат. Но если Вам нужно самим собрать свежую версию чего-либо из исходников, то можно напороться на проблемы.
Разработчики дистра такой софт патчат. Но если Вам нужно самим собрать свежую версию чего-либо из исходников, то можно напороться на проблемы.
Да, это входит в ту самую упомянутую «неидеальность». Если задумали собирать и развертывать нечто специфическое — придется быть готовым к приключениям.
Единственную проблему, которую так и не смог победить в контейнерах с alpine это oracle-instantclient и php-oci8. Если это нужно то лучше использовать debian
Увидел только одно преимущество — размер базовой установки. А жизнь без systemd и других не очень обязательных штук есть и в других дистрибутивах, но при этом удобнее из-за развитых сообществ и внушительных репозиториев.
UFO just landed and posted this here
А как него ставится стандартное барахло типа LAMPа? Так же через package manager можно или всё руками собирать?
UFO just landed and posted this here
Ну, с Linux у нас уже все хорошо,
Соответственно, ставится все штатным apk. Само собой, и postgresql с nginx тоже есть.
В Alpine Linux нет расширения PHP для MSSQL и не планируется.
Честно говоря, никогда не рассматривал LAMP в таком виде, в сочетании с Microsoft SQL Server.
Там был LEMP (да, MySQL тоже нужен был), но это не важно. Все контейнеры сделали на alpine, но вот с PHP пришлось остановиться на Debian.
В репо есть модуль php-mssql, вы про него?
Мне, как разработчику, философия Alpine импонирует, но докер-образы на его базе я не рискнул предлагать админам/девопсам. Если их инициатива и их основная ответственность за то, что что-то ломается или не собирается, то возражать смысла не вижу.
Вот докер продвигать смысл вижу как разработчик, но базовый образ того дистра же, что по дефолту на серверах. Чтобы максимально задействовать их знания и опыт в диагностике и решении проблем.
Вот докер продвигать смысл вижу как разработчик, но базовый образ того дистра же, что по дефолту на серверах. Чтобы максимально задействовать их знания и опыт в диагностике и решении проблем.
Скептически отношусь к любви разработчиков к докеру, но ведь можно сделать ход конем — и поставить Alpine на сервере! А если серьезно — конечно все зависит от наличия реального выигрыша, и готовности такое решение сопровождать.
Нет, ну alpine на сервере это совсем не серьезно. Тут очень много причин, почему это довольно рискованная затея.
А вот для докера и правда очень удобно. Конечно, зависит в первую очередь от приложений, назначения образа. Тянуть 500+МБ не всегда хочется, и не всегда удобно.
К примеру, в докере могут храниться вспомогательные скрипты (не сильно требовательные к окружению) которые периодически будут запускаться в кластере. Для небольших С/Go/Rust/… приложений я бы также выбрал alpine, если нет желания собирать from scratch.
А вот для докера и правда очень удобно. Конечно, зависит в первую очередь от приложений, назначения образа. Тянуть 500+МБ не всегда хочется, и не всегда удобно.
К примеру, в докере могут храниться вспомогательные скрипты (не сильно требовательные к окружению) которые периодически будут запускаться в кластере. Для небольших С/Go/Rust/… приложений я бы также выбрал alpine, если нет желания собирать from scratch.
Без иронии — подскажите минусы использования в качестве полноценной ОС на сервере, чтобы я не впал в фанатизм.
Собственно, вы же сами назвали основную фишку Alpine — его простота и минималистичность. Она, по совместительству, является и его «ахиллесовой пятой».
Для «контейнера/сервера одного приложения», либо для ембедда/iot-устройств — оно мегафича. Для энтерпрайз-сервера уже скорее недостаток.
Экономия нескольких гигабайт места на диске в обмен на усечение пакетной базы, отсутствие LTS- поддержки, отказ от общепринятых и, соответственно, более обкатанных средств администрирования — ну, так себе идея для сколько-нибудь серьезного сервера.
Для «контейнера/сервера одного приложения», либо для ембедда/iot-устройств — оно мегафича. Для энтерпрайз-сервера уже скорее недостаток.
Экономия нескольких гигабайт места на диске в обмен на усечение пакетной базы, отсутствие LTS- поддержки, отказ от общепринятых и, соответственно, более обкатанных средств администрирования — ну, так себе идея для сколько-нибудь серьезного сервера.
По-моему, вы немного запутали ситуацию «Alpine в контейнере в продакшн» и «Alpine в качестве хост-системы в продакшн».
Второе, возможно, выглядит странно, но у меня не хватает опыта оценить плюсы/минусы такого решения
Второе, возможно, выглядит странно, но у меня не хватает опыта оценить плюсы/минусы такого решения
У меня не хватает даже для «Alpine в контейнере в продакшн». Вернее как, плюсы и минусы я понимаю, но вот оценить реальный их баланс (присвоить веса плюсам и минусам) не могу в случае если сам пишу докерфайлы FROM alpine/ubuntu/debian. С вендорскими типа nginx:alpine или своими на их базе с минимальным переписыванием базового, типа конфиги nginx свои положить — по своей инициативе делать не буду, но pull request приму. Но вот если будет сильная кастомизация с установкой пакетов или влазанием в конфиги ОС, то "не глядя" точно не приму.
Никогда не понимал в чем проблема этих 500+МБ.
Они же хранятся слоями, т.е. 10 контейнеров на одном образе это не 500*10, а просто 500МБ + то что уникально для каждого контейнера.
Они же хранятся слоями, т.е. 10 контейнеров на одном образе это не 500*10, а просто 500МБ + то что уникально для каждого контейнера.
Интересная штучка, а readonly root там можно малой кровью настроить?
$ holywar mode disable
Простите, у Вас ошибка в тексте. Вот как правильно:
$ holywar --mode-disable
А как там обстоят дела с jvm? Пару лет назад приходилось плясать с поиском и установкой «левого» пакета glibc (т.к. в оф. репозитории его нет) чтобы поставить oracle-jdk с java-приложением
openjdk есть в community repo
Что-то не находит: pkgs.alpinelinux.org/packages?name=jdk&branch=edge&repo=community (даже если бы был, как оно работает с musl-libc?)
Да и зачастую нужен оракловый jdk
Да и зачастую нужен оракловый jdk
На сервере оно наверное неплохо — а на встроенных системах Alpine очень не хватает нормального UDEV.
На сервере (вообще тут не понятно, что имеется в виду «на сервере»?) может и не хватает, но именно на встраиваемых системах — чего именно не хватает в том же mdev из busybox?
Мне нужно было подключить несколько разных устройств с FTDI-конверторами, которым китайцы не удосужились поменять VID:PID. В Убунту это решилось простым UDEV-правилом по Serial (ЕМНИП), содержавшим название устройства. В Alpine же Serial не доступен в качестве критерия — как минимум в той конфигурации что у меня была.
Один маленький недостаток Alpine — все пакеты собраны с -Os по-умолчанию.
А это примерно -20% скорости работы.
Что такое -0s?
Ключ компилятора отвечающий за тип оптимизации. Конкретно этот оптимизирует по объему.
Читать подробнее
Читать подробнее
Изначально Alpine проектировался для ембеддеда, так что это by design.
Сражаться за каждый процесс при запуске оправдано на ноуте «два ядра два гига». На современных серверах в этом мало смысла. И уж точно никто не будет ставить туда малоизученный alpine или обожаемые генту или арч. Вендоры даже слушать не станут.
Однако, в качестве основы для контейнеров alpine безусловно очень хорош.
Однако, в качестве основы для контейнеров alpine безусловно очень хорош.
Что у нас с поддержкой NAS-ов/ armv5? С ходу ненашёл…
Применили патчи ядра grsecurity/PaX (про их эффективность мнения расходятся, но все же);
В свежем релизе поддержка grsecurity (неофициальных патчей от Матиаса Краузе и самого проекта Alpine) прекращена.
Собрали пакеты с использованием режимов, снижающих вероятность эксплуатации ряда возможных уязвимостей.
Неплохо, но реализация malloc в musl менее защищена от повреждения внутренних структур данных, чем в glibc или OpenBSD libc. К сожалению, в сети практически никто об этом не пишет. Встречаются даже заблуждения об обратном.
Странное послевкусие от всего этого, сильно напоминающее — мне заплатили за пиар.
Автор продемонстрировал что «на ты с консолью», и при этом, например, мягко обошел такие вещи как, в той же убунте есть серверные дистрибутивы, которые в том числе есть и без системд.
То есть выбрал факторы удобные ему для рассказа о его дистрибутиве, и пропустил неудобные.
Автор продемонстрировал что «на ты с консолью», и при этом, например, мягко обошел такие вещи как, в той же убунте есть серверные дистрибутивы, которые в том числе есть и без системд.
То есть выбрал факторы удобные ему для рассказа о его дистрибутиве, и пропустил неудобные.
Я же не утверждаю, что это единственно верный подход, а просто рассказываю о том, что мне понравилось. И Natanael Copa меня наверняка пошлет за предложение за это платить :D И я ни в коем случае не против, если вы подскажете неудобные факторы, это очень дополнит рассказ!
Давайте условимся в том, что я никого ни в чем не обвиняю. Мне просто что-то показалось странным. А именно — Вы как автор произвели впечатление человека погруженного в тему, а вовсе не новичка который не смог пойти дальше стартовой страницы того же сайта Убунты.
А значит, если верить моей паранойе, прекрасно знаете и про ubuntu-server и про то что она существует в версии 14.04 где по умолчанию нет никакого systemd и о том что при старте этого дистрибутива количество процессов окажется на уровне описываемого вами дистрибутива.
Словом, дело то ваше конечно, но если уж сравнивать — то попробовать это сделать объективно. Подобное с подобным.
А значит, если верить моей паранойе, прекрасно знаете и про ubuntu-server и про то что она существует в версии 14.04 где по умолчанию нет никакого systemd и о том что при старте этого дистрибутива количество процессов окажется на уровне описываемого вами дистрибутива.
Словом, дело то ваше конечно, но если уж сравнивать — то попробовать это сделать объективно. Подобное с подобным.
Последняя LTS-версия убунты без systemd — 16.04. Новых пока не обещают.
Имхо, больше похоже на увлечённость/очарованность, нежели на пиар.
То есть выбрал факторы удобные ему для рассказа о его дистрибутиве, и пропустил неудобные.
Имхо, больше похоже на увлечённость/очарованность, нежели на пиар.
Странное послевкусие от всего этого, сильно напоминающее — мне заплатили за пиар.Заплатили? За пиар мини дистра со специфичным использованием? Ещё и на рус, а не англ?
В управление человечеством электроволнами с колец Юпитера верится больше, чем в это.
Ну не знаю, после танцев с настройками приложений в Alpine для себя решил, что Alpine буду использовать только для сборки контейнеров (где процессы как правило воспроизводимы и более-менее типичны), а вот сами контейнеры уже на машине с CentOS\RHEL\Ubuntu\чем-угодно-полноценным. По крайней мере пока.
В общем история про микроскоп и гвозди работает в обе стороны.
В общем история про микроскоп и гвозди работает в обе стороны.
На самом деле, alpine на сервере — это откровенно стремное решение, на мой взгляд, как минимум потому, что alpine — это большой и жирный болт на обратной совместимости.
Тот же musl и busybox содержат команды, которые не совместимые с стандартными GNU тулзами, что иногда очень сильно раздражает и приводит к багам (pycharm не мог нормально работать с docker контейнерами на alpine где-то до 2018 года, потому что у tar другие ключи, например).
В дополнение к этому, основная либа для apline — это libressl, разработчики которой тоже не поддерживают совместимость с openssl чисто из вредности.
Он вроде как неплох для контейнеров (хотя на самом деле, шаг влево, шаг в право и привет страдания), но просто ужасен для сервера.
Ну и еще добавлю, что даже не смотря на то, что многие приложения есть в альпин-версии контейнера, далеко не все компании их тестируют, что иногда приводит к крашам в alpine образах, например. Хотя на ubuntu-based образе все ок.
Тот же musl и busybox содержат команды, которые не совместимые с стандартными GNU тулзами, что иногда очень сильно раздражает и приводит к багам (pycharm не мог нормально работать с docker контейнерами на alpine где-то до 2018 года, потому что у tar другие ключи, например).
В дополнение к этому, основная либа для apline — это libressl, разработчики которой тоже не поддерживают совместимость с openssl чисто из вредности.
Он вроде как неплох для контейнеров (хотя на самом деле, шаг влево, шаг в право и привет страдания), но просто ужасен для сервера.
Ну и еще добавлю, что даже не смотря на то, что многие приложения есть в альпин-версии контейнера, далеко не все компании их тестируют, что иногда приводит к крашам в alpine образах, например. Хотя на ubuntu-based образе все ок.
Вот я и дожил до того момента, когда вижу как кто-то восхваляет простоту устройства дистрибутивов какими они были в 2000-м :)
Действительно, зачем забивать гвозди микроскопом и изобретать велосипеды?
Есть SUSE Studio для минимизации, под контейнеры есть CoreOS, Red Hat Enterprise Linux Atomic Host.
Если руками зачистить всё, что можно и нельзя, то минимальный CentOS можно ужать в ~150 Мб (но это, конечно, боль). Если до такого же уровня ужимать Альпайн, можно получить что-то типа ~40-50 Мб — что с одной стороны в 3 раза лучше, а с другой — стоят ли того всего-то 100 метров, при терабайтах СХД?
А ещё у Альпайна плохо описан процесс подключения внешних компонентов, и особенно — «third-party» модулей ядра. Надо будет как-нить в свободное время заняться…
А ещё у Альпайна плохо описан процесс подключения внешних компонентов, и особенно — «third-party» модулей ядра. Надо будет как-нить в свободное время заняться…
А кто щупал Intel ClearLinux?
А подскажите, пожалуйста, ресурс на котором описано как сделать так, чтобы Alpine Linux за минимально возможное время запускался на embedded arm? Не распаковывал и не устанавливал пакеты, каждый раз при запуске. Не генерировал при каждом запуске новый ключ ssh.
Sign up to leave a comment.
Зачем забивать гвозди микроскопом, если есть Alpine Linux?