утилиты в едином docker-образе

Зачем в контейнере tmux? Явно используется неверный подход к разработке в докере.

hstr

По идеологии в докер-контейнере не должно быть истории команд, но пусть кинет камень тот, кто не запускал например psql в контейнере с postgres. Так что пофиг, если надо пусть будет.

Зачем в контейнере tmux

Он, предположим, запускает тесты, и пока они работают, хочет запустить утилиту от фреймворка чтобы получить какую-то информацию. Он может вместо tmux, конечно, сделать еще один `exec -it container bash` в эмуляторе терминала.

Зачем разработчику может в контейнере понадобиться `hstr`, я надеюсь, тебе объяснять не надо.

Явно используется неверный подход
Явно

_Явно_ ты карго-сектант без собственных мозгов.

По идеологии в докер-контейнере не должно быть истории команд

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

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

На проде нужно делать контейнер как можно меньше, содержащим только нужное окружение и непосредственно приложение.

Сделать два контейнера (как и две ветки, дев и прод в пайплайнах) будет более верным решением.

В данном случае, «Явно» - это выдача сомнительных заключений псевдо-супер-экспертом на основании ничего.

Он один умный, гуру, знает «как правильно». С чего он взял-то? ЧСВ давит?

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

Высокомерие - это плохо.

Это работает в обе стороны.

Да, но это потребует разных образов, то есть другой набор пакетов, другой срез кода репозитория (зачем на проде код тестов?) и т.д. Плюс открывается возможность для ситуаций, когда код может работать по-разному в разных окружениях. В ci где образы собираются и в registry их тоже станет больше, т.е. дополнительное усложнение. Это сильно сложнее и трудозатратнее.

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

А теперь представь, что у тебя пошло горизонтальное масштабирование на несколько десятков копий инстанса. Сколько лишнего будет в итоге из-за этого?

Поэтому правильный путь: отдельно дев, отдельно прод. Если приложение не сильно огромное, то можно вообще использовать в качестве тестового стенда непосредственно ноут разработчика и, допустим, werf.

другой срез кода репозитория (зачем на проде код тестов?)

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

Это сильно сложнее и трудозатратнее.

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

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

И неправильно :) Может быть чревато проблемами в будущем.

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

Хорошей практикой считается distroless и attack surface reduction - даже шелл выпить из прод-контейнера, не говоря уже о тестах и прочем. Нет никакой сложности в пайплайне собирать разные версии для среды разработки и прода - один раз настроил и все, никаких проблем. Если есть сомнения по поводу «работает по-разному в разных окружениях» - просто в деве в прод-образ ставить весь дебаг и тесты, тоже не вижу проблемы с этим.

А почему не два образа? Но сделать так:

FROM ubuntu:22.04 as prod
...
CMD["/bin/bash"]

docker build -t prod:v1 .

FROM prod:v1 as base
RUN apt-get install -y --no-install-recommends \
tmux
...
CMD["/bin/bash"]

То есть в своей модификации используешь все слои исходного образа + добавляешь что нужно. Профит :)

P.S. на образ ubuntu не ругайтесь, просто для примера. Use alpine and busybox :)

А ну и это, можно свой registry развернуть и в него пушнуть этот образ для разработки…

Что мешает программисту запустить tmux на локалхосте, сделать alias run_test='docker exec -it container' и дёргать любые утилиты?

А вообще, вот правильный вариант, имхо.

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

вообще сейчас я делаю так: после пересоздания контейнера копирую и запускаю скрипт, который доустанавливает все эти hstr, file и т.п., правит ~/.bashrc, а ~/.bash_history симлинкает на файл в /var/log/, который у меня в этом контейнере как volume-mount.

вот думал, может быть перенести это в Dockerfile, либо может быть какой-то еще подход есть

про алиас в хостовом шеле спасибо, что напомнил

кстати для docker-compose я использую скрипт-обертку, т.к. набирать все эти -p ... -f ... -f ... -f ... --env ... муторно.

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

Раз уж тут собрались специалисты по докеру, спрошу. Как необходимо работать с контейнером в котором куча различных утилит и для их работы в безконтейнерном варианте требуется правка .bashrc. Есть какой-нибудь best practices для данного случая?

Неправильно. Запускаться софт должен локально. Контейнер это для прода или если тебе не надо его отлаживать. В правильном контейнере вообще нет ничего кроме твоего приложения и библиотек для запуска вроде libc. И, конечно, никаких tmux-ов и sh. Ты туда ещё gnome поставь и vscode запусти.

По описанию типичная XY problem. Какая цель всего этого вообще? Best practice - один контейнер - одно приложение, всё взаимодействие по сети. Нужен контейнер для дебага? Сделай свой образ и запихни туда всё, что нужно.

Какая цель всего этого вообще?

Стеганная связка OpenFOAM+liggghts гвоздями прибитая к убунте 16 что-то там.

Best practice - один контейнер - одно приложение

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

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

+1 После прочтения утилиты в едином docker-образе (комментарий) точно такая же мысль возникла.

Спасибо, значит в принципе все правильно сделал, что запихнул содержимое этого докера в lxc и использую его как виртуалку. А то мало ли я чего-то в докере недопонял.

вот думал, может быть перенести это в Dockerfile, либо может быть какой-то еще подход есть

entrypoint скрипт на bash - отличная история, если что.

Вообще, можешь глянуть вот тут: https://github.com/dmfed/devenv Это я страдал фигней и изобретал велосипед. Но может чего пригодится из этого.

https://hub.docker.com/r/linuxserver/libreoffice

У себя в Kubernetes-кластере я сделал так: есть базовый Debian docker-образ, на основе которого создаются и обновляются образы, содержащие дополнительный софт (Nginx, Node, PHP-FPM, СУБД и пр.). В этот базовый образ засунуты все базовые утилиты, которые необходимы для удаленного входа в любой контейнер - в том числе tmux. Особенно полезен tmux при запуске вспомогательных контейнеров, в контексте которых выполняются какие-то пакетные действия - типа запуска CLI-утилит фрейворка (php yii) и CLI-утилит работы с БД. При этом можно спокойно запускать команду и временно отключаться от контейнера. Ну и при случайном обрыве связи ничего страшного не происходит.

Существенный момент - монолитный деплой приложений не используется в принципе. Конкретные версии прикладной части засовываются в конечные контейнеры с помощью Init-контейнеров и хранятся в репозитории просто в виде архивов, прикрученных к busybox-образу. Init-контейнеры используются и для доставки конкретной админской конфигурации системной и прикладной частей, которая хранится в кубовых Secret-объектах и часто меняется-подправляется.

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