о чем речь?

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

Docker-контейнеры как среды выполнения

Первоначальный и основной вариант использования докер-контейнера: автономное приложение, которое взаимодействует с хост-системой только через некоторые сетевые порты.
Представьте себе веб-приложение: Docker-контейнер обычно содержит веб-сервер и веб-приложение, работающее, например, на порту 80 (внутри контейнера). Затем контейнер запускается на хосте путем привязки внутреннего порта 80 контейнера к порту хоста (например, 8000).
Тогда единственное взаимодействие между контейнерным приложением и хост-системой осуществляется через этот привязанный сетевой порт.

Контейнеры как среды выполнения совершенно разные:

• вместо контейнеризации приложения, контейнеризуется система сборки приложения.
  • это может быть компилятор, IDE, движок для ноутбуков, издательская система Quarto...
• цели:
  • иметь стандартную, простую в установке и совместном использовании среду
    • представьте себе сложную среду сборки с фиксированными версиями R, Python и миллионами внешних пакетов. Установка всего необходимого с правильными версиями может оказаться очень сложной и трудоемкой задачей. Публикация образа Docker, содержащего все, что уже установлено и предварительно настроено, позволяет существенно сэкономить время.
  • иметь воспроизводимую среду
    • используя его, вы можете воспроизвести некоторые результаты анализа, поскольку вы используете ту же самую контролируемую среду
    • вы также можете легко воспроизводить ошибки, что является первым шагом к их исправлению

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

Docker-контейнеры и файловая система хоста

Предположим, вы контейнеризировали IDE, например. Рстудия.
Ваша Rstudio установлена ​​и работает внутри Docker-контейнера, но ей необходимо читать и редактировать файлы в папке вашего проекта.

Для этого вы связываете папку вашего проекта (в файловой системе хоста), используя опцию docker run --volume.
Тогда ваши файлы будут доступны из Docker-контейнера.

Теперь проблема — права доступа к файлам. Предположим, что пользователь вашего хоста имеет идентификатор пользователя 1001, и предположим, что пользователь, владеющий процессом Rsudio в контейнере, является либо 0 (root), либо 1002.

Если пользователем контейнера является root, то у него не возникнет проблем с чтением ваших файлов.
Но как только вы отредактируете некоторые существующие файлы или создадите новые (например, pdf, html), эти файлы будут принадлежать корневому каталогу также в файловой системе хоста!.
Это означает, что ваш локальный пользователь хоста не сможет использовать их или удалить, поскольку они принадлежат пользователю root.

Теперь, если идентификатор пользователя контейнера — 1002, Rstudio может не иметь возможности читать ваши файлы, редактировать их или создавать новые файлы.
Даже если это возможно, установив некоторые очень разрешительные разрешения, пользователь вашего локального хоста может не иметь возможности их использовать.

Конечно, один из способов решения этой проблемы методом грубой силы — запуск с правами root как на главном компьютере, так и в Docker-контейнере. Это не всегда возможно и вызывает некоторые очевидные критические проблемы безопасности.

решение проблемы владельца файла, часть 1: параметр docker run --user

Поскольку мы не можем заранее знать, какой будет идентификатор пользователя хоста (здесь 1001), мы не можем предварительно настроить
идентификатор пользователя контейнера докеров.

docker run теперь предоставляет параметр --user, который позволяет создать псевдо пользователя с некоторым предоставленным идентификатором пользователя
во время выполнения. Например, docker run --user 1001... создаст докер-контейнер, работающий с процессами
принадлежит пользователю с идентификатором пользователя 1001.

Так что же мы еще обсуждаем этот вопрос? Разве это не решено?

Вот некоторые особенности этого динамически создаваемого пользователя:

• это псевдопользователь
• у него нет домашнего каталога (/home/xxx)
• он не отображается в /etc/passwd
• невозможно предварительно настроить, например. с профилем bash, некоторыми переменными окружения, настройками приложения по умолчанию и т. д.

Мы можем обойти эти проблемы, но это может быть утомительно и неприятно.
Чего нам действительно хотелось бы, так это предварительно настроить пользователя Docker-контейнера и иметь возможность динамически изменять его идентификатор пользователя во время время выполнения...

решение проблемы с владельцем файла, часть 2: введите docker_userid_fixer

docker_userid_fixer — это утилита с открытым исходным кодом, предназначенная для использования в качестве точки входа в Docker для устранения проблемы с идентификатором пользователя, которую я только что поднял.

Давайте посмотрим, как его использовать: вы устанавливаете его в качестве ENTRYPOINT докера, указывая, какого пользователя следует использовать, и динамически изменяете его идентификатор пользователя:

ENTRYPOINT ["/usr/local/bin/docker_userid_fixer","user1"]

Давайте будем точнее:

• целевой пользователь — это пользователь, запрошенный для docker_userid_fixer, здесь user1
• запрошенный пользователь — это пользователь, предоставленный при запуске Docker, т. е. пользователь, который (изначально) владеет первым процессом (PID 1)

Затем при создании среды выполнения контейнера есть два варианта:

• либо запрошенный идентификатор пользователя (уже) соответствует целевому идентификатору пользователя, то ничего менять не нужно
• или нет. Например, запрошенный идентификатор пользователя — 1001, а целевой идентификатор пользователя — 100. Затем docker_userid_fixer исправит идентификатор пользователя целевого пользователя user1 с 1000 на 1001 непосредственно в основном процессе контейнера.

Так что на практике это решает нашу проблему:

• если вам не нужно исправлять идентификатор пользователя контейнера, просто запустите docker обычным способом (без опции --user)
• или вы используете параметр --user, тогда, помимо запуска вашего основного процесса с запрошенным вами идентификатором пользователя, он изменит вашего предварительно настроенного пользователя на запрошенный вами идентификатор пользователя, так что ваш контейнер будет работать с вашим предполагаемым пользователем и предназначенным ID пользователя.

настройка docker_userid_fixer

Инструкции по настройке можно найти здесь.

Но все сводится к следующему:

• создайте или загрузите крошечный исполняемый файл (17 КБ)

• скопируйте его в образ Docker

• сделайте его исполняемым с root-правом setuid

• настройте его как точку входа

кровавые подробности

Я добавил несколько коротких заметок https://github.com/kforner/docker_userid_fixer#how-it-works
но я попробую перефразировать.

Суть реализации заключается в корне setuid исполняемого файла docker_userid_fixer в контейнере.
Нам нужны права root для изменения идентификатора пользователя, и этот setuid позволяет это привилегированное выполнение только для
программу docker_userid_fixer, и это на очень короткое время.

Как только идентификатор пользователя будет изменен, если это необходимо, docker_userid_fixer переключит основной процесс
запрошенному пользователю (и идентификатору пользователя!).

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