Comments 111
Есть еще вполне популярный дистрибутив Arch.
И что все так к несчастному systemd прицепились? Сколько копий уже было сломано. По своему опыту могу сказать, так как я в свое время очень много писал скриптов для init.d (реально много): определения unit'ов для systemd во много раз проще писать, отлаживать и использовать, чем эти несчастные init.d скрипты, которые легко и просто пишутся только в самой простой ситуации. Init.d скрипты легко ломаются и сложно отлаживаются. И в любой мало-мальски нетривиальной ситуации написать init.d скрипт сложнее, чем unit systemd.
1. файл конфигурации
2. переменные среды
3. ключи запуска
4. selinux
…
n. Последнее ультимативное средство конфигурации всего через 42
?
А можно пример, когда systemd init сильно лучше простого init.d скрипта. Допускаю, что весь этот огород в systemd нагородили не от хорошей жизни. Тем не менее не перевариваю сложного, systemd бесит. Не могу сказать, что очень часто туда приходится ходить, но хорошо помню случай, когда я битый час просто искал откуда вызывается служба в systemd. Alpine очень полюбил, хотя он для десктопа пока слабо пригоден, тем не менее в качестве рабочего верстака использую именно этот дистрибутив. На одноплатных компьютерах для systemd вообще нет места.
А tinycore linux для таких целей не канает? Где-то меньше десяти мегабайт весит, и кажется дефолтный вариант внутри vagrant
Ха, коммент мгновенно ушел в минус. Ох, это все из-за упоминания FreeBSD в теме для серьезных админов Linux? :)
Они возможно не пробовали фряху) и переучиваться не желают
Авторы дистрибутива сделали свою собственную надстройку над iptables под названием «Alpine Wall». И она не висит постоянно отдельным процессом в системе;
Ну вот, и тут начались дистрибо-специфичные костыли.
ИМХО минимальная установка Арча решит все заявленные проблемы.
Может мне кто-нибудь объяснить как можно не любить логичный, лаконичный и простой как табуретка iptables, и хотеть пользоваться чем-то другим вместо него?
Не правда, не торчит. В простейших случаях ему можно сказать "открой порт 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
Не знаю, видимо я «с рождения» микротиком по голове ударенный. Не люблю слепые методы, как второй.
У Дебиана есть Debootstrap, из коробки он минимальнее Арча.
Ну и Арч на сервере — странно, если честно.
Разработчики дистра такой софт патчат. Но если Вам нужно самим собрать свежую версию чего-либо из исходников, то можно напороться на проблемы.
Вот докер продвигать смысл вижу как разработчик, но базовый образ того дистра же, что по дефолту на серверах. Чтобы максимально задействовать их знания и опыт в диагностике и решении проблем.
А вот для докера и правда очень удобно. Конечно, зависит в первую очередь от приложений, назначения образа. Тянуть 500+МБ не всегда хочется, и не всегда удобно.
К примеру, в докере могут храниться вспомогательные скрипты (не сильно требовательные к окружению) которые периодически будут запускаться в кластере. Для небольших С/Go/Rust/… приложений я бы также выбрал alpine, если нет желания собирать from scratch.
Для «контейнера/сервера одного приложения», либо для ембедда/iot-устройств — оно мегафича. Для энтерпрайз-сервера уже скорее недостаток.
Экономия нескольких гигабайт места на диске в обмен на усечение пакетной базы, отсутствие LTS- поддержки, отказ от общепринятых и, соответственно, более обкатанных средств администрирования — ну, так себе идея для сколько-нибудь серьезного сервера.
Второе, возможно, выглядит странно, но у меня не хватает опыта оценить плюсы/минусы такого решения
У меня не хватает даже для «Alpine в контейнере в продакшн». Вернее как, плюсы и минусы я понимаю, но вот оценить реальный их баланс (присвоить веса плюсам и минусам) не могу в случае если сам пишу докерфайлы FROM alpine/ubuntu/debian. С вендорскими типа nginx:alpine или своими на их базе с минимальным переписыванием базового, типа конфиги nginx свои положить — по своей инициативе делать не буду, но pull request приму. Но вот если будет сильная кастомизация с установкой пакетов или влазанием в конфиги ОС, то "не глядя" точно не приму.
Они же хранятся слоями, т.е. 10 контейнеров на одном образе это не 500*10, а просто 500МБ + то что уникально для каждого контейнера.
$ holywar mode disable
Простите, у Вас ошибка в тексте. Вот как правильно:
$ holywar --mode-disable
openjdk есть в community repo
Да и зачастую нужен оракловый jdk
Один маленький недостаток Alpine — все пакеты собраны с -Os
по-умолчанию.
А это примерно -20% скорости работы.
Читать подробнее
Изначально Alpine проектировался для ембеддеда, так что это by design.
Однако, в качестве основы для контейнеров alpine безусловно очень хорош.
Собственно, актуальный список поддерживаемых архитектур:
Насколько я понимаю, под armhf подразумевается armv7, но могу ошибаться.
Применили патчи ядра grsecurity/PaX (про их эффективность мнения расходятся, но все же);
В свежем релизе поддержка grsecurity (неофициальных патчей от Матиаса Краузе и самого проекта Alpine) прекращена.
Собрали пакеты с использованием режимов, снижающих вероятность эксплуатации ряда возможных уязвимостей.
Неплохо, но реализация malloc в musl менее защищена от повреждения внутренних структур данных, чем в glibc или OpenBSD libc. К сожалению, в сети практически никто об этом не пишет. Встречаются даже заблуждения об обратном.
Автор продемонстрировал что «на ты с консолью», и при этом, например, мягко обошел такие вещи как, в той же убунте есть серверные дистрибутивы, которые в том числе есть и без системд.
То есть выбрал факторы удобные ему для рассказа о его дистрибутиве, и пропустил неудобные.
А значит, если верить моей паранойе, прекрасно знаете и про ubuntu-server и про то что она существует в версии 14.04 где по умолчанию нет никакого systemd и о том что при старте этого дистрибутива количество процессов окажется на уровне описываемого вами дистрибутива.
Словом, дело то ваше конечно, но если уж сравнивать — то попробовать это сделать объективно. Подобное с подобным.
То есть выбрал факторы удобные ему для рассказа о его дистрибутиве, и пропустил неудобные.
Имхо, больше похоже на увлечённость/очарованность, нежели на пиар.
Странное послевкусие от всего этого, сильно напоминающее — мне заплатили за пиар.Заплатили? За пиар мини дистра со специфичным использованием? Ещё и на рус, а не англ?
В управление человечеством электроволнами с колец Юпитера верится больше, чем в это.
В общем история про микроскоп и гвозди работает в обе стороны.
Тот же musl и busybox содержат команды, которые не совместимые с стандартными GNU тулзами, что иногда очень сильно раздражает и приводит к багам (pycharm не мог нормально работать с docker контейнерами на alpine где-то до 2018 года, потому что у tar другие ключи, например).
В дополнение к этому, основная либа для apline — это libressl, разработчики которой тоже не поддерживают совместимость с openssl чисто из вредности.
Он вроде как неплох для контейнеров (хотя на самом деле, шаг влево, шаг в право и привет страдания), но просто ужасен для сервера.
Ну и еще добавлю, что даже не смотря на то, что многие приложения есть в альпин-версии контейнера, далеко не все компании их тестируют, что иногда приводит к крашам в alpine образах, например. Хотя на ubuntu-based образе все ок.
Действительно, зачем забивать гвозди микроскопом и изобретать велосипеды?
Есть SUSE Studio для минимизации, под контейнеры есть CoreOS, Red Hat Enterprise Linux Atomic Host.
А ещё у Альпайна плохо описан процесс подключения внешних компонентов, и особенно — «third-party» модулей ядра. Надо будет как-нить в свободное время заняться…
Зачем забивать гвозди микроскопом, если есть Alpine Linux?