Comments 5
Вот с позиции разработчика, который не сильно разбирается в администрировании, но которому часто приходится создавать свои и запускать их и чужие образы, две самые большие проблемы заключались в согласовании uid и передаче секретов.
UID хостового пользователя в моей практике приходится использовать при запуске команд, в основном сборки приложения и разных кодогенераторов, dev tools. Чтобы артефакты, которые оказываются в файловой системе хоста и внутри проекта принадлежали пользователю (разработчику).
В runtime внутри контейнера с приложением как правило используется root, либо служебный пользователь приложения, как он определён вендором образа.
В runtime внутри контейнера с приложением как правило используется root, либо служебный пользователь приложения, как он определён вендором образа.
Ещё при отладке приложения, когда монтируешь некоторые или все каталоги проекта в контейнер и окахывается, что каталог cache или log от рута или вообще 14345 юзера. Ещё когда шаришь данные между контейнерами или котнейнером и хостом (например для бэкапа) через тома, а вендоры образа разных пользователей ставят. В общем разные кейсы есть, когда крайне желательно использовать --user как при разработке и тестировании, так и при эксплуатации. Но далеко не все даже именитые вендоры такую возможность поддерживают. Ну и в своих образах обычно после пары попыток отказываешься от идеи uid/gid agnostic образов — всё от рута или системных пользователей типа www-data.
Есть ещё мэппинг, но очень неюзабельный
Стремитесь к маленьким образам. Удаляйте временные файлы и избегайте установки ненужных пакетов.
С одной стороны да. С другой стороны это доставляет много хлопот при отладке. Благо хоть vim обычно устанавливают, а вот tcpdump, curl, snmpwalk и т. п. часто не хватает.
К вопросу временной установки нужных утилит на время отладки с последующим передеплоем по завершению относятся неоднозначно.
Кто как решает данный вопрос?
Sign up to leave a comment.
7 принципов проектирования приложений, основанных на контейнерах