systemd-филы, объясните простую вещь

Но работать-то можно в кампании, которая не является красной тряпкой Линуксоеда или нет?

как минимум в 100 раз от нужного объёма

А вот это блоатварь или нет?

vadim@aquila:~$ pacman -Qi binutils | grep Установленный
Установленный размер : 41,28 MiB
vadim@aquila:~$ pacman -Qi fasm | grep Установленный
Установленный размер : 461,48 KiB
vadim@aquila:~$ 

И в самом бинарнике (который раздут как минимум в 100 раз от нужного объёма)

Кто определил нужный объем-то? Меня вот устраивает. Исходя из KISS хотелось бы меньше, но это исключитетельно эстетические вопросы, не имеющие ровным счетом никаких практических последствий. Соотношение пользы на мегабайт вообще не в пользу моих эстетических воззрений.

спецификациях его использования

Спецификация контейнера предельно жестко определена и довольно компактна. О чем ты вообще?

в той помойке, которую в итоге генерят безголовые авторы докерфайлов и контейнеров

Не пользуйся. Я вот не пользуюсь чужими контейнерами, кроме базовых образов типа образов ОС и образов postgresql / nginx, которые нормальные.

Но работать-то можно в кампании, которая не является красной тряпкой Линуксоеда или нет?

В Redhat? Так он там и не работает.

После того, что Поттеринг огреб от «Линуксоида» у него только такой путь был. Чтобы прямо у всех пригорело.

Причем Поттеринг реально революционер и большой молодец. Он сделал то, что давно напрашивалось, но все боялись трогать.

jail это как раз контейнер, такой какой он должен быть - фс в chroot-е, опасные сисколлы запрещены, сеть ограничена нужными рамками (ещё есть виртуальная сеть, в которой можно изнутри jail-а настраивать файрволл и роутинг, но оно опционально и мне не нужно).

А в докерах устроили свалку из якобы нужных фич, которые только замусоривают систему и мешают работать в итоге. Да, в комплект к этой свалке можно принести ещё пачку костылей для нейтрализации этого бреда, чтобы всё в итоге работало относительно вменяемо (но потрачив кучу лишних вычислительных ресурсов на настройку), но зачем, когда можно изначально сделать просто?

А есть какая-то документация по этому поводу? Потому что мне тоже странно слышать слова про клетку.

Раньше мы тоже использовали chroot чтобы восстановить систему, которая не загружалась. С обычными скриптами System V это было легко и очевидно. А теперь вдруг стало нельзя.

Странная возня за безопасность, когда в chroot я могу оный systemd вообще грохнуть нахрен. Просто стерев его с диска.

Ну, например один пример который я видел - это когда для того, чтобы засунуть в контейнер один файл, который можно скачать с официального статического адреса по https, прописали копирование этого файла из другого докер-контейнера (публичного в докерхабе, кажется официального от того продукта который надо скачать), который собирался из нескольких слоёв и тратил на это заметное количество времени.

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

Вот что это за уродство например? https://github.com/MariaDB/mariadb-docker/blob/a6b360fc45b1a8fcd63b87ab69d4ce...

Ты когда-нибудь контейнер видел? Обычный морской. Каким боком каталог в файловой системе похож на контейнер?

Морские контейнеры тут ни при чём. Это троллинг такой или что?

Там не в безопасности клетки дело.

Просто команда уходит в PID 1, к systemd в хост-системе. А он вполне логично отказывается запускать сервисы хост-системы по команде из чрута. Да и сам пользователь не этого явно хотел.

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

А, понятно. Жесть конечно. Дичь. Теперь надо придумывать другую тактику восстановления.

А, понятно. Жесть конечно. Дичь. Теперь надо придумывать другую тактику восстановления.

Тактику восстановления чего? Системы? Зачем для восстановления системы запускать systemd сервисы на хосте?

В смысле «не причем»? Как ты думаешь, почему docker назван докером? Контейнер - это коробка в которую можно что-то сложить и перенести.

chroot коробкой не является

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

Да, помойку можно устроить их чего угодно. Но есть инструменты, которые прямо притягивают некомпетентных личностей с их некомпетентным кодом. И я думаю что это не спроста.

Но с докером дело не только в этом. У докера объективно плохая архитектура. Например, его штатное и общепринятое применение - давать доступ к докер-сокету юзеру, которое на самом деле означает, что юзеру выданы рут права на всю систему, только вот те, кто только начал с ним знакомиться, почему-то не видят это предупреждение большими буквами сразу на входе, а наоборот видят рекомендацию создавать себе эту дыру. Хуже того, даже не желая того явно, они могут просто скачать где-то контейнер и запустить его, думая что раз оно контейнеризовано значит наружу не вылезет. А потом окажется что в нём прописано privileged, и опять об этом не будет никаких предупреждений нигде.

И ещё: синтаксис докерфайла явно ориентирован на технологию «накачаем мусора из инета и запустим». Да, на нём можно написать описание без этого дефекта, но это, судя по всему, не его целевое применение.

Вот что это за уродство например? https://github.com/MariaDB/mariadb-docker/blob/a6b360fc45b1a8fcd63b87ab69d4ce…

И чо? Любая шелловая портянка «тру линукс админа» выглядит буквально так же. Разница только в том, что теперь эти портянки выкладывают на Docker Hub. Ты волен их не использовать, ровно так же, как был волен не копирован странное со stack overflow. Возьми любимый контейнер дистра, поставь туда mariadb и настрой как тебе нужно. Красота!

Да, помойку можно устроить их чего угодно. Но есть инструменты, которые прямо притягивают некомпетентных личностей с их некомпетентным кодом. И я думаю что это не спроста.

Hint: простые инструменты. Например, люди убивают друг-друга (да и себя) ножами регулярно, потому что это просто и удобно. Предлагаешь теперь резать овощи ложкой, потому что ножи это мейнстрим и притягивают некомпетентных личностей?

но башескрипты предпочитаю избегать

А на чём ты пишешь скрипты?

простые инструменты

…в контексте докера…

Кажется, теперь я видел всё.

…в контексте докера…

И чем докер сложный? Нужно написать один файл на простом декларативном язычке, и запустить его сборку одной простой командой. А потом ещё одной простой командой запустить контейнер.

Но он реально прост как полено.

И сложность там вся инкапсулирована. (Не то что б её было много и так.)

Пример противоположности - обсуждаемый выше bash. Инструмент выглядит простым. Но сложность его использования вся вывалена наружу на пользователя.

И чем докер сложный?

Конечно.

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

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

К гному можно вообще файлов не писать, теперь и гном простой? :)

Простота написания файла не означает простоты инструмента и понимания его внутренного устройства и особенностей работы.

Простой инструмент для (по крайней мере в части юзкейсов) того же — это bwrap.

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

chroot конечно не является, это же просто сисколл. А вот директория - вполне.

Перенести её можно так:

ssh "tar -C /path/to/source -c -z -f - ." | tar -C /path/to/destination -x -z -f -

(вместо ssh можно и другие транспорты использовать, хоть netcat если всё в защищённой локалке)

и после переноса запустить - всё будет работать, если конечно внутри не было привязки к конкретному айпи-адресу, который сменился.

Чтобы перенести уже работавший докер-контейнер, сохранив его состояние, понадобится явно не меньше команд.

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

Сколько всего? Вот референс: https://docs.docker.com/reference/dockerfile/

Там всего 18 (восемнадцать) инструкций.

К гному можно вообще файлов не писать, теперь и гном простой? :)

Гномом пользоваться сложно.

Я когда последний раз запускал гном-шел, обнаружил, что там выпилили настройку для мультимониторной конфигурации, которая для меня критична. На этом я и удалил гном.

C докером таких проблем нет. Он делает ровно то, что от него ожидаешь. И имеет ровно те крутилки, которые ожидаешь. Соответствует принципу наименьшего удивления, ака принцип минимального количества WTF per minute.

Ещё раз: (относительная) простота dockerfile не означает прототы Docker.

Ещё раз: (относительная) простота dockerfile не означает прототы Docker.

Эта мантра может повторяться бесконечно, она никак не убеждает уважаемое собрание в истинности происходящего.

C докером таких проблем нет. Он делает ровно то, что от него ожидаешь. И имеет ровно те крутилки, которые ожидаешь. Соответствует принципу наименьшего удивления, ака принцип минимального количества WTF per minute.

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

бывает надо чего-нибудь отключить из запуска

Эта мантра может повторяться бесконечно, она никак не убеждает уважаемое собрание в истинности происходящего.

Ты серьёзно не отличаешь простоты конфига от простоты инструмента, для которого этот конфиг написан? К гному вот вообще надо 0 конфигов с 0 инструкций писать — гном ещё проще по тако логике?

Ты серьёзно не отличаешь простоты конфига от простоты инструмента, для которого этот конфиг написан?

Так ты не дал никаких других предметных критериев.

P.S. bwrap, который ты привел, использует user namespaces, которые радуют нас двумя-тремя новыми дырами каждые полгода.

бывает надо чего-нибудь отключить из запуска

так в лучших традициях sysv init удаляешь симлинк :))))

Ура. Наконец-то что-то дельное, а не мерилка размерами.

Но есть инструменты, которые прямо притягивают некомпетентных личностей с их некомпетентным кодом

Любые массовые инструменты подвержены этой «проблеме». Даже язык C.

давать доступ к докер-сокету юзеру, которое на самом деле означает, что юзеру выданы рут права на всю систему

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

А потом окажется что в нём прописано privileged, и опять об этом не будет никаких предупреждений нигде.

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

синтаксис докерфайла явно ориентирован на технологию «накачаем мусора из инета и запустим».

Синтаксис Dockerfile - это десяток команд. Естественно для универсальности там будет команда, которая позволяет запускать команды shell’а.

Чтобы перенести уже работавший докер-контейнер, сохранив его состояние, понадобится явно не меньше команд.

3. docker tag, docker push и на другой машине docker run

Причем если совпадают архитектуры, то все точно сразу запустится. Без танцев с названиями интерфейсов, прописыванием ip, сетей и проблемы занятых портов другими приложениями.

бородавкой, срезанной с корпоративной жопы редхата

Как точно и лаконично :)

Так ты не дал никаких других предметных критериев.

Простота реализации. Или простота понимания принципов работы. Или количество компонентов и связей между ними. Можно кучу критериев использовать непосредственно к объекту.

bwrap, который ты привел, использует user namespaces, которые радуют нас двумя-тремя новыми дырами каждые полгода

Docker тоже их использует, правда опционально. В любом случае, речь была не о дырах или их отсутствии, а о простоте и сложности.

Простота реализации. Или простота понимания принципов работы. Или количество компонентов и связей между ними. Можно кучу критериев использовать непосредственно к объекту.

Иии? ФС стекаются через overlayfs, сепарация через неймспейсы. Можно монтировать тома. Где сложность-то?

Где сложность-то?

Основная — в containerd. Но Docker — это даже не только containerd.

Чувак, 80% повседневного функционала docker пишутся на баше в сотню строк.

https://github.com/p8952/bocker

Требует btrfs, правда. Ужасной сложности там точно нет, особенно в масштабах, описываемых firkax

Вы как-то темните. Лучше скажите сразу, что конкретно сложного в докере.

В случаях, когда его разворачивают для трёх микросервисов, nginx и базы, от него больше вреда.

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

В общем, имеет смысл выбрать стандартный инструмент, просто потому, что он стандартный. Компьютер будет работать больше, зато человек меньше. Что очень и очень правильно.

получается чудовищно переусложнённое говно,

Это есть такое. Тут какой-то изъян в психологии, последтвие грехопадения должно быть, но инженеры стремятся создать максимально сложные системы. А когда появляются инструменты, делающие сложное простым, мы просто увеличиваем свои хотелки и строим ещё более сложную хрень.

В plan9 изоляцию придумали ещё раньше. Поскольку любые ресурсы — это файлы и пространства имён у каждого пользователя своё, то изоляция ресурсов получается естественным образом. Собственно, в линуксе реализовали ту же самую мысль + построили удобные инструменты.

Что здесь неконкретного? На объём кода containerd и докеровских прибамбасов к нему посмотрите. Вот они и сложные. Containerd в первую очередь и docker с кучей разных штук, половина из которых не нужны 99% юзерам, во вторую.

Что здесь неконкретного?

Примерно всё. Сложность же понятие неабсолютное, сложно всегда кому-то и что-то. Вот, для кого докер сложный? Что именно сложно этому человеку?

На объём кода containerd и докеровских прибамбасов к нему посмотрите.

На объём бинарника уже посмотрели. Посчитаем и строчки кода:

find containerd -name "*.go" ! -name "*test.go"|xargs wc -l| tail -1
  38990 total

docker с кучей разных штук, половина из которых не нужны 99% юзерам

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

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

Мы используем k8s. Нанять адекватного девопса оказалось нелегко, как нелегко нанять адекватного разработчика. Отдельно проблемой является то, что почти никто из разрабов в этой гигалапше ямла разобраться не может, и иногда приходится решать проблемы, вызванные именно самим k8s.

Собственно, в этом как раз и заключается мой опыт: использование k8s в сравнительно небольших продуктах (бэк из пачки сервисов, nginx, база) является сомнительной идеей.

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

- Что такое: потребляет двести литров солярки в час, требует при этом 50 литров спирта для охлаждения, и режет яблоко на три части?
- Советская машина для резки яблок на четыре части.

Нанять адекватного девопса оказалось нелегко

Есть такое. Но нанять девопса, который разбирается в ваших велосипедах (предположим, вместо k8s вы б собрали что-нибудь самопальное), и вовсе невозможно.

в этой гигалапше ямла

По поводу повсеместного использования yaml у меня есть мнение, но оно нецензурное.

и иногда приходится решать проблемы, вызванные именно самим k8s.

Вы сейчас про сложности управления кубернетисом или же нагрузкой, которая на нём крутится?

Но нанять девопса, который разбирается в ваших велосипедах (предположим, вместо k8s вы б собрали что-нибудь самопальное), и вовсе невозможно.

Не спорю. Мой вопрос в том, есть ли что-то более-менее распространённое, но при этом не настолько переусложнённое. Не верю что нет.

Вы сейчас про сложности управления кубернетисом или же нагрузкой, которая на нём крутится?

Первое.

Мои доблестные коллеги пытались развернуть схему, в которой каждое окружение (около дюжины на тот момент) пилилось на три аккаунта AWS, одно для вычислительных узлов, одно для данных и ещё одно не помню зачем, сверх того был один мастер-аккаунт и аккаунт для IAM пользователей (которые уже могут принять роли в целевом аккаунте), чтобы точно гарантированно совсем-совсем изолировать всё от всего и от всех. Потом их в дурку увезли, конечно.

Вот, кто их об этом просил, кто вложил такую мысль в голову?

что-то более-менее распространённое, но при этом не настолько переусложнённое.

про nomad слышал много хорошего, но сам не использовал. Я б поискал решение в области комбинации из кубернетеса и самодисциплины. Как тупая запускалка pod’ов он какой-то концептуальной сложности не вносит, а если кто-нибудь предложит service mesh в проект затащить, ему можно будет тёмную устроить, например.

Первое.

Тут ничего не скажу. Я https://kubespray.io/#/ использовал, но в том проекте нагрузка была мизерная. А на текущем месте у нас AWS EKS, решаем проблемы деньгами.