Вот был код 1.1.1

Вылил с новыми кредами 1.1.2

В чем разница в коде между версиями?

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

А зачем тебе вообще контейнеры?

За тем же зачем и остальным)

Неконкретно :) остальным (например, мне и @slo_Oth ) контейнеры нужны для того, чтобы в прод доставлять ровно то, что прошло тестирование. А у тебя другой подход, тебе эти гарантии не важны. Поэтому и цель может быть другой

Ну например в случае дев среды не так важна сохраннасть доступа к дев базе, так как там только тестовые данные

Ты опять не про то :)
Мы про идентичность того, что исполняется в разных средах (тест и прод), а не про сохранность доступа к дев-базе.

Тут то я с вами согласен)

Мне кажется мы потеряли нить спора)

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

я в одном месте работал, никак не мог переубедить руководителя, что пароль на магизине от WiFi 8 символов, 6 из которых висит на вывеске - мягко говоря хреново)

он кстати примерно так же мне говорил про усложнение, и шапочку из фольги обещал на ДР подарить, но так и не подарил(

а еще мне друзья года 3 назад когда я им че то про базовую безопасность рассказывал, сказали что точно подарят шапку из фольги, и в стёбной форме предложили выбрать форму той самой шапки, я попросил в виде шляпы Капитана Джека Воробья, но так и не подарили... черты ваще такие😂😂😂

но только не credentials в image, потому что Image и container это разные вещи
image должен содержать ЗАВИСИМОСТИ + код приложения + в лучшем случае базовые конфиги (остальное прокидывается из куба в configmap)

cat устройств random неслабо так жрёт CPU, так что я бы такое обходил стороной.

ну заменил на /dev/zero ;)
разницы по сети никакой
мне ж для теста надо было

/dev/zero неспортивно, его сжимать будут везде, где возможно

Раз тут тёрли за образы контейнеров вчера, то как вы относитесь к варианту вообще отобрать управление образами у разработчиков? Я имею ввиду такой способ. Контейнеры без приложений собирает и обновляет инфраструктурный отдел. Код от разработчиков туда отправляется через ci/cd, разумеется, но в bind mount, а не сам контейнер.

Плюс тут в том, что при обновлении кода не нужно пересобирать весь образ. Развёртывание кода будет всяко гораздо быстрей. Как минимум один минус в том, что если разработчикам что-то понадобилось внутри контейнера, то нагрузят отдел инфраструктуры. С другой стороны, большинство разработчиков (не все), которые мне встречались ммм... весьма недалёкие ) И в этом случае в контейнеры не напихают что попало.