Si optamos por esto, estoy más a favor de la opción RUNP, en lugar de tener
todos los contenedores se ejecutan en modo privilegiado.

El miércoles 18 de septiembre de 2013 a las 13:07, Benjamin Podszun
[email protected]ó :

Actualmente parece que no hay forma de ejecutar operaciones privilegiadas fuera de
Docker ejecutar -privileged.

Eso significa que no puedo hacer las mismas cosas en un Dockerfile. Mi reciente
problema: me gustaría ejecutar fusible (para encfs) dentro de un contenedor. Instalando
fusible ya es un desastre con hacks y desagradables soluciones (consulte [1] y [2]),
porque mknod falla / no es compatible sin un paso de compilación privilegiado.

La única solución alternativa en este momento es realizar la instalación manualmente, utilizando
run -privileged, y creando una nueva 'imagen base fusible'. Lo que significa que yo
no se puede describir el contenedor completo, desde una imagen base oficial hasta el final,
en un solo Dockerfile.

Por lo tanto, sugiero agregar

• una construcción de Docker -privileged
  esto debería hacer lo mismo que ejecutar -privileged, es decir, eliminar todos
  limitaciones de los topes

o

• un comando RUNP en el Dockerfile
  esto debería .. bueno .. EJECUTAR, pero con _P_rivileges

Intenté buscar en la fuente, pero soy inútil con go y no pude encontrar un
punto de entrada decente para adjuntar una prueba de concepto, desafortunadamente. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: # 514 (comentario) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
Responda a este correo electrónico directamente o véalo en Gi
.

Víctor VIEUX
http://vvieux.com

En realidad, es posible que tengamos que hacer ambas cosas, es decir, RUNP + requiere un "-privileged"
bandera.

Si confiamos solo en RUNP (sin requerir "-privileged"), entonces
Tengo que preguntarme cuando hacemos una compilación "¿esta compilación es segura?".
Si confiamos solo en "-privileged", perdemos la información (en el
Dockerfile) que "esta acción requiere privilegios extendidos".

Creo que una combinación de ambos es la forma más segura.

El miércoles 18 de septiembre de 2013 a las 4:07 a.m., Benjamin Podszun
[email protected]ó :

Actualmente parece que no hay forma de ejecutar operaciones privilegiadas fuera de
Docker ejecutar -privileged.

Eso significa que no puedo hacer las mismas cosas en un Dockerfile. Mi reciente
problema: me gustaría ejecutar fusible (para encfs) dentro de un contenedor. Instalando
fusible ya es un desastre con hacks y desagradables soluciones (consulte [1] y [2]),
porque mknod falla / no es compatible sin un paso de compilación privilegiado.

La única solución alternativa en este momento es realizar la instalación manualmente, utilizando
run -privileged, y creando una nueva 'imagen base fusible'. Lo que significa que yo
no se puede describir el contenedor completo, desde una imagen base oficial hasta el final,
en un solo Dockerfile.

Por lo tanto, sugiero agregar

• una construcción de Docker -privileged
  esto debería hacer lo mismo que ejecutar -privileged, es decir, eliminar todos
  limitaciones de los topes

o

• un comando RUNP en el Dockerfile
  esto debería .. bueno .. EJECUTAR, pero con _P_rivileges

Intenté buscar en la fuente, pero soy inútil con go y no pude encontrar un
punto de entrada decente para adjuntar una prueba de concepto, desafortunadamente. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: # 514 (comentario) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
Responda a este correo electrónico directamente o véalo en Gi
.

@jpetazzo https://twitter.com/jpetazzo
Última publicación de blog: http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

Suena razonable. Para mí, esta característica (poder crear nodos de dispositivo) hace o rompe la capacidad de crear la implementación en Docker. Si puedo ayudar (probando principalmente, intenté buscar en la fuente pero fallé hasta ahora. Parece que los comandos disponibles en un archivo de compilación se encuentran a través de la reflexión, agregué un comando runp que configuró config.privileged en verdadero, pero hasta ahora No puedo construir y probar -> atascado) Con mucho gusto invertiría algo de tiempo.

Sugeriría RUNP + build -privileged .

_ enciende algunas señales de humo para llamar la atención de @shykes , @crosbymichael_

... Y luego tendremos que encontrar a alguien que lo implemente, por supuesto ☺
¿Sería eso algo que le gustaría probar (con la orientación y los comentarios adecuados del equipo central, por supuesto)?

Si la última parte estaba dirigida a mí: Claro, ¿por qué no? Ya estoy jugando con el código de go (no es un idioma con el que esté familiarizado, pero vea más arriba: estoy tratando de averiguar qué está pasando de todos modos).

Con un par de consejos / alguien a quien hacer ping para algunas preguntas, ciertamente lo probaría.

No estoy vendido en RUNP ni con privilegios de construcción.

Generalmente no me gusta nada que introduzca diferentes compilaciones posibles de la misma entrada. Es por eso que no puede pasar argumentos o variables env a una compilación.

Específicamente, no me gusta introducir dependencias de "privilegiados" en todas partes, porque designa un conjunto de capacidades que es a) muy grande yb) no está claramente especificado o definido. Eso está bien como un mecanismo burdo para que los administradores de sistemas eludan la seguridad de una manera de todo o nada: una "escotilla de escape" cuando el entorno de ejecución estándar de la ventana acoplable no es suficiente. En ese sentido, es similar a bind-mounts y lxc-conf personalizado.

-
@solomonstre
@getdocker

El viernes 20 de septiembre de 2013 a las 3:18 p.m., Benjamin Podszun
[email protected] escribió:

Si la última parte estaba dirigida a mí: Claro, ¿por qué no? Ya estoy jugando con el código de go (no es un idioma con el que esté familiarizado, pero vea más arriba: estoy tratando de averiguar qué está pasando de todos modos).

Con un par de consejos / alguien a quien hacer ping para algunas preguntas, ciertamente lo probaría.

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -24844868

Bueno, ¿está de acuerdo en que debería ser posible crear una imagen de la ventana acoplable que, por ejemplo, ejecute fusible?
Para eso necesitaríamos mknod.

A mi modo de ver, no hay forma de que estas compilaciones sean diferentes según los parámetros: la compilación funcionará (los límites no están / menos restringidos que ahora) o fallará (status quo). Hay poco o ningún riesgo de que existan diferentes 'versiones' del mismo archivo de compilación, ¿verdad?

Me estoy encontrando con este problema ahora. Para construir la imagen que necesito, tengo que realizar una serie de run -privileged pasos + un commit paso, en lugar de build ing un Dockerfile. Idealmente, sería bueno expresar los pasos de construcción de la imagen en un Dockerfile.

¿También está relacionado con las operaciones de mknod?
Si pudiera describir exactamente las acciones que requieren el modo privilegiado en
su caso, sería muy útil!
Gracias,

Hola @jpetazzo , de la lista de correo, aquí está el problema al que me enfrento: https://groups.google.com/forum/#!topic/docker -user / 1pFhqlfbqQI

Estoy tratando de mount a fs que creé (creado para trabajar con aufs y algo sobre el diario ) dentro del contenedor. El comando específico que estoy ejecutando es mount -o loop=/dev/loop0 /db/disk-image /home/db2inst1 , donde /db/disk-image se creó con dd if=/dev/zero of=disk-image count=409600 y home/db2inst1 es desde donde estoy tratando de iniciar db2.

Si lo entiendo correctamente, durante el proceso de instalación, necesita un directorio que no sea AUFS, o más bien, algo que admita O_DIRECT . Si ese es el caso, Docker 0.7 debería resolver el problema, ya que usará ext4 (e instantáneas a nivel de bloque) en lugar de AUFS.

+1 para esto también.

La instalación de paquetes que requieren cambios en la configuración de la memoria y la configuración del kernel (por ejemplo, Vertica DB, WebSphere MQ) solo se puede realizar en modo privilegiado.

Intentemos separar las preocupaciones cuando se trata de ejecutar / compilar con "privilegiados": puede ser necesario solo durante la compilación, solo durante la ejecución a través de docker run o ambos.

Debería ser posible permitir que una compilación haga algo que requiera un poco más de permisos para un paso (o más) si es necesario. Necesitaba esto para un proyecto y tuve que convertir la mitad de un Dockerfile en un script de shell que invocaba la compilación y continuaba compilando cosas en modo privilegiado, por lo que sería útil tener una compilación "privilegiada".

Sin embargo, no deberíamos bajar completamente al modo privilegiado de forma predeterminada solo para poder usar sysctl para cambiar algunas configuraciones. Esto debe hacerse a través de la configuración de imagen o mediante argumentos de línea de comando que se pasarán a docker run .

Derecha. @orikremer , ¿tiene detalles sobre los parámetros que Vertica DB y WebSphere MQ estaban intentando cambiar?

Si se trata de cosas en / sys o / proc, la mejor solución podría ser colocar una maqueta allí en su lugar, en lugar de cambiar al modo privilegiado (ya que los cambios no se mantendrán de todos modos).

A largo plazo, un sistema de archivos simulado podría capturar el cambio y convertirlos en directivas Dockerfile, indicando al tiempo de ejecución que "oye, este contenedor necesita tal o cual ajuste".

@jpetazzo Han pasado un par de días desde que creé la imagen. AFAIR Vertica se quejaba de que no tiene suficiente memoria y ambos intentaban cambiar el máximo de archivos abiertos.
Intentaré recrear la imagen usando un Dockerfile y reportaré.

Tomando nota del problema n. ° 2080 ya que está relacionado.

@jpetazzo comenzó a recrear la imagen sin privilegios. Dos cuestiones hasta ahora:

• nice in limits.conf: Vertica agrega "dbadmin - nice 0" a /etc/security/limits.conf. Cuando intento cambiar a ese usuario cuando se ejecuta en un contenedor sin privilegios, aparece el error "No se pudo abrir la sesión". En un contenedor privilegiado, el cambio de usuario funciona sin errores.
• max archivos abiertos: dado que el máximo necesario en el contenedor era mayor que el establecido en el host, tuve que cambiar /etc/init/docker.conf en el host y establecer "limit nofile" y luego ulimit -n en el contenedor. ¿Es ese el enfoque correcto?

Al intentar cambiar a ese usuario,

¿Cómo ocurre el cambio? No entiendo cómo -privileged ayudaría con el cambio de usuario; Probablemente me esté perdiendo algo aquí :-)

max archivos abiertos

Si lo entiendo correctamente, el instalador vertical intenta establecer el número máximo de archivos abiertos en un número muy alto, y eso solo funciona si Docker se inició con un número tan alto _o_ con la bandera -privileged ; ¿Derecha?

cambiar de usuario - su dbadmin falla con ese error.
Pude reproducir por:

• extraer una nueva imagen (centos-6.4-x86_64) y ejecutar sin privilegios
• useradd testuser
• editar /etc/security/limits.conf, agregar "testuser - nice 0"
• intente su testuser -> debería fallar con "no se pudo abrir la sesión"
  En un contenedor privilegiado su testuser funciona bien.

max archivos abiertos - correcto. el instalador intenta establecer un número superior al que tiene el host. Solo al aumentar la configuración de hosts o al iniciar -privileged, esto funciona.

Intenté con el siguiente Dockerfile:

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

Y funciona bien. ¿Cuál es el nombre exacto de la imagen que estás usando?
(¡Intenté centos-6.4-x86_64 pero parece que no puedo jalarlo!)

@lukewpatterson ¿Puedes compartir cómo conseguiste que el sistema de archivos de bucle funcionara dentro de tu contenedor?

@jpetazzo Ejecutando este archivo acoplable

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

falló con:

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$

Encendí la depuración para el módulo PAM (agregando debug a la línea pam_limits.so en /etc/pam.d/system-auth ), instalé syslog , intenté su nuevamente, y esto es lo que encontré en /var/log/secure :

7 de octubre 14:12:23 8be1e7bc5590 su: pam_limits (su: session): lectura de la configuración de '/etc/security/limits.conf'
7 de octubre 14:12:23 8be1e7bc5590 su: pam_limits (su: session): process_limit: Processing - agradable 0 para USUARIO
7 de octubre 14:12:23 8be1e7bc5590 su: pam_limits (su: session): configuración de lectura de '/etc/security/limits.d/90-nproc.conf'
7 de octubre 14:12:23 8be1e7bc5590 su: pam_limits (su: session): process_limit: procesando soft nproc 1024 para DEFAULT
7 de octubre 14:12:23 8be1e7bc5590 su: pam_limits (su: session): No se pudo establecer el límite para 'agradable': Operación no permitida

Luego strace d el proceso su y descubrí que la siguiente llamada al sistema estaba fallando:

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

Esto, a su vez, hace que el módulo pam_limits informe una falla; y esto evita que su continúe.
Curiosamente, en Ubuntu, pam_limits no está habilitado para su de forma predeterminada; e incluso si lo habilita, la llamada setrlimit falla, pero su continúa y funciona de todos modos.
Podría estar relacionado con el código de auditoría, no estoy seguro.

Ahora bien, ¿por qué falla setrlimit ? Porque al contenedor le falta la capacidad sys_resource , que es necesaria para aumentar cualquier tipo de límite.

Creo que solo comentaría esa directiva limits.conf .
(Por cierto, es una mala práctica agregar cosas directamente a limits.conf ; creo que debería ir a un archivo separado en limits.d ).

Nota: dado que ya aumentó el límite para la cantidad de archivos abiertos para Docker, también podría aumentar el límite para la prioridad máxima; ¡Eso debería funcionar también!

Espero que esto ayude.

En ese Dockerfile, tiene la siguiente línea por sí sola:

RUN su testuser

No hay un comando que vaya con esto (y no aplicará ningún shell resultante a los comandos RUN posteriores), por lo que no me sorprendería si realmente falla al intentar abrir un shell y no estar en un lugar interactivo en el que hacerlo tenga sentido. (ya que docker build no es un proceso interactivo). No tengo tiempo en este momento para confirmar, pero probablemente valga la pena intentarlo con un comando real que se pasa a su .

@jpetazzo Gracias por la descripción detallada. Intentaré aumentar la prioridad máxima para Docker y ver si eso ayuda.

(Por cierto, es una mala práctica agregar cosas directamente a limits.conf; debería ir a un archivo separado en limits.d, creo).

De acuerdo, pero como este es el código de instalación de Vertica que lo está poniendo allí, estoy tratando de solucionarlo.

@tianon Lo mismo sucede si ejecuto esto en un shell interactivo (/ bin / bash).

Mis disculpas, creo que aún valió la pena intentarlo.

Sin embargo, el punto sobre esa línea que no tiene mucho sentido en el Dockerfile todavía se aplica. Probablemente quisiera algo más como esto (después de descubrir los problemas de límites):

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

@tianon tienes razón, no tiene mucho sentido. Eso fue simplemente para demostrar que el su mismo falla.

Para volver a la discusión original: creo que está bien desde un punto de vista de seguridad (¡y útil!) Permitir capacidades de setfcap y mknod en el proceso de compilación (y probablemente en la ejecución regular del contenedor como bien). ¿Alguien ve algún problema que pueda derivarse de eso?

@jpetazzo ¡ Todo lo contrario! Resolvería muchos problemas que estoy encontrando. Creo que esto es necesario para las personas que desean ejecutar contenedores Docker que actúan / se parecen más a una máquina real.

¡OK! Si le parece bien, estoy cerrando este problema a favor del # 2191, "Habilite las capacidades de mknod y setfcap en todos los contenedores", entonces :-)

¿Conocemos estos escenarios?

El domingo 13 de octubre de 2013 a las 12:22 p. M., Unclejack [email protected] escribió:

2191 https://github.com/dotcloud/docker/issues/2191 no resuelve esto

problema para todos los escenarios que requerirían la construcción de Docker -privileged.

-
Responda a este correo electrónico directamente o véalo en Gi
.

@jpetazzo https://twitter.com/jpetazzo
Última publicación de blog:
http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

@jpetazzo Esto es necesario cuando desea utilizar un Dockerfile para crear una imagen del sistema operativo.

Eliminé mi comentario por error al editarlo.

Eche un vistazo a cómo se vería esto sin hacer todo en un 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

Esto solo me obliga a solucionar la falta de runp en el Dockerfile o docker build -privileged , lo que hace que los Dockerfiles sean inútiles y me obliga a escribir una herramienta para duplicar la funcionalidad similar a Dockerfile.

Obviamente, el Dockerfile sería mucho más útil con runp o docker build -privileged :
ejemplo de 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 ejemplo:

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

@unclejack : lo siento, ¡mi pregunta no fue lo suficientemente precisa!
Lo que quise decir fue "¿qué permiso necesitas exactamente (además de mknod y setfcap)?"

@jpetazzo Es difícil de decir, tendría que auditar esto de alguna manera para averiguar qué se necesita. Montaje de sistemas de archivos, usando dispositivos de bloque montados en bucle invertido y algunas otras cosas.

Hay al menos tres necesidades separadas cuando se trata de construir imágenes: permisos requeridos durante un docker build , permisos requeridos cuando se ejecuta un contenedor con docker y necesidades de tiempo de ejecución para procesos durante la construcción, ejecución o ambos (como sysctls y otros) .

Creo que tener docker build -privileged (o runp para usar el modo privilegiado solo para los comandos que realmente lo necesitan) sería útil.

Ah, definitivamente las monturas son grandes. Ese es un caso de uso muy válido, y _probablemente_ no queremos permitirlos en el caso general. Estoy reabriendo el problema.

@jpetazzo RE: módulo PAM (también estoy instalando Vertica) ¿Sugeriría volver a compilar la ventana acoplable después de sacar sys_resource de lxc.cap.drop?

¿Quizás algunos de estos límites se pueden establecer a través del archivo docker.conf?

Debe tenerse en cuenta que el propio Docker podría estar ejecutándose en un conjunto limitado de capacidades, por lo que estos privilegios pueden no estar disponibles para que Docker los delegue en sus contenedores. Eso sería especialmente cierto en un escenario de Docker anidado que debería emitir la tierra # 2080; esto podría permitir Docker anidado sin privilegios.

No es que esto cambie nada, excepto que es posible que las soluciones como 'runp' o '-priviledged' no tengan el éxito garantizado en todos los entornos de Docker. Eso debe tenerse en cuenta al agregar dichos comandos y al documentarlos.

@ramarnat @jpetazzo solo para cerrar el ciclo en la instalación de Vertica y el problema del nivel agradable,
Intenté establecer el límite agradable en docker.conf, pero eso no funcionó para mí y me vi obligado a ejecutar bash privilegiado e instalarlo manualmente.

@orikremer @jpetazzo Pude ejecutar la instalación eliminando sys_resource de lxc_template.go y volviendo a compilar la ventana acoplable. Puedo publicar una solicitud de extracción, pero esperaré a que otros opinen sobre las implicaciones de seguridad de eliminar eso de la configuración de lxc.

@ramarnat : dependiendo del escenario, algunas personas pensarán que eliminar sys_resource está bien; para otros, será un problema.

Una posibilidad podría ser aumentar los límites base a algo más alto (los descriptores de archivo también son un problema para Elastic Search). Esto sería como afirmar que "un tiempo de ejecución mínimo de Docker debería poder manejar 1,000,000 descriptores de archivos". Si Docker no puede aumentar el límite cuando se inicia, emitirá una advertencia y continuará (como lo hace para el grupo de controladores de memoria / intercambio).

Sin embargo, esto no soluciona el escenario de montaje / bucle (todavía estoy durmiendo en este).

@jpetazzo quizás proporcione una forma de anular los valores codificados en lxc_template.go. Ya hay algo para el escenario con la línea de comando -lxc_conf, pero no funciona para la naturaleza .drop de estas directivas de configuración lxc. ¡Lo intenté!

Bueno, esa es una posibilidad, pero también es una buena manera de romper la compatibilidad futura entre diferentes sistemas de contenedorización :-) Veremos si no podemos encontrar algo mejor.

¿Podríamos incluir en la lista blanca / dev / loop * en modo no privilegiado? Supongo que el problema es que podría darme acceso a los archivos montados en bucle de otros contenedores, o incluso a los del host ...

@solomonstre
@estibador

El jueves 17 de octubre de 2013 a las 6:09 p.m., Jérôme Petazzoni
[email protected] escribió:

Bueno, esa es una posibilidad, pero también es una buena manera de romper la compatibilidad futura entre diferentes sistemas de contenedorización :-) Veremos si no podemos encontrar algo mejor.

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -26565782

@jpetazzo Eso es cierto, pero creo que Docker necesitará una forma estándar de anular la configuración de los sistemas de contenedorización subyacentes si está permitido, ¡volviendo a la consideración de construcción privilegiada, supongo!

@solomonstre El punto es que tiene que haber una manera de permitir que docker build compile en modo privilegiado. Permitir el acceso a / dev / loop * no me ayudará con mi caso de uso particular.

@solomonstre :

Entiendo que algunas compilaciones requerirán dispositivos de bucle, montajes y otras cosas. Repasemos nuestras opciones:

1. docker build -privileged
   Conveniente, pero marca la línea entre "compilaciones normales" y "compilaciones privilegiadas". Si tiene una imagen muy útil que requiere un constructor privilegiado, será difícil construirla sobre constructores públicos. Por ejemplo, si alguien inicia un servicio para automatizar compilaciones, probablemente no ofrecerá compilaciones privilegiadas (o tendrá que usar protecciones adicionales).
2. Relaja un poco los permisos en el constructor.
   Esto significa (al menos) habilitar cap_sysadmin (esto hace que el paranoico me estremezca un poco), y tal vez darle uno o dos dispositivos de bucle a cada constructor. Esto limitaría el número total de constructores que se ejecutan en paralelo; pero no es un gran problema, ya que se supone que las compilaciones son procesos rápidos y, lo que es más importante, activos. Es decir, si tiene 50 compilaciones ejecutándose en paralelo, a menos que tenga una máquina con un subsistema de E / S kickass, esas compilaciones no progresarán mucho.
3. Envuelva la construcción dentro de otra capa de virtualización / aislamiento.
   En lugar de ejecutar la compilación directamente dentro de Docker, ejecute algo como QEMU-in-Docker o UML-in-Docker. Esta es una solución genial desde el punto de vista del desarrollador de Docker, ya que no significa trabajo adicional; esta es una mala solución desde el punto de vista del usuario de DOcker, ya que significa lidiar con otra capa de complejidad.

Me pregunto si la solución correcta podría ser permitir docker build -privileged` y, al mismo tiempo, pensar en ganchos que permitirían una implementación transparente de la opción 3. Supongamos que soy un "proveedor de compilación de Docker": si alguien solicita una compilación privilegiada, todo lo que tengo que hacer es insertar algo en algún lugar para ejecutar su proceso de compilación dentro de un entorno de espacio aislado (QEMU y UML son candidatos obvios, pero otros también pueden funcionar; son solo ejemplos convenientes).

¿Qué piensan ustedes?

@backjlack , ¿puedo preguntar cómo usa ese contenedor una vez que está construido? Qué
sucede cuando "Docker lo ejecuta" exactamente, ¿cuál es la aplicación? Solo
tratando de tener una idea de los casos de uso para esto.

El viernes 18 de octubre de 2013 a las 9:59 a. M., Jérôme Petazzoni
[email protected]ó :

@solomonstre https://github.com/solomonstre : lista blanca / dev / loop es,
En mi humilde opinión, un gran no-no, porque con la rama DM, daría lectura / escritura
acceso a todo (ya que el comportamiento predeterminado de la rama DM es usar
dispositivos de bucle para almacenar las piscinas).

Entiendo que algunas compilaciones requerirán dispositivos de bucle, montajes y otros
cosas. Repasemos nuestras opciones:

1. docker build -privileged Conveniente, pero traza la línea entre
   "compilaciones normales" y "compilaciones privilegiadas". Si tiene una
   imagen útil que requiere un constructor privilegiado, será difícil de
   constrúyelo sobre constructores públicos. Por ejemplo, si alguien inicia un servicio para automatizar
   compilaciones, probablemente no ofrecerán compilaciones privilegiadas (o tendrán
   utilizar salvaguardias adicionales).
2. Relajar un poco los permisos en el constructor Esto significa (al menos)
   habilitando cap_sysadmin (esto hace que el paranoico me estremezca un poco), y tal vez
   dando uno o dos dispositivos de lazo a cada constructor. Esto limitaría el total
   número de constructores funcionando en paralelo; pero no es gran cosa ya que
   Se supone que las compilaciones son procesos rápidos y, lo que es más importante, activos.
   IE, si tiene 50 compilaciones ejecutándose en paralelo, a menos que tenga una máquina
   con un subsistema de E / S de gran potencia, esas compilaciones no progresarán mucho.
3. Envuelva la construcción dentro de otra capa de virtualización / aislamiento.
   En lugar de ejecutar la compilación directamente dentro de Docker, ejecute algo como
   QEMU-in-Docker o UML-in-Docker. Esta es una solución genial de un Docker
   punto de vista del desarrollador, ya que no significa trabajo adicional; esto es un pobre
   solución desde el punto de vista del usuario de DOcker, ya que significa lidiar con
   otra capa de complejidad.

Me pregunto si la solución correcta podría ser permitir que Docker build-privileged`,
y al mismo tiempo, piense en ganchos que permitan transparencias
implementación de la opción 3. Supongamos que soy un "proveedor de compilación de Docker": si
alguien solicita una compilación privilegiada, todo lo que tengo que hacer es insertar
algo en algún lugar para ejecutar su proceso de compilación dentro de un espacio aislado
entorno (QEMU y UML son candidatos obvios, pero otros podrían funcionar
también; son solo ejemplos convenientes).

¿Qué piensan ustedes?

-
Responda a este correo electrónico directamente o véalo en Gi
.

+1 - Me gustaría ver las capacidades de mknode para instalar fusibles (para montar cubos S3) o la capacidad de ejecutar ejecuciones privilegiadas en Dockerfiles. Aún no estoy seguro de cuál es la mejor solución.

+1. alguna actualización sobre este tema?

+1
El 17 de noviembre de 2013 a las 11:31 p. M., "Yukw777" [email protected] escribió:

+1. alguna actualización sobre este tema?

-
Responda a este correo electrónico directamente o véalo en Gi
.

También encontré el problema de Fuse al intentar instalar Java y estoy interesado en una solución. Probé la solución alternativa sugerida aquí https://gist.github.com/henrik-muehe/6155333 pero no me funciona en la ventana acoplable de la Raspberry Pi.

@jpetazzo : Me gusta la estrategia general de implementar la bandera -privileged mientras se explora al mismo tiempo una solución a más largo plazo. Con ese fin, envié una solicitud de extracción para implementar esta función. Tenga en cuenta que a partir de ahora, no implementa el comando "RUNP" como se discutió anteriormente en este hilo.

(Permítanme "publicar de manera cruzada" esto, ya que las personas podrían terminar aquí buscando una solución alternativa)

Si en realidad no está utilizando el archivo del dispositivo (pero es solo parte de un script post-inst como en el caso del paquete fusible), puede hacer lo siguiente:

fakeroot apt-get ...

o:

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

Estoy seguro de que tiene buenas intenciones, pero el primer comentario / mi informe ya incluía dos soluciones.
Para ser justos, agregó nuevos a la lista, pero el problema no es 'No se puede instalar fusible' y leer la primera publicación debería ayudar a las personas que solo necesitan el paquete para instalar sin importar qué.

El problema real es 'Necesito llamar a mknod' (o más genérico: necesito operaciones privilegiadas que hasta ahora fallan).

@jpetazzo Esto podría arreglar eso, ¿verdad? https://lwn.net/Articles/564977/ - Hasta entonces, optaría por 3) porque aislar el acceso al dispositivo _es_ otra capa de complejidad y tiene que ser administrado en alguna parte.

Tampoco estoy convencido de que el montaje en bucle o el fusible sea una característica necesaria. Se siente una locura otorgar a un contenedor en uso permisos de raíz de espacio para montar un sistema de archivos que está (fusible: la implementación se ejecuta, bucle: el archivo de imagen está) en el espacio de usuario.

Si necesita montar una imagen del sistema de archivos o fusionar fs, puede montarlo fuera del contenedor y usarlo como un montaje de volumen / enlace. Aunque podría ser una buena característica para admitir y administrar sistemas de archivos remotos en docker iself. Tal vez un dockerfile MOUNT/punto de montaje.

@discordianfish 3) es prácticamente una no solución.

¿Ayudaría # 2979 con este problema?

También estoy esperando una resolución para esto, pero no por mknod. Estamos ejecutando contenedores centos con rpms que establecen límites para los usuarios que usan /etc/security/limits.d/ y actualmente estoy usando una solución alternativa que consiste en:

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

en la parte superior de mi Dockerfile. (Solo estamos haciendo prototipos, no te preocupes :))

Hola @jpetazzo Probé las dos opciones que

sudo docker build - privileged -t oracle_xe porque en mi Dockerfile quiero ejecutar estos 2 comandos

RUN mount -o remontaje, tamaño = 3G / dev / shm
Montaje RUN -a

Pero eso no funciona, no sé si la sintaxis que utilicé es incorrecta, el error que obtengo es
bandera proporcionada pero no definida: -privileged

También probé la segunda opción para usar RUNP pero eso tampoco funcionó, cuando construyo la imagen, omite ese paso diciendo

Omitiendo instrucción desconocida RUNP. Puedo enviarte el Dockerfile que estoy intentando construir. Por favor ayudame a resolver este problema.

Gracias.

Creo que no se implementaron ni RUNP ni "build --privileged".
Si es posible, no dude en compartir el Dockerfile; podría ser útil
podemos darle la solución "menos peor" :-)

El miércoles 9 de abril de 2014 a las 7:44 a.m., Manoj7 [email protected] escribió:

Hola jpetazzo, probé las dos opciones que sugieres. Estoy tratando de construir
una imagen "oracle_xe" usando

sudo docker build - privilegiado -t oracle_xe porque en mi Dockerfile i
quiero ejecutar estos 2 comandos

RUN mount -o remontaje, tamaño = 3G / dev / shm
Montaje RUN -a

Pero si eso no funciona, no sé si la sintaxis que utilicé es
incorrecto. También probé la segunda opción para usar RUNP pero eso tampoco
funciona, cuando construyo la imagen se salta ese paso diciendo
Omitiendo instrucción desconocida RUNP. Puedo enviarte el Dockerfile que soy
tratando de construir. Por favor ayudame a resolver este problema.

Gracias.

Responda a este correo electrónico directamente o véalo en Gi
.

@jpetazzo https://twitter.com/jpetazzo
Última publicación de blog:
http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

Hola @jpetazzo , me gustaría hacer un "EJECUTAR sudo umount / etc / hosts" en mi Dockerfile. ¿Hay alguna solución "menos peor" para esto? ;)

@jpetazzo

El Dockerfile que usé para construir la imagen oracle_xe

Desde *

MANTENIMIENTO * * * * * * *

AÑADIR 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 remontaje, tamaño = 3G / dev / shm
Montaje RUN -a
EJECUTE cd / appl / oracle / xe && descomprima oracle-xe-11.2.0-1.0.x86_64.rpm.zip
EJECUTAR cd / appl / oracle / xe / Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm
EJECUTE 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

Lo primero que intenté fue

sudo docker build -privileged -t oracle_xe.

Esto no funcionó y luego intenté usar RUNP
Montaje RUNP -o remontaje, tamaño = 3G / dev / shm
Montaje RUNP -a
esto tampoco funcionó, se omitieron estos dos pasos.

@gatoravi : desafortunadamente, desmontar / etc / hosts no funcionará fácilmente. ¿Por qué necesitas hacer eso? (Entiendo que puede tener razones muy válidas, pero me encantaría escucharlas para darle la mejor solución ...)

@ Bhagat7 : ¡cierto! Pregunta: ¿necesita el / dev / shm más grande en tiempo de ejecución _y_ en tiempo de instalación, o solo en tiempo de ejecución? Si es en el momento de la compilación, ¿qué paso está fallando y cómo?

@jpetazzo Me gustaría agregar una nueva dirección IP a / etc / hosts como parte del proceso de construcción de mi herramienta.
Algo como echo $IP $HOST >> / etc / hosts.

Puedo hacer esto bien si uso docker run --privileged y luego hago un sudo umount \etc\hosts pero parece que no puedo comprometerme usando docker commit por lo tanto, tengo que repetir el umount paso cada vez manualmente cuando ejecuto un contenedor.

Me gustaría de alguna manera hacer que \etc\hosts se pueda escribir y hacerlo persistente, parece que no puedo encontrar la manera de hacerlo con docker commit o con un Dockerfile.

@jpetazzo

Tuve este problema

bash-4.1 # / etc / init.d / oracle-xe configure
Especifique el puerto HTTP que se utilizará para Oracle Application Express [8080]:

Especifique un puerto que se utilizará para el oyente de la base de datos [1521]: 1521

Especifique una contraseña que se utilizará para las cuentas de la base de datos. Tenga en cuenta que lo mismo
La contraseña se utilizará para SYS y SYSTEM. Oracle recomienda el uso de
diferentes contraseñas para cada cuenta de base de datos. Esto se puede hacer después
Configuracion inicial:
Confirma la contraseña:

¿Desea que Oracle Database 11g Express Edition se inicie en el arranque (y / n) [y]: y

Iniciando Oracle Net Listener ... Hecho
Configurando la base de datos ... Hecho
Iniciando la instancia de Oracle Database 11g Express Edition ... Hecho
La instalación se completó con éxito.
bash-4.1 # cd /u01/app/oracle/product/11.2.0/xe/bin
base-4.1 # sqlplus
Ingrese el nombre de usuario: sistema
Ingrese Contraseña: * **
Pero me sale este error
ORA-01034: ORACLE no disponible
ORA-27101: el reino de memoria compartida no existe
Linux-x86_64 Error: 2: No existe tal archivo o directorio
ID de proceso: 0
ID de sesión: 0 Número de serie: 0
df -h dentro del contenedor devuelto
Tamaño del sistema de archivos utilizado% de uso disponible montado en
tmpfs 64M 0 64M 0% / dev / shm

Entonces, cuando aumenté el tamaño de tmpfs a 3G, no obtuve este error. Lo resolví ejecutando el contenedor como
sudo docker run -privileged -i -t oracle_xe / bin / bash. Ejecuté los 2 comandos de montaje dentro del contenedor. Pero no quiero hacerlo de esa manera, sino que quiero ponerlos en mi Dockerfile y compilarlo.

@gatoravi : OK, entendido. Entonces, dos preguntas más: ¿necesita esos hosts adicionales en / etc / hosts durante la compilación, o solo durante la ejecución? ¿Y por qué lo necesitas?

@ Bhagat7 : Lo siento, todavía no tengo una solución elegante para esto :-( Sugeriría tener dos Dockerfiles:

• uno primero que hace todos los pasos (excepto el que requiere el / dev / shm más grande), y define una CMD que verificará si el contenedor se está ejecutando en modo privilegiado, montará el / dev / shm más grande y ejecutará el especial mando;
• un segundo Dockerfile para realizar más pasos (a menos que también necesite / dev / shm en tiempo de ejecución, por ahora necesita algo con privilegios).

@jpetazzo Nos gustaría proporcionar a nuestros usuarios una imagen (/ contenedor) con un / etc / hosts / editable para que puedan construir nuestro código que modifica ese archivo :) En cuanto a por qué necesitamos agregar el host, yo ' Realmente no estoy seguro de ser honesto, lo hacemos como parte de nuestra instalación para ayudar a señalar ciertos nombres de host a direcciones IP.

@ Bhagat7 He podido

1. https://github.com/wnameless/docker-oracle-xe-11g
   y
2. en el anfitrión ...

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 Muchas gracias por responder. Creo que construiste Oracle XE sobre Ubuntu. Pero estoy tratando de construirlo sobre Centos.

@jpetazzo Muchas gracias por tu sugerencia

Hola tios,

Estoy usando google-chrome, que necesita escribir en /dev/shm que parece ser generalmente 777 y 755 aquí. Intenté agregar una configuración específica a mi /etc/fstab pero no puedo ejecutar mout -a para aplicar las modificaciones en una compilación. Por supuesto que probé el básico chmod o chown pero tampoco puedo hacerlo en la compilación.

Si utilizo mis comandos cuando inicio sesión en el modo --privileged , todo está bien. Pero necesito, como explicaron otras personas, hacer esto en la construcción.

¿Cualquier sugerencia?

Gracias.

@tomav, el problema de permisos "/ dev / shm" es en realidad # 5126, que se corrigió en # 5131 y ya está combinado con el maestro (y estará en la próxima versión)

Gracias @tianon.

hoy tuve esta idea: quiero un contenedor que administre mis volúmenes de datos. fácil, pero como estoy en un vps, quiero que esos volúmenes estén encriptados, pero proporcionados a otros contenedores como de costumbre en claro. el punto es, simplemente, no tener datos claros en el disco virtual y una forma rápida de destruir mediante la eliminación de la clave.

Seguí algunos de los pasos bellamente documentados en este artículo sobre la creación de un cryptfs para colocar contenedores: https://launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

tenga en cuenta que _no_ estoy tratando de hacer eso, pero en realidad tengo un contenedor con un cryptfs montado:
por lo que se debe crear, montar y formatear un sistema de archivos cifrado durante la compilación a través de la ventana acoplable.

que falla:

• cuando trato de encontrar un dispositivo de bucle:

+ 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'.)

• extrañamente, el mismo dockerfile exacto _a veces_ tiene éxito en encontrar un dispositivo de bucle, entonces:

+ 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?

¿Hay alguna forma de evitar esto todavía? (aparte de mover los pasos de montaje / formato del disco a run )

+1 Sería especialmente útil para entornos "docker in docker"

+1 en esto, iptables no funciona en modo sin privilegios, lo que hace que todo lo que intente configurar las reglas del firewall falle.

@PerilousApricot : tenga en cuenta, sin embargo, que incluso si pudiera establecer una regla de iptables en RUN , se perdería inmediatamente, ya que una imagen contiene solo el estado del sistema de archivos. No sabe sobre procesos en ejecución, rutas de red, reglas de iptables, etc.

Eso está bien para mí, ya que el contenedor solo tendría puertos específicos
reenviado, no me preocupa el cortafuegos, en su mayoría solo quiero el
instalador para poder tener éxito en absoluto

Andrew Melo

@PerilousApricot ¡ Ya veo! En ese caso, ¿qué pasa con la vinculación simbólica de iptables a /bin/true ? Eso también debería hacer feliz al instalador. (¿O algún truco similar para engañar al instalador?)

Intenté eso, pero el instalador también necesita analizar la salida de
iptables, así que no es tan fácil :)

De acuerdo, sé que esto se está volviendo hack, pero, ¿qué tal si se pone un iptables falso en su lugar? ¿Cuál generaría una salida ficticia?

Entiendo totalmente que no es genial; pero en serio, ese tipo de instalador debería arreglarse en primer lugar :)

El caso de uso de la ventana acoplable en la ventana acoplable es lo que me trajo aquí. Bueno, docker en lxc, para ser específico, ya que nuestro entorno de desarrollo usa lxc, y me gustaría que los desarrolladores pudieran construir las imágenes en lxc.

También me gustaría esto para la ventana acoplable en la ventana acoplable. Hay una imagen que debe extraerse antes de que se pueda ejecutar la aplicación, que es bastante grande, y prefiero que se extraiga y se almacene en caché como parte de docker build lugar de tener que extraer y / o confirmar con frecuencia contenedores que lo tienen tirado.

Esta función es imprescindible en mi humilde opinión, una combinación de RUNP junto con build-privileged sería genial.

El escenario de producción / vida real al que me he enfrentado son las imágenes de Docker creadas con el aprovisionamiento de Puppet en un contenedor intermedio. En ciertos servicios que requieren capacidades elevadas, hay fallas en la compilación que requieren que el contenedor se ejecute por debajo de -privileged con un ENTRYPOINT o CMD que vuelva a aplicar el guión de la marioneta.

Esto retrasa el tiempo de inicio del servicio real dentro del contenedor, ya que la configuración de la marioneta debe construirse y luego aplicarse para garantizar el estado adecuado (y esto requiere mucho tiempo), así como el contenedor en ejecución _podría_ no necesitar ejecutarse en -privileged reales

Espero que lo anterior tenga sentido.

@jpetazzo Estoy tratando de construir un servidor web sobre centos6. Estoy varado en la configuración de reglas de iptable a través del dockerfile. Es similar al problema de

Por cierto: NO estoy a favor de implementar hacks como iptables falsos.

@pmoust : ¿tiene detalles sobre qué operaciones de compilación requieren privilegios elevados? Probablemente recomendaré evitar el problema, y ​​me doy cuenta de que esto podría no ser satisfactorio para usted; pero no obstante, me complacería entender qué tipo de instalador / constructor podría requerir esos privilegios ...

@ passion4aix : tenga en cuenta que si establece reglas de iptables en el Dockerfile, NO se guardarán. Docker solo guarda el estado del sistema de archivos, no los procesos de enrutamiento / filtrado / ejecución ... Hay formas de configurar las reglas de iptables con contenedores "sidekick". ¿Es eso algo que podría ser interesante para ti?

@jpetazzo El instalador de Bitrock es un ejemplo. Requiere que / tmp se monte como tmpfs. Es posible que desee echar un vistazo a http://answers.bitrock.com/questions/3092/running-installer-inside-docker

@jpetazzo o básicamente cualquier instalador de openstack

También me encontré con un problema similar al intentar ejecutar TokuMX en un contenedor Docker, ya que TokuMX requiere que la opción de kernel 'transparent_hugepage' esté deshabilitada.

¿Hay algún avance en este tema? Ya tiene más de un año y, mirando los comentarios, la mayoría de la gente tiene uso para ejecutar acciones privilegiadas desde un Dockerfile.

Personalmente, no optaría por la compilación con la solución '--privileged'. La solución RUNP es mejor ya que entonces solo puede ejecutar algunas acciones como usuario privilegiado en lugar de ejecutar toda la instalación como privilegiado. De esta manera, al menos, debe pensar cuándo usar RUNP y solo usarlo cuando sea necesario.

Me parece que la pregunta ya no es SI se debe agregar esta opción, sino solo cuando esté lista. Entonces, ¿cuándo podemos esperar esta funcionalidad?

@diversit Tendrían que estar acoplados. Entonces, --privileged en la línea de comando permitiría la capacidad de usar RUNP , de lo contrario, esto sería una pesadilla de seguridad para las personas que realizan compilaciones de código que no es de confianza (incluido DockerHub).

Pero también tenga en cuenta que puede hacer esto manualmente fuera de la sintaxis de Dockerfile. El proceso de compilación consiste en leer el Dockerfile, crear un contenedor a partir de él y volver a enviarlo a una imagen.

@deas : Creo que esto se puede resolver haciendo VOLUME /tmp .

@PerilousApricot : ¿puedes elaborar un poco? No entiendo por qué cualquier tipo de instalador requeriría privilegios especiales. (Sí, soy un viejo obstinado de Unix, ese es uno de mis defectos: D)

@diversit : para ese caso específico, creo que el administrador de la máquina debería deshabilitar las páginas gigantes transparentes antes de construir. Porque si al constructor se le permite hacer eso, lo hará globalmente (¿no?) Y podría romper otros contenedores que podrían requerir la función. ¿Entiendes lo que quiero decir? Sería malo si la construcción del contenedor X se rompe al ejecutar el contenedor Y ...

Todos: Entiendo totalmente que es muy frustrante cuando un Dockerfile no funciona, y todo lo que necesitas es esta bandera --privileged / RUNP . Pero si comenzamos a tener compilaciones privilegiadas, se romperán un montón de cosas (por ejemplo, compilaciones automatizadas en Docker Hub), por eso nos sentimos muy mal por ello. Y por si sirve de algo, estoy dispuesto a investigar todos los escenarios que requieran compilaciones privilegiadas y ayudar a solucionarlos :-) (¡Ya que estoy convencido de que esos instaladores no funcionan!)

@jpetazzo Muchas / la mayoría de las herramientas de implementación de openstack (por ejemplo, https://openstack.redhat.com/Main_Page) establecen reglas de iptables. Me gustaría poder desplegar / implementar versiones en contenedores de la aplicación, por lo que poder crear un archivo docker y hacerlo de una vez es importante para mí. Sé que las reglas de iptables no se conservan a través del proceso de contenedorización de forma nativa, pero se conservan a través de iptables-save, por lo que una simple restauración de iptables en el proceso de CMD hará que las reglas se vuelvan a cargar. Es mucho más complicado simplemente "eliminar" iptables porque muchas de las herramientas de implementación usan herramientas de CI como puppet o chef para realizar la implementación real, por lo que de alguna manera necesitaría hacer un stub compatible que terminaría emulando todos los las entradas / salidas al comando iptables "real".

Además, creo que es una compensación justa decir: "Si tiene un Dockerfile que requiere compilaciones privilegiadas, pierde las funciones X, Y, Z".

Oracle xe no se ejecutará sin suficiente espacio de memoria compartida. Todas las cuentas son que remontar tmpfs con suficiente espacio hacen que Oracle xe esté feliz de iniciar y completar su configuración. se rumorea que será superado aumentando el tamaño de la montura)

Durante una construcción
EJECUTAR desmontar tmpfs
falla con
umount: / proc / kcore: debe ser superusuario para desmontar

dame RUNP o dame la muerte .... o .... muéstrame lo que podría hacer de otra manera :)

Mi ejemplo no es válido; @jpefazzo sigue en pie :) Mi configuración de Oracle estaba causando el problema y parece que no hay necesidad de ajustar el tamaño de tmpfs ... al menos para la instalación inicial.

Me encuentro con un problema de iptables en CentOS 7.0 que solo se resuelve cuando run ning con --privileged https://github.com/docker/docker/issues/3416

Sin soporte para edificios privilegiados, no estoy seguro de cómo solucionar el problema.

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 Creo que con el security-opts agregado en # 8299 será posible hacer esto sin --privileged

@jpetazzo No veo cómo el uso de VOLUME /tmp resuelve el problema de los instaladores de Bitrock. Eso puede funcionar para la compilación, pero también hará que /tmp omita las capas AUFS para todos los contenedores basados ​​en esa imagen, ¿verdad? Al final del día, parece que la causa raíz debería arreglarse en AUFS.

Este es mi caso de uso: quiero crear un entorno chroot dentro de un contenedor Docker. El problema es que debootstrap no se puede ejecutar, porque no puede montar proc en el chroot:
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
Si run --privileged el contenedor, (por supuesto) funciona ...
Realmente, realmente me gustaría hacer un debootstrap del chroot en el Dockerfile (mucho más limpio). ¿Hay alguna manera de hacer que funcione, sin esperar a RUNP o build --privileged?

¡Muchas gracias!

+1 para - privilegiado o montaje. Necesidad de automatizar la construcción de glusterfs

Esto está afectando mis esfuerzos por crear una imagen a partir del instalador de Bitnami Tomcat. El 99% del proceso de instalación se ejecuta sin problemas pero, cuando intenta iniciar Tomcat por primera vez, falla con el siguiente resultado en catalina-daemon.out:

set_caps: no se pudieron configurar las capacidades
verifique que su kernel admita capacidades
set_caps (CAPS) falló para el usuario 'tomcat'
Salida de servicio con un valor de retorno de 4

Puedo ejecutar correctamente el instalador de Tomcat manualmente en un contenedor que creo con "--cap-add ALL". Parece extraño que no pueda usar 'docker build' para crear una imagen que pueda crear manualmente usando 'docker run' y luego 'docker commit'. Los contenedores que se utilizan durante el proceso de compilación deben tener toda la funcionalidad que los contenedores que puede crear utilizando 'docker run'.

@gilbertpilz De manera muy explícita, no pueden hacer eso para garantizar la portabilidad y la seguridad de la construcción.

@ cpuguy83 - Eso no tiene ningún sentido. Puedo construir la imagen que quiero, a mano, si lo hago:

docker ejecutar --cap-add ALL .... / bin / bash
bitnami-tomcatstack-7.0.56-0-linux-x64-installer.run ...
Salida
Docker commit ...

Todo lo que pido es la capacidad de usar "docker build" para hacer lo mismo que estoy haciendo manualmente aquí. No veo cómo se están "asegurando" "la portabilidad y la seguridad" si puedo crear la imagen de una manera pero no de la otra.

Ok, déjame darte un Dockerfile que monta el / etc / passwd del host en el constructor y simplemente me lo envía.

Estas cosas pueden ser peligrosas.
También tenga en cuenta que --privileged (y --cap-add ALL) le dan al usuario en el contenedor el control total del host.

Permitir estas cosas comprometería la totalidad de DockerHub

@ cpuguy83 : no es necesario que coloques el control en el Dockerfile. Puede agregar la opción "--cap-add" (o algo similar) al comando "docker build". Si seguimos su lógica, los scripts de shell no deberían permitir el uso del comando "sudo" porque alguien podría escribir un script que hiciera cosas malas.

Pero no le daría sudo a alguien en quien no confíe imicorly con las llaves del reino.
Build debe poder, de la manera más segura posible, ejecutar código que no sea de confianza.

La introducción de indicadores CLI para habilitar funciones adicionales en la compilación rompe la portabilidad de la compilación, y es por eso que aún no se ha agregado.

Dicho esto, es casi seguro que el instalador se equivoque aquí al solicitar cosas a las que él mismo no debería tener acceso.

Exactamente. No debe dar a las personas en las que no confía la capacidad de ejecutar compilaciones de la ventana acoplable que requieran privilegios, pero la ventana acoplable no debe impedir que las personas en las que usted confía lo hagan. Esta es una decisión de política y realmente no me gusta cuando las herramientas presumen de tomar decisiones de política por mí. Una buena herramienta me permite implementar las decisiones políticas que he tomado de una manera clara y no sorprendente.

No está viendo el panorama más amplio.

Hay más en este ecosistema que su servidor y mi servidor. DockerHub, por ejemplo, está haciendo compilaciones de código que no es de confianza todo el tiempo.

Entonces DockerHub definitivamente _no_ debería habilitar la adición de capacidades para sus compilaciones. Si esto significa que no puedo enviar mi compilación de docker a DockerHub, estoy de acuerdo con eso.

@ cpuguy83 @tianon @jpetazzo - Cuando comienza el FUD, me veo obligado a hablar:

Permitir estas cosas comprometería la totalidad de DockerHub

srsly?
Implementando esta característica == TEOTWAWKI?

Por supuesto, DockerHub nunca ejecutaría docker build con la bandera --privileged solicitada.
Sin pensarlo demasiado, hay al menos dos formas obvias de implementarlo:

• flag solo funciona si también lanza docker -d con alguna nueva bandera como: --i-want-a-broken-security-model
• Cree una marca en tiempo de compilación que habilite la ruta del código.

En general, la relación entre el rechinar de dientes y las razones de ingeniería contra la implementación parece realmente alta aquí.

@tamsky Y luego tenemos una situación en la que las construcciones funcionan en un lugar pero no en otro.
Estoy explicando por qué las cosas son como son, no discutiendo un caso u otro.

Pero también ... la mayoría de las cosas no necesitan ningún tipo de acceso privilegiado, y aquellas que sí necesitan acceso privilegiado generalmente no lo necesitan _realmente_ para que la instalación funcione. Si la instalación de algo falla debido a esto, ese instalador no funciona, como es el caso del problema de tomcat citado.
Habilitar tal característica alentaría a las personas a correr con el modo privilegiado en lugar de resolver el problema real en cuestión.

@ cpuguy83

Y luego tenemos una situación en la que las construcciones funcionan en un lugar pero no en otro.

Imagine por un momento que hemos sido transportados mágicamente a un mundo donde la _política_ es diferente, y algunas construcciones funcionan en un lugar pero no en otro ...

¿Por qué esto es tan importante?
¿Exactamente a quién le importa?

¿Ha considerado Docker Inc que su requisito / mantra de denominador común más bajo de "todas las compilaciones deben funcionar en todas partes" podría estar ignorando una necesidad real del cliente?

La política actual es externalizar el costo de ingeniería para que los clientes "obtengan X para construir en Docker":

En lugar de proporcionar esta función en la ventana acoplable, está forzando a todos los proyectos de terceros en el mundo que no "necesitan ningún tipo de acceso privilegiado" (pero en realidad sí), a ser actualizados primero o parcheados para manejar el caso de compilación de la ventana acoplable.

Eventualmente, si Docker se ejecutará en múltiples plataformas, la 'compilación de docker' NO funcionará de la misma manera en todos los sistemas. Es decir, una compilación de un contenedor de Windows, un contenedor de Solaris o incluso un contenedor de ARM Linux no será igual que en x86-64 Linux. El contexto de seguridad para estos también será diferente, según sea apropiado para sus plataformas.

Es decir, @ cpuguy83 , no siempre podemos suponer que Dockerfiles seguirá siendo universal. Sin embargo, estoy de acuerdo en que debemos minimizar la variación que existe entre ellos. Podría valer la pena incluir la consideración de los usuarios que desean esta función, por peligrosa que sea, en las conversaciones que, en última instancia, deben tener lugar en torno al soporte de múltiples arcos / plataformas.

Las compilaciones no funcionan en todas partes porque, por ejemplo, se cargan perfiles de armadura de aplicaciones.
Además, ¿cómo haría el caso con contenedores acoplables pre-almacenados en caché horneados en una imagen?

El 18. 11. 2014, a las 2:53, tamsky [email protected] escribió:

@ cpuguy83

Y luego tenemos una situación en la que las construcciones funcionan en un lugar pero no en otro.

Imagine por un momento que hemos sido transportados mágicamente a un mundo donde la política es diferente, y algunas construcciones funcionan en un lugar pero no en otro ...

¿Por qué esto es tan importante?
¿Exactamente a quién le importa?

¿Ha considerado Docker Inc que su requisito / mantra de denominador común más bajo de "todas las compilaciones deben funcionar en todas partes" podría estar ignorando una necesidad real del cliente?

La política actual es externalizar el costo de ingeniería para que los clientes "obtengan X para construir en Docker":

En lugar de proporcionar esta función en la ventana acoplable, está forzando a todos los proyectos de terceros en el mundo que no "necesitan ningún tipo de acceso privilegiado" (pero en realidad sí), a ser actualizados primero o parcheados para manejar el caso de compilación de la ventana acoplable.

-
Responda a este correo electrónico directamente o véalo en GitHub.

No es "el instalador" el que está "roto" en esta situación, es Tomcat 7. Estoy usando la pila Tomcat de Bitnami que integra Tomcat con Apache y MySQL. Docker se encuentra al final de una cadena de suministro de servicios de origen, configuración, integración, pruebas y empaquetado. Requerirme que "arregle" Tomcat me impide aprovechar esta cadena de suministro. Es mucho más fácil construir la imagen que quiero a mano (iniciar un contenedor con "--privileged", ejecutar el instalador, hacer una instantánea del contenedor, etc.) que "arreglar" Tomcat.

+1
No puedo transferir mis roles de chef a Docker porque todos implican el uso de ufw para abrir puertos.
agregar --privileged to build arreglaría esto.

+1. No puedo tener debootstrap como un paso en mis Dockerfiles.

+1. No puedo tener debootstrap como un paso en mis Dockerfiles.

Parecía natural construir mi chroot a través de un Dockerfile / build, pero encontré los mismos problemas que mencionó @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

falla con:

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

¿Qué tal en lugar de RUNP , tener una marca de compilación --insecure ?
Para todos los comandos RUN, el contenedor subsiguiente se ejecutará con --add-cap=all . Esto en lugar de privilegiado ya que privilegiado hace algunas otras cosas también ...
Pero realmente esto podría cambiar para implementar la configuración completa de privileged si es necesario en algún momento sin tener que modificar la bandera.

@ cpuguy83
No me importa tener que usar una bandera pasada a la compilación de la ventana acoplable que habilita los comandos RUN para tener privilegios o habilita los comandos RUNP. Es valioso poder mirar un Dockerfile y decir por los comandos o algo dentro de él, que requeriría acceso privilegiado, y en tiempo de ejecución, en lugar de llegar al paso 10 y cometer errores, habría atajado al principio que el Dockerfile contiene comandos que requieren privilegios.

El caso de uso que me trajo a este hilo son los montajes de enlace, que quiero poder hacer dentro del contenedor. En este momento, solo puede hacerlos si ejecuta el contenedor en modo privilegiado. Le obliga a encadenar comandos juntos al inicio, o tener un script de inicio que se ejecuta para completar la configuración del sistema antes del proceso que deseaba ejecutar.

Sería bueno poder tener en el Dockerfile:

RUN mount --bind /dir1 /dir2

Describiré más mi caso de uso para que esto no sea solo una solicitud amplia de comandos privilegiados. Mi caso particular es que quiero vincular el montaje de un directorio en el área de la aplicación a un volumen de datos que estaba adjunto.

p.ej

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

Esto podría resolverse también haciendo el montaje de volumen directamente en el área de la aplicación, pero estoy buscando una manera de que se proporcionen en una ubicación común y deje que el contenedor de la aplicación realice su mapeo específico. Esto también podría resolverse con enlaces simbólicos, pero algunas aplicaciones no funcionan bien con enlaces simbólicos como su carpeta de destino / datos. Y si la aplicación admite la configuración de la ubicación del directorio de datos, también se podría hacer para señalar el área de montaje del volumen. En mi caso de uso, la aplicación no admite la configuración de la ubicación del directorio de datos, y la realidad es que siempre habrá aplicaciones en las que tendrá que realizar un montaje de enlace o enlace simbólico para separar correctamente sus datos y el espacio de la aplicación.

Esta capacidad de poder hacer esto A -> B -> C permite mantener los contenedores de datos genéricos y brinda flexibilidad en las diferentes combinaciones que puede lograr con --volumes-from con contenedores de aplicaciones y datos.

También puede lograr esto si tiene una cadena de contenedores con --volumes-from :

GenericDataContainer -> ApplicationDataContainer -> ApplicationContainer

Cuál puede ser la respuesta correcta, pero podría eliminar tener que crear otro contenedor para los datos de la aplicación si el contenedor de la aplicación pudiera ejecutar un montaje de enlace.

Puedo lograr esto hoy ejecutando el contenedor en modo privilegiado y luego ejecutar el enlace de montaje, pero como verá a continuación, no hay una manera de hacer que ese enlace de montaje persista y debe reiniciarse cada vez que inicie el contenedor. . Los enlaces simbólicos se conservan en las confirmaciones.

La respuesta para mi caso de uso particular puede ser usar el enfoque de contenedor de 3 cadenas o el script de inicio, pero sería bueno tener la capacidad de enlazar montajes dentro del contenedor (u otros comandos privilegiados) desde el Dockerfile. Probablemente hay otros casos de uso para los montajes de enlaces que podrían describirse y que no involucran ningún mapeo de host a contenedor que no se puede resolver con el encadenamiento de contenedores de datos.

No estoy seguro de si se trata de un problema específico relacionado con el montaje de enlace, pero si los resultados de los comandos privilegiados persisten cuando realiza una confirmación de la ventana acoplable, podría separar la construcción de la imagen de la ventana acoplable y la ejecución de la imagen de la ventana acoplable. Puede controlar el área donde realiza la compilación de la ventana acoplable y los usuarios finales solo obtienen el contenedor comprometido que pueden ejecutar en modo sin privilegios. Actualmente, esta no es la causa cuando ejecutas un montaje de enlace y un compromiso. Sin embargo, esto podría estar más relacionado con el funcionamiento de /proc/mounts .

Aquí hay un ejemplo simple.

[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

Cree un ejemplo de montaje de enlace, también cree un ejemplo de enlace simbólico

[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

Mostrar archivo se ve desde los 3 directorios

[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

Mostrar /proc/mounts actualizado

[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

Salga del contenedor que lo detiene, luego comience de nuevo

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

/proc/mounts tiene el montaje de enlace

[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

El enlace simbólico sobrevivió, pero no se unió al montaje

[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> /]#

Montaje de enlace de reinicio

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

En lugar de salir del contenedor, separe con ctrl+p ctrl+q y luego confirme el contenedor

Confirme el contenedor como una nueva imagen, inicie un nuevo contenedor desde la imagen en modo no privado

[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

Compruebe el /proc/mounts
Falta el montaje de enlace, no estoy seguro de qué activó los montajes adicionales / 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

Symlink sobrevivió

[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

Actualmente estoy tratando de ejecutar imágenes de la ventana acoplable en mi paso de compilación, usando dind . Entonces, actualmente, ¿no hay forma de usar ejecutar imágenes de Docker en su compilación?

Todos, si desean esto, intenten '/ usr / bin / unshare -f -m -u -i -n -p -U -r - / ruta / a / binary'. Esto creará un contenedor dentro de su compilación con un espacio de nombre de usuario. Puede modificar las opciones para dejar de compartir según sea necesario. De hecho, lo uso para ejecutar '/ sbin / capsh', para establecer de forma granular las capacidades de mis procesos.

No puedo decir que esto resolverá todos los casos de usuarios para compilaciones privilegiadas, pero debería ayudar a algunos de ustedes.

Estoy de acuerdo en que esto debería convertirse en parte del propio Docker, y la integración de los espacios de nombres de usuario parece estar en progreso.

@saulshanabrook no puede ejecutar imágenes de la

No es una solución real para alguien que busca ejecutar imágenes de la ventana acoplable, pero señalaré que 'unshare' y 'capsh' funcionan, por lo que es posible hacer un tiempo de ejecución similar a un contenedor en contenedores sin privilegios (como durante una compilación ). Podría decirse que es posible dejar de lado la 'ejecución de la ventana acoplable' y realizar este paso manualmente, y volver a enviar las imágenes a la ventana acoplable. Tengo la mayor parte de esto funcionando hoy, incluso si no lo tengo todo envuelto en un moño. Eventualmente, por supuesto, dicha funcionalidad debe ingresar al propio Docker.

+1 para docker pull a través de RUNP

La imposibilidad de ejecutar la compilación de Docker con privilegios promueve la compilación manual con un shell y una confirmación de la ventana acoplable, lo que hace que los archivos Docker sean inútiles. No creo que agregar una marca privilegiada a la compilación de la ventana acoplable trazaría una línea entre las compilaciones y las compilaciones privilegiadas; esa línea ya estaba dibujada cuando se agregó la bandera para ejecutarse y necesita ser compatible.

+1 Esto hace que el contenedor docker sea reproducible en cualquier momento dado (solo es necesario llevar el dockerfile solo)

+1 tener que destrozar completamente mis roles básicos de ansible solo para trabajar en cosas como esta. Realmente esperaba que la adopción de la ventana acoplable me permitiera usar gran parte de mi código ansible existente, pero no solo ya he creado roles personalizados para el tamaño, sino que ahora tengo que solucionar problemas como este.

@lsjommer ¿qué tipo de cosas tienes que

No estoy diciendo que no implementemos esto, pero seamos realistas sobre lo que estamos hablando.

Además, esto sería relativamente fácil de implementar si alguien quiere hacerlo ...

@ cpuguy83 Esto es de nuestro rol de línea de base estándar "bare metal" que estoy tratando de adoptar en los contenedores Docker para instalar todas las bibliotecas, y se trata de la memoria compartida, pero tal vez ni siquiera necesito molestarme con eso en la compilación del contenedor. y solo necesita ejecutarlo en el host del contenedor?
http://pastebin.com/P3QQxjNQ

Admito que no entiendo completamente cómo Docker maneja el intercambio de recursos.

@ljsommer Entonces, configurar shm es una bestia diferente y no persistiría entre los comandos RUN (o para cuando realmente docker run ) de todos modos.

@ cpuguy83 Sí, creo que esto fue principalmente mi culpa en el sentido de que encontré lo que pensé que era un problema que simplemente puedo cambiar a la línea de base para el host del contenedor.
Gracias por tomarse el tiempo para responder y disculpas por no educarme adecuadamente antes de quejarme.
;)

¿Alguna idea sobre RUNP / -privileged durante el proceso de compilación?
Sería genial configurar tablas de IP para limitar el acceso de la ventana acoplable a direcciones IP especificadas

También quiero RUNP y / o "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

Este Dockerfile no funciona debido al siguiente error, pero funciona si se hace con "docker run --privileged" ...

getsockopt failed strangely: Operation not permitted

@malcm , @ sakurai-youhei: incluso si tuviera algo como RUNP , no funcionaría en este escenario, porque las reglas de iptables no persisten en el sistema de archivos.

Déjame explicarte: cuando haces RUN x , Docker ejecuta x luego toma una instantánea del sistema de archivos. Las cosas fuera del sistema de archivos (procesos en ejecución, tablas de enrutamiento, reglas de iptables, configuración de sysctl ...) no se almacenan en las imágenes de Docker.

Si desea reglas de iptables personalizadas, un método es:

• inicie su contenedor, por ejemplo, con --name myapp
• iniciar otro contenedor, privilegiado, de una sola vez, para configurar la regla de iptables, por ejemplo, docker run --net container:myapp --privileged iptablesimage iptables -t nat ...

¿Tiene sentido?

@jpetazzo : Gracias por su respuesta. En mi caso, puse el segundo comando para hacer que la regla de iptables persista como datos en el sistema de archivos como se muestra a continuación. Esto debería permitirme cargar la regla de iptables después de iniciar el contenedor con la opción --privileged.

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

Sin RUNP ni "build --privileged", me veo obligado a escribir como:

ADD iptables.rules /etc/

Sí, esto podría ser suficiente, sin embargo, necesito agregar iptables.rules junto a Dockerfile en mi repositorio.

Es por eso que quiero (o me gustaría tener suavemente) RUNP. :)

@jpetazzo @strib
Más allá de los problemas de iptables, montajes y otras operaciones privilegiadas, creo que hay un escenario de compilación que deberíamos abordar.

Enviamos dispositivos para su implementación en máquinas virtuales e instalación completa. Sin embargo, para las pruebas utilizamos entornos de contenedor. A su vez, dentro de esos electrodomésticos corremos contenedores. Por lo tanto, los contenedores de prueba deben basarse en Docker-in-Docker. Ahora imagine que tenemos una imagen de servicio que necesita ser precargada en la imagen de prueba (para que las imágenes de servicio no se descarguen del registro en el tiempo de prueba). En este momento no podemos hacer eso ya que no podemos ejecutar el contenedor d-in-d en modo privilegiado durante la compilación del Dockerfile que usa d-in-d como base: el demonio docker no se inicia, "docker pull "o" carga de la ventana acoplable "no funcionarán.

Tuve un problema en el que, cuando se ejecutaba en un host RHEL7, su fallaba si el usuario actual era root. Extrañamente, si el usuario actual era otra cosa, su funcionaba bien. Independientemente, la solución fue pasar al comando de ejecución la bandera --add-cap=SYS_RESOURCE ; Sin embargo, debido a este problema, no fue posible hacer esto durante el paso de compilación.

+1 Scripting alrededor de Dockerfiles con docker run y docker commit es ridículo. Incluya esta funcionalidad.

+1 sobre la necesidad de esta función. Creo que se podría configurar un "nivel de seguridad" global en un archivo de configuración que limita las capacidades que se le pueden dar a un contenedor. Debería haber un valor predeterminado seguro (como hoy) y un administrador de sistemas podría cambiarlo para permitir que los contenedores se ejecuten con más privilegios. Los archivos dockerfile con una instrucción RUNP de este tipo podrían fallar al ejecutarse con un mensaje como "este archivo Dockerfile requiere las siguientes capacidades ... para construir" en un sistema que tiene tales límites globales.

Creo que esto permite un equilibrio entre seguridad y usabilidad.

También tenemos este problema al intentar construir una imagen con una base de datos propietaria de evli, que permanecerá sin nombre, dentro de ella.
La base de datos quiere asignar cantidades masivas de memoria, lo que no está permitido por la ventana acoplable.

Nuestra solución alternativa actual es una compilación de 2 fases con una ejecución: paso privilegiado y un paso de confirmación independiente.

Quizás podríamos configurar la ventana acoplable para permitir la asignación de memoria de alguna otra manera. Es un poco difícil averiguar qué quiere hacer realmente la base de datos porque es propietario.

+1
para esta función.
para ejemplos históricos y de casos de uso, consulte este engaño
https://github.com/docker/docker/issues/12138#issuecomment -90536998
gracias @ cpuguy83 por señalar al engañado

Yo también tengo este problema, intentar conectarme a un recurso compartido cifs durante la compilación de la ventana acoplable no está permitido a menos que se proporcione la bandera privilegiada, ¿alguna forma de evitar esto?

Ahora hay una solicitud de extracción que implementa esto; puedes comprobar el progreso allí; https://github.com/docker/docker/issues/12261

Si algo requiere el modo privilegiado, posiblemente esté modificando el host de alguna manera, lo que significa que es posible que la imagen no sea portátil, ya que estas modificaciones deberían ejecutarse en otros hosts que intentan consumir la imagen.

Una vez que se haya fusionado # 13171, creo que deberíamos cerrar esto, ya que hará que rodar su propio constructor sea trivial y, por lo tanto, permitirá tener privilegios.
No creo que el docker build incorporado deba permitir esto.

Entonces @ cpuguy83 , si entiendo bien, la forma de respaldar este problema sería reimplementar completamente docker build pero ¿con un parámetro adicional?

Supongo que debo decir que, una vez que se apruebe el otro parche, necesitaré armar mi propia versión de docker build (¿tal vez docker pbuild ?) Para completar la funcionalidad adicional.

¿Hay algún avance en este tema? Revisé los PR mencionados anteriormente y todos fallaron.
¿Es posible hacer una opción BUILD --privileged/--granted más granular y hacer que los accesos concedidos a un grupo específico de recursos de host se limiten solo al creador / propietario de la imagen?

+1 para cualquier solución que me permita hacer RUN docker pull en un Dockerfile.

Caso de uso: necesito un montón de herramientas para la conversión de imágenes y la creación de documentación, sin embargo, todas estas herramientas no se pueden instalar en una sola imagen debido a bibliotecas en conflicto. Es por eso que separo algunas de estas herramientas en una imagen separada y me gustaría distribuir todas las herramientas en una sola imagen, es decir, imagen en imagen. Por eso quiero hacer RUN docker pull en mi Dockerfile.

@ cpuguy83 , no parece que este problema se haya resuelto a satisfacción de nadie. Absolutamente, 100%, necesito poder hacer algo tan aburrido como escribir en /proc/sys/kernel/core_pattern durante una compilación.

En el mundo actual, puedo hacer esta operación privilegiada a través de una solución alternativa run y simplemente enviar esa imagen al centro de todos modos. Además, ningún Dockerfile que haya producido _ alguna vez_ es estrictamente reproducible, porque se extraen de repositorios públicos aleatorios que cambian constantemente. No tenia idea de que

1. El consumo público de mis imágenes fue una prioridad.
2. Siempre tenían la necesidad de ser reproducibles.

La gente _ va_ a hacer malas soluciones para conseguir privileged en la construcción. Creo que definitivamente deberías ir donde están tus usuarios y permitir esto en la herramienta de compilación principal. Agrega un mensaje aterrador si es necesario.

cc @thaJeztah , que parece simpatizar con esta posición

Mira, creé un PR para habilitar esto y fue rechazado.
No veo que esto suceda con el constructor de ninguna forma.

Parecía que hiciste la última llamada. Agitaré en el hilo de relaciones públicas, entonces.

Esto es necesario para instalar los paquetes JDK 1.6 más antiguos en CentOS, ya que su intento de registro de RPM es binmft_misc, que falla sin ejecutarse con menos privilegios.

Dockerbuild no es un stater para construir contenedores con él.

Para replicar

DESDE Centos5.11
EJECUTAR yum intall -y jre-1.6.0_29-fcs

Necesitamos tener una parte de comando privilegiado de compilación como una bandera opcional. Estoy intentando portar una de nuestras aplicaciones a la ventana acoplable como un POC y falla para uno de nuestros componentes, ya que tiene configuraciones de IPtables que no se están aplicando y la compilación falla. Puedo hacer los cambios necesarios manualmente y confirmarlos, pero entonces, ¿cuál es la diversión de la compilación de docker? Es solo una parte de la compilación y debería ser fácil de transferir, ya que ya forma parte de la versión principal.

Docker debería poder ejecutar fácilmente contenedores intermedios con un conjunto de opciones privilegiadas.

@shubhamrajvanshi estamos en el proceso de mover el "constructor" del demonio (y al cliente), esto debería abrir la puerta a más personalizaciones en el proceso de compilación (incluida la posibilidad de implementar constructores personalizados). Posiblemente se pueda considerar la posibilidad de permitir compilaciones "privilegiadas", pero esa es una decisión que se puede tomar después de la refactorización. (Ver https://github.com/docker/docker/blob/master/ROADMAP.md#122-builder)

@shubhamrajvanshi, no puedes hacer cambios en iptables en la compilación por una buena razón, la configuración nunca se mantendrá.

Hay muy pocas cosas que se pueden hacer con privilegios que incluso tienen sentido en la construcción.

@thaJeztah Gracias, sería útil.
@ cpuguy83 ¿Sería ese el caso incluso si estoy usando el paquete iptables-persistent en la imagen?

Esto guardaría las reglas en el disco, luego aún tendrían que recargarse, desafortunadamente.

_ ENCUESTA DE USUARIOS_

_La mejor manera de recibir una notificación cuando haya cambios en esta discusión es haciendo clic en el botón Suscribirse en la parte superior derecha.

Las personas que se enumeran a continuación han apreciado su discusión significativa con un +1 aleatorio:

@karelstriegel

Realmente me gustaría esto también, para permitir el uso de los controladores CUDA de nVidia con Docker en CoreOS. El instalador que proporcionan compila un módulo del kernel contra la fuente del kernel y luego lo instala usando modprobe. No veo cómo hacer que funcione sin algún tipo de opción privilegiada para construir.

¿Por qué no admitir siempre el modo privilegiado de forma predeterminada en la compilación?

+1
Quiero usar el comando mysql en Dockerfile para centos7.
Por supuesto, podemos usar entrypoint.sh, pero es más útil si podemos usar -privileged tanto para compilar como para ejecutar.

No es necesario que --privileged ejecute el comando MySQL.

Este problema debe cerrarse, ya que no parece que vaya a suceder (o incluso que deba suceder).
Permitir privilegios en la compilación significa permitir que el constructor cambie cosas en el host, lo que a su vez hace que la imagen solo funcione en ese host (o hosts que hayan tenido modificaciones similares).

Permitir privilegios en la compilación significa permitir que el constructor cambie cosas en el host, lo que a su vez hace que la imagen solo funcione en ese host (o hosts que hayan tenido modificaciones similares).

¿Esto se aplica al caso de usuario de chroot?

Estoy tratando de averiguar cómo hacer dpkg-depcheck -d ./configure sin algo como esto.

Durante la compilación (o ejecutar sin --priviledged) aparece el siguiente error: no tengo idea de cómo averiguar qué permiso necesita o cómo habilitarlo.

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$ 

Después de unos 3 años y 162 comentarios, creo que tiene mucho interés por hacer. Los comentarios acerca de que un modo privilegiado no es necesario para la mayoría de los casos citados son ciertos, incluso el mío; pero no debe usarse para prohibir lo que podría ser útil para construcciones locales, temporales, exploratorias y / o convenientes. Publique advertencias hasta que las vacas emitan pedos en armonía, imprima advertencias en la línea de comandos, insulte y denuncie su uso, pero dé a la gente flexibilidad. La portabilidad no siempre es el interés principal de todos.

_ ENCUESTA DE USUARIOS_

_La mejor manera de recibir notificaciones de actualizaciones es usar el botón _Suscribirse_ en esta página._

No utilices comentarios "+1" o "Yo también tengo esto" sobre problemas. Nosotros automaticamente
recopile esos comentarios para mantener el hilo corto.

Las personas que se enumeran a continuación han votado a favor de este problema al dejar un comentario +1:

@robeferre

+1

Realmente necesito montar un volumen NFS dentro de un contenedor acoplable, hasta ahora no podía crear el recurso compartido NFS sin el indicador "--privileged = true". En mi opinión, el mejor caso es construir la imagen usando un comando privilegiado. ¿Cómo es esto posible?

+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

Estoy tratando de instalar gobject-introspection en el sistema gentoo en la ventana acoplable durante la compilación, pero falla con este error:

• ISE: _do_ptrace: ptrace (PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operación no permitida

El mismo resultado cuando trato de instalarlo manualmente en el contenedor, pero cuando lo intento desde el contenedor iniciado en modo privilegiado (docker run --privileged), entonces funciona bien.

El mismo problema cuando intento instalar glibc.

Así que también necesito una forma de ejecutar un comando privilegiado durante la compilación.

Estoy usando la versión 1.10.1 de Docker y el problema con glibc no aparece en 1.9

En la versión 1.10 algo se rompió y no podemos construir contenedores de 32 bits, porque la red no está disponible
--privileged o --security-opt seccomp: inconfined para BUILD - es realmente necesario.
O las directivas correspondientes en Dockerfile

gran +1 de mi parte

Es un problema real para mí que no puedo usar el comando 'montar' durante la compilación.
Estaba tratando de superar la limitación de que un directorio de host no se puede montar en un contenedor durante la compilación, así que configuré un servidor NFS en el host e intenté montar un recurso compartido de NFS, solo para descubrir que no es posible debido al modo sin privilegios.

En mi caso de uso, necesito instalar algunas cosas en la imagen sin copiarlas al contexto de compilación y AGREGARlas antes de instalarlas.

Se siente como si me hubieran quedado sin opciones.

thaJeztah hizo referencia a este problema el 10 de marzo
Regresión en el comportamiento de LTTng después de actualizar a 1.10.2 # 20818 Cerrado

No, no está cerrado, estamos usando 1.11.0-0 ~ astutamente y en contenedores de 32 bits, Neworking no funciona desde 1.10.0, pero 1.9.x funcionó bien.
Solo los privilegiados pueden ayudarnos a poner en marcha contenedores. Pero no podemos construir nuevos

Me sorprende que algo tan obviamente necesario por tanta gente no se haya implementado a pesar de que la gente lo ha estado pidiendo durante 2.5 años solo en este hilo y dado que la gente ha enviado PR para implementar esta funcionalidad.

De acuerdo @ctindel , este problema es una de las razones por las que estoy migrando de docker a rkt .

@ctindel Es algo que no estamos listos para implementar o respaldar. La implementación en sí es bastante simple (incluso la implementé yo mismo para que pudiéramos discutir), ese no es el problema.

--privileged es un tanque, y permitirlo en la construcción es peligroso y afecta en gran medida la portabilidad de la imagen.

Brian

Si tiene una solución alternativa, por favor, compártala conmigo también. me gustaría
Valora eso.

Gracias
Shubham Rajvanshi
669-300-8346

El lunes 2 de mayo de 2016 a las 2:30 p.m., Brian Goff [email protected] escribió:

@ctindel https://github.com/ctindel Es algo para lo que no estamos preparados
implementar o apoyar. La implementación en sí es bastante simple (incluso
lo implementé yo mismo para que pudiéramos discutir), ese no es el problema.

- privilegiado es un tanque, y permitirlo en la construcción es peligroso, y
afecta en gran medida la portabilidad de la imagen.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/1916#issuecomment -216369957

No entiendo el efecto sobre la portabilidad. ¿Cómo afectan las operaciones privilegiadas en el momento de la compilación a la portabilidad? Quiero decir, no es difícil crear imágenes no portátiles de varias formas con o sin privilegios, pero ¿hay alguna forma de que las imágenes creadas con operaciones privilegiadas no sean necesariamente portátiles?

No creo que todos los contenedores deban ser portátiles. Algunos contenedores se crean para compartir con la comunidad y algunos pueden crearse para implementar aplicaciones internas.

El problema de portabilidad con una aplicación que requiere ejecutarse en modo privilegiado radica en la propia aplicación.

El modo privilegiado es el medio de último recurso para que la aplicación funcione sin cambios de código.

Creo que un creador de imágenes que requiere la construcción en modo privilegiado comprende que dicho contenedor también puede requerir la ejecución en modo privilegiado.

Se debe documentar claramente que no se recomienda la construcción en modo privilegiado, ya que podría crear problemas de portabilidad.

Enviado desde Outlook Mo bilehttps: //aka.ms/blhgte

El lunes 2 de mayo de 2016 a las 2:53 p. M. -0700, "Trevor Blackwell" < [email protected] [email protected] > escribió:

No entiendo el efecto sobre la portabilidad. ¿Cómo afectan las operaciones privilegiadas en el momento de la compilación a la portabilidad? Quiero decir, no es difícil crear imágenes no portátiles de varias formas con o sin privilegios, pero ¿hay alguna forma de que las imágenes creadas con operaciones privilegiadas no sean necesariamente portátiles?

Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente o véalo en Gi

@tlbtlbtlb Porque el modo privilegiado le da acceso completo al host. Quizás configuré algo simple como shmmax o algo mucho peor.
Te garantizo que estas cosas sucederán el día 1 que esté disponible.

@ davidl-zend "portable" no significa compartir con la comunidad. Significa pasar de una máquina a otra.

@ cpuguy83 Como otros han señalado, también hay muchas otras formas de romper la portabilidad de la imagen. Todo lo que está haciendo al no tener un proceso para la construcción privilegiada es forzar a las personas a tener un proceso de dos pasos, ya sea compilando parcialmente desde un Dockerfile y luego cambiando manualmente el contenedor y haciendo una confirmación, o compilando parcialmente desde un Dockerfile y terminando la instalación privilegiada la primera vez que se inicia el contenedor, lo cual apesta porque eso significa que si está haciendo algo que requiere mucho tiempo, el primer arranque podría tardar minutos en funcionar.

Dados los comentarios que he visto en varios foros, estoy dispuesto a apostar a que MUCHAS personas ya están haciendo exactamente esto para evitar la limitación de la ventana acoplable que existe en la actualidad.

Una vez que tenga una arquitectura en la que la portabilidad de la imagen se rompa de muchas otras formas, ¿qué sentido tiene inclinarse contra este molino de viento específico?

Claramente, ya no podrá hacer que docker hub o travis-ci construyan su imagen, pero las personas que lo necesiten con el modo de privilegios lo entenderán de todos modos.

@ctindel Me encantaría ver algunos ejemplos de problemas de portabilidad de imágenes

Hacer este tipo de cosas en el primer inicio del contenedor es _exactamente_ el camino correcto a seguir.
Es una configuración de tiempo de ejecución que no debería estar en la imagen.

@ cpuguy83 ¿Estás debatiendo el hecho de que alguien podría hacer una compilación parcial desde un Dockerfile, hacer girar un contenedor en modo privilegiado, hacer más cambios y luego hacer una confirmación de Docker? ¿En qué se diferencia eso de hacer una compilación en modo privilegiado? Porque eso es lo que están haciendo otras personas hoy.

No estoy tratando de ser irritable, solo digo que esta es una limitación severa en la plataforma en la que la gente está trabajando de una manera incómoda.

Por ejemplo, hay paquetes Debian de terceros (y probablemente RPM) que no se pueden instalar correctamente a menos que tenga ciertas capacidades en el sistema. La instalación de un paquete debian no es una "configuración en tiempo de ejecución", es una maldita parte del proceso de instalación.

@ctindel No estoy debatiendo esto en absoluto. La diferencia está en apoyar el comportamiento. Si no hubiera diferencia, no estaríamos teniendo esta discusión.

Para mí, soy un adulto que consiente y quiero poder rodar una imagen de pila de paquetes a través de un montón de nodos. Actualmente, la construcción con un Dockerfile bombardea, así que tengo que hacer trampa para sortear las restricciones de la ventana acoplable.

@ cpuguy83 Todavía no me queda muy claro (y creo que otros en este hilo) qué se gana exactamente al no proporcionar esta opción con la que la gente está trabajando de otras maneras. El tipo de pureza arquitectónica (no tengo una mejor palabra para eso) por el que parece estar argumentando desapareció en el momento en que se agregó la opción de confirmación de todos modos, por lo que realmente no entiendo qué diferencia hay si se hace a través de un Dockerfile con compilación privilegiada o mediante una confirmación de docker en un contenedor privilegiado.

Excepto que una forma es un PITA maldito para las personas y una vía se inserta muy bien en el mecanismo actual de construcción con Dockerfile.

Además, no respondiste a mi pregunta. ¿Por qué considera que la instalación simple de un paquete debian de terceros (o packstack) es una "configuración en tiempo de ejecución"?

@ctindel Portabilidad. El hecho de que se pueda hacer algo no significa que sea compatible, e incluirlo en build , lo que lo hace conveniente para todos, significa que es compatible.
_Estaremos_ inundados con problemas de imágenes que no funcionan entre hosts ... lo que básicamente anula todo el motivo de Docker.

Si un paquete requiere la instalación de --privileged , entonces debe incluirse en el paquete. La instalación no debería requerir --privileged ... y si realmente lo requiere, entonces esta es una señal de que la instalación en sí no es portátil (requiere cambiar cosas en el host) ... Me gustaría incluso vea que la ventana acoplable se puede ejecutar en un contenedor sin --privileged (tenga en cuenta que es ejecutable, puede instalarlo todo lo que quiera sin problemas sin --privileged).

¡Pero permitir que se haga a través de la confirmación de Docker significa que también es compatible!

No entiendo, estás haciendo que muchas personas solucionen las limitaciones de este producto porque te preocupa que alguien se queje con ustedes personalmente sobre algún tipo de imagen no compatible.

Aún no respondiste a mi pregunta sobre por qué el acto de instalar un paquete (ni siquiera estoy hablando de configurarlo aquí) es un acto de "configuración en tiempo de ejecución". Decir simplemente "portabilidad" no significa nada.

¿Hay algo específico x86_64 sobre Docker? ¿No habrá finalmente imágenes de la ventana acoplable creadas para una arquitectura de CPU específica? ¿No los hace eso también no portátiles? Me refiero a que toda esta idea de que de alguna manera siempre podrás tomar cualquier imagen de la ventana acoplable y ejecutarla en cualquier host de la ventana acoplable del mundo, independientemente de toneladas de otras variables, parece imposible de todos modos, así que no entiendo la gran necesidad de presionar de nuevo en esta característica en particular que la gente está pidiendo.

Por cierto, permítanme agradecerles sus respuestas y su compromiso continuo. ¡Muchos otros proyectos de github donde se ignoran los hilos de problemas!

Estoy de acuerdo con el punto sobre las personas que trabajan en torno a esto mediante el uso de docker run --privileged con docker commit . He creado una solución como esa para dos empresas hasta ahora. La gente HARÁ imágenes así y no tiene sentido actuar como si hacerlo fuera algo horrible, horrible.

Demonios, si tiene tanto miedo de admitir contenedores que se construyeron con --privileged , simplemente indíquelo claramente en la documentación para que la gente sepa perfectamente que lo está haciendo bajo su propio riesgo. Aunque no he visto ningún efecto negativo hasta ahora. Pero, de nuevo, no hemos intentado ejecutar contenedores en diferentes distribuciones.

@PerilousApricot, ¿qué está causando realmente el problema con packstack? Estamos felices de solucionar problemas específicos, o ayudar a solucionarlos, pero no piense que simplemente agregar --privileged que brinda acceso de raíz completo y sin restricciones a su servidor host, es la forma correcta de hacerlo. Todos los casos que conozco en los que las personas han planteado problemas de compilación específicos generalmente se pueden solucionar, ya que la mayoría de las cosas en realidad no necesitan acceso de root en la máquina host para hacer una compilación.

@justincormack ¿Cuál es la solución para un paquete de terceros (es decir, no se puede cambiar) que inicia su propio servicio donde el script de inicio necesita montar un sistema de archivos tmpfs? Me refiero incluso a ignorar --privileged por ahora tampoco hay forma de hacer un --cap-add o un --security-opt apparmor: ilimitado durante una compilación (¿no creo?)

@ctindel No debería intentar montar un tmpfs en la instalación. Si necesita tmpfs en tiempo de ejecución, entonces genial, pero en el momento de la instalación ciertamente no es correcto.

@ cpuguy83 Estás imponiendo una filosofía de implementación y arquitectura en algo que no se puede cambiar porque proviene de un tercero comercial. No todo se arreglará "en sentido ascendente", incluso si arreglan la versión más nueva de .deb o .rpm, no significa que volverán y volverán a publicar la versión anterior, que es lo que podría necesitar en la imagen de la ventana acoplable.

Ese es el punto de toda esta discusión, está imponiendo restricciones arbitrarias que hacen que sea mucho más difícil usar Docker debido a alguna preocupación filosófica acerca de las solicitudes de apoyo de personas que "lo hacen mal".

Eso es como decir que los sistemas operativos no deberían permitir que las personas cambien las clases de programación de procesos porque si lo hace mal, puede llevar a una inversión de prioridades. O que nadie debería hacer un martillo porque es posible golpearse el pulgar si lo usa mal.

Como se ha dicho muchas veces, la ventana acoplable YA SOPORTA ESTO a través del comando de confirmación, es más doloroso para los usuarios. Las personas que no quieran esta función no la usarán, y los adultos que lo consientan y quieran usarla entendiendo las limitaciones pueden hacerlo con los ojos bien abiertos.

@ctindel Más como no, no puedes manejar esta bomba nuclear porque podrías matar a todos en un radio de 50 km.

¿Qué tiene este paquete que necesita para cargar un tmpfs durante la instalación? La instalación consiste literalmente en extraer archivos de algún formato de archivo a rootfs.

Todo se puede cambiar.
Es un cambio mucho más simple y seguro que se debe realizar en sentido ascendente para no montar un tmpfs en la instalación que para habilitar privilegios en la compilación.

Docker se trata de la portabilidad de la carga de trabajo. Habilitar privilegios en la compilación (o privilegios adicionales, o ajustar perfiles de seguridad, etc.) rompe fundamentalmente esto y no es algo que podamos aceptar hoy.

commit y build son dos cosas muy diferentes, y el hecho de que sea posible hacer algo de una manera no significa que debamos permitir hacerlo de todas las demás.

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

No se requieren privilegios.

La iglesia de la protabilidad.
Un día, la portabilidad "forzada" acabará con este proyecto; ya lo está haciendo.
Se están negando tantas funciones debido a la portabilidad esquiva, no se están logrando muchos avances debido a eso .....
Un día, alguien bifurcará un proyecto y hará que la portabilidad sea opcional. Sueños ... sueños ... Amén.

Si lo desglosamos en dos casos:

1. Instaladores que utilizan operaciones privilegiadas de forma frívola, como montar tmpfs para mejorar el rendimiento. Estos instaladores podrían repararse fácilmente (pero es posible que no lo sean en un futuro próximo).

En este caso, es una filosofía válida para Docker rechazar a los instaladores que se comportan mal. La mayoría de los instaladores tienen algún tipo de solución que hace que Dockerfile sea un poco más largo.

1. Instaladores que dependen fundamentalmente de operaciones privilegiadas, como instalar módulos de kernel para controladores de GPU. Estos también son fundamentalmente no portátiles. No funcionarán en docker-machine para Mac, por ejemplo.

En este caso, la experiencia de Docker se rompe de todos modos. No puedo usar docker-machine en Mac, por ejemplo, solo puedo crear la imagen en una máquina host de destino compatible. Mi caso de uso fue instalar los controladores de la GPU nVidia en un sistema operativo host (CoreOS), lo que desalienta la instalación directamente en el sistema operativo host.

Entonces, creo que he llegado a ver la virtud de no apoyar, privilegiado en cualquier caso. Creo que lo que me hizo cambiar de opinión es la conveniencia de crear imágenes en mi computadora portátil usando docker-machine, en lugar de enviar primero mi código a una caja de Ubuntu y construir allí.

@tlbtlbtlb No entiendo a qué "virtud" te refieres. Considere algo que no sea frívolo, pero hay toneladas de imágenes de la ventana acoplable que se ejecutarán en un entorno pero no en otro. Por ejemplo, puede montar un volumen de host en un contenedor mongodb desde linux-> linux porque y el controlador de almacenamiento mmapv1 funcionará bien, pero no puede pasar un directorio mac osx a través de virtualbox a un contenedor mongodb en su computadora portátil porque el Las cosas de mmap no funcionarán correctamente en ese caso.

Me doy cuenta de que esto no es un problema con respecto a la construcción, pero la idea de que las imágenes de la ventana acoplable son "portátiles" y pueden "ejecutarse en cualquier lugar" es una tontería total en este momento. Si es el caso de que no pueden correr en ningún lado, ¿cuál es la virtud de decir que deberían poder "construir en cualquier lugar"?

El caso es que la imagen de mongodb funciona en todas partes. Proporcionar una configuración de tiempo de ejecución no válida es una bestia diferente.

Docker tiene una separación muy específica e intestinal de configuración portátil y configuración no portátil.

Qué tal esto ?
Necesito tener mis ips reales dentro del contenedor para mi paso de verificación de configuración de nginx.

este es mi 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

Por qué si ejecuto el contenedor con la opción de privilegios, puedo configurar la ip a la interfaz de loopback. Pero es un guión más para agregar.

@ cpuguy83 Tengo alrededor de 20 líneas de entradas iptable Me gustaría RUN en mi Dockderfile pero no puedo porque necesito --cap-add=NET_ADMIN . Estos comandos deberían suceder independientemente de quién esté ejecutando el contenedor e independientemente de la máquina en la que lo ejecuten (el contenedor ejecuta una aplicación interna). ¿Dónde / cómo sugeriría que haga eso en base a lo que discutió anteriormente?

@MatthewHerbst Desafortunadamente, las reglas de iptables no pueden / no pueden persistir con la imagen.

@ cpuguy83 Estoy usando una imagen centos:6 y puedo ejecutar la ejecución /sbin/service iptables save para mantener las reglas en el sistema de archivos. Creo que hay una capacidad similar en Ubuntu y otros a través del paquete iptables-persistent .

Puede generar las reglas de iptables para ese archivo, no es necesario
aplicarlos realmente. La situación de la red donde se ejecuta el contenedor puede
ser muy diferente, por lo que debe aplicar las reglas en tiempo de ejecución (si es así,
puede estar mejor con el host que los genera).

El 16 de mayo de 2016 a las 16:03, "Matthew Herbst" [email protected] escribió:

@ cpuguy83 Estoy en CentOS y puedo ejecutar run / sbin / service iptables save to
persistir las reglas en el sistema de archivos. Creo que su es similar
capacidad en Ubuntu y otros a través del paquete iptables-persistent.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub

@justincormack no sé por qué no pensé en eso. ¡Gracias!

¿Cómo se supone que debe ejecutar comandos que requieren privilegios cuando se usa docker service ? Necesito establecer el nombre de host en algunas de mis máquinas, pero desafortunadamente esto requiere privilegios.

@nostrebor que no tiene nada que ver con este problema abierto.
Estamos evaluando qué opciones deben existir para los servicios en lugar de copiarlas 1 a 1. El modo privilegiado probablemente no estará en 1.12 para los servicios.

Estoy intentando compilaciones de Docker que compilan algo para la instalación, pero deben compilarse con bibliotecas que existen en un sistema de archivos de red CVMFS. Por supuesto, no puedo montar CVMFS sin ejecutar --privileged, así que no puedo hacerlo usando un Dockerfile.

@ cpuguy83 @tlbtlbtlb Este es un caso de un 'instalador' que depende fundamentalmente de una acción privilegiada. Pero no es lo que yo llamaría un 'uso frívolo', solo necesito acceso a bibliotecas compartidas en un sistema de archivos de red. Aún así, la instalación en este caso NO consiste simplemente en extraer archivos de algún archivo.

No entiendo cómo montar un sistema de archivos de red es un problema de portabilidad. (Todos nuestros entornos de destino tendrán acceso a este sistema de archivos. Deben hacerlo porque crean otro código que TAMBIÉN debe vincular al código binario en el sistema de archivos de red).

¿Debería probar un enfoque diferente? ¿Debo montar CVMFS en el host y compartir ese directorio con el contenedor o algo así? No quiero tener que configurar un sistema de compilación externo solo para hacer esta imagen; la imagen en la que se basa ya tiene un sistema de compilación completo que hará el trabajo. Solo necesito poder montar CVMFS.

Estaba emocionado de hacer esto con un Dockerfile, pero parece que tendré que hacerlo de la manera difícil usando algunos scripts con docker run --privileged , o usar algo más en lugar de Docker. ¿Hay alguna forma de montar un sistema de archivos en un contenedor _sin_ tener acceso privilegiado?

Hice una solución alternativa, colocando / repitiendo comandos privilegiados dentro de un script y usé la instrucción CMD para ejecutar el script en el punto de entrada del contenedor, así que después de construir una imagen como esa, puedo ejecutar el contenedor en modo privilegiado y todo funciona.

@drstapletron , de acuerdo con la documentación de CERN cvmfs, tiene dos opciones por ahora, montar cvmfs de host a contenedor o instalar cvmfs dentro de un contenedor privilegiado.

Para el segundo caso, acabo de escribir un archivo de ventana acoplable para los chicos de cmssw, aquí:
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

por lo que al usar este archivo, puede simplemente crear una imagen (o puede tomarla de cmssw dockerhub) y ejecutarla en modo P, y todo estará allí dentro del contenedor (ls / cvmfs / *)

No estoy seguro de si esto se cubrió anteriormente, ya que es una lista bastante larga de comentarios sobre este tema. A mí también me gustaría tener comandos de compilación privilegiados. Mi caso de uso actual es solucionar un problema que encontré al construir go ebuild en un stage3 de gentoo. Si no uso un contenedor, las instrucciones actuales en el manual de gentoo hacen que systemd se comporte de manera errática una vez que 'desmonto -l / mnt / gentoo / dev {/ shm, pts,} && umount -l / mnt / gentoo / { proc, sys} 'desde un sistema arrancado con systemd ... Cuando muevo mi compilación stage3 a un contenedor docker, todo funciona bien hasta que una compilación requiere ptrace, o alguna otra característica restringida ... que el go-1.7.1. ebuild parece requerir.

Por ahora, simplemente estoy ejecutando la compilación dentro de un comando de ejecución de la ventana acoplable, confirmando y luego continuando desde allí, pero sería preferible habilitar ptrace dentro del comando de compilación de la ventana acoplable para evitar los pasos manuales.

También me gustaría esta función. Quiero crear un entorno de compilación, pero requiere un módulo de kernel y modprobe no cooperará conmigo cuando estoy compilando. ¿Existen soluciones alternativas para esto?

Específicamente:

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

Parece un caso de uso totalmente razonable.

@seltzy Sugiero no contener la respiración esperando que alguien de docker reconozca la razonabilidad de su caso de uso.

Cuando se trata de arquitectura e inclusión de funciones, son muy duros, pragmáticos, distantes y tienden a ignorar todos y cada uno de los casos de uso que no encajan en _su_ hoja de ruta.

Nosotros, la gente común, debemos entender que el equipo de docker toma decisiones de arquitectura que satisfacen sus propias necesidades (clientes comerciales probables y de autoservicio), y esas decisiones rara vez se superponen con nuestras (el usuario final público) muy laboriosamente elaboradas problemas que presentamos aquí.

Por supuesto, son libres de asignar sus recursos de ingeniería de esta manera.
Pero proporciona un historial que rogaría la imaginación si alguna vez se describiera a la empresa como "tomando en serio las necesidades de los usuarios".

@tamsky, ¡ lo clavaste!

@tamsky Puedo entender por qué piensas eso, ya que el proyecto no ha aceptado una característica que claramente deseas.

Les puedo asegurar que esto no tiene nada que ver con ningún tipo de decisión comercial. El hecho es que --privileged en la compilación cederá a imágenes no portátiles.
Cosas como modprobe en el entorno de compilación no son útiles e incluso pueden hacer que dos compilaciones produzcan resultados completamente diferentes.

Yo mismo he implementado --privileged en build. No es un problema de ingeniería, y realmente es bastante trivial de implementar. Apoyarlo es el problema.
Para usuarios avanzados, se puede implementar un constructor personalizado, incluso reutilizando el código existente, utilizando las API existentes que pueden incluir soporte privilegiado.

Dicho esto, este problema sigue abierto por una razón. Es porque la gente está escuchando.

Gracias por tu consideración.

@ cpuguy83 Gracias por la explicación. No me di cuenta de que era un problema de portabilidad. Supongo que mi deseo por esto está alimentado por malentendidos.

¿Cuál es el enfoque filosófico general a tomar cuando se enfrenta a la tentación de tener una estructura privilegiada?

@seltzy no esté tan seguro de que su caso de uso no sea un ejemplo razonable de la necesidad de esta función

@ cpuguy83 Todavía estoy esperando una respuesta sobre mi caso de uso. El sistema de compilación de nuestra institución se distribuye a través de un sistema de archivos de red que debo montar en mi contenedor. Esto requiere que el contenedor se ejecute en modo privilegiado. La decisión de mi institución de utilizar un sistema de archivos de red para la distribución de software no es inusual para la física de partículas. Afirmas que --privileged en la compilación crea imágenes no portátiles, pero esto no tiene ninguna relación con mi caso de uso. Nuestro modelo de desarrollo ya ha renunciado a cualquier portabilidad que _podríamos_ perder debido a nuestro uso de un sistema de archivos de red (¿en serio?). Solo necesitamos que la máquina de desarrollo esté a punto de montarla.

@ cpuguy83 PD: mencionaste un constructor personalizado. ¿Dónde puedo encontrar información sobre esto? ¡Gracias!

De todos modos, toda esta discusión sobre la portabilidad de los contenedores es una pista falsa. Ya puede lograr lo mismo creando una imagen de la etapa 1, iniciando un contenedor en modo privilegiado, haciendo lo que tenga que hacer y luego usando docker commit para crear la imagen final a partir de ese contenedor.

Una vez que agregaron la opción de confirmación de la ventana acoplable, cualquier noción de portabilidad de la imagen salió por la puerta de todos modos, por lo que obligar a las personas a hacer esto en 3 pasos en lugar de 1 no está ganando nada y solo sirve para molestar a las personas que realmente podrían usar una opción de compilación privilegiada.

@drstapletron Montar un sistema de archivos no es necesariamente algo que pueda romper la portabilidad (a menos que alguien esperara que se montara en la imagen).
El problema aquí es tener la capacidad de montar un sistema de archivos también significa poder hacer un montón de cosas desagradables.

@ctindel Sí, puede hacer lo que quiera en los contenedores que cree. Sin embargo, el hecho de que docker build sea ​​"el" método admitido para crear imágenes significa que debemos asegurarnos de que las imágenes creadas con él _son_ portátiles.

Las imágenes portátiles no son una pista falsa. La portabilidad de la carga de trabajo es el principal objetivo de diseño de Docker. Nuestra directiva principal, por así decirlo.

@seltzy La mayoría de las cosas que requieren privilegios adicionales pertenecen al tiempo de ejecución, porque la mayoría de las veces los privilegios elevados se utilizan para modificar el host de alguna manera.
Dicho esto, ciertamente puedo entender que se requieren algunas cosas en el momento de la compilación (como el montaje nfs anterior) ... pero incluso con el caso de NFS y la construcción manual de la imagen (no con docker build ), no le daría al contenedor --privileged ni ninguna capacidad adicional, en su lugar, montaría la exportación nfs como un volumen.

@drstapletron mount no requiere --privileged solo un conjunto de capacidades más restringido y es mucho más probable que suceda antes que un modo con privilegios completos, ya que brinda acceso de root completo al host, lo que la mayoría de la gente hace no quieren. (Todavía tiene problemas de seguridad pero son más manejables).

Así que tengo un caso de uso completamente portátil que no modifica el host. Incluso es de código abierto y puedes verlo aquí .

Básicamente, quiero ejecutar Mock en un contenedor Docker portátil para crear una imagen ISO CentOS personalizada. Mock, para aquellos que no lo saben, es un generador de RPM en contenedores. El problema es que, dado que usa contenedores, necesito --privileged o --cap-add . Idealmente, creo que docker build funcionaría como una función, tomando algunos argumentos y devolviendo su resultado final. Sin embargo, sin estas banderas, no puedo hacer eso.

Aquí igual ! Usar mock inside docker es una pesadilla por eso :(

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 escribió:

El hecho es que, privilegiado en la compilación cederá a imágenes no portátiles.

¿Por qué no permitir --privileged para aquellos que no requieren una portabilidad de largo alcance?
Una simple nota en la documentación oficial sería un compromiso razonable (por ejemplo, _Warning: pasar --privilege al comando build puede resultar en una imagen menos portátil! _). Esto resolvería los requisitos de casi todos; algunos usuarios no necesitan portabilidad, otros sí, una advertencia sería suficiente para satisfacer las necesidades de todos.

Estoy seguro de que la falta de build --privileged complica significativamente mi caso de uso actual.

Podría llamarse --non-portable . Todavía no he usado las partes de implementación de la ventana acoplable, pero las cosas del sistema de archivos de aislamiento + superposición han sido realmente útiles sin eso.

Necesito usar algún software propietario que requiere un contenedor privilegiado para su instalación. No hay nada que pueda hacer al respecto. Estoy atascado con la necesidad de realizar el proceso de compilación, ejecución y confirmación de 3 etapas.

La portabilidad de los contenedores no significa nada para mí ni para mi negocio; de hecho, apuesto a que no significa nada para la gran mayoría de las empresas. Lo importante es que me gustaría mantener menos software, por lo que creo que seleccionar la portabilidad sobre la usabilidad en este tema es perjudicial para Docker.

+1 para esto, en el proceso de compilación usamos setfacl, esto falla durante la compilación y los servicios no se inician en el contenedor. Creo que como usuarios finales no deberíamos estar restringidos, use la opción --priviledge solo si la necesita y la opción predeterminada está deshabilitada.

+1 para esto. En nuestro proceso de compilación, se requiere montar el / proc y / dev. Idealmente, deberíamos poder tener el paso de montaje como parte del archivo docker.

@ samsun387 ¿Por qué su proceso de construcción requiere esto?

@skshandilya setfacl no es portátil y me sorprendería si las acl pudieran persistir en una imagen.

@robhaswell "requiere un contenedor privilegiado" no ayuda mucho. ¿Qué se está utilizando realmente en la instalación?

+1. mock init necesita esto.
Casi leo todo el número. no entiendo por qué la gente sigue preguntando "por qué necesitas esto" durante 3 años seguidos.

@Betriebsrat Porque "X necesita esto" no es realmente tan útil.
¿Qué está haciendo "X"? ¿Por qué "X" necesita esto durante la fase de construcción?

Por ejemplo, el caso anterior con capacidades para montar /proc y /dev realmente no parece el lugar correcto para la fase de compilación, e incluso parece que la imagen estaría vinculada al host en tal un caso.

"privilegiado" es también un tanque. Abre absolutamente todo, desactiva todas las funciones de seguridad, da acceso de escritura a lugares típicamente de solo lectura ... donde alguien probablemente solo necesita poder hacer algo muy específico.

Estas preguntas se hacen para que podamos obtener el caso de uso real y cómo podríamos satisfacer dicho caso.

Por cierto, cuando digo "funciones de seguridad" me refiero a dos cosas:

1. Cosas para prevenir la piratería
2. Aislamiento de las preocupaciones de la aplicación de las preocupaciones del host (es decir, la creación de la imagen no debe vincular la imagen al host en el que se basa).

Parece que el mío se resolvió en 21051, estoy fuera, por ahora :)

@shykes dijo el 28 de noviembre de 2013 @ https://github.com/docker/docker/pull/2839#issuecomment -29481246 ::

Lo sentimos, el diseño actual es hacer cumplir '1 fuente, 1 compilación', por lo que no permitimos ningún argumento para la compilación de Docker que no sea el directorio de fuentes.

Entiendo el hecho de que algunas compilaciones actualmente no pueden realizarse porque necesitan operaciones privilegiadas. Para manejar eso correctamente, es posible que necesitemos 1) permitir que un Dockerfile exprese la necesidad de ser construido de una manera privilegiada, y 2) implementar un sistema de autorización / trus que permita a Docker pausar la compilación, advertir adecuadamente al usuario del riesgo, exponer información sobre el origen y la confiabilidad del Dockerfile y luego recopilar la decisión del usuario de permitir o denegar la compilación.

@ cpuguy83 , ¿el diseño ha cambiado en absoluto desde la aplicación: "1 fuente, 1 compilación"?
¿El Proyecto Docker está dispuesto a modificar ese diseño y permitir esta función solicitada por la comunidad?

El comentario anterior de Shykes parece explicar lo que "podríamos necesitar" hacer para solucionar este problema. Al mismo tiempo, el lenguaje utilizado ("podría") parece proporcionar al proyecto de la ventana acoplable mucho espacio para encontrar razones adicionales para rechazar este cambio de diseño.

Agregar una declaración NEEDS_PRIVILEGED tiene sentido, pero ¿todo esto sobre pausar la compilación? Simplemente falle con un error y deje que el operador pase la opción --privileged si realmente desea permitir la compilación privilegiada.

@ cpuguy83 la avanzados que saben perfectamente bien cuáles son los riesgos de usarlo. Y la mayoría de ellos acepta eso y soluciona esto simplemente usando docker commit como parte de su compilación para el paso que lo necesita.

No está impidiendo de ninguna manera que las personas usen el modo privilegiado en la compilación, solo lo está haciendo molesto.

Si su objetivo es hacer que sea molesto, dígalo directamente y cierre este problema en lugar de dejar que continúe durante años y años.

Diga "no arreglaremos esto porque queremos que sea molesto" y cierre este problema.

/hilo

@ cpuguy83 , según tengo entendido, Mock usa unshare(2) con la bandera CLONE_NEWNS y posiblemente otras, cuando crea su entorno chroot / container. Esto requiere al menos CAP_SYS_ADMIN .

¿Qué está haciendo "X"? ¿Por qué "X" necesita esto durante la fase de construcción?

En nuestro caso de uso, no lo sabemos. Es una mierda propietaria que no podemos cambiar. La cuestión es que a nuestro negocio no le importa la "seguridad" (en este contexto) o la portabilidad, o cualquiera de las preocupaciones que se han enumerado. Solo queremos poner esta maldita mierda en un recipiente y pasar a hacer algo valioso.

Como dice @PonderingGrower , lo haremos de todos modos, es solo una cuestión de cuánto tiempo perdemos mientras lo hacemos.

Las personas que alguna vez necesitan el modo privilegiado en la compilación suelen ser usuarios avanzados que saben perfectamente cuáles son los riesgos de usarlo.

Estoy totalmente en desacuerdo con esa suposición. En general, las personas que usan --privileged pertenecen a la misma categoría de usuarios que ejecutan ciegamente chmod -r 777 "porque alguien escribió que solucionó el problema"

En nuestro caso de uso, no lo sabemos. Es una mierda propietaria que no podemos cambiar. La cuestión es que a nuestro negocio no le importa la "seguridad" (en este contexto) o la portabilidad, o cualquiera de las preocupaciones que se han enumerado.

"en este contexto" aquí, lo que significa: dar "alguna mierda patentada" acceso de root en su host.

@thaJeztah No tengo ningún problema con eso. Es un software que hemos comprado y por el que pagamos soporte. Si no estuviéramos usando contenedores, aún necesitaría root para instalar.

Necesitamos esta función para usar dind mientras compilamos para preconfigurar algunos contenedores dentro del que estamos construyendo.

¿De qué estás discutiendo aquí durante 3 años?

docker run tiene opciones --cap-add , --cap-drop y otras. Entonces, el comando RUN en Dockerfile quiere tener las mismas opciones. Entonces Dockerfile desea enviar solicitudes a la máquina principal y pedirle que agregue / elimine algunos privilegios.

La máquina principal puede hacer lo que quiera con estas solicitudes. Puede hacer que el shell sea interactivo, puede crear un diálogo de confirmación de interfaz gráfica de usuario, etc. ¿Por qué está discutiendo la resolución de estas solicitudes en este problema?

Un número significativo de usuarios de la ventana acoplable desea tener la capacidad de --cap-add o --privileged en el comando de compilación, para imitar lo que hay en el comando de ejecución.

Es por eso que este boleto ha estado abierto durante 3 años con personas que intervienen constantemente a pesar de que los mantenedores no están interesados ​​en darles a los usuarios lo que quieren en este caso específico.

@ctindel Este es definitivamente el problema de este problema. Hay una brecha entre docker build --cap-add y RUN --cap-add .

Algunas personas quieren resolver las solicitudes de privilegios de la máquina secundaria con solo docker build --cap-add=caps_array . ¿Qué es? Esto es solo: caps_array.include? requested_cap .

Algunas personas quieren pre_requested_caps.include? requested_cap . Algunas personas quieren stdout << requested_cap, stdin.gets == 'y' Algunas personas quieren gui_confirm requested_cap . Algunas personas definitivamente querrán UAC_fullscreen_dialog requested_cap .

El método de resolución de requested_cap depende del gusto del usuario y creo que esta pregunta nunca se hará.

Pero RUN --cap-add no tiene nada que ver con los gustos de la gente. ¿Qué estamos esperando?

@ andrew-aladev Realmente no entiendo lo que dice tu publicación. El punto es que las personas tienen software de terceros (RPM, DEB, lo que sea) que no está bajo su control, que quieren instalar en una imagen en el momento de la "construcción de la ventana acoplable" y que requiere capacidades adicionales para instalarse correctamente. Dado que son RPM de terceros, no hay forma de resolver el requisito de mayores privilegios durante la fase de instalación.

Están solucionando el problema ejecutando un contenedor con esas capacidades mejoradas, instalando su software y luego creando una imagen a partir de ese contenedor. Es una molestia y muestra claramente que no hay ninguna razón funcional para prohibir la adición de cap en el momento de la compilación, ya que el mismo fin se puede lograr de forma indirecta.

@ctindel Mi inglés no es muy bueno, lo siento.

Sé. Intenté hacer emerger glibc y recibí ptrace not permitted .

docker puede ejecutar un contenedor con capacidades aumentadas / disminuidas por sí mismo. RUN comando en Dockerfile debe admitir --cap-add , --cap-drop , etc.

Imaginemos que nuestro Dockerfile tendrá RUN --cap-add=SYS_PTRACE -- emerge -v1 glibc . ¿Cómo funcionaría?

1. La máquina secundaria envía una solicitud a los padres y solicita SYS_PTRACE .
2. Parent permite capacidades extendidas.
3. El padre crea un nuevo contenedor con SYS_PTRACE permitido.

Veo que nadie en este tema está realmente discutiendo sobre eso. La gente solo está discutiendo sobre un método para permitir estas capacidades.

@thaJeztah dijo

En general, las personas que usan --privileged pertenecen a la misma categoría de usuarios que ejecutan ciegamente chmod -r 777

Este hombre quiere un método más flexible de validación que requiera capacidades que solo log :info, requested_cap; return privileged? .

@ctindel dijiste

Agregar una declaración NEEDS_PRIVILEGED tiene sentido, pero ¿todo esto sobre pausar la compilación? Simplemente falle con un error y deje que el operador pase la opción --privileged si realmente desea permitir la compilación privilegiada.

Quieres que el shell sea interactivo. Quieres stdout << requested_cap, stdin.gets == 'y' . Este es el otro método de validación de las capacidades necesarias.

@ cpuguy83 dijo

alguien probablemente solo necesita poder hacer algo muy específico ... cosas para evitar la piratería.

Este hombre quiere docker build --cap-add=caps_array caps_array.include? requested_cap . Este es el otro método de validación de las capacidades necesarias.

Entonces estoy preguntando: ¿Por qué RUN en Dockerfile todavía no tienen soporte de --cap-add , --cap-drop , etc.? Nadie discute sobre eso. ¡Han pasado 3 años!

@ andrew-aladev Supongo que nadie ha defendido esa sintaxis porque se ha dejado en claro que la sintaxis de dockerfile está congelada hasta que el constructor se reescribe / refactoriza / desacopla del motor principal. https://github.com/docker/docker/issues/29719#issuecomment -269342554

Más específicamente, el título del problema y el OP están solicitando: compilación privilegiada

esto hace que Fonzie golpee: .

poder ejecutar strace en el paso build ayuda mucho.
Actualmente, soluciono esto moviendo todas las cosas que necesito para depurar al paso run - no es ideal.

¿Alguien sabe por qué funcionaría en el paso run y no en el build ? es decir, las razones históricas.
¿Existe una alternativa a strace que funcione sin muchos permisos o configuración?

Hay una solución / solución alternativa propuesta para esto en
https://github.com/docker/docker/issues/6800#issuecomment -50494871:

si tiene problemas en la compilación de la ventana acoplable, puede usar un "contenedor de construcción":
docker run --cap-add [...] mybuilder | docker build -t myimage -

¿Alguien (posiblemente @tiborvass) podría dar más detalles sobre esto? ¿De qué tipo es mybuilder aquí?
¿El nombre de la imagen con algún PUNTO DE ENTRADA? ¿O es la imagen parte de [...] y mybuilder refiere
a un script de shell? ¿Y cómo convenzo a docker run de pasar el context.tar.gz al docker build -
si eso es realmente lo que está pasando aquí. Gracias de antemano, Steffen

@sneumann mybuilder sería un nombre de imagen y tendría algunos CMD o ENTRYPOINT hecho. El contrato para que funcione esa solución es que mybuilder tendrá que tar el contexto desde dentro del contenedor y dejarlo ir a la salida estándar. Eso se pasa al stdin de docker build , gracias a la tubería de shell | y se considera que es el contexto porque la ruta de contexto para docker build -t myimage - es - .

un poco extraño al mirar el código, parece que esta opción está disponible en el comando build :

• run : supongo que container aquí significa 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.

¿Alguien más informado tiene alguna idea de por qué no se está aplicando?

@mbana el --security-opt es para contenedores nativos de Windows, que admiten "credentialspec" https://github.com/docker/docker/pull/23389

¿Es posible modificar esto y hacer que persista para que el futuro build habilite ptrace ?

para cualquiera que esté interesado, aquí hay algunos buenos enlaces:

• http://www.projectatomic.io/docs/docker-building-images/ - cómo construir la imagen usando la técnica descrita anteriormente. es decir, use run para build la imagen.
• https://blog.afoolishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/ - misceláneos

He visto muchas afirmaciones de varias personas de que esta función no es necesaria porque las compilaciones se pueden cambiar para que no requieran ciertas operaciones privilegiadas, pero no hay sugerencias sobre qué hacer con el caso "docker in docker". Si una compilación necesita ejecutar comandos docker , por ejemplo, para desplegar algunas imágenes que queremos enviar dentro de esta, o para construir una subimagen, ¿cómo se supone que haremos esto sin algún tipo de privilegio opción de construcción?

Por ahora voy a solucionar esto usando docker run y docker commit pero sería genial si docker build pudiera soportar este caso de uso.

@scjody Parece que quieres # 31257

@ cpuguy83 No estoy seguro de que cubra lo que está sucediendo en este caso, pero lo

Hola, me gustaría poner mi nombre en el sombrero por favor-implemente-este. ¿O tal vez hay una solución diferente a mi problema (docker novato aquí) que alguien podría señalarme?

Estoy tratando de crear una imagen basada en la imagen oficial de centos / systemd y aprovisionarla con Saltstack. Esto requiere iniciar (y tal vez reiniciar) el demonio salt-minion con systemd, lo cual no se puede hacer (AFAIK) sin el modo privilegiado.

@onlyanegg Creo que en esa situación, Saltstack reemplaza en gran medida la funcionalidad del constructor; tenga en cuenta que cada instrucción RUN se ejecuta en un nuevo contenedor, momento en el que el contenedor de compilación anterior se detiene y se asigna a una imagen / capa.

¿Ha considerado realizar la compilación ejecutando un contenedor y confirmando los resultados ( docker commit )?

Gracias por responder, @thaJeztah. No me di cuenta de que eso era lo que hacía la directiva RUN . Leí la mayor parte de este problema, así que estoy al tanto de la docker build -> docker run -> docker commit , que es lo que probablemente terminaré haciendo. Estoy más a favor de tener un solo archivo que describa mi imagen, parece más ordenado. Tal vez pueda poner todos esos pasos en los posprocesadores del empaquetador y luego lo tendré.

¿Por qué este se ignora tanto? En tiempos de contenedores, kubernetes y minikube, y el uso de Docker en CI y la unificación del entorno de desarrollo, esta funcionalidad es realmente crucial.

@onlyanegg debería poder reiniciar los servicios _sin_ modo privilegiado. Si tiene un Dockerfile que lo ilustra (es decir, "el comando RUN en la línea 8 de este Dockerfile no funciona porque requiere un modo privilegiado") ¡estaría más que feliz de echarle un vistazo!

@derberg precisamente! En tiempos de contenedores, CI, CD, es importante que las herramientas de construcción se puedan contener (en el sentido de seguridad). Si permite el modo privilegiado, debe cambiar drásticamente la forma en que usa las herramientas de CI como Jenkins, Travis, Codeship, etc. Misma pregunta: si tiene un Dockerfile que requiere el modo privilegiado, me complacería echarle un vistazo para sugerir alternativas.

¡Gracias!

@jpetazzo intenta obtener una imagen de la

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

Ahora constrúyelo y ponlo en marcha. Después de comenzar, ejecute service docker start para iniciar el demonio de la ventana acoplable. Luego verifique el estado del servicio service docker status :

• con el estado de la bandera privilegiada está bien y puede iniciar el contenedor sin problemas
• sin la bandera, nunca empieza

@jpetazzo ech, acabo de notar que eres el creador de https://github.com/jpetazzo/dind :), así que estás al tanto de la ventana acoplable en el concepto de ventana acoplable :)

De todos modos, es consciente de que se necesita una bandera privilegiada para ejecutar. Así que ahora puedes imaginar a un grupo de personas trabajando en algún entorno y queriendo tener un entorno unificado para el desarrollo con algunas cosas preconfiguradas en su interior, por ejemplo, minikube con componentes preinstalados o cualquier otra cosa.

Entonces, ¿hay alguna manera de montar un recurso compartido NFS o SMB en docker build todavía?

@derberg esos pasos no funcionarán, incluso si el contenedor de compilación estaba ejecutando --privileged ; los paquetes de la ventana acoplable (y el script de instalación) están (por ejemplo) instalando paquetes de kernel en Ubuntu 16.04.
Esa es exactamente la razón por la que --privileged es una mala idea para docker build , porque podría realizar cambios en el _host_.

Aunque Docker necesitará privilegios cuando _ejecutando_, la instalación en sí no necesita esto; por ejemplo, estos son los pasos que ejecutaría para instalar Docker en su imagen;

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

Y puede ejecutarlo bien (estoy usando --privileged aquí, pero quizás sean posibles permisos más detallados):

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

Así es como evito este problema, para las personas que realmente necesitan crear una imagen de Docker en modo privilegiado. Puede que no resuelva todos los casos, pero puede ayudar en algunos.

Este método necesita un archivo Dockerfile, un archivo docker-compse y un script de shell.

El Dockerfile

Es lo mismo que necesitaría para construir la imagen. La única diferencia, deténgase en donde necesita realizar operaciones privilegiadas, no las incluya. Deben ser ejecutados por el docker-compose, como un script. Por ejemplo:

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 /

Esos más comandos que deben ejecutarse en modo privilegiado ahora están en further-commands-to-run-in-privileged-mode.sh . Se incluye en la imagen y luego lo ejecutará Docker Composer para finalizar el proceso de compilación.

El archivo de composición de la ventana acoplable

El archivo de redacción es la clave. Primero construirá la imagen desde arriba de Dockerfile e iniciará un contenedor desde esa imagen en modo privilegiado , luego podrá realizar su operación privilegiada allí. Por ejemplo:

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

Construye la imagen

Los pasos siguientes también se pueden guardar en un script de shell.

# 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 No tengo ningún problema con la instalación, tengo problemas para iniciar el servicio de la ventana acoplable durante la compilación y extraer algunas imágenes para que estén disponibles en la imagen de fábrica.

Agregue el siguiente script a su Dockerfile y verá que el servicio Docker nunca se activa

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

@derberg ¡ Bien, ya veo! _Personalmente_, si quisiera incluir imágenes en un contenedor dind , las descargaría (por ejemplo, con reg ) y las cargaría la primera vez que se inicia el contenedor. ¿Por qué? Porque si extrae las imágenes durante la compilación, la imagen funcionará _sólo si dind se inicia con el mismo controlador de almacenamiento_. En otras palabras, su imagen podría funcionar o no en otra máquina.

Además, si sus imágenes son grandes (es decir, cualquier otra cosa que, digamos, busybox o alpine ), terminará con una imagen DinD realmente grande ...

Me encantaría saber más sobre su caso de uso final, porque estoy seguro de que podemos ayudarlo a encontrar una forma más eficiente que hornear una imagen DinD enorme :-)

(¡De lo contrario, la solución propuesta por @kraml es bastante elegante!)

También vea https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh
Descarga imágenes usando solo bash + curl + tar.
Lo usamos aquí: https://github.com/moby/moby/blob/master/Dockerfile#L171

@jpetazzo ya ejecutamos esa solución alternativa build-run-commit, pero sí, sigue siendo una solución alternativa desde mi punto de vista. El caso de uso es bastante específico relacionado con kubernetes y el entorno de minikube y no hay nada que podamos hacer por ahora. Por ahora, pudimos iniciar minikube en la ventana acoplable solo con la ventana acoplable como demonio, el uso de virtualbox u otros controladores vm no funcionó, por lo que dependemos del enfoque dind

Me encontré con este problema al intentar crear una imagen que contenía una aplicación heredada (caso de uso bastante normal), donde el instalador intentó ejecutar comandos sysctl y falló.

Volviendo a este hilo y revisando los 4 años completos (!!!) de ida y vuelta sobre el tema de cómo agregar algún tipo de capacidades privilegiadas al comando docker build, parece que las opciones disponibles en esta situación son una desagradable grupo de comandos sed para modificar el instalador para eliminar las llamadas sysctl, o una compilación de varias etapas -> ejecutar -> canalización de confirmación. Estoy de acuerdo con @derberg en que 'build -> run -> commit' se siente como una solución alternativa (en mi opinión, una solución asquerosa / hacky) y no creo que mi caso de uso sea tan único. Verificando otros hilos, he visto a muchas personas que informan problemas con varias instalaciones de aplicaciones y bases de datos con comandos docker build fallidos debido a la falta de privilegios.

En este punto, el comando docker run admite amplias opciones 'privilegiadas', junto con un "control de grano fino sobre las capacidades usando --cap-add y --cap-drop". Entonces, creo que las objeciones por motivos técnicos o de seguridad son discutibles. Si se agrega la opción de ejecución privilegiada junto con '--cap-add' y '--cap-drop', un ingeniero consciente de la seguridad podría optar por limitar una compilación con privilegios para incluir solo las capacidades específicas requeridas para su compilación.

Hola ,

Ya he informado de esto antes, el mismo problema.

¿Qué pasa con aquellos que solo quieren ejecutar un contenedor por VM con la misma identificación de usuario en la VM y el contenedor, usando Docker solo como una herramienta de empaquetado?

¿Existe todavía un problema de seguridad relacionado con esto?

Me encontré con este problema. Realmente podría usar capacidades para construir.

También encontré este problema.
Es muy útil cuando se usa la ventana acoplable como esclavos de CI / CD, lo que podría requerir un permiso privilegiado en docker build para instalar las cadenas de herramientas de construcción / prueba de CI / CD al construir la imagen de la ventana acoplable esclava.
Estoy esperando esta función durante años y realmente espero que pueda ser compatible en el futuro.

Realmente no entiendo por qué hay tanto rechazo por parte de los desarrolladores con respecto a la imagen de la ventana acoplable privilegiada.
Si los usuarios quieren pegarse un tiro en el pie, ¿por qué no dejarlos? Simplemente ponga un mensaje de advertencia y listo. Ya existen soluciones para lograr lo mismo, ¿por qué no hacerlo más fácil para los usuarios que realmente lo necesitan?
Han pasado 4-5 años y no ha habido ningún progreso en esto.
Simplemente asombroso...

A día de hoy, ni siquiera esta función se ha implementado todavía:
EJECUTAR --cap-add = SYS_PTRACE
que se adapte a las necesidades de muchos usuarios.

¿Podría sugerir cómo puedo construir este Dockerfile en el host 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

porque recibo este error al emerger 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'

¿Cómo puedo ejecutarlo sin --cap-add=SYS_ADMIN --device /dev/fuse o --privileged ?

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

Puedo hacerlo con un archivo bash separado en el punto de entrada, pero necesito un solo Dockerfile

@ amd-nick ¿cuál es su expectativa de la línea RUN unionfs-fuse ... durante la compilación? Incluso si eso funcionara, solo tendría el sistema de archivos montado durante ese único RUN , y desaparecería en el siguiente paso.

@thaJeztah es difícil de explicar para mí. Estoy intentando modificar este repositorio . ¿Puedo simplemente saltarme esta línea en el edificio?

Hola

Al azar, la compilación de la ventana acoplable elige un nombre de host que comienza con cero '0', lo que rompe nuestra aplicación, traté de ejecutar "nombre de host" en tal caso dentro de mi DockerFile pero enfrenté el mismo problema.

También me gustaría tener una opción para ejecutar la compilación de la ventana acoplable con RUNP u obtener una opción para elegir el nombre de host durante la compilación.

¿Alguien ha intentado construir este tipo de imágenes con Kaniko ? Lo acabo de hacer con el Dockerfile de @maneamarius en Docker para Mac y parece compilarse con éxito una vez que llamas al comando docker run "build" de Kaniko con --cap-add=SYS_PTRACE . Sin embargo, tengo algunos problemas para cargar el tarball resultante localmente, el uso de RAM es un poco alto ya que no puede usar overlayfs y el almacenamiento en caché de capas sigue siendo WIP. Es posible que las cosas funcionen si accedo a un registro, pero aún no lo he probado.

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

Tener esta función ayudaría enormemente a los esfuerzos para crear imágenes de Docker a través de Puppet en imágenes base de Redhat / CentOS.

Desde la última vez que publiqué , he realizado un seguimiento de los cambios en RUN guardar y ejecutar iteración, pero podemos almacenar en caché alpine , ubuntu , y cualquier base popular que exista).

Está en un estado en el que he tenido éxito en la construcción del Dockerfile de @maneamarius que emerge Golang en una imagen de Gentoo en este proyecto / demostración sin modificar el Dockerfile de @maneamarius o cortarlo de ninguna manera ( EDITAR: desde entonces Tuve que modificar Dockerfile para anclar la imagen base de gentoo a la versión que era latest en el momento de esta publicación. De lo contrario, aún no se ha modificado ):

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

También configuré Azure Pipelines para compilar el Dockerfile en una imagen con Kaniko con --cap-add=SYS_PTRACE , cargar el tarball de salida de Kaniko y ejecutar go version en la imagen generada. Pensé que alguna "prueba de vida" interactiva sería interesante. Algunos de los comentarios anteriores aquí también estaban relacionados con los sistemas de CI, así que pensé que configuraré un sistema de CI público para que funcione también. Por cierto, se consideró Travis CI, pero la salida de compilación fue demasiado larga y se canceló y Azure está perfectamente satisfecho con 166k líneas de salida. Si el Dockerfile se compilara con aproximadamente 70k líneas de salida menos, probablemente habría tenido éxito en Travis CI. Un vínculo a los resultados de la compilación de Azure Pipeline se encuentra en la parte superior del archivo README.

Usa buildah Luke

Estoy cerrando este problema porque la función ahora está disponible como 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 He actualizado mi buildx . Cuando estaba probando el comando que mencionaste, me estaba dando un error

$ 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 docs: For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

Gracias @AkihiroSuda . Funcionó ahora.

solo para agregar otro caso de uso.
Estoy tratando de arreglar una compilación de dockerfile de un contenedor ibmdb2 con una base de datos de prueba
IBM eliminó la imagen v10 del concentrador. Pero la imagen de la base de datos v11 solo comienza con --privileged.
Así que todo el código que configura la base de datos en el Dockerfile no funciona ahora porque db2 no se inicia sin privilegios. :(
Parece haber una solución complicada con el uso de docker run y docker commit.
En una tubería de construcción productiva, esto crea mucha complejidad adicional.

Tengo que preguntar como https://github.com/maneamarius en https://github.com/moby/moby/issues/1916#issuecomment -361173550

¿Por qué es tan importante apoyar esto? La construcción ejecuta una carrera bajo el capó.

En este caso de uso específico, una opción de compilación privilegiada admitiría una especie de "compatibilidad con versiones anteriores" y sé que no soy el único que tuvo este problema después de mi investigación web.

@uvwild No estoy seguro de si esto ayuda a su caso de uso, pero puede intentar compilar con kaniko.Su imagen se creará sin un docker deamon y puede extraer la imagen una vez que esté lista y usar kaniko es como ejecutar un contenedor. puede usar --privileged o --cap-add <capability which is needed> que podrían resolver su problema.

Acepto que no es una solución completa que esperabas, sino una solución alternativa más sencilla que puede encajar en tu proceso de compilación.

EDITAR: Como dijo @ alexey-vostrikov, buildah podría ser una solución más factible para casos de uso que necesitan --privileged para construir la imagen