А вы пытаетесь соблюдать FHS в контейнерах?

IMHO, ненужный перфекционизм. Контейнер - это не отдельная операционная система, в distroless контейнере может быть вообще один бинарник.

А вы пытаетесь соблюдать FHS в контейнерах?

Нет.

/home/build

Это домашний каталог пользователя build?

По теме: нет.

Не пытаюсь, а строго соблюдаю. Чтобы потом не надо было тратить кучу времени на танцы с find'ом, чтобы понять, где там что лежит.

Да и в голову никогда не приходило не соблюдать.

Nyet. Потом когда что-то надо подебажить-покрутить, короткие пути удобнее набивать. Сначала /app/ или вовсе /app.py в корне коробили, потом понял, что это не запрещено и вообще удобно.

контейнеры from scratch, с одним бинарником. Что нужно соблюдать?

Какой в этом смысл внутри контейнера?

Нет конечно.

Обхожу на почтительном расстоянии и FHS, и контейнеры.

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

С другой стороны, смысл есть в том, чтобы определить общие правила именования и в том числе монтирования хранилищ и следовать им во всех контейнерах. У меня два правила. Если у сервиса есть устойчивое общеизвестное место (например, /etc/nginx для конфигов nginx), то туда и монтирую. Если нет или это что-то связано с данными пользователя (например, сайт или база mysql), то в /mnt/www /mnt/db etc

Не пытаюсь, а строго соблюдаю. Чтобы потом не надо было тратить кучу времени на танцы с find’ом, чтобы понять, где там что лежит.

Дык файндом как раз и приходится пользоваться, когда все разбросано по FHS. А когда сложил все говно яйца в одну корзину /app, то и искать ничего не нужно, все рядом.

А ещё nodejs обезьяны не умеют в Линукс и тем более в FHS, слишком много внимания придётся уделять на ревью их «инфры» в докер образе.

Дык файндом как раз и приходится пользоваться, когда все разбросано по FHS. А когда сложил все говно яйца в одну корзину /app, то и искать ничего не нужно, все рядом.

Проблема в том, что в каждом таком /app своя школьная наколенная FHS, с которой нужно отдельно разбираться и привыкать. И так в каждой новой конторе, в каждом новом проекте. Постоянно это неимоверно бесит.

Да что за монстров вы запускаете в контейнерах? Апликуха, подмонтированные секреты, может динамические зависимости, ну конфиг в крайнем случае. Где тут наколенная FHS, ума не приложу…

Вообще связка «контейнер» и «файнд» звучит максимально фэйспалмно. Вы в 2023 году до сих пор по ssh в контейнеры ходите?

Не ясно, какую проблему решаете кроме «я не за тем хреном десять лет линупс учил, чтобы делать просто». Хлебушек, троллейбус, классика!

FHS - тупая кривая параша из 70-х годов, нахер его соблюдать

Речь о контейнерах на основе дистрибутивов вроде RHEL, Ubuntu, Alpine и тд.

Хотя даже если в контейнере один бинарник, всё равно там какая-то структура будет вроде /dev/ и подобного.

Ну вот положил ты этот один бинарник в /app, и что такого страшного случилось? Сразу же потерял его и найти её можешь?

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

Почитал тему, и по ответам возник вопрос требующий уточнения, а про какие контейнеры вопрос? Если про lxc, то к ним отношение в плане FHS, как и к хостовой системе.

А если про докер, то какая разница, что и куда положил? Какие-то надуманные опасения «потом ищи где что лежит». Зачем искать то, что ты принудительно располагаешь в указанном месте, либо в параметрах запуска контейнера, либо в инструкциях сборки.

Непонятно.

У меня NixOS. Что такое FHS?

Herbalife?

Вы в 2023 году до сих пор по ssh в контейнеры ходите?

«docker exec» и его аналоги конечно же для слабаков. Только ssh.

Бывают аппликухи, которые написаны не только golang одним бинарником. Они по зависимостям могут требовать множество модулей. Таких аппликух может быть много. Поэтому собирается отдельный слой с зависимостями, а потом поверх него контейнер с аппликухой.

Свой наколенный FHS любят городить питонисты, например. Они берут за базу какой-нибудь alpine, вкорячивают половину модулей системно, половину в /app/modules/, третью половину в /app/pyenv, а четвёртую подлкючают по хардкодному пути. И всё это вместо того, чтобы создать слой с нормально сложенными в одном месте по FHS в /usr/lib/. И потом этот слой переиспользовать, меняя только саму аппликуху.

Или какой-нибудь nginx с кастомными модулями. Тут тоже предлагаешь выносить nginx из стандартных путей в /app/ и обвешивать модулями, подменяя LD_PRELOAD?

В общем, примеров достаточно.

Если у тебя один контейнер с одним хелловордом, конечно, ты с таким не сталкивался.

Чтобы работало нормально, а не как слепленная из говна и палок параша из твоей головы.

А если у тебя не один бинарник?

слепленная из говна и палок параша

Прям Linux описал в эпоху до systemd, wayland и pipewire.

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

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

Только в твоей голове. И это вне зависимости от моего отношения к systemd.

заманаешься бегать и искать, кто куда и как положил эту библиотеку

Я ж про докер. Сборка образа и повторяема и реиспользуема, неважно что и куда ты положишь.

См. выше про слои. Когда много контейнеров, отличающихся только самой приложухой, нерационально класть библиотеки, от которых эти приложухи зависят в /app/. Нормальный вариант, собрать слой, в котором, библиотека лежит по стандартному пути. Тогда каждая приложуха будет использовать в качестве базы этот собранный образ. Меняться в итоговом контейнере будет только непосредственно само приложение. Когда поменяется версия этой библиотеки, контейнер автоматически пересоберётся уже с новым слоем. Если этого не сделать, надо искать, где лежит эта библиотека и подкладывать её руками для каждого контейнера, где она не находится по стандартному пути.

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

Есть в этом смысл?

Чаще всего нет.

Зачем? FHS сам по себе убог что ты в своём примере демонстрируешь как минимум два раза, используя /opt (который ты используешь как помойку для всего подряд, так же как другие используют корень) и /home (который совсем для другого) и не переносим, так что его использовать даже на персистентных машинах западло. А уж в контейнерах где живёт приложение и подавно.

«docker exec» и его аналоги конечно же для слабаков. Только ssh.

Суть-то не меняется. Нахрен ты в контейнер лезешь?!

Свой наколенный FHS любят городить питонисты, например. Они берут за базу какой-нибудь alpine, вкорячивают половину модулей системно, половину в /app/modules/, третью половину в /app/pyenv, а четвёртую подлкючают по хардкодному пути. И всё это вместо того, чтобы создать слой с нормально сложенными в одном месте по FHS в /usr/lib/. И потом этот слой переиспользовать, меняя только саму аппликуху.

Это каша в голове, и FHS тут как бы ортогонален. Сложи все модули в /app/modules и не делай голову, ну.

Чтобы понять, из-за чего приложение падает/работает некорректно. Чтобы найти те самые библиотеки, которые авторы контейнера распихали по углам. Чтобы отдебажить или проверить запуск с разными параметрами. И куча других чтобы. Это проще и быстрее на этапе отладки делать, чем пересобирать контейнер для каждой итерации.

А что, это уже запрещено?

Про nginx пример ты разумеется проигнорил.

Или какой-нибудь nginx с кастомными модулями. Тут тоже предлагаешь выносить nginx из стандартных путей в /app/ и обвешивать модулями, подменяя LD_PRELOAD?

Не знаю, никогда не пихал nginx в контейнер. Я больше по си, плюсам, голангу, ноде, питону и эрлангу с элексиром специализируюсь.

В общем, примеров достаточно.

Нет.

Если у тебя один контейнер с одним хелловордом, конечно, ты с таким не сталкивался.

=(

Чтобы понять, из-за чего приложение падает/работает некорректно. Чтобы найти те самые библиотеки, которые авторы контейнера распихали по углам. Чтобы отдебажить или проверить запуск с разными параметрами. И куча других чтобы. Это проще и быстрее на этапе отладки делать, чем пересобирать контейнер для каждой итерации.

Это уровень администратора локалхоста.

А что, это уже запрещено?

Да, я за такое сразу уволю!

Давай расскажи, как отладкой контейнеров занимаются администраторы нелокалхостов.

А nginx по-твоему на чём написан? Ну и куча всяких других демонов и сервисов, которые приходится в docker и кубер пихать.

Плюс /opt в том, что он пустой и там невозможно попасть в конфликт. В корне куча каталогов с именами, так и норовящими прийти в голову кому-нибудь.

А чем плох /home/build для сборки? Что значит «не переносим»?

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

Вот как раз, если у меня один бинарник, мне его проще положить в условный /usr/local/bin, а если куча артефактов сборки, то уж лучше /app, и WORKDIR туда же. И да, искать не надо, все лежит в одной куче. Чем это хуже той же кучи в /opt?

Я говорил про ситуацию, когда есть много разных библиотек, которыми пользуются разные программы. Вот есть общая либа, кладём её в /usr/lib, сохраняем образ. Потом все приложения, использующие эту библиотеку, собираем на базе этого образа. Если не использовать стандартный путь, каждый будет таскать с собой эту библиотеку. Неизбежно со временем, в разных контейнерах, эта библиотека будет разных версий.

Вот есть openssl. Куда его класть? Себе в /app/? Или же всё-таки по FHS?

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

Поставь openssl из пакетов же, ну. И ты сейчас не про типичное использование контейнеров, а типичное, как раз, то, о чем тебе тут говорят примерно все - контейнер для твоей конкретной задачи, собранного тобой твоего приложения в этом контейнере, которое будет жить там одно.

стесняюсь спросить, а если в контейнер злой хацкер назаливал шелов и прочих руткитов, как вы их находите без ssh и файнд?

Плюс /opt в том, что он пустой и там невозможно попасть в конфликт.

Как и любой другой кастомный каталог в корне.

В корне куча каталогов с именами, так и норовящими прийти в голову кому-нибудь.

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

А чем плох /home/build для сборки?

Тем что /home предназначен для домашек пользователей, а не для сборки.

Что значит «не переносим»?

Значит нет никакого FHS на куче систем включая *BSD, MacOSX, Windows и адекватных современных линуксах типа nix.