Проблема при попытке записи на смонтированный том изнутри контейнера в качестве пользователя без полномочий root

Question

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

Это моя установка:

На хост-машине (Ubuntu 14.04):

• Создано "Zookeeper" пользователь системы (ID = 106) и группы (ID = 111).
• Создал каталог «/ var/log/zookeeper» и установил право собственности на zookeeper (например, chown zookeeper: zookeeper). Это каталог, который я буду устанавливать в мой контейнер.

Внутри контейнера (Ubuntu 14.04):

• также создал "Zookeeper" пользователь системы (ID = 102) и группа (ID = 105), который я использую в качестве пользователя, из которого для выполнения команды в ENTRYPOINT.
• Создайте тот же каталог «/ var/log/zookeeper», который будет монтирован и добавлен в zookeeper: zookeeper (хотя я не думаю, что это имеет значение).

Как только я запускаю контейнер с монтированием/var/log/zookeeper и открываю оболочку внутри контейнера в качестве пользователя zookeeper (который был создан внутри контейнера), я обнаружил, что получаю Ошибка «Разрешить отказ», если я попытаюсь создать файл в смонтированном каталоге/var/log/zookeeper. Когда я делаю «LS -l», чтобы посмотреть на собственность этого каталога (все еще внутри контейнера) выглядит примерно так:

drwxr-xr-x 2 106 111 4096 Jun 30 17:18 zookeeper 

106 и 111 в данном случае соответствует пользователю Zookeeper и идентификаторы групп хост-машины, которые, по моему мнению, лежат там, где проблема. Я попытался открыть оболочку внутри контейнера, но на этот раз я вошел как пользователь root, и описанный выше сценарий работал отлично, только этот root был владельцем созданного файла (который ожидался).

Из этого я сделал вывод, что мне нужно либо:

(а) Запустите приложение внутри моего контейнера как корневой пользователь по умолчанию вместо пользователя Zookeeper, что я создаю.

(b) Создайте пользователя и группу zookeeper как на моем хост-компьютере, так и внутри контейнера, идентификаторы которого идентичны.

Ни случай является идеальным, поскольку для (а), запуск приложения в качестве корневого пользователя может иметь потенциальные проблемы безопасности (от того, что я прочитал в любом случае), а также для (б), это может быть очень трудно получить соответствие идентификатора из-за того, что они могут быть уже приняты другими пользователями, которые были созданы (которые у вас нет никакого контроля).

Неужели кто-нибудь когда-либо имел дело с чем-то подобным? Есть ли другие возможные решения, которые я могу игнорировать?

Answer 1

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

Answer 2

Очень важно, чтобы увидеть разницу между работой и развитие контейнер. Afaik, нет реальной проблемы, если ваш контейнер Docker работает как root, даже при производстве. Однако вы никогда не захотите или не захотите установить объем производства. Если вы хотите запустить его как zookeeper, не стесняйтесь это делать.

// Edit: Чем больше я читаю, тем больше я убежден, что на самом деле может возникнуть проблема с безопасностью при запуске приложения как root, поэтому вам лучше не делать этого при производстве.

Решение, чтобы попытаться соответствовать UID и GID жизнеспособна только для малых/локального проекта - это действительно делает его непереносимым. Вы можете попытаться установить произвольное высокое значение uid и gid, а затем сделать то же самое на каждой из ваших машин-разработчиков, но это не значит, что все будет хорошо.

Т.Л., д-р: На развития выполнения chmod -R 0777 существующих файлов, а затем umask 0000 разрешениям установки файлов и каталогов, созданных позже. Затем вы можете монтировать и редактировать свои файлы, как вам угодно, независимо от того, какой пользователь создал его.