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

В среду, 18 сентября 2013 г., 13:07, Бенджамин Подсун
[email protected] написал :

В настоящее время, похоже, нет возможности запускать привилегированные операции за пределами
docker run -привилегированный.

Это означает, что я не могу делать то же самое в Dockerfile. Мой недавний
проблема: я бы хотел запустить fuse (для encfs) внутри контейнера. Установка
fuse уже перепутал хаки и уродливые обходные пути (см. [1] и [2]),
потому что mknod не работает / не поддерживается без привилегированного шага сборки.

Единственный обходной путь прямо сейчас - выполнить установку вручную, используя
run -privileged и создание нового «базового образа предохранителя». Это означает, что я
не может описать весь контейнер, от официального базового изображения до финиша,
в одном Dockerfile.

Поэтому я предлагаю добавить либо

• сборка докера - привилегированный
  это должно сделать то же самое, что и run -privileged, т.е. удалить все
  ограничения колпачков

или

• команда RUNP в Dockerfile
  это должно .. ну .. ЗАПУСТИТЬСЯ, но с _P_rivileges

Я попытался посмотреть исходник, но я бесполезен с go и не смог найти
к сожалению, достойная точка входа, чтобы приложить доказательство концепции. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: # 514 (комментарий) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/dotcloud/docker/issues/1916
.

Виктор ВИЕ
http://vvieux.com

На самом деле, нам, возможно, придется сделать и то, и другое - например, RUNP + потребует "-привилегированный"
флаг.

Если мы полагаемся только на RUNP (без требования "-privileged"), то мы бы
Приходится задаться вопросом, когда мы делаем сборку, «безопасна ли эта сборка?».
Если мы полагаемся только на "-privileged", мы упускаем информацию (в
Dockerfile), что «для этого действия требуются расширенные права».

Я думаю, что сочетание того и другого - самый безопасный способ.

В среду, 18 сентября 2013 г., в 4:07, Бенджамин Подсун
[email protected] написал :

В настоящее время, похоже, нет возможности запускать привилегированные операции за пределами
docker run -привилегированный.

Это означает, что я не могу делать то же самое в Dockerfile. Мой недавний
проблема: я бы хотел запустить fuse (для encfs) внутри контейнера. Установка
fuse уже перепутал хаки и уродливые обходные пути (см. [1] и [2]),
потому что mknod не работает / не поддерживается без привилегированного шага сборки.

Единственный обходной путь прямо сейчас - выполнить установку вручную, используя
run -privileged и создание нового «базового образа предохранителя». Это означает, что я
не может описать весь контейнер, от официального базового изображения до финиша,
в одном Dockerfile.

Поэтому я предлагаю добавить либо

• сборка докера - привилегированный
  это должно сделать то же самое, что и run -privileged, т.е. удалить все
  ограничения колпачков

или

• команда RUNP в Dockerfile
  это должно .. ну .. ЗАПУСТИТЬСЯ, но с _P_rivileges

Я попытался посмотреть исходник, но я бесполезен с go и не смог найти
к сожалению, достойная точка входа, чтобы приложить доказательство концепции. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: # 514 (комментарий) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/dotcloud/docker/issues/1916
.

@jpetazzo https://twitter.com/jpetazzo
Последнее сообщение в блоге: http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

Звучит разумно. Для меня эта функция (возможность создавать узлы устройств) делает или мешает создавать развертывание в Docker. Если я могу помочь (в основном тестирование, я пытался посмотреть исходный код, но пока не смог. Кажется, доступные команды в файле сборки можно найти через отражение, я добавил команду runp, которая установила config.privileged в значение true, но пока что я не могу построить и протестировать -> застрял) Я бы с удовольствием потратил немного времени.

Я бы предложил RUNP + build -privileged .

_ включает дымовые шашки, чтобы привлечь внимание @shykes , @crosbymichael_

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

Если последняя часть была нацелена на меня: конечно, почему бы и нет. Я уже возился с кодом go (я не знаком с языком, но см. Выше: я все равно пытаюсь понять, что происходит).

С парой указателей / кого-нибудь, кто может ответить на некоторые вопросы, я бы обязательно попробовал.

Меня не продают на RUNP или build -privileged.

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

В частности, мне не нравится повсеместно вводить зависимости от «привилегированного», потому что он обозначает набор возможностей, который а) очень велик и б) четко не определен или не определен. Это нормально в качестве грубого механизма для системных администраторов обхода безопасности по принципу «все или ничего» - «аварийный выход», когда стандартной среды выполнения докеров недостаточно. Это похоже на bind-mounts и custom lxc-conf.

-
@solomonstre
@getdocker

В пт, 20 сентября 2013 г., 15:18, Benjamin Podszun
[email protected] написал:

Если последняя часть была нацелена на меня: конечно, почему бы и нет. Я уже возился с кодом go (я не знаком с языком, но см. Выше: я все равно пытаюсь понять, что происходит).

С парой указателей / кого-нибудь, кто может ответить на некоторые вопросы, я бы обязательно попробовал.

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -24844868

Что ж, согласны ли вы, что должна быть возможность создать образ докера, который, например, запускает fuse?
Для этого нам понадобится mknod.

На мой взгляд, эти сборки никак не могут отличаться в зависимости от параметров: сборка будет работать (ограничения не / менее ограничены, чем сейчас) или не удастся (статус-кво). Риск разных «версий» одного и того же файла сборки практически отсутствует, верно?

Я столкнулся с этой проблемой сейчас. Чтобы создать нужный мне образ, я должен выполнить серию шагов run -privileged + шаг commit вместо build ing файла Dockerfile. В идеале было бы неплохо выразить этапы сборки образа в Dockerfile.

Это также связано с операциями mknod?
Если бы вы могли точно описать действия, требующие привилегированного режима в
Ваш случай, было бы очень полезно!
Спасибо,

Привет, @jpetazzo , из списка рассылки, вот проблема, с которой я столкнулся: https://groups.google.com/forum/#!topic/docker -user / 1pFhqlfbqQI

Я пытаюсь mount создать созданную мной файловую систему (созданную для работы с aufs и кое-что о журналировании ) внутри контейнера. Я выполняю конкретную команду mount -o loop=/dev/loop0 /db/disk-image /home/db2inst1 , где /db/disk-image был создан с помощью dd if=/dev/zero of=disk-image count=409600 а home/db2inst1 - это то место, откуда я пытаюсь запустить db2.

Если я правильно понимаю, в процессе установки вам понадобится каталог, отличный от AUFS, или, скорее, что-то, что поддерживает O_DIRECT . Если это так, Docker 0.7 должен решить проблему, поскольку он будет использовать ext4 (и снимки на уровне блоков) вместо AUFS.

+1 за это тоже.

Установка пакетов, требующих изменения настроек памяти и конфигурации ядра (например, Vertica DB, WebSphere MQ), может выполняться только в привилегированном режиме.

Давайте попробуем разделить проблемы, когда дело доходит до запуска / сборки с «привилегированными»: это может потребоваться только во время сборки, только во время выполнения через docker run или и то, и другое.

Должна быть возможность разрешить сборке делать что-то, требующее немного больше разрешений для шага (или более), если это необходимо. Мне это было нужно для проекта, и мне пришлось преобразовать половину Dockerfile в сценарий оболочки, который вызывал сборку и продолжал строить объекты в привилегированном режиме, поэтому было бы полезно иметь «привилегированную» сборку.

Однако мы не должны полностью переходить в привилегированный режим по умолчанию, чтобы мы могли использовать sysctl для изменения некоторых настроек. Это должно быть сделано через конфигурацию изображения или через аргументы командной строки, которые нужно передать в docker run .

Верно. @orikremer , у вас есть подробности о параметрах, которые Vertica DB и WebSphere MQ пытались изменить?

Если это что-то в / sys или / proc, лучшим решением может быть вместо перехода в привилегированный режим (поскольку изменения не будут сохраняться в любом случае).

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

@jpetazzo Я создал изображение пару дней
Я попытаюсь воссоздать образ с помощью Dockerfile и доложу.

Отмечая проблему №2080, поскольку она связана.

@jpetazzo начал воссоздавать изображение без привилегий. На данный момент две проблемы:

• nice в limits.conf: Vertica добавляет "dbadmin - nice 0" в /etc/security/limits.conf. При попытке переключиться на этого пользователя при работе в непривилегированном контейнере я получаю ошибку «не удалось открыть сеанс». В привилегированном переключателе контейнера пользователь работает без ошибок.
• max открытых файлов: поскольку максимальное значение, необходимое в контейнере, было выше, чем значение, установленное на хосте, мне пришлось изменить /etc/init/docker.conf на хосте и установить «limit nofile», а затем ulimit -n в контейнере. Это правильный подход?

При попытке переключиться на этого пользователя

Как происходит переключение? Я не понимаю, как -privileged поможет с переключением пользователей; Я, наверное, что-то здесь упускаю :-)

макс открытые файлы

Если я правильно понимаю, вертикальный установщик пытается установить максимальное количество открытых файлов на очень большое число, и это работает, только если Docker был запущен с таким большим числом _или_ с флагом -privileged ; Правильно?

переключение пользователя - su dbadmin завершается с этой ошибкой.
Мне удалось воспроизвести:

• вытащите новый образ (centos-6.4-x86_64) и запустите без привилегий
• useradd testuser
• отредактируйте /etc/security/limits.conf, добавьте "testuser - nice 0"
• попытка su testuser -> должна завершиться ошибкой с "не удалось открыть сеанс"
  В -привилегированном контейнере su testuser работает нормально.

max открытые файлы - правильно. установщик пытается установить число больше, чем у хоста. Только увеличив параметр hosts или запустив -privileged, это сработает.

Я только что попробовал со следующим Dockerfile:

FROM ubuntu
RUN useradd testuser
RUN echo testuser - nice 0 > /etc/security/limits.conf
CMD su testuser

И работает нормально. Какое точное название изображения вы используете?
(Я попробовал centos-6.4-x86_64 но похоже, что не могу его вытащить!)

@lukewpatterson Не могли бы вы рассказать, как у вас работает файловая система цикла внутри вашего контейнера?

@jpetazzo Запуск этого файла

FROM backjlack/centos-6.4-x86_64
RUN useradd testuser
RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
RUN su testuser
RUN echo 'test' > ~/test.txt

не удалось:

ori<strong i="10">@ubuntu</strong>:~/su_test$ sudo docker build .
Uploading context 10240 bytes
Step 1 : FROM backjlack/centos-6.4-x86_64
 ---> b1343935b9e5
Step 2 : RUN useradd testuser
 ---> Running in b41d9aa2be1b
 ---> 2ff05b54e806
Step 3 : RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
 ---> Running in e83291fafc66
 ---> 03b85baf140a
Step 4 : RUN su testuser
 ---> Running in c289f6e5f3f4
could not open session
Error build: The command [/bin/sh -c su testuser] returned a non-zero code: 1
The command [/bin/sh -c su testuser] returned a non-zero code: 1
ori<strong i="11">@ubuntu</strong>:~/su_test$

Я включил отладку для модуля PAM (добавив debug в строку pam_limits.so в /etc/pam.d/system-auth ), установил syslog , попытался su Снова /var/log/secure :

7 октября 14:12:23 8be1e7bc5590 su: pam_limits (su: session): чтение настроек из '/etc/security/limits.conf'
7 октября 14:12:23 8be1e7bc5590 su: pam_limits (su: session): process_limit: processing - хороший 0 для ПОЛЬЗОВАТЕЛЯ
7 октября 14:12:23 8be1e7bc5590 su: pam_limits (su: session): чтение настроек из '/etc/security/limits.d/90-nproc.conf'
7 октября 14:12:23 8be1e7bc5590 su: pam_limits (su: session): process_limit: обработка soft nproc 1024 для DEFAULT
7 октября 14:12:23 8be1e7bc5590 su: pam_limits (su: session): не удалось установить предел для 'nice': операция не разрешена

Затем я strace d процесс su и обнаружил, что следующий системный вызов дал сбой:

setrlimit(RLIMIT_NICE, {rlim_cur=20, rlim_max=20}) = -1 EPERM (Operation not permitted)

Это, в свою очередь, заставляет модуль pam_limits сообщить об ошибке; и это предотвращает продолжение su .
Интересно, что в Ubuntu pam_limits su по умолчанию не включен для setrlimit завершится ошибкой, но su продолжается и работает в любом случае.
Возможно, это связано с кодом аудита, я не уверен.

Итак, почему setrlimit не работает? Поскольку в контейнере отсутствует возможность sys_resource , которая требуется для повышения любого ограничения.

Думаю, я бы просто закомментировал эту директиву limits.conf .
(Кстати, добавлять что-то прямо в limits.conf - плохая практика; я думаю, он должен идти в отдельный файл в limits.d .)

Примечание: поскольку вы уже увеличили лимит на количество открытых файлов для Docker, вы также можете увеличить лимит максимального приоритета; это тоже должно работать!

Надеюсь, это поможет.

В этом Dockerfile у вас есть следующая строка:

RUN su testuser

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

@jpetazzo Спасибо за подробное описание. Я попробую поднять максимальный приоритет для Docker и посмотрю, поможет ли это.

(Кстати, добавлять что-то прямо в limits.conf - плохая практика; я думаю, он должен быть помещен в отдельный файл в limits.d.)

Согласен, но поскольку это код установщика Vertica, который помещает его туда, я пытаюсь обойти это.

@tianon То же самое происходит, если я запускаю это в интерактивной оболочке (/ bin / bash).

Приношу свои извинения, думаю, попробовать стоило.

Тем не менее, утверждение о том, что эта строка не имеет особого смысла в Dockerfile, все еще актуально. Вероятно, вы хотели чего-то большего (после того, как вы выясните проблемы с ограничениями):

RUN su testuser -c 'echo test > ~/test.txt'

@tianon , ты прав, в этом нет особого смысла. Это было просто, чтобы продемонстрировать, что сам su не работает.

Вернемся к исходному обсуждению: я считаю, что с точки зрения безопасности (и полезно!) Допустить возможности setfcap и mknod в процессе сборки (и, вероятно, при обычном выполнении контейнера как хорошо). Кто-нибудь видит проблемы, которые могут возникнуть из-за этого?

@jpetazzo Совсем наоборот! Это решило бы многие проблемы, с которыми я сталкиваюсь. Я думаю, это необходимо для людей, которые хотят запускать контейнеры Docker, которые действуют / выглядят больше как настоящая машина.

OK! Если вас это устраивает, я закрываю этот вопрос в пользу # 2191, "Включить возможности mknod и setfcap во всех контейнерах", затем :-)

Знаем ли мы о таких сценариях?

Вс, 13 октября 2013 г., в 12:22, unclejack [email protected] написал:

2191 https://github.com/dotcloud/docker/issues/2191 не решает эту проблему

проблема для всех сценариев, для которых требуется сборка докеров с привилегиями.

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -26224788
.

@jpetazzo https://twitter.com/jpetazzo
Последнее сообщение в блоге:
http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

@jpetazzo Это необходимо, если вы хотите использовать Dockerfile для создания образа операционной системы.

Я удалил свой комментарий по ошибке при его редактировании.

Посмотрите, как это будет выглядеть, если не делать все в Dockerfile:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh

build.sh

docker build -t mybuild .
docker run -i -t -privileged -cidfile mybuild.cid mybuild /root/build.sh
buildcid=`cat mybuild.cid`
rm mybuild.cid
docker commit $buildcid mybuild-final

Это просто заставляет меня работать над отсутствием runp в Dockerfile или docker build -privileged , что делает Dockerfiles бесполезным и заставляет меня писать инструмент для дублирования функций, подобных Dockerfile.

Очевидно, что Dockerfile будет намного полезнее с runp или docker build -privileged :
пример runp:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
runp /root/build.sh

docker build -privileged пример:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
run /root/build.sh

@unclejack : извините, мой вопрос был недостаточно точным!
Я имел в виду «какое именно разрешение вам нужно (помимо mknod и setfcap)?»

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

Когда дело доходит до создания образов, существует как минимум три отдельных потребности: разрешения, требуемые во время docker build , разрешения, необходимые при запуске контейнера с докером, и потребности среды выполнения для процессов во время сборки, запуска или обоих (например, sysctls и другие) .

Я думаю, что было бы полезно иметь docker build -privileged (или runp для использования привилегированного режима только для тех команд, которые действительно в нем нуждаются).

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

@jpetazzo RE: модуль PAM (я тоже устанавливаю Vertica), не могли бы вы предложить перекомпилировать докер после извлечения sys_resource из lxc.cap.drop?

Может быть, некоторые из этих ограничений можно установить через файл docker.conf?

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

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

@ramarnat @jpetazzo просто для того, чтобы замкнуть цикл установки Vertica и проблемы с хорошим уровнем,
Я попытался установить хороший предел в docker.conf, но у меня это не сработало, и мне пришлось запустить bash с правами доступа и вручную установить его.

@orikremer @jpetazzo Мне удалось запустить установку, удалив sys_resource из lxc_template.go и перекомпилировав докер. Я могу разместить здесь запрос на перенос, но я подожду, пока другие выскажут свое мнение о последствиях для безопасности удаления этого из конфигурации lxc.

@ramarnat : в зависимости от сценария некоторые люди подумают, что удаление sys_resource - это нормально; для некоторых это будет проблемой.

Можно было бы увеличить базовые ограничения до чего-то большего (дескрипторы файлов также являются проблемой для эластичного поиска). Это было бы похоже на утверждение, что «минимальная среда выполнения Docker должна уметь обрабатывать 1 000 000 файловых дескрипторов». Если Docker не может поднять предел при запуске, он выдаст предупреждение и продолжит работу (как это происходит для группы контроллеров памяти / подкачки).

Однако это не исправляет сценарий монтирования / цикла (я все еще сплю на этом).

@jpetazzo может предоставить способ переопределить жестко закодированные значения в lxc_template.go. Уже есть что-то для сценария с командной строкой -lxc_conf, но это не работает для .drop природы этих директив конфигурации lxc - я пробовал!

Что ж, это возможно, но это также хороший способ нарушить будущую совместимость между различными системами контейнеризации :-) Посмотрим, сможем ли мы найти что-нибудь лучше.

Можно ли добавить / dev / loop * в белый список в непривилегированном режиме? Я полагаю, проблема в том, что это может дать мне доступ к файлам, смонтированным в цикле другого контейнера, или даже к ...

@solomonstre
@docker

17 октября 2013 г., 18:09, Жером Петаццони
[email protected] написал:

Что ж, это возможно, но это также хороший способ нарушить будущую совместимость между различными системами контейнеризации :-) Посмотрим, сможем ли мы найти что-нибудь лучше.

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -26565782

@jpetazzo Это правда, но я думаю, что докеру понадобится стандартный способ переопределения базовой конфигурации системы контейнеризации, если это разрешено - я думаю, вернемся к привилегированному рассмотрению сборки!

@solomonstre Дело в том, что должен быть способ разрешить сборку docker build в привилегированном режиме. Разрешение доступа к / dev / loop * не поможет мне в моем конкретном случае использования.

@solomonstre : белый список / dev / loop - это, IMHO, большой

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

1. docker build -privileged
   Удобно, но проводит грань между «обычными сборками» и «привилегированными сборками». Если у вас есть очень полезный образ, для которого требуется привилегированный сборщик, будет сложно создать его на общедоступных сборщиках. Например, если кто-то запускает службу для автоматизации сборок, он, вероятно, не будет предлагать привилегированные сборки (или им придется использовать дополнительные меры безопасности).
2. Немного ослабьте разрешения в конструкторе
   Это означает (по крайней мере) включение cap_sysadmin (это заставляет меня немного вздрогнуть) и, возможно, предоставление одного или двух устройств петли каждому разработчику. Это ограничит общее количество параллельных сборщиков; но это не имеет большого значения, поскольку сборки должны быть быстрыми и, что более важно, активными процессами. IE, если у вас есть 50 параллельных сборок, если у вас нет машины с отличной подсистемой ввода-вывода, эти сборки не будут прогрессировать.
3. Оберните сборку другим уровнем виртуализации / изоляции.
   Вместо того, чтобы запускать сборку прямо в Docker, запустите что-нибудь вроде QEMU-in -Docker или UML-in-Docker. Это отличное решение с точки зрения разработчика Docker, так как не требует дополнительной работы; это плохое решение с точки зрения пользователя DOcker, поскольку оно означает работу с другим уровнем сложности.

Интересно, может ли правильным решением было бы разрешить docker build -privileged`, и в то же время подумать о хуках, которые позволили бы прозрачную реализацию варианта 3. Предположим, я «поставщик сборки докеров»: если кто-то запрашивает привилегированную сборку, все, что мне нужно сделать, это вставить что-нибудь где-нибудь, чтобы запустить процесс сборки в изолированной среде (QEMU и UML - очевидные кандидаты, но другие тоже могут работать; они просто удобные примеры).

Что вы ребята думаете?

@backjlack , могу я спросить, как вы используете этот контейнер после его
бывает когда вы "докер запускаете" именно его, что это за приложение? Просто
пытаясь понять варианты использования для этого.

Пт, 18 октября 2013 г., 9:59, Жером Петаццони
[email protected] написал :

@solomonstre https://github.com/solomonstre : белый список / dev / loop есть,
ИМХО, большое нет-нет, потому что с веткой DM он давал бы чтение / запись
доступ ко всему (поскольку по умолчанию ветка DM использует
петлевые устройства для хранения пулов).

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

1. docker build -privileged Удобно, но проводит черту между
   «нормальные сборки» и «привилегированные сборки». Если у вас очень
   полезный образ, требующий привилегированного строителя, будет сложно
   строить на общественных строителях. Например, если кто-то запускает сервис для автоматизации
   сборки, они, вероятно, не будут предлагать привилегированные сборки (или у них будут
   использовать дополнительные меры безопасности).
2. Немного ослабьте разрешения в конструкторе Это означает (по крайней мере)
   включение cap_sysadmin (это заставляет меня немного дрожать параноика) и, возможно,
   предоставление одного или двух петлевых устройств каждому строителю. Это ограничило бы общую
   количество параллельно работающих строителей; но это не имеет большого значения, так как
   сборки должны быть быстрыми и, что более важно, активными процессами.
   IE, если у вас параллельно запущено 50 сборок, если у вас нет машины
   с подсистемой ввода-вывода отличной работы эти сборки не будут прогрессировать.
3. Оберните сборку другим уровнем виртуализации / изоляции.
   Вместо того, чтобы запускать сборку прямо в Docker, запустите что-то вроде
   QEMU-in -Docker или UML-in-Docker. Это крутое решение от Docker
   точка зрения разработчика, поскольку это означает отсутствие дополнительной работы; это плохой
   решение с точки зрения пользователя DOcker, поскольку оно означает работу с
   еще один уровень сложности.

Интересно, может ли правильным решением было бы разрешить сборку докеров с привилегиями »,
и в то же время подумайте о крючках, которые позволят прозрачно
реализация варианта 3. Предположим, я «провайдер сборки докеров»: если
кто-то запрашивает привилегированную сборку, все, что мне нужно сделать, это вставить
что-то где-то для запуска процесса сборки в изолированной
окружение (QEMU и UML - очевидные кандидаты, но другие могут работать
тоже; это просто удобные примеры).

Что вы ребята думаете?

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -26612009
.

+1 - Я хотел бы увидеть возможности mknode для установки fuse (для установки ведер S3) или возможность выполнять привилегированные запуски в Dockerfiles. Пока не уверен, какое решение будет лучшим.

+1. какие-нибудь обновления по этой проблеме?

+1
17 ноября 2013 г., 23:31, "yukw777" [email protected] написал:

+1. какие-нибудь обновления по этой проблеме?

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -28676216
.

Я также столкнулся с проблемой Fuse при попытке установить Java, и меня интересует решение. Я попробовал обходной путь, предложенный здесь https://gist.github.com/henrik-muehe/6155333, но он не работает для меня в докере на Raspberry Pi.

@jpetazzo : мне нравится общая стратегия реализации флага -privileged при одновременном изучении более долгосрочного решения. С этой целью я отправил запрос на перенос для реализации этой функции. Обратите внимание, что на данный момент он не реализует команду «RUNP», как обсуждалось ранее в этом потоке.

(Позвольте мне "отправить кросс-пост", так как люди могут оказаться здесь в поисках обходного пути)

Если вы на самом деле не используете файл устройства (но это всего лишь часть сценария post-inst, как в случае с пакетом fuse), вы можете сделать:

fakeroot apt-get ...

или:

dpkg-divert --local --rename --add /sbin/mknod && ln -s /bin/true /sbin/mknod`

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

Настоящая проблема в том, что «мне нужно вызвать mknod» (или более общий: мне нужны привилегированные операции, которые пока не завершаются).

@jpetazzo Это может исправить, верно? https://lwn.net/Articles/564977/ - До тех пор я бы выбрал 3), потому что изоляция доступа к устройству - это еще один уровень сложности, и им нужно где-то управлять.

Я также не уверен, что установка петли или предохранителя является необходимой функцией. Это безумие давать контейнеру в используемом пространстве права root для монтирования файловой системы, которая (плавкий предохранитель: запускается, цикл: файл образа) находится в пользовательском пространстве.

Если вам нужно смонтировать образ файловой системы или объединить fs, вы можете смонтировать его вне контейнера и использовать как монтирование тома / привязки. Хотя это может быть хорошей функцией для поддержки и управления удаленными файловыми системами в docker iself. Может быть dockerfile MOUNT/точка крепления.

@discordianfish 3) в значительной степени не решение.

# 2979 поможет с этой проблемой?

Жду разрешения и на это тоже, но не из-за mknod. Мы запускаем контейнеры centos с rpms, которые устанавливают ограничения для пользователей, использующих /etc/security/limits.d/, и в настоящее время я использую обходной путь кувалды, состоящий из:

RUN /bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/*

в верхней части моего Dockerfile. (Мы просто создаем прототип, не волнуйтесь :))

Привет @jpetazzo Я попробовал оба варианта, которые вы предложили. Я пытаюсь создать образ "oracle_xe", используя

sudo docker build - привилегированный -t oracle_xe, потому что в моем Dockerfile я хочу запустить эти 2 команды

RUN mount -o remount, размер = 3G / dev / shm
RUN mount -a

Но это не работает, я не знаю, неверен ли синтаксис, который я использовал, ошибка, которую я получаю, это
флаг предоставлен, но не определен: -privileged

Я также попробовал второй вариант - использовать RUNP, но это тоже не сработало, когда я создаю образ, он пропускает этот шаг, говоря

Пропуск Неизвестной инструкции RUNP. Я могу отправить вам файл Dockerfile, который я пытаюсь создать. Пожалуйста, помогите мне решить эту проблему.

Спасибо.

Думаю, ни RUNP, ни build --privileged не реализованы.
Если возможно, не стесняйтесь поделиться Dockerfile; это могло быть полезно так
мы можем предложить вам обходной путь "наименее худшего" :-)

В среду, 9 апреля 2014 г., в 7:44, Manoj7 [email protected] написал:

Привет, jpetazzo, я попробовал оба варианта, которые вы предложили. Я пытаюсь построить
изображение "oracle_xe" с использованием

sudo docker build - привилегированный -t oracle_xe, потому что в моем Dockerfile i
хочу запустить эти 2 команды

RUN mount -o remount, размер = 3G / dev / shm
RUN mount -a

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

Спасибо.

Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -39972199
.

@jpetazzo https://twitter.com/jpetazzo
Последнее сообщение в блоге:
http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

Привет, @jpetazzo , я бы хотел сделать «RUN sudo umount / etc / hosts» в моем Dockerfile - есть ли «наименее худший» обходной путь для этого? ;)

@jpetazzo

Dockerfile, который я использовал для создания образа oracle_xe

От *

ТЕХНИЧЕСКИЙ ОБСЛУЖИВАНИЕ * * * * * * *

ДОБАВИТЬ oracle-xe-11.2.0-1.0.x86_64.rpm.zip /appl/oracle/xe/oracle-xe-11.2.0-1.0.x86_64.rpm.zip
RUN mount -o remount, размер = 3G / dev / shm
RUN mount -a
ЗАПУСТИТЬ cd / appl / oracle / xe && распаковать oracle-xe-11.2.0-1.0.x86_64.rpm.zip
ЗАПУСТИТЬ cd / appl / oracle / xe / Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm
ЗАПУСТИТЬ cd / appl / oracle / xe && rm oracle-xe-11.2.0-1.0.x86_64.rpm.zip
ENV ORACLE_HOME /u01/app/oracle/product/11.2.0/xe
ENV ORACLE_SID XE

Первое, что я попробовал, было

sudo docker build -privileged -t oracle_xe.

Это не сработало, и я попытался использовать RUNP
RUNP mount -o remount, размер = 3G / dev / shm
Крепление РУНП -a
это тоже не сработало, эти два шага были пропущены.

@gatoravi : к сожалению, размонтировать / etc / hosts нелегко. Зачем тебе это нужно? (Я понимаю, что у вас могут быть очень веские причины, но я бы хотел услышать их, чтобы дать вам лучший обходной путь ...)

@ Bhagat7 : верно! Вопрос: вам нужен более крупный / dev / shm во время выполнения _и_ во время установки или только во время выполнения? Если это во время сборки, на каком этапе происходит сбой и как?

@jpetazzo Я хотел бы добавить новый IP-адрес в / etc / hosts как часть процесса сборки моего инструмента.
Что-то вроде echo $IP $HOST >> / etc / hosts.

Я могу сделать это нормально, если я использую docker run --privileged а затем сделаю sudo umount \etc\hosts но похоже, что я не могу зафиксировать это, используя docker commit поэтому мне нужно повторить umount step каждый раз вручную при запуске контейнера.

Я бы хотел как-нибудь сделать \etc\hosts доступным для записи и сделать его постоянным, не могу найти способ сделать это ни с docker commit ни с Dockerfile.

@jpetazzo

У меня была эта проблема

bash-4.1 # / etc / init.d / oracle-xe настроить
Укажите порт HTTP, который будет использоваться для Oracle Application Express [8080]:

Укажите порт, который будет использоваться для прослушивателя базы данных [1521]: 1521

Укажите пароль, который будет использоваться для учетных записей базы данных. Обратите внимание, что тот же
пароль будет использоваться для SYS и SYSTEM. Oracle рекомендует использовать
разные пароли для каждой учетной записи базы данных. Это можно сделать после
начальная конфигурация:
Подтвердите пароль:

Вы хотите, чтобы Oracle Database 11g Express Edition запускалась при загрузке (да / нет) [y]: y

Запуск Oracle Net Listener ... Готово
Настройка базы данных ... Готово
Запуск экземпляра Oracle Database 11g Express Edition ... Готово
Установка успешно завершена.
bash-4.1 # cd /u01/app/oracle/product/11.2.0/xe/bin
база-4.1 # sqlplus
Введите имя пользователя: система
Введите пароль: * **
Но я получаю эту ошибку
ORA-01034: ORACLE недоступен.
ORA-27101: область разделяемой памяти не существует
Linux-x86_64 Ошибка: 2: нет такого файла или каталога
ID процесса: 0
ID сеанса: 0 Серийный номер: 0
df -h внутри контейнера возвращается
Используемый размер файловой системы Доступность% Установлено на
tmpfs 64M 0 64M 0% / dev / shm

Поэтому, когда я увеличил размер tmpfs до 3G, я не получал этой ошибки. Я решил это, запустив контейнер как
sudo docker run -privileged -i -t oracle_xe / bin / bash. Я выполнил 2 команды монтирования внутри контейнера. Но я не хочу делать это таким образом, вместо этого я хочу поместить их в свой Dockerfile и собрать его.

@gatoravi : Хорошо, понял. Тогда еще два вопроса: нужны ли вам эти дополнительные хосты в / etc / hosts во время сборки или только во время запуска? А зачем тебе?

@ Bhagat7 : Извините, у меня пока нет элегантного решения для этого :-( Я бы посоветовал иметь два Dockerfile:

• первый, который выполняет все шаги (за исключением того, который требует большего / dev / shm), и определяет CMD, который будет проверять, работает ли контейнер в привилегированном режиме, монтировать больший / dev / shm и запускать специальный команда;
• второй Dockerfile для выполнения дальнейших действий (если вам также не нужен / dev / shm во время выполнения, тогда вам нужна привилегированная вещь).

@jpetazzo Мы хотели бы предоставить нашим пользователям изображение (/ container) с редактируемым / etc / hosts /, чтобы они могли создать наш код, который изменяет этот файл :) Что касается того, почему нам нужно добавить хост, я ' m не совсем уверен, если честно, мы делаем это как часть нашей установки, чтобы помочь указать определенные имена хостов на IP-адреса.

@ Bhagat7 Мне удалось запустить oracle XE в контейнере docker 0.9, используя комбинацию:

1. https://github.com/wnameless/docker-oracle-xe-11g
   а также
2. на хосте ...

sysctl -w kernel.msgmni=4096
sysctl -w kernel.msgmax=65536
sysctl -w kernel.msgmnb=65536
sysctl -w fs.file-max=6815744
echo "fs.file-max = 7000000" > /etc/sysctl.d/30-docker.conf
service procps start

@mikewaters Большое спасибо за ответ. Я думаю, вы построили Oracle XE поверх Ubuntu. Но я пытаюсь построить его на Centos.

@jpetazzo Большое спасибо за ваше предложение

Привет, народ,

Я использую google-chrome, который должен писать на /dev/shm который обычно 777, а здесь 755. Я попытался добавить конкретную конфигурацию в свой /etc/fstab но не могу запустить mout -a чтобы применить изменения к сборке. Конечно, я пробовал базовые chmod или chown но не могу этого сделать и при сборке.

Если я использую свои команды при входе в систему в режиме --privileged , все в порядке. Но мне нужно, как объяснили другие, сделать это при сборке.

Любое предложение?

Спасибо.

@tomav проблема с

Спасибо @tianon.

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

Я выполнил несколько шагов, красиво задокументированных в этой статье, о создании cryptfs для размещения контейнеров: https://launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

обратите внимание, что я _не_ пытаюсь это сделать, но на самом деле у меня есть контейнер с смонтированным cryptfs:
поэтому зашифрованная файловая система должна быть создана, смонтирована, отформатирована во время сборки через докер.

что терпит неудачу:

• когда я пытаюсь найти устройство петли:

+ losetup -f
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)

• как ни странно, тот же самый файл докеров _ иногда_ удается найти устройство цикла, затем:

+ losetup -f
+ LOOP_DEVICE=/dev/loop1
+ losetup /dev/loop1 /cryptfs/disk
+ cryptsetup luksFormat --batch-mode --key-file=/etc/cryptfs/random /dev/loop1
setpriority -18 failed: Permission denied
/dev/mapper/control: mknod failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

есть ли еще способ обойти это? (кроме перемещения шагов монтирования / форматирования диска в run )

+1 Было бы особенно полезно для окружения "докер в докере"

+1 на этом, iptables не работает в непривилегированном режиме, что приводит к сбою любых попыток настройки правил брандмауэра.

@PerilousApricot : однако обратите внимание, что даже если бы вы могли установить правило iptables в RUN , оно было бы немедленно потеряно, поскольку изображение содержит только состояние файловой системы. Он не знает о запущенных процессах, сетевых маршрутах, правилах iptables и т. Д.

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

Эндрю Мело

@PerilousApricot Понятно ! В таком случае, как насчет символической ссылки iptables на /bin/true ? Это тоже должно порадовать установщика. (Или какой-нибудь подобный трюк, чтобы обмануть установщика?)

Я пробовал это, но установщик также должен проанализировать вывод из
iptables, так что все не так просто :)

Хорошо, я знаю, что это становится хакерским, но - как насчет того, чтобы вместо этого поставить поддельный iptables ? Что сгенерирует фиктивный результат?

Я полностью понимаю, что это не здорово; а если серьезно, то в первую очередь надо исправить такой установщик :)

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

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

Эта функция обязательна, ИМХО, комбинация RUNP вместе с build-privileged была бы отличной.

Сценарий из реальной жизни / производства, с которым я столкнулся, - это образы Docker, созданные с использованием Puppet в промежуточном контейнере. В некоторых службах, требующих повышенных возможностей, возникают сбои при сборке, требующие запуска контейнера под -privileged с ENTRYPOINT или CMD которые повторно применяют марионеточный сценарий.

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

Я надеюсь, что сказанное выше имеет смысл.

@jpetazzo Я пытаюсь создать веб-сервер поверх centos6. Я застрял при настройке правил iptable через файл докеров. Это похоже на проблему @PerilousApricot .

Кстати: Я НЕ за использование таких хаков, как поддельные iptables.

@pmoust : у вас есть подробности о том, для каких операций сборки требуются повышенные привилегии? Я, вероятно, порекомендую избежать этой проблемы, и я полностью понимаю, что это может быть неудовлетворительным для вас; но, тем не менее, я был бы рад понять, какой тип установщика / сборщика может потребовать эти привилегии ...

@ passion4aix : обратите внимание, что если вы установите правила iptables в Dockerfile, они НЕ будут сохранены. Docker сохраняет только состояние файловой системы, а не маршрутизацию / фильтрацию / запущенные процессы ... Есть способы настроить правила iptables с контейнерами "sidekick". Это может быть вам интересно?

@jpetazzo Программа установки Bitrock - один из примеров. Он требует, чтобы / tmp был смонтирован как tmpfs. Возможно, вы захотите взглянуть на http://answers.bitrock.com/questions/3092/running-installer-inside-docker

@jpetazzo или любой другой установщик openstack

Я также столкнулся с аналогичной проблемой при попытке запустить TokuMX в контейнере Docker, поскольку TokuMX требует, чтобы параметр ядра transparent_hugepage был отключен.

Есть ли прогресс в этом вопросе? Ему уже больше года, и, глядя на комментарии, большинство людей используют для запуска привилегированных действий из Dockerfile.

Лично я бы не стал выбирать сборку с решением --privileged. Решение RUNP лучше, поскольку тогда вы можете запускать только некоторые действия как привилегированный пользователь, а не запускать всю установку как привилегированный. Таким образом, по крайней мере, вы должны думать о том, когда использовать RUNP, и использовать его только тогда, когда это необходимо.

Мне кажется, вопрос уже не в том, следует ли добавить эту опцию, а только тогда, когда это будет сделано. Итак, когда мы можем ожидать эту функциональность?

@diversit Их нужно было бы --privileged в командной строке позволит использовать RUNP , иначе это будет кошмаром безопасности для людей, выполняющих сборки ненадежного кода (включая DockerHub).

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

@deas : Думаю, это можно решить, выполнив VOLUME /tmp .

@PerilousApricot : не могли бы вы немного уточнить? Я не понимаю, почему любой установщик требует особых привилегий. (Да, я старый упрямый парень с Unix, это один из моих недостатков: D)

@diversit : для этого конкретного случая я думаю, что администратор машины должен отключить прозрачные огромные страницы перед сборкой. Потому что, если конструктору разрешено это делать, он будет делать это глобально (верно?) И может сломать другие контейнеры, которым может потребоваться эта функция. Вы видите, что я имею в виду? Было бы плохо, если бы сборка контейнера X сломала работающий контейнер Y ...

Всем: Я полностью понимаю, что это очень неприятно, когда Dockerfile не работает, и все, что вам нужно, это флаг --privileged / RUNP . Но если мы начнем создавать привилегированные сборки, это сломает массу вещей (например, автоматические сборки в Docker Hub!), Поэтому мы очень переживаем из-за этого. И чего бы это ни стоило, я готов исследовать все сценарии, требующие привилегированных сборок, и помочь их исправить :-) (поскольку я лично убежден, что эти установщики не работают!)

@jpetazzo Многие / большинство инструментов развертывания openstack (например, https://openstack.redhat.com/Main_Page) устанавливают правила iptables. Я хотел бы иметь возможность катить / развертывать контейнерные версии приложения, поэтому для меня важна возможность создать файл докеров и сделать это за один раз. Я знаю, что правила iptables изначально не сохраняются в процессе контейнеризации, но они сохраняются через iptables-save, поэтому простое восстановление iptables в процессе CMD приведет к перезагрузке правил. Гораздо сложнее просто «заглушить» iptables, потому что многие инструменты развертывания используют инструменты CI, такие как puppet или chef, для выполнения фактического развертывания, поэтому вам нужно как-то создать совместимую заглушку, которая в конечном итоге эмулирует все входы / выходы «настоящей» команды iptables.

Кроме того, я думаю, что будет справедливым компромиссом сказать: «Если у вас есть Dockerfile, требующий привилегированных сборок, вы теряете функции X, Y, Z».

Oracle xe не будет работать без достаточного общего пространства памяти. Все учетные записи говорят о том, что remountimg tmpfs с enuf space делает Oracle xe счастливым для запуска и завершения своей конфигурации .. (для тех, кто понимает, это шаг '/etc/init.d/oracle-xe configure', который жалуется на ограничения целевой памяти по слухам, можно обойтись за счет увеличения размера крепления)

Во время сборки
RUN размонтировать tmpfs
терпит неудачу с
umount: / proc / kcore: для размонтирования должен быть суперпользователь

дай мне РУНП или дай мне смерть .... или .... покажи мне, что можно сделать иначе :)

Мой пример неверен; @jpefazzo все еще стоит :) Мои настройки Oracle вызывали проблемы, и, похоже, нет необходимости настраивать размер tmpfs ... по крайней мере, для начальной установки.

Я сталкиваюсь с проблемой iptables в CentOS 7.0, которая разрешается только тогда, когда run ning с --privileged https://github.com/docker/docker/issues/3416

Без поддержки привилегированного строительства я не знаю, как еще решить эту проблему.

Step 24 : RUN iptables -I INPUT -p tcp --dport 80 -j ACCEPT
 ---> Running in 74ebc19b6935
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

@buley Я верю, что с добавлением security-opts в # 8299 можно будет сделать это без --privileged

@jpetazzo Я не понимаю, как использование VOLUME /tmp решает проблему установщиков Bitrock. Это может сработать для сборки, но также заставит /tmp обходить слои AUFS для всех контейнеров на основе этого образа, верно? В конце концов, кажется, что основная причина должна быть исправлена ​​в AUFS.

Вот мой вариант использования: я хочу создать среду chroot внутри контейнера докеров. Проблема в том, что debootstrap не может работать, потому что не может смонтировать процесс в chroot:
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
Если я run --privileged контейнер, он (конечно) работает ...
Я действительно очень хотел бы удалить chroot в Dockerfile (намного чище). Есть ли способ заставить его работать, не дожидаясь RUNP или build --privileged?

Большое спасибо!

+1 для привилегированных или монтажных. Потребность в автоматизации сборки glusterfs

Это влияет на мои усилия по созданию образа из установщика Bitnami Tomcat. 99% процесса установки выполняется без проблем, но когда он пытается запустить tomcat в первый раз, это не удается со следующим выводом в catalina-daemon.out:

set_caps: не удалось установить возможности
убедитесь, что ваше ядро ​​поддерживает возможности
set_caps (CAPS) не удалось для пользователя 'tomcat'
Выход из службы с возвращаемым значением 4

Я могу успешно запустить установщик Tomcat вручную в контейнере, который я создаю с помощью "--cap-add ALL". Кажется странным, что я не могу использовать «docker build» для создания образа, который я могу создать вручную, используя «docker run», а затем «docker commit». Контейнеры, которые используются в процессе сборки, должны обладать всеми функциональными возможностями контейнеров, которые вы можете создать с помощью docker run.

@gilbertpilz Они явно не могут этого сделать, чтобы гарантировать переносимость и безопасность сборки.

@ cpuguy83 - В этом нет никакого смысла. Я могу создать изображение, которое хочу, вручную, если я это сделаю:

docker run --cap-add ВСЕ .... / bin / bash
bitnami-tomcatstack-7.0.56-0-linux-x64-installer.run ...
выход
docker commit ....

Все, о чем я прошу, - это возможность использовать «docker build», чтобы делать то же самое, что я делаю здесь вручную. Я не вижу, как «гарантируются» «переносимость и безопасность», если я могу создать образ одним способом, но не другим.

Хорошо, позвольте мне дать вам Dockerfile, который монтирует / etc / passwd хоста в построитель и просто отправляет его мне.

Это может быть опасно.
Также обратите внимание, что --privileged (и --cap-add ALL) дают пользователю в контейнере полный контроль над хостом.

Разрешение этих вещей поставит под угрозу весь DockerHub.

@ cpuguy83 - Вам не нужно помещать элемент управления в Dockerfile. Вы можете добавить параметр «--cap-add» (или что-то подобное) к команде «docker build». Если мы следовали вашей логике, сценарии оболочки не должны разрешать использование команды «sudo», потому что кто-то может написать сценарий, который будет делать плохие вещи.

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

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

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

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

Вы не видите более широкой картины.

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

Тогда DockerHub определенно не должен _не_ разрешать добавлять возможности для своих сборок. Если это означает, что я не могу отправить свою сборку докеров в DockerHub, меня это устраивает.

@ cpuguy83 @tianon @jpetazzo - Когда запускается FUD, я вынужден сказать:

Разрешение этих вещей поставит под угрозу весь DockerHub.

сурово?
Реализация этой функции == TEOTWAWKI?

Конечно, DockerHub никогда не запустит docker build с запрошенным флагом --privileged .
Если не задумываться, есть как минимум два очевидных способа реализовать это:

• flag работает, только если вы также запускаете docker -d с новым флагом, например: --i-want-a-broken-security-model
• Создайте флаг времени компиляции, который включает путь кода.

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

@tamsky И тогда у нас есть ситуация, когда сборки работают в одном месте, а не в другом.
Я объясняю, почему дела обстоят именно так, а не спорю о том или ином.

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

@ cpuguy83

И тогда у нас есть ситуация, когда сборки работают в одном месте, но не работают в другом.

Представьте на мгновение, что мы волшебным образом перенесены в мир, где _политика_ другая, и некоторые сборки работают в одном месте, а не в другом ...

Почему это так важно?
Кого это волнует?

Считает ли Docker Inc, что их мантра / требование наименьшего общего знаменателя «все сборки должны работать везде» может на самом деле игнорировать реальную потребность клиентов?

В настоящее время политика экстернализирует инженерные затраты для клиентов, чтобы «заставить X встроить докер»:

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

В конце концов, если Docker будет работать на нескольких платформах, docker build НЕ будет работать одинаково во всех системах. То есть сборка контейнера Windows, контейнера Solaris или даже контейнера ARM Linux не будет такой же, как в x86-64 Linux. Контекст безопасности для них также будет отличаться в зависимости от их платформ.

Это означает, что @ cpuguy83 , мы не всегда можем предполагать, что файлы Dockerfiles останутся универсальными. Однако я согласен с тем, что нам нужно минимизировать разницу между ними. Возможно, стоит включить внимание пользователей, которым нужна эта функция, сколь бы опасной она ни была, в разговоры, которые в конечном итоге должны произойти вокруг поддержки мультиархивности / мультиплатформенности.

Сборки работают не везде, потому что, например, загружены профили брони приложений.
Также, как бы вы поступили с предварительно кэшированными контейнерами докеров, запеченными в образ?

18.11.2014 в 2:53 tamsky [email protected] написал:

@ cpuguy83

И тогда у нас есть ситуация, когда сборки работают в одном месте, но не работают в другом.

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

Почему это так важно?
Кого это волнует?

Считает ли Docker Inc, что их мантра / требование наименьшего общего знаменателя «все сборки должны работать везде» может на самом деле игнорировать реальную потребность клиентов?

В настоящее время политика экстернализирует инженерные затраты для клиентов, чтобы «заставить X встроить докер»:

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

В этой ситуации «сломан» не «установщик», а Tomcat 7. Я использую стек Tomcat от Bitnami, который интегрирует Tomcat с Apache и MySQL. Docker находится в конце цепочки поставок услуг по настройке, интеграции, тестированию и упаковке. Требование «исправить» Tomcat мешает мне воспользоваться этой цепочкой поставок. Намного проще собрать нужный образ вручную (запустить контейнер с помощью «--privileged», запустить программу установки, сделать снимок контейнера и т. Д.), Чем «исправить» Tomcat.

+1
Я не могу перенести свои роли повара в докер, потому что все они включают использование ufw для открытия портов.
добавление --privileged to build исправит это.

+1. Не могу использовать debootstrap как шаг в моих файлах Docker.

+1. Не могу использовать debootstrap как шаг в моих файлах Docker.

Казалось естественным построить мой chroot через Dockerfile / build, но возникли те же проблемы, что и @fbrusch .

FROM ubuntu:utopic
ENV HOME /root
RUN sudo apt-get update
RUN sudo apt-get install -y eatmydata
RUN for i in /usr/bin/apt*; do sudo ln -s /usr/bin/eatmydata $(basename $i); done
RUN sudo apt-get install -y debootstrap qemu-user-static binfmt-support
RUN sudo debootstrap --foreign --arch arm64 trusty ubuntu-arm64-chroot
RUN ls ubuntu-arm64-chroot
RUN sudo cp /usr/bin/qemu-aarch64-static ubuntu-arm64-chroot/usr/bin
RUN sudo cp /etc/resolv.conf ubuntu-arm64-chroot/etc
RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log

не работает с:

Step 11 : RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log
 ---> Running in 2654257e860a
I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
W: Failure trying to run:  mount -t proc proc /proc
W: See //debootstrap/debootstrap.log for details
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using DSA key ID 437D05B5
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key <[email protected]>"
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using RSA key ID C0B21F32
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2012) <[email protected]>"
mount: block device proc is write-protected, mounting read-only
mount: cannot mount block device proc read-only
 ---> de534a4e5458
Removing intermediate container 2654257e860a
Successfully built de534a4e5458

А что насчет вместо RUNP флага сборки --insecure .
Для всех команд RUN последующий контейнер будет запускаться с --add-cap=all . Это вместо привилегированного, поскольку привилегированный делает и другие вещи ...
Но на самом деле это может измениться, чтобы реализовать полные настройки privileged , если это необходимо в какой-то момент, без необходимости изменять флаг.

@ cpuguy83
Я не возражаю против использования флага, переданного в сборку докера, который позволяет использовать команды RUN или разрешать команды RUNP. Имеет значение возможность взглянуть на Dockerfile и сказать с помощью команд или чего-то внутри него, что для этого потребуется привилегированный доступ, и во время выполнения вместо перехода к шагу 10 и ошибок он бы с самого начала сделал ярлык, что Dockerfile содержит команды, требующие привилегий.

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

Было бы неплохо иметь возможность просто иметь в Dockerfile:

RUN mount --bind /dir1 /dir2

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

например

/usr/local/application/data -> /mnt/data 
/mnt/data -> HOST:/var/datasets/dataset1

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

Эта возможность делать это A -> B -> C позволяет сохранить общие контейнеры данных и обеспечивает гибкость в различных комбинациях, которые вы можете достичь с помощью --volumes-from с контейнерами приложений и данных.

Вы также можете добиться этого, создав цепочку контейнеров с --volumes-from :

GenericDataContainer -> ApplicationDataContainer -> ApplicationContainer

Это может быть правильным ответом, но вы могли бы избавиться от необходимости создавать еще один контейнер для данных приложения, если бы контейнер приложения мог выполнить монтирование привязки.

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

Ответом для моего конкретного варианта использования может быть использование подхода с тремя цепочками контейнеров или сценария инициализации, но было бы неплохо иметь возможность выполнять привязку монтирования внутри контейнера (или другие привилегированные команды) из Dockerfile. Вероятно, существуют другие варианты использования привязок, которые можно описать, которые не связаны с сопоставлением хоста с контейнером, что не может быть решено с помощью объединения контейнеров данных.

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

Вот простой пример

[root@ip-10-0-3-202 ~]# docker run --privileged -i -t --name test_priv centos:centos6 /bin/bash
[root<strong i="17">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Создайте пример монтирования привязки, также создайте пример символической ссылки

[root<strong i="6">@d1d037cb170c</strong> /]# mkdir /var/data1
[root<strong i="7">@d1d037cb170c</strong> /]# mkdir /var/data2
[root<strong i="8">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2
[root<strong i="9">@d1d037cb170c</strong> /]# ln -s /var/data1 /var/data3

Шоу-файл виден из всех 3-х директорий

[root<strong i="13">@d1d037cb170c</strong> /]# touch /var/data1/test
[root<strong i="14">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="15">@d1d037cb170c</strong> /]# ls /var/data2
test
[root<strong i="16">@d1d037cb170c</strong> /]# ls /var/data3
test

Показать /proc/mounts обновлено

[root<strong i="21">@d1d037cb170c</strong> /]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 /var/data2 ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0

Выйдите из контейнера, который его останавливает, затем начните снова

[root<strong i="25">@d1d037cb170c</strong> /]# exit
[root@ip-10-0-3-202 ~]# docker start -a -i test_priv
test_priv

/proc/mounts отсутствует крепление привязки

[root<strong i="7">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Симлинк выжил, но не привязал mount

[root<strong i="11">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="12">@d1d037cb170c</strong> /]# ls /var/data2
[root<strong i="13">@d1d037cb170c</strong> /]# ls /var/data3
test
[root<strong i="14">@d1d037cb170c</strong> /]#

Сброс привязки крепления

[root<strong i="18">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2

Вместо выхода из контейнера отсоедините его с помощью ctrl+p ctrl+q а затем зафиксируйте контейнер.

Зафиксируйте контейнер как новый образ, запустите новый контейнер из образа в непривилегированном режиме

[root@ip-10-0-3-202 ~]# docker commit test_priv test_priv
74305f12076a8a6a78f492fd5f5110b251a1d361e63dda2b167848f59e3799e2
[root@ip-10-0-3-202 ~]# docker run -i -t --name test_nonpriv test_priv /bin/bash

Отметьте /proc/mounts
bind mount отсутствует, не уверен, что вызвало дополнительные монтирования / proc / [sys, sysrq-trigger, irq, bus, kcore]

[root<strong i="5">@ba1ba4083763</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-ba1ba40837632c3900e4986b78d234aefbe678a5ad7e675dbab7d91a9a68469e / ext4 rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs ro,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
proc /proc/sys proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/sysrq-trigger proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/irq proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/bus proc ro,nosuid,nodev,noexec,relatime 0 0
tmpfs /proc/kcore tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0

Симлинк выжил

[root<strong i="9">@ba1ba4083763</strong> /]# ls /var/data1
test
[root<strong i="10">@ba1ba4083763</strong> /]# ls /var/data2
[root<strong i="11">@ba1ba4083763</strong> /]# ls /var/data3
test
[root<strong i="12">@ba1ba4083763</strong> /]# exit

В настоящее время я пытаюсь запустить образы докеров на этапе сборки, используя

Все, если хотите, попробуйте '/ usr / bin / unshare -f -m -u -i -n -p -U -r - / path / to / binary'. Это создаст контейнер внутри вашей сборки с пространством имен пользователя. Вы можете настроить параметры, чтобы не делиться ими по мере необходимости. На самом деле я использую это для запуска '/ sbin / capsh', чтобы детально настроить возможности для моих процессов.

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

Я согласен, что это должно стать частью самого Docker, и интеграция пространств имен пользователей, похоже, продолжается.

@saulshanabrook, вы не можете запускать образы

Это не настоящее решение для тех, кто хочет запускать образы докеров, но я отмечу, что 'unshare' и 'capsh' действительно работают, поэтому можно выполнять среду выполнения, подобную контейнеру, в непривилегированных контейнерах (например, во время сборки ). Возможно, можно обойти «запуск докера» и выполнить этот шаг вручную, а затем повторно отправить образы обратно в докер. У меня большая часть этого сегодня работает, даже если у меня нет всего этого, завернутого в лук. В конце концов, конечно, такая функциональность должна быть реализована в самом Docker.

+1 за вытягивание докеров через RUNP

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

+1 Это делает воспроизводимый контейнер докеров в любой момент времени (просто нужно нести только файл докеров)

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

@lsjommer, над какими вещами нужно работать? --privileged - это совершенно небезопасный способ запуска контейнера, который дает пользователю в контейнере полный root-доступ к хосту.

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

Кроме того, это было бы относительно легко реализовать, если кто-то захочет пойти на это ...

@ cpuguy83 Это наша стандартная базовая роль "голого металла", которую я пытаюсь внедрить в контейнеры докеров, чтобы установить все библиотеки, и она имеет дело с общей памятью, но, возможно, мне даже не нужно возиться с ней при сборке контейнера и нужно только запустить его на хосте контейнера?
http://pastebin.com/P3QQxjNQ

Признаюсь, я не совсем понимаю, как Docker обрабатывает совместное использование ресурсов.

@ljsommer Итак, установка shm - это совсем другое дело, и она не будет сохраняться между командами RUN (или когда вы на самом деле docker run ) в любом случае.

@ cpuguy83 Да, я думаю, что в основном это была моя ошибка в том, что я столкнулся с проблемой, которую я считал проблемой, которую я могу просто перенести на базовый уровень для самого хоста контейнера.
Спасибо, что нашли время, чтобы ответить, и извиняюсь за то, что не обучился должным образом, прежде чем пожаловаться.
;)

Есть идеи о RUNP / -privileged во время процесса сборки?
Было бы здорово установить IP-таблицы, чтобы ограничить доступ докеров к конкретным IP-адресам.

Я также хочу RUNP и / или «docker build --privileged».

FROM ubuntu:latest
MAINTAINER xyz

RUN apt-get -qq update
RUN apt-get -yq install iptables

RUN iptables -t nat -I OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8080 && iptables-save > /etc/iptables.rules

Этот Dockerfile не работает из-за следующей ошибки, но работает, если вы выполняете с «docker run --privileged» ...

getsockopt failed strangely: Operation not permitted

@malcm , @ sakurai-youhei: даже если бы у вас было что-то вроде RUNP , это не сработает в этом сценарии, потому что правила iptables не сохраняются в файловой системе.

Позвольте мне объяснить: когда вы выполняете RUN x , Docker выполняет x затем делает снимок файловой системы. Вещи за пределами файловой системы (запущенные процессы, таблицы маршрутизации, правила iptables, настройки sysctl ...) не хранятся в образах Docker.

Если вам нужны настраиваемые правила iptables, можно воспользоваться одним из способов:

• запустите свой контейнер, например, с --name myapp
• запустить другой контейнер, привилегированный, одноразовый, для настройки правила iptables, например docker run --net container:myapp --privileged iptablesimage iptables -t nat ...

Имеет ли это смысл?

@jpetazzo : Спасибо за ответ. В моем случае я ввел вторую команду, чтобы правило iptables сохранялось как данные в файловой системе, как показано ниже. Это должно позволить мне загрузить правило iptables после запуска контейнера с параметром --privileged.

RUN do-something-with-iptables && iptables-save > /etc/iptables.rules

Без RUNP и "build --privileged" меня заставляют писать примерно так:

ADD iptables.rules /etc/

Да, этого может быть достаточно, однако мне нужно добавить iptables.rules рядом с Dockerfile в мое репо.

Вот почему я хочу (или хочу мягко) RUNP. :)

@jpetazzo @strib
Помимо проблем с iptables, монтирования и других привилегированных операций, я думаю, что есть один сценарий сборки, который мы должны рассмотреть.

Мы поставляем устройства для развертывания на виртуальных машинах и для установки на «голое железо». Однако для тестирования мы используем контейнерные среды. В свою очередь, внутри этих устройств мы запускаем контейнеры. Так что тестовые контейнеры должны быть основаны на docker-in-docker. Теперь представьте, что у нас есть образ службы, который необходимо предварительно загрузить в тестовый образ (чтобы образы служб не загружались из реестра во время тестирования). Прямо сейчас мы не можем этого сделать, поскольку мы не можем запустить контейнер d-in-d в привилегированном режиме во время сборки Dockerfile, который использует d-in-d в качестве основы: демон docker не запускается, "docker pull "или" загрузка докера "не сработает.

У меня возникла проблема, из-за которой при запуске на хосте RHEL7 su завершился ошибкой, если текущий пользователь был пользователем root. Как ни странно, если текущий пользователь был кем-то еще, su работал нормально. В любом случае обходной путь заключался в передаче команде запуска флага --add-cap=SYS_RESOURCE ; однако из-за этой проблемы это было невозможно сделать на этапе сборки.

+1 Сценарии вокруг файлов Docker с docker run и docker commit - это смешно. Пожалуйста, включите эту функцию.

+1 о необходимости этой функции. Я думаю, что глобальный «уровень безопасности» можно настроить в файле конфигурации, который ограничивает возможности, которые могут быть предоставлены контейнеру. Должно быть безопасное значение по умолчанию (как сегодня), и системный администратор мог бы изменить его, чтобы разрешить запуск контейнеров с дополнительными привилегиями. dockerfiles с такой инструкцией RUNP может не запуститься с сообщением типа «этот Dockerfile требует следующих возможностей .... для сборки» в системе, которая имеет такие глобальные ограничения.

Я думаю, что это позволяет найти баланс между безопасностью и удобством использования.

У нас также есть эта проблема при попытке создать образ с проприетарной базой данных evli, которая останется безымянной внутри него.
База данных хочет выделить огромное количество памяти, что не разрешено докером.

Наш текущий обходной путь - это двухэтапная сборка с шагом run --privileged и отдельным шагом фиксации.

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

+1
для этой функции.
для исторического примера и примера использования см. этот обман
https://github.com/docker/docker/issues/12138#issuecomment -90536998
спасибо @ cpuguy83 за указание на обман

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

Теперь есть запрос на вытягивание, который это реализует; там можно следить за прогрессом; https://github.com/docker/docker/issues/12261

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

Как только # 13171 будет объединен, я думаю, нам следует закрыть это, так как это сделает запуск вашего собственного построителя тривиальным, и, как таковой, разрешение --privileged.
Я не думаю, что встроенный docker build должен позволять это.

Итак, @ cpuguy83 , если я правильно понимаю, способ поддержать эту проблему - полностью переопределить docker build но с дополнительным параметром?

Я предполагаю сказать, что после того, как другой патч будет протолкнут, мне нужно будет собрать свою собственную версию docker build (может быть, docker pbuild ?), Чтобы заполнить дополнительные функции?

Есть ли прогресс в этом вопросе? Я проверил упомянутые выше PR, и все они не прошли.
Можно ли сделать опцию BUILD --privileged/--granted более детальной и предоставить доступ к определенной группе ресурсов хоста, ограниченный только создателем / владельцем изображения?

+1 для любого решения, которое позволяет мне делать RUN docker pull в Dockerfile.

Пример использования: мне нужен набор инструментов для преобразования изображений и создания документации, однако все эти инструменты не могут быть установлены в один образ из-за конфликтующих библиотек. Вот почему я выделил некоторые из этих инструментов в отдельное изображение, и я хотел бы распределить все инструменты в одном изображении, то есть изображение в изображении. Вот почему я хочу сделать RUN docker pull в моем Dockerfile.

@ cpuguy83 не похоже, что эта проблема была решена к /proc/sys/kernel/core_pattern во время сборки.

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

1. Публичное использование моих изображений было приоритетом.
2. У них была какая-то потребность в воспроизводимости.

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

cc @thaJeztah , который, кажется, симпатизирует этой позиции

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

Похоже, вы сделали последний звонок. Я тогда буду агитировать в самой PR-ветке.

Это необходимо для установки старых пакетов JDK 1.6 под CentOS, поскольку его RPM пытается зарегистрировать binmft_misc, который не работает без запуска с --privileged.

Dockerbuild не предназначен для создания контейнеров с его помощью.

Чтобы воспроизвести

ОТ Centos5.11
ЗАПУСТИТЬ yum intall -y jre-1.6.0_29-fcs

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

Docker должен легко запускать промежуточные контейнеры с установленными привилегированными параметрами.

@shubhamrajvanshi: мы находимся в процессе перемещения «строителя» из демона (и к клиенту), это должно открыть дверь для дополнительных настроек процесса сборки (включая возможность реализации собственных построителей). Возможно, можно рассмотреть возможность разрешения «привилегированных» сборок, но это решение может быть принято после рефакторинга. (См. Https://github.com/docker/docker/blob/master/ROADMAP.md#122-builder)

@shubhamrajvanshi, вы не можете вносить изменения в iptables в сборке по уважительной причине, настройки никогда не сохранятся.

С параметром --privileged можно сделать очень мало вещей, которые имеют смысл даже при сборке.

@thaJeztah Спасибо, это было бы полезно.
@ cpuguy83 Будет ли это так, даже если я использую в образе пакет iptables-persistent.

Это сохранит правила на диск, и, к сожалению, их все равно придется перезагружать.

_ПОЛЬЗОВАТЕЛЬСКИЙ ОПРОС_

_ Лучший способ получать уведомления об изменениях в этом обсуждении - это нажать кнопку «Подписаться» в правом верхнем углу. _

Перечисленные ниже люди оценили ваше содержательное обсуждение случайным +1:

@karelstriegel

Мне бы тоже этого хотелось, чтобы можно было использовать драйверы CUDA от nVidia с Docker на CoreOS. Предоставляемый ими установщик собирает модуль ядра на основе исходного кода ядра, а затем устанавливает его с помощью modprobe. Я не понимаю, как заставить его работать без какой-либо опции --privileged для сборки.

Почему по умолчанию всегда не поддерживать привилегированный режим при сборке?

+1
Я хочу использовать команду mysql в Dockerfile для centos7.
Конечно, мы можем использовать entrypoint.sh, но будет полезнее, если мы сможем использовать -privileged как для сборки, так и для запуска.

Для запуска команды MySQL нет необходимости в параметре --privileged.

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

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

Применимо ли это к случаю пользователя chroot?

Я пытаюсь понять, как сделать dpkg-depcheck -d ./configure без чего-то подобного.

Во время сборки (или запуска без --priviledged) я получаю сообщение об ошибке ниже - я понятия не имею, как определить, какое разрешение ему нужно или как его включить.

dpkg-depcheck -d ./configure
strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Permission denied
strace: test_ptrace_setoptions_followfork: unexpected exit status 1
Running strace failed (command line:
strace -e trace=open,execve -f -q -o /tmp/depchJNii2o ./configure
devel<strong i="8">@98013910108c</strong>:~/src/cairo-1.14.2$ 

Примерно через 3 года и 162 комментария, я думаю, что это вызвало большой интерес. Комментарии о том, что привилегированный режим не нужен для большинства упомянутых случаев, верны, даже мои собственные; но не следует использовать для запрета того, что может быть полезно для локальных, временных, исследовательских и / или целесообразных сборок. Публикуйте предупреждения до тех пор, пока коровы не начнут пукать гармонично, распечатывайте предупреждения из командной строки, ругайте и осуждайте их использование, но дайте людям гибкость. Портативность не всегда является основным интересом для всех.

_ПОЛЬЗОВАТЕЛЬСКИЙ ОПРОС_

_Лучший способ получать уведомления об обновлениях - использовать кнопку _Подписаться_ на этой странице.

Пожалуйста, не используйте комментарии «+1» или «У меня тоже это есть» по поводу проблем. Мы автоматически
соберите эти комментарии, чтобы цепочка оставалась короткой.

Люди, перечисленные ниже, проголосовали за эту проблему, оставив +1 комментарий:

@robeferre

+1

Мне действительно нужно смонтировать том NFS внутри контейнера докеров, до сих пор я не мог создать общий ресурс NFS без флага «--privileged = true». На мой взгляд, лучший вариант - создать образ с помощью привилегированной команды. Как это возможно?

+1

Step 19 : RUN lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root
 ---> Running in 4c51b7cf0058
lxc_container: lxccontainer.c: create_run_template: 893 error unsharing mounts
lxc_container: lxccontainer.c: create_run_template: 1084 container creation template for percise failed
lxc_container: lxc_create.c: main: 274 Error creating container percise
The command '/bin/sh -c lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root' returned a non-zero code: 1

Я пытаюсь установить gobject-introspection в системе gentoo в докере во время сборки, но это не удается с этой ошибкой:

• ISE: _do_ptrace: ptrace (PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): операция не разрешена

Тот же результат, когда я пытаюсь установить его вручную в контейнер, но когда я пытаюсь установить его из контейнера, запущенного в привилегированном режиме (docker run --privileged), он работает хорошо.

Та же проблема при попытке установить glibc.

Так что мне также нужен способ запуска привилегированной команды во время сборки.

Я использую докер версии 1.10.1, и проблема с glibc не появляется в 1.9

В версии 1.10 что-то сломалось, и мы не можем создавать 32-битные контейнеры, потому что сеть недоступна
--privileged или --security-opt seccomp: Unlimited для BUILD - действительно необходимо.
Или соответствующие директивы в Dockerfile

большой +1 от меня

Для меня настоящая проблема, что я не могу использовать команду mount во время сборки.
Я пытался преодолеть ограничение, согласно которому каталог хоста не может быть смонтирован в контейнер во время сборки, поэтому я настроил сервер NFS на хосте и попытался смонтировать общий ресурс NFS, просто чтобы узнать, что это невозможно из-за непривилегированного режима.

В моем случае мне нужно установить некоторые вещи в образ, не копируя его в контекст сборки, и ДОБАВЛЯЯ его перед установкой.

Такое ощущение, что я остался без вариантов.

thaJeztah упомянул об этом 10 марта
Регресс в поведении LTTng после обновления до 1.10.2 # 20818 Закрыто

Нет, он не закрыт, мы используем 1.11.0-0 ~ wily, а в 32-битных контейнерах neworking не работает с 1.10.0, но 1.9.x работал хорошо.
Только -privileged может помочь нам запустить контейнеры. Но мы не можем строить новые

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

Согласен с @ctindel , эта проблема является одной из причин, по которой я перехожу с docker на

@ctindel Это то, что мы не готовы реализовать или поддержать. Сама реализация довольно проста (я даже реализовал ее сам, чтобы мы могли обсудить), проблема не в этом.

--privileged - это бак, и разрешать его сборку опасно и сильно влияет на переносимость образов.

Брайан,

Если у вас есть работа, поделитесь, пожалуйста, и со мной. я мог бы
понятно, что.

Спасибо
Шубхам Раджванши
669-300-8346

2 мая 2016 г. в 14:30 Брайан Гофф на [email protected] написал:

@ctindel https://github.com/ctindel Это то, к чему мы не готовы
внедрить или поддержать. Сама реализация довольно проста (я даже
реализовал это сам, чтобы мы могли обсудить), проблема не в этом.

--privileged - это танк, и позволять ему строить опасно, и
сильно влияет на переносимость изображений.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/1916#issuecomment -216369957

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

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

Проблема переносимости приложения, которое требует работы в привилегированном режиме, заключается в самом приложении.

Привилегированный режим - это крайняя мера, позволяющая заставить приложение работать без изменения кода.

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

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

Отправлено из Outlook Мо желчью https://aka.ms/blhgte

В понедельник, 2 мая 2016 г., в 14:53 -0700 «Тревор Блэквелл» < [email protected] [email protected] > написал:

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

Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/docker/docker/issues/1916#issuecomment -216375159

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

@ davidl-zend "портативный" не означает делиться с сообществом. Это означает переход с одной машины на другую.

@ cpuguy83 Как

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

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

Ясно, что вы больше не сможете использовать docker hub или travis-ci для создания своего образа, но люди, которым он нужен, построенный в привилегированном режиме, все равно это поймут.

@ctindel Мне бы хотелось увидеть несколько примеров нарушения переносимости изображений

Выполнение такого рода действий при первом запуске контейнера - _точно_ правильный путь.
Это конфигурация времени выполнения, ее не должно быть в образе.

@ cpuguy83 Вы обсуждаете тот факт, что кто-то может выполнить частичную сборку из файла Docker, развернуть контейнер в привилегированном режиме, внести больше изменений, а затем выполнить фиксацию докера? Чем это отличается от сборки в привилегированном режиме? Потому что это то, чем сегодня занимаются другие люди.

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

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

@ctindel Я вообще не обсуждаю это. Разница поддерживает поведение. Если бы не было разницы, у нас не было бы этого обсуждения.

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

@ cpuguy83 Мне все еще очень непонятно (и я думаю, что другие участники этой темы), что именно получается, если не предоставлять эту опцию, которую люди работают другими способами. Вид архитектурной чистоты (у меня нет лучшего слова для этого), за которую вы, кажется, спорите, исчезло в ту минуту, когда была добавлена ​​опция фиксации, поэтому я действительно не понимаю, какая разница, выполняется ли это через Dockerfile с привилегированной сборкой или через фиксацию докера в привилегированном контейнере.

За исключением того, что один способ - это долбанная PITA для людей, и односторонний способ отлично вписывается в текущий механизм сборки с помощью Dockerfile.

Кроме того, вы не ответили на мой вопрос. Почему вы считаете простую установку стороннего пакета debian (или стека пакетов) «конфигурацией времени выполнения»?

@ctindel Переносимость. То, что что-то можно сделать, не означает, что оно поддерживается, и включение этого в build , что делает его удобным для всех, означает, что оно поддерживается.
Нас _will_ затопляют проблемы с изображениями, не работающими между хостами ... что практически полностью устраняет причину Docker.

Если пакет требует даже установки --privileged , то это следует решить с помощью пакета. Для установки не требуется --privileged ... и если это действительно требуется, то это признак того, что сама установка не переносима (требует изменения вещей на хосте) ... Я бы даже хотел посмотрите, как docker можно запускать в контейнере без --privileged (обратите внимание, что это запускается, вы можете без проблем установить все, что хотите, без --privileged).

Но разрешение сделать это через фиксацию докеров означает, что она также поддерживается!

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

Вы все еще не ответили на мой вопрос о том, почему процесс установки пакета (я даже не говорю о его настройке здесь) является актом «настройки времени выполнения». Просто сказать «портативность» ничего не значит.

Есть ли что-то особенное в докере для x86_64? Не появятся ли в конечном итоге образы докеров, созданные для конкретной архитектуры ЦП? Разве это не делает их непереносимыми? Я имею в виду, что вся эта идея о том, что каким-то образом вы всегда сможете взять любой образ докера и запустить его на любом хосте докера в мире, независимо от множества других переменных, в любом случае кажется невозможной, поэтому я не понимаю сверхсильной необходимости нажимать вернемся к этой особенности, о которой просят люди.

Кстати, позвольте мне поблагодарить вас за ваши ответы и постоянное участие. Множество других проектов на github, в которых потоки задач игнорируются!

Я согласен с тем, что люди работают над этим, используя docker run --privileged с docker commit . Пока что я сделал подобное решение для двух компаний. Люди БУДУТ создавать подобные образы, и нет смысла вести себя так, как будто это что-то ужасное, ужасное.

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

@PerilousApricot, что на самом деле вызывает проблему с packstack? Мы рады исправить определенные проблемы или помочь в их исправлении, но не думайте, что простое добавление --privileged которое дает полный неограниченный root-доступ к вашему хост-серверу, является правильным способом сделать это. Все известные мне случаи, когда люди поднимали определенные проблемы сборки, как правило, можно исправить, так как большинству вещей фактически не нужен root-доступ на хост-машине для выполнения сборки.

@justincormack Какое решение для стороннего пакета (т.е. не может быть изменен), который запускает собственную службу, в которой сценарий инициализации должен монтировать файловую систему tmpfs? Я имею в виду даже игнорирование --privileged, на данный момент также нет способа сделать --cap-add или --security-opt apparmor: Unlimited во время сборки (я не думаю?)

@ctindel Не следует пытаться смонтировать tmpfs при установке. Если он нуждается в tmpfs во время выполнения, тогда отлично, но во время установки это определенно неправильно.

@ cpuguy83 Вы навязываете архитектурную философию и философию реализации чему-то, что

В этом суть всего этого обсуждения: вы вводите произвольные ограничения, которые значительно усложняют использование докера из-за некоторой философской озабоченности по поводу запросов на поддержку от людей, которые «делают это неправильно».

Это все равно, что сказать, что операционные системы не должны позволять людям изменять классы планирования процессов, потому что, если вы сделаете это неправильно, это может привести к инверсии приоритета. Или что никто не должен делать молоток, потому что можно ударить большим пальцем, если вы воспользуетесь им неправильно.

Как уже много раз говорилось, docker УЖЕ ПОДДЕРЖИВАЕТ ЭТО с помощью команды фиксации, это просто более болезненно для ваших пользователей. Люди, которым не нужна эта функция, не будут ее использовать, а согласные взрослые, которые хотят ее использовать, понимая ограничения, могут сделать это с широко открытыми глазами.

@ctindel Скорее нет, вы не можете справиться с этой ядерной бомбой, потому что вы можете убить всех в радиусе 50 км.

Что такого в этом пакете, что ему нужно загружать tmpfs во время установки? Установка - это буквально распаковка файлов из архива некоторого формата в rootfs.

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

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

commit и build - две очень разные вещи, и то, что что-то можно сделать одним способом, не означает, что мы должны позволять делать это и любым другим способом.

FROM python

ENV PACKSTACK_VERSION 7.0.1
RUN cd /opt && git clone https://github.com/openstack/packstack.git \
  && cd packstack \
  && git checkout $PACKSTACK_VERSION \
  && rm -rf .git \
  && python setup.py install

Никаких привилегий не требуется.

Церковь доходности.
Однажды «принудительная» переносимость убьет этот проект - он уже делает это.
Такому количеству функций отказывают из-за неуловимой переносимости, из-за этого не достигается так много прогресса ...
Однажды кто-нибудь раскроет проект и сделает переносимость необязательной. Мечты ... мечты .... Аминь.

Если мы разделим это на два случая:

1. Установщики, которые легкомысленно используют привилегированные операции, например монтируют tmpfs для повышения производительности. Такие установщики легко исправить (но, возможно, не в ближайшем будущем).

В этом случае для Docker правильная философия - противодействовать плохо работающим установщикам. У большинства установщиков есть какое-то обходное решение, которое просто делает Dockerfile немного длиннее.

1. Установщики, которые в основном зависят от привилегированных операций, таких как установка модулей ядра для драйверов графического процессора. Они также принципиально непереносимы. Например, они не будут работать на docker-machine для Mac.

В этом случае работа с Docker все равно нарушается. Я не могу использовать докер-машину на Mac, например, я могу создать образ только на совместимой целевой хост-машине. Моим вариантом использования была установка драйверов графического процессора nVidia на ОС хоста (CoreOS), что не рекомендовало установку непосредственно в ОС хоста.

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

@tlbtlbtlb Я не понимаю, о какой «добродетели» вы говорите. Подумайте о том, что не является легкомысленным, но существует множество образов докеров, которые будут работать в одной среде, но не в другой. Например, вы можете смонтировать хост-том в контейнер mongodb, переходя из linux-> linux, потому что и драйвер хранилища mmapv1 будет работать нормально, но вы не можете передать каталог mac osx через virtualbox в контейнер mongodb на вашем ноутбуке, потому что В этом случае материал mmap не будет работать должным образом.

Я понимаю, что это не проблема при сборке, но идея о том, что образы докеров «переносимы» и могут «работать где угодно», на данный момент является полной чушью. Если дело в том, что они не могут никуда бежать, какой смысл в том, чтобы говорить, что они должны иметь возможность «строить где угодно»?

Дело в том, что образ mongodb работает везде. Предоставление недопустимой конфигурации среды выполнения - совсем другое дело.

Docker имеет очень конкретное внутреннее разделение портативной конфигурации и непереносимой конфигурации.

Как насчет этого ?
Мне нужно иметь мои настоящие IP-адреса внутри контейнера для моего прохода проверки конфигурации nginx.

это мой Dockerfile:

FROM ubuntu:14.04.4

RUN apt-get update
RUN apt-get install -y software-properties-common
RUN add-apt-repository ppa:nginx/stable
RUN apt-get update
RUN apt-get install -y nginx-full vim
RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
RUN ifconfig lo:1 192.168.168.57 netmask 255.255.255.0 up
RUN ifconfig lo:2 192.168.168.58 netmask 255.255.255.0 up

ADD . /etc/nginx

➜  nginx git:(ha-node-01) ✗ docker build -t nginx4test .
Sending build context to Docker daemon 976.4 kB
Step 1 : FROM ubuntu:14.04.4
 ---> 90d5884b1ee0
Step 2 : RUN apt-get update
 ---> Using cache
 ---> eea42cb6135d
Step 3 : RUN apt-get install -y software-properties-common
 ---> Using cache
 ---> 9db86ab17850
Step 4 : RUN add-apt-repository ppa:nginx/stable
 ---> Using cache
 ---> 5ed2266a93a9
Step 5 : RUN apt-get update
 ---> Using cache
 ---> 09fcfdc1fed3
Step 6 : RUN apt-get install -y nginx-full vim
 ---> Using cache
 ---> cc0c1662e009
Step 7 : RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
 ---> Running in 5d962ec4e35d
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFNETMASK: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
The command '/bin/sh -c ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up' returned a non-zero code: 255

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

@ cpuguy83 У меня около 20 строк с записями iptable Я хотел бы RUN в моем Dockderfile но не могу, так как мне нужно --cap-add=NET_ADMIN . Эти команды должны выполняться независимо от того, кто запускает контейнер, и независимо от того, на какой машине они его запускают (контейнер запускает внутреннее приложение). Где / как вы посоветуете мне это сделать, исходя из того, что вы обсуждали выше?

@MatthewHerbst К сожалению, правила iptables не могут / не могут сохраняться с изображением.

@ cpuguy83 Я использую изображение centos:6 и могу запустить run /sbin/service iptables save чтобы сохранить правила в файловой системе. Я считаю, что у них есть аналогичная возможность в Ubuntu и других через пакет iptables-persistent .

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

16 мая 2016 года в 16:03 «Мэтью Хербст» [email protected] написал:

@ cpuguy83 Я использую CentOS и могу запустить run / sbin / service iptables save в
сохранить правила в файловой системе. Я считаю, что они похожи
возможность в Ubuntu и других системах через пакет iptables-persistent.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub

@justincormack , не знаю, почему я не подумал об этом! Спасибо!

Как вы должны выполнять команды, требующие привилегий, при использовании docker service ? Мне нужно установить имя хоста на нескольких моих машинах, но, к сожалению, для этого требуются привилегии.

@nostrebor , не имеющий отношения к этой открытой проблеме.
Мы оцениваем, какие варианты должны существовать для услуг, а не копируем их один к одному. Привилегированного режима наверное не будет в 1.12 для сервисов.

Я пробую сборки докеров, которые компилируют что-то для установки, но они должны компилироваться с библиотеками, которые существуют в сетевой файловой системе CVMFS. Конечно, я не могу смонтировать CVMFS, не запустив --privileged, поэтому я вообще не могу это сделать с помощью Dockerfile.

@ cpuguy83 @tlbtlbtlb Это случай, когда «установщик» в основном зависит от привилегированного действия. Но это не то, что я бы назвал «легкомысленным использованием», мне просто нужен доступ к разделяемым библиотекам в сетевой файловой системе. Тем не менее, установка в этом случае НЕ является простым извлечением файлов из какого-либо архива.

Я не понимаю, почему монтирование сетевой файловой системы является проблемой переносимости. (Все наши целевые среды будут иметь доступ к этой файловой системе. Они необходимы, потому что они создают другой код, который ТАКЖЕ должен связываться с двоичным кодом в сетевой файловой системе.)

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

Я был в восторге от того, чтобы сделать это с помощью Dockerfile, но, похоже, мне придется сделать это сложным путем, используя некоторые скрипты с docker run --privileged , или использовать что-то другое вместо докера. Есть ли способ смонтировать файловую систему в контейнере без привилегированного доступа?

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

@drstapletron , согласно документации CERN cvmfs, у вас есть два варианта: либо смонтировать cvmfs с хоста в контейнер, либо установить cvmfs внутри привилегированного контейнера.

В случае секунд, я просто написал docker-файл для ребят из cmssw, здесь:
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

поэтому, используя этот файл, вы можете просто создать образ (или вы можете взять его из cmssw dockerhub) и запустить его в режиме P, и все уже будет внутри контейнера (ls / cvmfs / *)

Не уверен, что это было рассмотрено выше, поскольку это довольно длинный список отзывов по этой проблеме. Я тоже хотел бы иметь --privileged команды сборки. Мой текущий вариант использования - обойти проблему, с которой я столкнулся при создании ебилда go на стадии gentoo3. Если я не использую контейнер, текущие инструкции в руководстве по gentoo заставят systemd вести себя беспорядочно после того, как я 'umount -l / mnt / gentoo / dev {/ shm, pts,} && umount -l / mnt / gentoo / { proc, sys} 'из системы, загруженной с помощью systemd ... Когда я перемещаю свою сборку stage3 в контейнер докеров, все работает нормально до тех пор, пока для сборки не потребуется ptrace или какая-то другая ограниченная функция ... что go-1.7.1. ebuild вроде требует.

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

Мне тоже нужна эта функция. Я хочу создать среду сборки, но для этого требуется модуль ядра, и modprobe не будет сотрудничать со мной при сборке. Есть ли обходные пути для этого?

Конкретно:

modprobe vcan && \
ip link add type vcan && \
ifconfig vcan0 up

Похоже на вполне разумный вариант использования.

@seltzy Я предлагаю не задерживать дыхание, ожидая, что кто-нибудь из docker подтвердит разумность вашего варианта использования.

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

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

Разумеется, они могут свободно распределять свои инженерные ресурсы таким образом.
Но он предоставляет послужной список, который поразил бы воображение, если бы компания когда-либо была описана как «серьезно относящаяся к потребностям пользователей».

@tamsky ты прибил!

@tamsky Я могу понять, почему вы так думаете, ведь в проекте не реализована функция, которую вы явно желаете.

Уверяю вас, это не имеет ничего общего с каким-либо деловым решением. Дело в том, что --privileged при сборке уступит место непереносимым изображениям.
Такие вещи, как modprobe в среде сборки бесполезны и даже могут привести к тому, что две сборки будут давать совершенно разные результаты.

Я сам реализовал --privileged при сборке. Это не инженерная проблема, и на самом деле ее довольно легко реализовать. В том, чтобы поддерживать его, вот в чем проблема.
Для опытных пользователей можно реализовать собственный конструктор, даже повторно используя существующий код, используя существующие API, которые могут включать привилегированную поддержку.

Тем не менее, этот вопрос по-прежнему остается открытым. Потому что люди слушают.

Спасибо за ваше внимание.

@ cpuguy83 Спасибо за объяснение. Я не понимал, что это проблема переносимости. Полагаю, мое желание подпитывается недоразумением.

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

@seltzy не будьте уверены, что ваш вариант использования не является разумным примером необходимости этой функции.

@ cpuguy83 Я все еще жду ответа о моем варианте использования. Система сборки нашего учреждения распределена по сетевой файловой системе, которую я должен смонтировать в своем контейнере. Это требует, чтобы контейнер работал в привилегированном режиме. Решение моего учреждения использовать сетевую файловую систему для распространения программного обеспечения не является чем-то необычным для физики элементарных частиц. Вы утверждаете, что --privileged при сборке создает непереносимые образы, но это совершенно не связано с моим вариантом использования. Наша модель разработки уже отказалась от любой переносимости, которую мы могли потерять из-за использования сетевой файловой системы (правда?). Нам просто нужно, чтобы машина разработки собиралась его смонтировать.

@ cpuguy83 PS вы упомянули кастомный строитель. Где я могу найти информацию об этом? Спасибо!

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

После того, как они добавили опцию фиксации докеров, всякое понятие переносимости образов все равно исчезло, поэтому принуждение людей делать это в 3 шага вместо 1 ничего не дает и только раздражает людей, которые действительно могут использовать привилегированный вариант сборки.

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

@ctindel Да, вы можете делать все, что хотите, в docker build является «поддерживаемым» методом построения изображений, означает, что нам необходимо гарантировать, что изображения, созданные с его помощью, _are_ переносимы.

Переносные изображения - не отвлекающий маневр. Переносимость рабочих нагрузок - основная цель разработки Docker. Как бы наша главная директива.

@seltzy Большинство вещей, требующих дополнительных привилегий, относятся к среде выполнения, потому что большую часть времени повышенные привилегии используются для некоторого изменения хоста.
Тем не менее, я могу понять, что некоторые вещи требуются во время сборки (например, монтирование nfs выше) .... но даже в случае NFS и ручного создания образа (не с docker build ) я не дал бы контейнеру --privileged или каких-либо дополнительных возможностей, вместо этого я бы смонтировал экспорт nfs как том.

@drstapletron mount не требует --privileged только более ограниченного набора возможностей и гораздо более вероятно, что произойдет раньше, чем полный привилегированный режим, так как это дает полный root-доступ к хосту, что делает большинство людей не хочу. (У него все еще есть проблемы с безопасностью, но они более управляемы).

Итак, у меня есть полностью переносимый вариант использования без изменения хоста. Это даже с открытым исходным кодом, и вы можете увидеть это здесь .

По сути, я хочу запустить Mock в переносном контейнере Docker для создания настроенного ISO-образа CentOS. Mock, для тех, кто не знает, представляет собой контейнерный конструктор RPM. Проблема в том, что поскольку он использует контейнеры, мне нужны --privileged или --cap-add . В идеале, я думаю, docker build будет работать как функция, принимая несколько аргументов и возвращая свой окончательный результат. Однако без этих флагов я не смогу этого сделать.

То же самое ! Из-за этого использование mock внутри докера - кошмар :(

Sending build context to Docker daemon 9.728 kB
Step 1 : FROM centos
 ---> 980e0e4c79ec
Step 2 : MAINTAINER Gregory Boddin
 ---> Using cache
 ---> 93e709c87f25
Step 3 : RUN yum install -y spectool mock
 ---> Using cache
 ---> 7006ef8d0276
Step 4 : RUN useradd mock -g mock
 ---> Using cache
 ---> bfb931c56d89
Step 5 : ADD *.cfg /etc/mock/
 ---> Using cache
 ---> 15521d2822b1
Step 6 : RUN su mock -c"/usr/bin/mock -r edge-5-x86_64 --init"
 ---> Running in 542a742b6017
INFO: mock.py version 1.2.17 starting (python version = 2.7.5)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
ERROR: Namespace unshare failed.

@ cpuguy83 написал:

Дело в том, что --privileged on build уступит место непереносимым изображениям.

Почему бы не разрешить --privileged для тех, кому не требуется далеко идущая переносимость?
Простое примечание в официальной документации было бы разумным компромиссом (например, _Warning: передача --privilege команде build может привести к менее переносимому изображению! _). Это решило бы требования почти каждого; некоторым пользователям не нужна переносимость, некоторым она нужна, предупреждения было бы достаточно, чтобы удовлетворить потребности всех.

Я уверен, что отсутствие build --privileged значительно усложняет мой текущий вариант использования.

Его можно было бы назвать --non-portable . Я еще не использовал части docker для развертывания, но изоляция + наложение файловой системы была действительно полезной и без этого.

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

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

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

+1 за это. В нашем процессе сборки необходимо смонтировать файлы / proc и / dev. В идеале у нас должна быть возможность сделать шаг монтирования частью файла dockerfile.

@ samsun387 Почему это требуется в процессе сборки?

@skshandilya setfacl не переносится, и я был бы удивлен, если бы acl можно было сохранить в образе.

@robhaswell "требует привилегированного контейнера" ​​не очень помогает. Что на самом деле используется при установке?

+1. mock init нуждается в этом.
почти прочитал весь выпуск. не понимаю, почему люди продолжают спрашивать «зачем тебе это нужно» три года подряд.

@Betriebsrat Потому что "X нуждается в этом" на самом деле не так уж и полезно.
Что делает «Х»? Зачем «X» это нужно на этапе сборки?

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

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

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

Кстати, когда я говорю «функции безопасности», я имею в виду две вещи:

1. Вещи для предотвращения взлома
2. Изоляция проблем приложения от проблем хоста (т. Е. Построение образа не должно привязывать образ к хосту, на котором оно построено).

Похоже, что моя решила 21051, я выхожу, пока :)

@shykes сказал 28 ноября 2013 г. @ https://github.com/docker/docker/pull/2839#issuecomment -29481246 ::

Извините, текущий дизайн предусматривает принудительное применение «1 источник, 1 сборка», поэтому мы не допускаем никаких аргументов для сборки докеров, кроме исходного каталога.

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

@ cpuguy83 , изменился ли вообще дизайн от принудительного: «1 источник, 1 сборка»?
Готов ли проект Docker изменить этот дизайн и разрешить эту функцию, запрошенную сообществом?

Приведенный выше комментарий Шайкса, кажется, объясняет, что «нам, возможно, потребуется» сделать, чтобы решить эту проблему. В то же время используемый язык («мог бы»), по-видимому, предоставляет проекту докера много места для придумывания дополнительных причин отклонить это изменение дизайна.

Добавление объявления NEEDS_PRIVILEGED имеет смысл, но все эти вещи о приостановке сборки? Просто выдайте ошибку и позвольте оператору передать параметр --privileged, если он действительно хочет разрешить привилегированную сборку.

@ cpuguy83 дело в том, что люди, которым когда-либо понадобится привилегированный режим при сборке, обычно являются docker commit как часть своей сборки для шага, который в этом нуждается.

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

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

Скажите: «Мы не будем исправлять это, потому что мы хотим, чтобы это раздражало», и закройте эту проблему.

/нить

@ cpuguy83 , unshare(2) с флагом CLONE_NEWNS - и, возможно, другие - при создании своей среды chroot / контейнера. Для этого требуется как минимум CAP_SYS_ADMIN .

Что делает «Х»? Зачем «X» это нужно на этапе сборки?

В нашем случае мы не знаем. Это какая-то пропиетическая чушь, которую мы не можем изменить. Дело в том, что наш бизнес не заботится о «безопасности» (в данном контексте), переносимости или каких-либо проблемах, которые были перечислены. Мы просто хотим положить эту чертову чушь в контейнер и заняться чем-то ценным.

Как говорит @PonderingGrower , мы все равно это сделаем, это просто вопрос того, сколько времени мы тратим на это.

люди, которым когда-либо понадобится привилегированный режим при сборке, обычно являются опытными пользователями, которые прекрасно знают, каковы риски его использования

Я категорически не согласен с этим предположением. В целом, люди, использующие --privileged относятся к той же категории пользователей, которые вслепую запускают chmod -r 777 "потому что кто-то написал, что это устранило проблему"

В нашем случае мы не знаем. Это какая-то пропиетическая чушь, которую мы не можем изменить. Дело в том, что наш бизнес не заботится о «безопасности» (в данном контексте), переносимости или каких-либо проблемах, которые были перечислены.

"в этом контексте" здесь, что означает: предоставление "некоторой проприетарной чуши" корневого доступа на вашем хосте.

@thaJeztah У меня нет проблем с этим. Это программное обеспечение, которое мы приобрели и оплатили поддержку. Если бы мы не использовали контейнеры, для установки все равно потребовался бы root.

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

Что вы здесь обсуждаете 3 года?

docker run имеет параметры --cap-add , --cap-drop и другие. Итак, команда RUN в Dockerfile хочет иметь те же параметры. Итак, Dockerfile хочет отправить запросы на родительский компьютер и попросить его добавить / удалить некоторые привилегии.

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

Значительному числу пользователей докеров нужна возможность --cap-add или --privileged в команде сборки, чтобы имитировать то, что содержится в команде запуска.

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

@ctindel Это определенно проблема данного вопроса. Между docker build --cap-add и RUN --cap-add есть разрыв.

Некоторые люди хотят разрешать запросы привилегий от дочерней машины всего за docker build --cap-add=caps_array . Что это? Это просто: caps_array.include? requested_cap .

Некоторые люди хотят pre_requested_caps.include? requested_cap . Некоторые люди хотят stdout << requested_cap, stdin.gets == 'y' Некоторые люди хотят gui_confirm requested_cap . Некоторые люди обязательно захотят UAC_fullscreen_dialog requested_cap .

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

Но RUN --cap-add имеет ничего общего со вкусами людей. Что мы ждем?

@ andrew-aladev Я не совсем понимаю, о чем говорится в вашем посте. Дело в том, что у людей есть стороннее программное обеспечение (RPM, DEB, что угодно), которое не находится под их контролем, которое они хотят установить в образ во время «сборки докера» и которое требует дополнительных возможностей для правильной установки. Поскольку они являются сторонними RPM-пакетами, невозможно удовлетворить требование о повышенных привилегиях на этапе установки.

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

@ctindel У меня не очень хороший английский, извините.

Я знаю. Я попытался установить glibc и получил ptrace not permitted .

docker может запускать контейнер с увеличенными / уменьшенными возможностями самостоятельно. RUN команда в Dockerfile должна поддерживать --cap-add , --cap-drop и т. Д.

Представим, что в нашем Dockerfile будет RUN --cap-add=SYS_PTRACE -- emerge -v1 glibc . Как это будет работать?

1. Дочерняя машина отправляет запрос родителю и запрашивает SYS_PTRACE .
2. Родитель допускает расширенные возможности.
3. Родитель создает новый контейнер с разрешенным SYS_PTRACE.

Я вижу, что на самом деле никто в этом вопросе не спорит по этому поводу. Люди просто спорят о способе реализации этих возможностей.

@thaJeztah сказал

В целом, люди, использующие --privileged, относятся к той же категории пользователей, которые слепо запускают chmod -r 777.

Этому человеку нужен более гибкий метод проверки требуемых возможностей, чем просто log :info, requested_cap; return privileged? .

@ctindel ты сказал

Добавление объявления NEEDS_PRIVILEGED имеет смысл, но все эти вещи о приостановке сборки? Просто выдайте ошибку и позвольте оператору передать параметр --privileged, если он действительно хочет разрешить привилегированную сборку.

Вы хотите сделать оболочку интерактивной. Вы хотите stdout << requested_cap, stdin.gets == 'y' . Это еще один метод проверки необходимых возможностей.

@ cpuguy83 сказал

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

Этот человек хочет docker build --cap-add=caps_array caps_array.include? requested_cap . Это еще один метод проверки необходимых возможностей.

Итак, я спрашиваю: почему RUN в Dockerfile до сих пор не поддерживают --cap-add , --cap-drop и т. Д.? Об этом никто не спорит. Прошло 3 года!

@ andrew-aladev Я предполагаю, что никто не спорил с этим синтаксисом, потому что было ясно, что синтаксис dockerfile заморожен до тех пор, пока построитель не будет переписан / отремонтирован / отделен от основного движка. https://github.com/docker/docker/issues/29719#issuecomment -269342554

В частности, заголовок проблемы и OP запрашивают --privileged build

это вызывает у Фонзи вздох: .

возможность запустить strace на шаге build помогает.
в настоящее время я работаю над этим, перемещая все, что мне нужно для отладки, на шаг run - не идеально.

кто-нибудь знает, почему это будет работать на шаге run а не на шаге build ? то есть исторические причины.
есть ли альтернатива strace которая работает без особых разрешений или конфигурации?

Предлагаемое решение / обходной путь для этого есть в
https://github.com/docker/docker/issues/6800#issuecomment -50494871:

если у вас есть проблемы со сборкой докеров, вы можете использовать «контейнер построителя»:
docker run --cap-add [...] mybuilder | docker build -t myimage -

Может ли кто-нибудь (возможно, @tiborvass) подробнее рассказать об этом? Что за mybuilder здесь?
Имя изображения с какой-нибудь ENTRYPOINT? Или часть изображения [...] и mybuilder относится
в сценарий оболочки? И как мне убедить docker run передать context.tar.gz в docker build -
если это действительно то, что здесь происходит. Заранее спасибо, Штеффен

@sneumann mybuilder будет именем изображения и действительно иметь CMD или ENTRYPOINT . Контракт для этого обходного пути заключается в том, что mybuilder должен будет tar контекст внутри контейнера и передать его на стандартный вывод. Это передается на стандартный ввод docker build , благодаря конвейеру оболочки | и считается контекстом, потому что путь контекста для docker build -t myimage - равен - .

немного странно, глядя на код, кажется, что эта опция доступна в команде build :

• run : я предполагаю, что container здесь означает run - https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/container/opts.go # L485.
• build : https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/image/build.go#L108.

кто-нибудь, кто более осведомлен, знает, почему он не применяется?

@mbana --security-opt предназначена для собственных контейнеров Windows, которые поддерживают "credentialspec" https://github.com/docker/docker/pull/23389.

можно ли изменить это и сделать так, чтобы в будущем build включил ptrace ?

для всех, кто интересуется, вот несколько хороших ссылок:

• http://www.projectatomic.io/docs/docker-building-images/ - как создать образ с помощью описанной выше техники. т.е. используйте run для build изображения.
• https://blog.afoolishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/ - разное

Я видел много заявлений от разных людей о том, что эта функция не нужна, потому что сборки могут быть изменены, чтобы не требовать определенных привилегированных операций, но никаких предложений о том, что делать в случае «докера в докере». Если сборка должна запускать команды docker , например, для получения некоторых изображений, которые мы хотим отправить внутри этого, или для создания вспомогательного изображения, как мы должны это сделать без каких-либо привилегированных вариант сборки?

Сейчас я собираюсь обойти это, используя docker run и docker commit но было бы здорово, если бы docker build поддерживал этот вариант использования.

@scjody Похоже, ты хочешь # 31257

@ cpuguy83 Я не уверен, что это касается того, что происходит в этом случае, но я попробую, как только это объединится. Спасибо!

Привет, я хотел бы написать свое имя в шапке, пожалуйста, примените это. Или, может быть, есть другое решение моей проблемы (здесь docker noob), на которое кто-то мог бы указать мне?

Я пытаюсь создать образ на основе официального образа centos / systemd и предоставить его с помощью Saltstack. Это требует запуска (и, возможно, перезапуска) демона salt-minion с помощью systemd, что невозможно (AFAIK) без привилегированного режима.

@onlyanegg Я думаю, что в этой ситуации Saltstack в значительной степени заменяет функциональность конструктора; имейте в виду, что каждый оператор RUN выполняется в новом контейнере, после чего предыдущий контейнер сборки останавливается и фиксируется в изображении / слое.

Рассматривали ли вы выполнение сборки, запустив контейнер и зафиксировав результаты ( docker commit )?

Спасибо за ответ, @thaJeztah. Я не понимал, что это то, что сделала директива RUN . Я прочитал большую часть этой проблемы, поэтому я знаю обходной путь docker build -> docker run -> docker commit , которым я, скорее всего, и займусь. Я просто больше за то, чтобы мое изображение описывалось в одном файле - кажется более аккуратным. Может быть, я смогу поместить все эти шаги в постпроцессоры упаковщика, и тогда я получу это.

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

@onlyanegg, вы сможете перезапускать службы _без привилегированного режима. Если у вас есть Dockerfile, иллюстрирующий это (например, «команда RUN в строке 8 этого Dockerfile не работает, потому что требует привилегированного режима»), я был бы более чем счастлив взглянуть!

@derberg именно так! Во времена контейнеров, CI, CD важно, чтобы инструменты сборки могли быть ограничены (в смысле безопасности). Если вы разрешаете привилегированный режим, вы должны кардинально изменить то, как вы используете инструменты CI, такие как Jenkins, Travis, Codeship и т. Д. Тот же вопрос: если у вас есть Dockerfile, требующий привилегированного режима, я был бы рад взглянуть, чтобы предложить альтернативы.

Спасибо!

@jpetazzo попробуйте получить образ докера с докером внутри него:

FROM ubuntu:16.04

# Get dependencies for curl of the docker
RUN apt-get update && apt-get install -y \
    curl \
    sudo \
    bash \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSL https://get.docker.com/ | sh

Теперь собери и запусти. После запуска запустите service docker start чтобы запустить docker deamon. Затем проверьте статус службы service docker status :

• со статусом привилегированного флага все в порядке, и вы можете запустить контейнер без проблем
• без флага он никогда не запускается

@jpetazzo ech, только что заметил, что вы являетесь создателем https://github.com/jpetazzo/dind :), так что вы знаете о докере в концепции докера :)

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

Итак, есть ли способ смонтировать общий ресурс NFS или SMB в docker build ?

@derberg: эти шаги не --privileged ; пакеты докеров (и сценарий установки) (например) устанавливают пакеты ядра в Ubuntu 16.04.
Именно по этой причине --privileged - плохая идея для docker build , потому что он может вносить изменения в _host_.

Несмотря на то, что docker будет нуждаться в привилегиях при _работе_, для самой установки это не нужно; например, вот шаги, которые вы должны выполнить, чтобы установить докер в свой образ;

docker build -t foo -<<'EOF'
FROM ubuntu:16.04

RUN apt-get update && apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common \
    && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable"
RUN apt-get update && apt-get install -y docker-ce \
    && rm -rf /var/lib/apt/lists/*
EOF

И вы можете запустить его нормально (я использую здесь --privileged , но, возможно, возможны более мелкие разрешения):

docker run -it --rm --privileged -v /var/lib/docker foo dockerd --debug

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

Для этого метода требуется файл Dockerfile, файл docker-compse и сценарий оболочки.

Dockerfile

Это то же самое, что и для создания образа. Единственная разница, остановитесь там, где вам нужно выполнять привилегированные операции, не включайте их. Они должны запускаться программой docker-compose как скрипт. Например:

FROM ubuntu:16.04
RUN apt-get update && apt-get install <your packages>
# And more commands
......

## Below are the operations you intended to run in privileged mode when building the image, which does not work.
# More commands....
## But they now are moved to a separated shell script and it will be included in the image
COPY further-commands-to-run-in-privileged-mode.sh /

Те другие команды, которые необходимо запустить в привилегированном режиме, теперь находятся в further-commands-to-run-in-privileged-mode.sh . Он включен в образ и позже будет запущен docker composer для завершения процесса сборки.

Файл для создания докеров

Файл набора - это ключ. Он сначала создаст образ из указанного выше файла Docker и запустит контейнер из этого образа в привилегированном режиме , после чего вы сможете выполнить свою привилегированную операцию там. Например:

version: '3'

services:
  your_service:
    container_name: your_container
    # First build the image from the Dockerfile
    build:
      # Change this to where you keep above Dockerfile
      context: ../docker-build
    image: "your_image_name:your_image_tag"

    # Then start a container from the just built image in privileged mode to finish what's left
    entrypoint: /further-commands-to-run-in-privileged-mode.sh
    privileged: true

Создайте образ

Следующие ниже шаги также можно сохранить в сценарии оболочки.

# First build the image and container(in privileged mode)
docker-compose -f docker-compose.yml up

# Then commit the temporary build container to a new image, change the ENTRYPOINT to what you want
docker commit \
    -c 'ENTRYPOINT ["/bin/bash"]' \
    <build container name> \
    <final image name>:<final image tag>

# Remove the temporary build container
docker rm <build container name>

@thaJeztah У меня нет проблем с установкой, у меня проблема с запуском службы докеров во время сборки и извлечением некоторых изображений, чтобы они были доступны в образе из коробки.

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

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

@derberg Хорошо, понятно! _Лично_, если бы я хотел включить изображения в контейнер dind , я бы загрузил их (например, с помощью reg ) и загрузил бы их при первом запуске контейнера. Почему? Потому что, если вы вытащите изображения во время сборки, они будут работать только в том случае, если dind запущен с тем же драйвером хранилища_. Другими словами, ваше изображение может работать или не работать на другом компьютере.

Также - если ваши изображения большие (то есть что-то еще, кроме, скажем, busybox или alpine ), вы получите действительно большое изображение DinD ...

Мне бы хотелось узнать больше о вашем последнем сценарии использования - потому что я уверен, что мы можем помочь вам найти более эффективный способ, чем запекание огромного образа DinD :-)

(В остальном решение, предложенное @kraml , довольно элегантно!)

Также см. Https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh
Загружает изображения, используя только bash + curl + tar.
Мы используем его здесь: https://github.com/moby/moby/blob/master/Dockerfile#L171

@jpetazzo мы уже использовали такое обходное решение build-run-commit, но да, с моей точки зрения, это обходной путь. Вариант использования довольно специфичен, связан с кубернетами и средой minikube, и на данный момент мы ничего не можем сделать. На данный момент мы смогли запустить minikube в докере только с докером в качестве демона, использование виртуального бокса или других драйверов vm не сработало, поэтому мы зависим от подхода dind

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

Возвращаясь к этой теме и просматривая все 4 года (!!!) назад и вперед по вопросу о том, как добавить какие-то привилегированные возможности в команду сборки докера, кажется, что доступные параметры в этой ситуации либо неприятный набор команд sed для изменения установщика, чтобы удалить вызовы sysctl, или многоступенчатую сборку -> запуск -> конвейер фиксации. Я согласен с @derberg, что 'build -> run -> commit' кажется обходным решением (я думаю, грубым / хакерским обходным путем), и я не думаю, что мой вариант использования является таким уникальным. Проверяя другие потоки, я видел множество людей, сообщающих о проблемах с установкой различных приложений и баз данных с неудачными командами docker build из-за отсутствия прав.

На данный момент команда docker run поддерживает расширенные «привилегированные» параметры, а также «точный контроль над возможностями с использованием --cap-add и --cap-drop». Итак, я считаю, что возражения по соображениям безопасности или по техническим причинам неуместны. Если параметр привилегированного запуска добавлен вместе с '--cap-add' и '--cap-drop', инженер, заботящийся о безопасности, может решить ограничить привилегированную сборку, чтобы включить только определенные возможности, необходимые для их сборки.

Привет ,

Я уже сообщал об этом раньше, такая же проблема.

Как насчет тех, кто просто хочет запускать один контейнер на каждую виртуальную машину с одним и тем же идентификатором пользователя на виртуальной машине и контейнере, используя докер как инструмент упаковки?

Есть ли еще проблема безопасности в связи с этим?

Попался в эту проблему. Могли действительно использовать возможности для сборки.

Заглянул и в эту проблему.
Это очень полезно при использовании докеров в качестве подчиненных устройств CI / CD, которым может потребоваться привилегированное разрешение на docker build для установки цепочек инструментов для сборки / тестирования CI / CD при создании образа подчиненного докера.
Я жду эту функцию годами и очень надеюсь, что она будет поддерживаться в будущем.

Я действительно не понимаю, почему разработчики так сильно возражают против --privileged for docker image.
Если пользователи хотят прострелить себе ногу, почему бы им не позволить? Просто поставьте предупреждающее сообщение и все. Уже есть обходные пути для достижения того же, почему бы не упростить задачу для пользователей, которые действительно в этом нуждаются?
Прошло 4-5 лет, и никакого прогресса в этом нет.
Просто удивительно...

На сегодняшний день даже эта функция еще не реализована:
ВЫПОЛНИТЬ --cap-add = SYS_PTRACE
который будет соответствовать потребностям многих пользователей.

Не могли бы вы подсказать, как я могу собрать этот Dockerfile на хосте Gentoo Linux:

FROM gentoo/stage3-amd64
# Download and extract latest portage
RUN wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2 && \
    wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2.md5sum && \
    md5sum -c portage-latest.tar.bz2.md5sum 
RUN tar -xjvf portage-latest.tar.bz2 -C /usr
RUN emerge dev-lang/go

потому что я получаю эту ошибку при запуске dev-lang / go:

##### Building Go bootstrap tool.
cmd/dist
 * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:_do_ptrace():75: failure (Operation not permitted):
 * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted
/usr/lib64/libsandbox.so(+0xb692)[0x7fd10e265692]
/usr/lib64/libsandbox.so(+0xb778)[0x7fd10e265778]
/usr/lib64/libsandbox.so(+0x6259)[0x7fd10e260259]
/usr/lib64/libsandbox.so(+0x6478)[0x7fd10e260478]
/usr/lib64/libsandbox.so(+0x7611)[0x7fd10e261611]
/usr/lib64/libsandbox.so(execve+0x3f)[0x7fd10e2634ff]
bash[0x41d8ff]
bash[0x41f387]
bash[0x420138]
bash[0x4219ce]
/proc/330/cmdline: bash ./make.bash 

 * ERROR: dev-lang/go-1.9.2::gentoo failed (compile phase):
 *   build failed
 * 
 * Call stack:
 *     ebuild.sh, line 124:  Called src_compile
 *   environment, line 1034:  Called die
 * The specific snippet of code:
 *       ./make.bash || die "build failed"
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/go-1.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/go-1.9.2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-lang/go-1.9.2/work/go/src'
 * S: '/var/tmp/portage/dev-lang/go-1.9.2/work/go'

Как я могу запустить его без --cap-add=SYS_ADMIN --device /dev/fuse или --privileged ?

RUN apt-get -y install unionfs-fuse
RUN unionfs-fuse -o cow dir1=RW:dir2=RO dir3/

Я могу сделать это с помощью отдельного файла bash в точке входа, но мне нужен единственный файл Docker

@ amd-nick, чего вы ожидаете от строки RUN unionfs-fuse ... во время сборки? Даже если бы это сработало, файловая система была бы смонтирована только во время этого единственного RUN и исчезла бы на следующем шаге.

@thaJeztah мне сложно объяснить. Я пытаюсь изменить это репо . Могу я просто пропустить эту строку на здании?

Привет

Случайным образом сборка докеров выбирает имя хоста, начинающееся с нуля, что нарушает работу нашего приложения, я попытался запустить «hostname» в этом случае внутри своего DockerFile, но столкнулся с той же проблемой.

Я также хотел бы иметь возможность запускать сборку докеров с помощью RUNP или получить возможность выбрать имя хоста во время сборки.

Кто-нибудь пробовал создавать такие изображения с Dockerfile @maneamarius на Docker для Mac, и, похоже, он успешно строится, когда вы вызываете команду Kaniko docker run "build" с помощью --cap-add=SYS_PTRACE . Хотя у меня возникают некоторые проблемы с загрузкой полученного tarball локально, использование ОЗУ немного велико, так как он не может использовать overlayfs, а кэширование слоев по-прежнему остается незавершенным. Все может работать, если я нажму на реестр, но я еще не пробовал.

docker run --cap-add=SYS_PTRACE --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --context=/workspace --tarPath=/workspace/test.tar --destination=test  --single-snapshot

Наличие этой функции значительно поможет усилиям по созданию образов Docker через Puppet на базовых образах Redhat / CentOS.

С момента последней публикации я следил за изменениями в RUN итерации сохранения и запуска, но мы можем кэшировать alpine , ubuntu и другие популярные базы).

Это в состоянии, когда мне удалось создать Dockerfile @maneamarius, который представляет Golang в образе Gentoo в этом проекте / демонстрации, не изменяя Dockerfile @maneamarius и не разрушая его каким-либо образом ( EDIT: я с тех пор пришлось изменить Dockerfile чтобы закрепить базовый образ gentoo на версии, которая была latest на момент публикации. В противном случае он все еще не изменен. ):

https://github.com/nelsonjchen/kaniko-privileged-maneamarius-moby-1916

Я также настроил Azure Pipelines для встраивания Dockerfile в образ с помощью Kaniko с --cap-add=SYS_PTRACE , загрузки выходного архива Kaniko и запуска go version в сгенерированном образе. Я подумал, что будет интересно какое-нибудь интерактивное «доказательство жизни». Некоторые из предыдущих комментариев здесь также касались систем CI, поэтому я решил, что настрою общедоступную систему CI, чтобы она также работала. Кстати, Travis CI рассматривался, но вывод сборки был слишком длинным, и он был прерван, и Azure полностью довольна 166 тыс. Строк вывода. Если бы Dockerfile был построен с примерно на 70 тыс. Строк вывода меньше, он, вероятно, преуспел бы в Travis CI. Ссылка на выходные данные сборки Azure Pipeline находится в верхней части README.

Используйте buildah Luke

Я закрываю этот вопрос, потому что функция теперь доступна как docker buildx build --allow security.insecure

https://github.com/docker/buildx/blob/master/README.md# --allowentitlement
https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run --- securityinsecuresandbox

@AkihiroSuda Я обновил докер до версии 19.03, чтобы попробовать buildx . Когда я пробовал команду, которую вы упомянули, она выдает мне ошибку

$ docker buildx build --allow security.insecure -t sample-petclinic -f Dockerfile .
[+] Building 0.0s (0/0)                                                                                                                                                         
failed to solve: rpc error: code = Unknown desc = entitlement security.insecure is not allowed

Docker version :

Client: Docker Engine - Enterprise
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        c92ab06
 Built:             Tue Sep  3 15:57:09 2019
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       c92ab06
  Built:            Tue Sep  3 15:55:37 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

документы buildx: For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

Спасибо @AkihiroSuda . Теперь это сработало.

просто чтобы добавить еще один вариант использования.
Я пытаюсь исправить сборку dockerfile контейнера ibmdb2 с тестовой базой данных
IBM удалила образ v10 из хаба. Но образ БД v11 начинается только с --privileged.
Таким образом, весь код, настраивающий базу данных в Dockerfile, теперь не работает, потому что db2 не запускается без привилегий. :(
Кажется, есть сложный обходной путь с использованием docker run и docker commit.
В продуктивном конвейере сборки это создает дополнительную сложность.

Я должен спросить, например, https://github.com/maneamarius в https://github.com/moby/moby/issues/1916#issuecomment -361173550

Почему это так важно? Сборка действительно выполняет запуск под капотом.

В этом конкретном случае использования привилегированный вариант сборки будет поддерживать своего рода «обратную совместимость», и я знаю, что не единственный, у кого возникла эта проблема после моего веб-исследования.

@uvwild Я не уверен, поможет ли это вашему kaniko. Ваш образ будет построен без docker deamon, и вы можете извлечь образ, как только он будет готов, а использование kaniko - это просто запуск контейнера вы можете использовать --privileged или --cap-add <capability which is needed> которые могут решить вашу проблему.

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

РЕДАКТИРОВАТЬ: как сказал @ alexey-vostrikov, buildah может быть более подходящим решением для случаев использования, которым требуется --privileged для создания изображения