Я не уверен, что понимаю, docker-compose run --user — это вариант, а docker-compose.yml поддерживает ключ user (http://docs.docker.com/compose/yml/ #working95dir-entrypoint-user-hostname-domainname-mem95limit-привилегированный-restart-stdin95open-tty-cpu95shares).

Я думаю, нам нужно поддерживать разрешение переменной среды в поле user , чтобы вы могли установить его на $UID , верно? #1377

Привет. Да, расширение $UID помогло бы в этом случае. Тем не менее, опция --user для команды docker-compose up (не только для docker-compose run ) была бы полезна для запуска всего проекта от имени конкретного пользователя.

Смысл в том, чтобы разрешить указывать пользователя, не касаясь yml.

запустить весь проект как конкретный пользователь

Мне никогда не приходило в голову, что люди могут захотеть это сделать. Не могли бы вы уточнить вариант использования?

Неважно, я прокрутил вверх. Я правильно понимаю, что вы работаете в Linux? При использовании boot2docker он создает файлы с разумными разрешениями.

Интересно, есть ли способ настроить демон Docker, чтобы он делал это для каждого тома, который он монтирует.

Да, в линуксе.

Я использую compose для запуска тестов на CI путем монтирования тома хоста (да, я знаю). Без этой опции некоторые файлы создаются с "неправильным" владельцем, т.е. root:root

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

up --user может быть опасным, если в некоторых контейнерах/сервисах уже указан пользователь.

@mrzechonek Я не думаю, что изменение контейнера из-за его среды — хорошая практика.

@josephpage да, может быть. Однако расширение $UID поможет.

Практически единственное, что мне нужно, это правильные разрешения на хост-томах. Я не знаю другого способа добиться этого, кроме запуска процесса контейнера как $UID...

На самом деле я бы предпочел, чтобы эта функция присутствовала в самом Деймоне, как сказал @aanand . Или, может быть, возможность монтировать том в таком режиме (может быть, драйвер хранилища?).

@mrzechonek , вы нашли обходной путь?

Не на самом деле нет. Прямо сейчас мы делаем docker-compose run --user , а затем переименовываем/переименовываем контейнер, чтобы compose думал, что он был запущен командой up , так что stop и ps подойдет.

1377 находится в мастере и будет в версии 1.5.0, так что вы сможете делать user: $UID в docker-compose.yml . Если вам удобно использовать мастер, вы можете попробовать его сейчас, в противном случае релиз RC должен появиться в ближайшие несколько недель.

Я собираюсь закрыть эту тему, так как сама функция реализована как часть #1377.

а затем переименуйте/переименуйте контейнер, чтобы композиция думала, что он был запущен командой up

На самом деле я не первый раз слышу о необходимости этого (хотя в данном случае я думаю, что это временно). У меня есть предложение исправить это в # 2042

Спасибо, #1377 прекрасно это исправляет.

@mrzechonek Не могли бы вы уточнить, как это решило вашу проблему? У меня точно такой же вариант использования: «Я бы хотел, чтобы докеризованное приложение генерировало файлы, принадлежащие мне, а не корню»

Я попытался добавить user: $UID в контейнер web , и когда я использую docker-compose run web touch foo , я получаю следующее:

WARNING: The UID variable is not set. Defaulting to a blank string.

Файл foo создан, но по-прежнему принадлежит root .

Я использовал user: $USER , но $UID тоже работает. Я не знаю, почему ваша установка жалуется на отсутствие переменных :(

У меня точно такая же проблема, как у @michaelmior.

При использовании $USER вместо этого я получаю System error: Unable to find user Max . Что имеет смысл, потому что это хост-пользователь.

Что может привести к тому, что $UID будет недоступен во время выполнения docker-compose?

Привет, такая же проблема здесь.
Я использую Fedora 23, и переменная UID не распространяется, когда я вызываю команду env на хосте.

обходной путь:
сначала сделайте export UID на хосте, затем позвоните своему docker-compose

Было бы неплохо, если бы docker-compose просто сделал доступным $UID без необходимости его экспорта. В итоге получается шаблон.

Если UID не экспортируется, компоновка не сможет его получить, поэтому я думаю, что то, о чем вы просите, невозможно.

Таким образом, составить просто как работающее приложение не может сделать вывод о пользователе, от имени которого оно работает?

Конечно, он может прочитать переменную окружения $USER , но вы можете сделать это и из файла Compose! Если переменная не экспортирована, она не будет доступна дочерним процессам. Кажется, действительно простое решение - просто экспортировать его.

Я больше думаю, что если UID не объявлен, то исполняемый файл может посмотреть uid того, кто его запустил, и сделать его доступным как таковой.

Опять же, думая о шаблонах и шагах, которые легко пропустить. Большинству людей нужна установка, в которой единственным шагом является docker-compose up . Зачем добавлять одно крошечное переменное требование, которое 99% людей будут устанавливать абсолютно одинаковым образом.

Есть ли хороший ресурс, в котором описаны любые другие подобные ошибки между хостами Mac и Linux?

Кроме того, принуждение пользователя — это не совсем то, чего мы хотим в Linux, нам нужно поведение, которое есть у Mac, где даже при запуске от имени пользователя root в контейнере новые файлы на хост-томах имеют полезные разрешения :(

На самом деле я просто был сбит с толку тем, почему мое поведение на Mac было лучше, чем на Linux, и это не имеет прямого отношения к этой проблеме. Я начал выпуск на Dinghy , чтобы найти решения для приятного опыта в Linux.

@mrzechonek , можете ли вы поделиться тем, как вы используете директиву user: , чтобы гарантировать правильность прав доступа к файлам на хосте и в контейнере?

Я просто добавляю user: $UID в файл .yml . Это в Linux, Gentoo и Ubuntu 12.04.

@mrzechonek спасибо. Делает ли ваш контейнер какую-то магию во время выполнения? Насколько я понимаю, user: отражает инструкцию Dockerfile. Но это просто означает, что команды внутри контейнера выполняются как user: $UID . Я не могу понять, как это помогает с разрешениями тома =/.

@mrzechonek : Это другое. Мы хотим, чтобы функция контролировала пользователя, в качестве которого действует контейнер, вне хост-системы, независимо от того, кто настроен внутри самого контейнера.

Подумайте: _ " root в контейнере пишет как пользователь myuser на хосте"_.

В нашем случае практически всегда один и тот же пользователь создает контейнер и запускает его, так что проблем нет.

Однако, если вы хотите «динамически» сопоставить пользователей контейнера с хост-пользователями, я думаю, что единственный способ сделать это — поддерживать пространства имен пользователей LXC в самом демоне докеров, функция, которая не реализована (пока? насколько я знаю). знать?).

Я не думаю, что docker-compose мог бы сделать это.

Похоже, я пропустил несколько релизов: https://integratedcode.us/2015/10/13/user-namespaces-have-arrived-in-docker/

Извините, я больше не использую Docker, по крайней мере, не активно в текущем проекте.

Спасибо @mrzechonek. В конечном счете, я пытаюсь сделать то, что пытается сделать @gkop - иметь файлы, сгенерированные контейнером, на томах, смонтированных на хосте, которые принадлежат стартовому контейнеру. Вот как это работает в OS X с последней бета-версией Docker 1.12 (как?), и я бы хотел, чтобы это было и в Linux.

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

(это вместо множества уродливых хаков для сопоставления пользовательской схемы текущей работающей системы с контейнером, просто чтобы все выровнялось)

@dmitrym0 Я думаю, что под OSX вы запускаете boot2docker внутри собственной виртуализации OSX (https://github.com/mist64/xhyve/), а затем внутри этой виртуальной машины создаются контейнеры. Это означает, что на самом деле все сопоставления пользователей выполняет виртуальная машина, а не демон Docker. root контейнера по-прежнему root хоста.

$UID не установлен по умолчанию на хостах Ubuntu 16.04. Для docker-compose было бы тривиально получить идентификатор пользователя, запустившего его, и тем не менее внедрить его. Гораздо меньше стандартного кода и среды, настроенной для пользователей, создающих приложения, что имеет смысл, поскольку компоновка полностью посвящена UX докера.

+1 для docker-compose up --user или исполняющий пользователь ....

Есть решения или новости по этой проблеме?

Нет, и я открыл эту функцию для движка докеров довольно давно: https://github.com/docker/docker/issues/22415

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

Если это то, что вас интересует, я предлагаю поделиться и проголосовать за билет, который я связал.

это работает для меня: user: "1000:1000"

@jovanialferez К вашему сведению, если вы жестко закодируете это таким образом, у вас возникнут проблемы, если в проекте участвуют другие люди, у которых их UID и GID не установлены на 1000. Я думаю, что OSX начинает нумеровать обычных пользователей с 500, и любой Linux установка с несколькими пользователями приведет к тому, что UID будет больше 1000.

@jovanialferez , который будет работать только в Linux.

отмеченный. спасибо @nfm @luispabon

Я недавно перешел с Mac на Linux и только что попал под это, не совсем понимаю, как это еще не решено

Упоминание этой проблемы еще раз, чтобы ее увидели новички: https://github.com/moby/moby/issues/22415

Нам действительно нужна возможность внешнего сопоставления процессов docker с конкретным пользователем. Акцент на внешнем виде. Не выбирать UID/GID процесса в контейнере. Но сопоставьте процесс контейнера с локальным UID/GID извне.

Да, в самом деле. Назначение uid/gid текущего пользователя контейнеру работает только в Linux. Хотя похоже на проблему с докером.

Мы столкнулись с немного более эзотерической проблемой в Windows. Мы используем локальный экземпляр OrientDB, который записывает файлы в файловую систему хоста, а в Windows он, похоже, этого не делает. О... может быть, это потому, что том хоста не является блочным?

Почти год назад, когда я пытался решить эту проблему, я нашел эту тему. Поскольку в то время не было предоставлено никакого решения, я создал кучу сценариев bash для запуска вашего docker-compose.

Сейчас спустя год все то же самое. Интересно, сколько времени требуется, чтобы решить такую ​​простую проблему для программного обеспечения, такого как docker-compose, которое даже не является настоящим провайдером, а вместо этого является оболочкой.

$UID не экспортируется в Linux по умолчанию, хорошо? Это мешает нам создать универсальный docker-compose — что само по себе странно, поскольку предполагается, что эта часть программного обеспечения является интерфейсным решением, верно?

Если вы, ребята, не любите тратить время по пустякам — и я это понимаю — тогда почему бы вам просто не позволить нам выполнить случайную команду хоста перед запуском сервиса, а? Мы могли бы просто сделать что-то вроде этого:

services:
  web:
     ...
     host_command: export UID

Разве это не очевидно?

+1

Эта проблема не набрала достаточного количества лайков и +1, и я упускаю ее из виду, но она нужна и востребована многими пользователями, включая меня.

Я здесь, чтобы дать свой +1, потому что я поражен этим. В настоящее время я не хочу, чтобы мои контейнеры запускались от имени пользователя root, но я хочу, чтобы они совместно использовали том на хосте, доступный для записи моему пользователю. Это невозможно сделать, если я не назначу пользователя, и расширение будет наиболее естественным способом сделать это вместо user: 1000:1000 , потому что, как было сказано ранее, это вызовет конфликты с пользователями в другой среде. $UID, даже если он не экспортируется, оказывается лучшим решением, поскольку он основан на среде, а не на основе docker-expose.

Просто мои 2 цента. Итак, кто-нибудь нашел способ сделать это в любом случае?

@darkguy2008 — обязательно раскрутите это: https://github.com/moby/moby/issues/22415

Я подозреваю, что в самом докере потребуется функция, прежде чем compose сможет строиться поверх нее.

Я не уверен, что понимаю, docker-compose run --user — это вариант, а docker-compose.yml поддерживает ключ user (http://docs.docker.com/compose/yml/ #working95dir-entrypoint-user-hostname-domainname-mem95limit-привилегированный-restart-stdin95open-tty-cpu95shares).

Я думаю, нам нужно поддерживать разрешение переменной среды в поле user , чтобы вы могли установить его на $UID , верно? #1377

Ссылка не работает.

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

version: "3"
services:
  testapp:
    image: ubuntu:20.04
    entrypoint: /bin/bash -c "cd $PWD && touch tmp"
    user: ${CURRENT_UID:?"Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"}
    volumes:
      - $PWD:$PWD

Покажет:

ERROR: Missing mandatory value for "user" option in service "testapp": "Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"

Указав, что файл должен быть выполнен следующим образом:

CURRENT_UID=$(id -u):$(id -g) docker-compose up

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

version: "3"
services:
  testapp:
    image: ubuntu:20.04
    entrypoint: /bin/bash -c "cd $PWD && touch tmp"
    user: ${CURRENT_UID:?"Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"}
    volumes:
      - $PWD:$PWD

Покажет:

ERROR: Missing mandatory value for "user" option in service "testapp": "Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"

Указав, что файл должен быть выполнен следующим образом:

CURRENT_UID=$(id -u):$(id -g) docker-compose up

Проблема в том, что для запуска моих сервисов требуется root доступа. Например:

app-php-fpm  | [14-Jun-2020 00:15:12] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
app-php-fpm  | [14-Jun-2020 00:15:12] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
app-redis    | 1:M 14 Jun 2020 00:15:12.710 * Ready to accept connections
app-php-fpm  | [14-Jun-2020 00:15:12] ERROR: Unable to create the PID file (/run/php-fpm.pid).: Permission denied (13)
app-php-fpm  | [14-Jun-2020 00:15:12] ERROR: FPM initialization failed
app-webserver exited with code 1
app-mysql exited with code 1
app-php-fpm exited with code 78