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

создавать рандомный каталог в корне это какое-то кощунство.

Большее, чем создать рандомный контейнер?

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

А что предназначено для сборки? Я всегда программы собираю в своей домашней директории.

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

Ну к Линуксу это все отношения не имеет. Про Никс может бы прав но на его основе я не пробовал делать контейнеры. Обычно делаю на alpine или Debian. В них с FHS вроде все хорошо.

А если openssl патченый? Или любая другая библиотека, реализующая какой-нибудь базовый функционал?

Что такое типичное использование контейнеров? Хелловорд? Я уже несколько раз писал, что для запуска хелловорда на локалхосте в принципе нет разницы, что там внутри контейнера.

Мне сейчас по работе приходится работать с контейнерами в которых бывают nginx, envoy, redis, sentinel, memcached, postgres, mysql, php-fpm, различные python-приложения, golang-софт, java-софт, mono-софт. Почти везде есть кастомные зависимости, обусловленные спецификой используемого софта. Часть софта разных версий, но библиотеки одинаковые.

Некоторые заявляют(хоть я с ними и не согласен), что скоро вообще на хосте не будет крутиться ничего кроме кубера и абсолютно весь софт переедет в контейнеры.

Так что контейнер с одним единственным бинарником внутри - уже давно далеко не типичное использование. Одно приложение - один контейнер - это да. Это жёсткое правило. Но приложения бывают разные и поэтому соблюдать внутри контейнера порядок - это залог успешного и стабильного использования.

адекватных современных линуксах типа nix.

Смешно. )

Увы удобство nixOS и nixpkg слишком преувеличено людьми, которые их ни разу не использовали.

Некоторые заявляют(хоть я с ними и не согласен), что скоро вообще на хосте не будет крутиться ничего кроме кубера и абсолютно весь софт переедет в контейнеры.

Так и будет, потому что это удобно.

А nginx по-твоему на чём написан?

Мне наплевать на чем он написан (на си). Я сказал, что не умею его администрировать, что куда ему подпихивать — я не знаю. Может он вообще откажется жрать конфиги не из /etc? Вообще мне кажется обсуждение nginx в контексте топика довольно странным. Ставь стандартный дистрибутивный софт стандартными дистрибутивными методами в стандартные дистрибутивные места (в каждом дистре немного разные, привет зоопарк, даже тут FHS не помощник).

Единственная причина следовать FHS, на мой взгляд, — это если ваша компания опакечивает свой софт и распространяет его на обычные линуксы. Тут Окей, почему бы не переиспользовать. Но в целом, что пакеты, что динамическая линковка — атавизмы, они не нужны в контейнерах.

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

Отладка — это твоё локалхостовое царство, делай там что хочешь, это ТВОЙ секрет. Но с момента, как твоё чудо приходит на ревью и затем прод, любые аргументы «МНЕ так было проще дебажить» не принимаются. Никто в твой контейнер с файндом не полезет. Да и зачем, если в докерфайле и так все написано.

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

Да и в линуксе вообще не нужны, чо уж там. Пусть каждый пихает весь софт куда ему вздумается. Бинарники в /share, маны в /etc/, а конфиги в /lib/reestr/HK_LOCAL_LOCALHOST/

Но с момента, как твоё чудо приходит на ревью и затем прод, любые аргументы «МНЕ так было проще дебажить» не принимаются.

С момента, когда быдлокодер, не слышавший про FHS соберёт контейнер и отдаст его мне и до того, как я дам добро на размещение этого контейнера в артифактори, мне приходится ковыряться, что он туда напихал и наводить внутри порядок. С помощью файнда и остального. Потому что такой как ты неуч пихает туда COPY /my/helloworld/ /app/ целиком. А что там в хелловорде, какие библиотеки, какие конфиги, а может быть секреты, ключи или даже файлы баз данных, он понимать не хочет. Если бы люди были поумнее и не разводили помойку везде, куда только дотягиваются их кривые руки, мне не пришлось бы дебажить контейнеры и лазить по ним файндом. И у меня лично нет libastral.so, чтобы понять, что там «ВСЁ» написано в докерфайле, когда туда копипастится целиком директория с локалхоста быдлокодера.

Mein Gott! Каким способом докер образ, собранный на локалхосте обезьяны, может попасть в регистри? У вас права на запись в регистри открыты любой швали? А про CI/CD и reproducible builds что-то слышали?

reproducible builds

Мне Гугл не помог перевести это на русский. Воспроизводимые сборки — так в отечественном ойти говорят?

Никаким и не попадёт. Потому что как раз в CI/CD я не дам на него аппрув, если внутри не будет порядка.

Хватит уже строить из себя умного и сыпать терминами.

Ты сказал,

И у меня лично нет libastral.so, чтобы понять, что там «ВСЁ» написано в докерфайле, когда туда копипастится целиком директория с локалхоста быдлокодера.

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

Ты прекрасно понял, о чём я говорю, когда привожу в пример COPY целой директории.

Хорошо, если ты имел в виду копирование директории с CI агента, как правило я прекрасно понимаю, что находится внутри, есть ли там секреты и т.д., потому что содержимое этой директории — результат предыдущих шагов в докерфайле и ничего более.

Если ты все же имеешь в виду директорию с хоста разработчика, я повторю свой вопрос: как?

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

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

А что предназначено для сборки? Я всегда программы собираю в своей домашней директории.

Ключевое слово - в своей. По FHS ничего не предназначено.

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

Если проект не заслуживает места в корне, то это фигня какая-то, а не проект.

У нас на проде всё относящееся к проекту лежит в /companyname. Безо всяких там контейнеров.

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

У меня таких много, на разных стеках. И по докерфайлу (и репозиторию, конечно) всегда прекрасно понятно, что попадёт в образ, а что нет. /app — это как раз стандарт, который позволяет не бегать с файндом.

/app — это как раз стандарт

Дай ссылку, где подробно почитать про этот стандарт.

Это стандарт исключительно в его компании. :)

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

Что тебе надоело? Ты до сих пор не привёл ни одного аргумента, лжёшь, ошибаешься и подменяешь понятия. Смотри ответ выше.

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

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

Я не могу тебе показать настройки своих рабочих контейнеров, а на личных серверах практически не использую докер. Но вот пример хорошего, правильно оформленного Dockerfile с нормальным следованием FHS. И в нём наглядно видно, зачем это сделано и нет никакой помойки в /app/.

P.S. Не этично удалять аргументы собеседника, когда участвуешь в дискуссии, но зарепортить я буду вынужден. Если время редактирования не истекло, убери ругательства.

Ладно, давай начнём с начала, и ты конкретно напишешь аргументы «за» FHS, вдумчиво, без воды и примешивания своих личных привычек или эмоций, тогда можно говорить о чем-то конкретном. Не надо примеров правильных на твой вкус докерфайлов, я тебе таких же сотню найду с /app, это неконструктивно.

Или можем просто разойтись каждый со своим мнением (в любом случае так оно и будет, скорее всего) и просто закончить этот спор.

Я тебе подскажу простой фреймворк problem-solving-а, который всегда приводит к хорошему результату, и помогает отсеять действительно важные свойства решений от вкусовщины:

1. Какую проблему я решаю?
2. Почему А решает мою проблему лучше чем Б?