Запуск Docker контейнера с --user или suexec с переменными env? - PullRequest
0 голосов
/ 10 марта 2019

Когда дело доходит до запуска контейнеров Docker от имени пользователя без полномочий root, я видел два подхода:

  1. Используйте параметр --user при выполнении docker run.
  2. Запустите контейнер докера от имени пользователя root (не используйте --user). Вместо этого передайте некоторые переменные окружения, содержащие UID и GID. Логика добавляется в сценарий точки входа для запуска процессов в качестве этого UID.

Первый вариант самый простой и не требует создания пользователей внутри контейнера. Вам просто нужно убедиться, что для подключенных томов UID и GID существуют на хосте.

Второй вариант выглядит более гибким, но его также сложнее настроить. Насколько я понимаю, ваш контейнер изначально запускается с правами root, что позволяет вам некоторое время выполнить однократную инициализацию и настройку из сценария точки входа. Затем вы, наконец, запускаете основной процесс вашего контейнера, используя suexec или аналогичную команду. Процесс, который в конечном итоге запускается в контейнере и использует (читает и записывает) ваши тома, использует соответствующий UID: GID.

В основном вариант 2 будет выглядеть так:

  1. Построить образ докера (здесь не происходит никаких пользовательских настроек)
  2. Запустите образ от имени пользователя root, указав некоторые переменные среды, содержащие UID и GID.
  3. Entrypoint проверяет, произошла ли начальная настройка.
  4. создает пользователя внутри контейнера с явными UID и GID, переданными в
  5. Рекурсивно создавать домашние каталоги chmod мест для настройки доступа для этого пользователя
  6. Запустить основной процесс (например, какой-нибудь исполняемый файл сервера)

Является ли вариант 2 лучшим подходом? Я использую tini прямо сейчас в качестве процесса инициализации для запуска моих служб. Буду ли я использовать tini для запуска entrypoint.sh, выполнения описанных выше шагов и в конце выполнения suexec на серверном процессе?

Я всегда боролся с настройками пользователя в Docker. useradd не имеет смысла внутри Dockerfile, поскольку мне нужно, чтобы UID совпадал с чем-то значимым на хосте (содержимое томов также должно быть доступно пользователям на хосте).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...