¿de qué se trata?

Se trata de un problema bastante técnico en el uso de contenedores acoplables que interactúan con la computadora host de la ventana acoplable, generalmente relacionado con el uso del sistema de archivos host dentro del contenedor.
Esto sucede en particular en el contexto de la investigación reproducible.
Desarrollé una utilidad de código abierto que ayuda a abordar ese problema.

contenedores acoplables como entornos de ejecución

El caso de uso inicial y principal de un contenedor acoplable: una aplicación autónoma que solo interactúa con el sistema host con algunos puertos de red.
Piense en una aplicación web: el contenedor acoplable normalmente contiene un servidor web y una aplicación web, que se ejecuta, por ejemplo, en el puerto 80 (dentro del contenedor). Luego, el contenedor se ejecuta en el host, vinculando el puerto interno 80 del contenedor a un puerto del host (por ejemplo, 8000).
Entonces, la única interacción entre la aplicación en contenedor y el sistema host es a través de este puerto de red vinculado.

Los contenedores como entornos de ejecución son completamente diferentes:

• en lugar de contener una aplicación, es el sistema de compilación de la aplicación el que está en contenedores.
  • podría ser un compilador, un IDE, un motor de notebook, un sistema de publicación Quarto...
• los objetivos son:
  • tener un entorno estándar, fácil de instalar y compartir
    • imagine un entorno de compilación complejo, con versiones fijas de R, Python y millones de paquetes externos. Instalar todo con las versiones correctas puede ser una tarea muy difícil y que requiere mucho tiempo. Compartir una imagen de la ventana acoplable que contiene todo lo que ya está instalado y preconfigurado supone un verdadero ahorro de tiempo.
  • tener un entorno reproducible
    • al usarlo, puede reproducir algunos resultados de análisis, ya que está utilizando el mismo entorno controlado
    • también puedes reproducir errores fácilmente, que es el primer paso para solucionarlos

Pero, para poder utilizar esos entornos de ejecución, esos contenedores deben tener acceso al sistema host, en particular al sistema de archivos del usuario host.

contenedores acoplables y el sistema de archivos host

Supongamos que ha contenedorizado un IDE, p. Rstudio.
Su Rstudio está instalado y ejecutándose dentro del contenedor acoplable, pero necesita leer y editar archivos en la carpeta de su proyecto.

Para eso, vinculas y montas la carpeta de tu proyecto (en tu sistema de archivos host) usando la opción docker run --volume.
Entonces se podrá acceder a sus archivos desde el contenedor acoplable.

El desafío ahora son los permisos de archivos. Suponga que su usuario host tiene un ID de usuario 1001, y suponga que el usuario propietario del proceso Rsudio en el contenedor es 0 (raíz) o 1002.

Si el usuario del contenedor es root, entonces no tendrá problemas para leer sus archivos.
Pero tan pronto como edite algunos archivos existentes y produzca otros nuevos (por ejemplo, pdf, html), estos archivos pertenecerán a la raíz ¡también en el sistema de archivos host!.
Lo que significa que su usuario de host local no podrá usarlos ni eliminarlos, ya que pertenecen al root.

Ahora, si la identificación de usuario del contenedor es 1002, es posible que Rstudio no pueda leer sus archivos, editarlos o producir archivos nuevos.
Incluso si puede, al configurar algunos permisos muy permisivos, es posible que el usuario de su host local no pueda usarlos.

Por supuesto, una forma de fuerza bruta de resolver ese problema es ejecutar con root tanto en la computadora host como dentro del contenedor acoplable. Esto no siempre es posible y plantea algunos problemas de seguridad críticos obvios.

resolviendo el problema del propietario del archivo, parte 1: la opción docker run --user

Debido a que no podemos saber de antemano cuál será el ID de usuario del host (aquí 1001), no podemos preconfigurarlo
el ID de usuario del usuario del contenedor acoplable.

docker run ahora proporciona una opción --user que permite crear un pseudo usuario con algún ID de usuario proporcionado
en tiempo de ejecución. Por ejemplo, docker run --user 1001 ... creará un contenedor acoplable que se ejecuta con procesos
perteneciente a un usuario con ID de usuario 1001.

Entonces, ¿qué estamos discutiendo todavía sobre este tema? ¿No está solucionado?

Aquí algunas peculiaridades de ese usuario creado dinámicamente:

• es un pseudo usuario
• no tiene directorio de inicio (/home/xxx)
• no aparece en /etc/passwd
• no se puede preconfigurar, p.e. con un perfil bash, algunas variables de entorno, valores predeterminados de la aplicación, etc...

Podemos solucionar estos problemas, pero puede resultar tedioso y frustrante.
Lo que realmente nos gustaría es preconfigurar un usuario de contenedor acoplable y poder cambiar dinámicamente su ID de usuario en el tiempo de ejecución...

resolviendo el problema del propietario del archivo, parte 2: ingrese docker_userid_fixer

docker_userid_fixer es una utilidad de código abierto destinada a usarse como punto de entrada de Docker para solucionar el problema del ID de usuario que acabo de plantear.

Veamos cómo usarlo: lo configuras como tu PUNTO DE ENTRADA de la ventana acoplable, especificando qué usuario debe usarse y modificando dinámicamente su ID de usuario:

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

Seamos precisos en nuestros términos:

• el usuario objetivo, es el usuario solicitado a docker_userid_fixer, aquí usuario1
• el usuario solicitado, es el usuario proporcionado por docker run, es decir, el usuario que (inicialmente) posee el primer proceso (PID 1)

Luego, en la creación del tiempo de ejecución del contenedor, hay dos opciones:

• o el ID de usuario solicitado (ya) coincide con el ID de usuario objetivo, entonces no es necesario cambiar nada
• o no. Por ejemplo, el ID de usuario solicitado es 1001 y el ID de usuario objetivo es 100. Luego, docker_userid_fixer corregirá el ID de usuario del usuario objetivo usuario1 de 1000 a 1001, directamente en el proceso principal del contenedor.

Entonces, en la práctica, esto resuelve nuestro problema:

• si no necesita corregir el ID de usuario de su contenedor, simplemente use Docker Run de la manera habitual (sin la opción --user)
• o usa la opción --user, luego, además de ejecutar su proceso principal con el ID de usuario que solicitó, modificará su usuario preconfigurado al ID de usuario solicitado, de modo que su contenedor se ejecute con el usuario y el usuario previstos. ID de usuario.

configuración de docker_userid_fixer

Puedes encontrar instrucciones sobre la configuración aquí.

Pero todo se reduce a:

• compila o descarga el pequeño ejecutable (17k)

• cópialo en tu imagen acoplable

• hacerlo ejecutable como setuid root

• configurarlo como tu punto de entrada

los detalles sangrientos

He puesto algunas notas breves https://github.com/kforner/docker_userid_fixer#how-it-works
pero intentaré reformularlo.

El quid de la implementación es la raíz setuid del ejecutable docker_userid_fixer en el contenedor.
Necesitamos permisos de root para cambiar el ID de usuario, y este setuid permite esa ejecución privilegiada solo para
el programa docker_userid_fixer, y eso por muy poco tiempo.

Tan pronto como se haya modificado el ID de usuario, si es necesario, docker_userid_fixer cambiará el proceso principal
al usuario solicitado (¡y al ID de usuario!).

Si estás interesado en estos temas (docker, investigación reproducible, desarrollo de paquetes R, algorítmica, optimización del rendimiento, paralelismo...) no dudes en contactarme para discutir oportunidades laborales y de negocio.