Для среды разработки мое решение для этого состоит в том, чтобы установить сценарий точки входа внутри контейнера, который запускается от имени пользователя root, изменить пользователя внутри контейнера, чтобы он соответствовал пользователю файла / каталога из монтирования тома (котороебудет вашим пользователем на хосте), а затем переключитесь на этого пользователя, чтобы запустить приложение.У меня есть пример выполнения этого вместе со сценариями, необходимыми для реализации этого в вашем собственном контейнере в моем репозитории базового образа: https://github.com/sudo-bmitch/docker-base
Там сценарий fix-perms выполняет тяжелую работу, включаякод, подобный следующему:
# update the uid
if [ -n "$opt_u" ]; then
OLD_UID=$(getent passwd "${opt_u}" | cut -f3 -d:)
NEW_UID=$(stat -c "%u" "$1")
if [ "$OLD_UID" != "$NEW_UID" ]; then
echo "Changing UID of $opt_u from $OLD_UID to $NEW_UID"
usermod -u "$NEW_UID" -o "$opt_u"
if [ -n "$opt_r" ]; then
find / -xdev -user "$OLD_UID" -exec chown -h "$opt_u" {} \;
fi
fi
fi
Этот скрипт запускается от имени root внутри контейнера при запуске.Последний шаг точек входа, которые я запускаю, будет вызывать что-то вроде:
exec gosu ${app_user} "$@"
, который запускает команду контейнера как пользователь приложения в качестве нового исполняемого файла pid 1.