Bueno, estoy ejecutando un contenedor que creará/modificará algunos archivos que necesito que persistan fuera del ciclo de vida del contenedor. Como resultado, estoy voluminizando una carpeta en el contenedor para ese propósito:
docker run -v $(pwd)/data:/app/data my-image En la primera ejecución, $(pwd)/data no existe, por lo que Docker lo creará por mí. Sin embargo, lo crea como el usuario con el que se ejecuta su propio proceso daemon, que es root . Esto es problemático ya que el usuario dentro del contenedor obviamente no es root .
Para solucionar este problema de permisos, creé un grupo de usuarios en la máquina host con la misma ID que el usuario dentro del contenedor, les di acceso a la carpeta principal de $(pwd)/data y agregué configuraciones de permisos de grupo en la carpeta ( chmod g+s ). Entonces, si ejecuto el siguiente comando como root:
sudo mkdir whatver la carpeta whatever será modificable por ese grupo y por extensión, por el usuario del contenedor. sin embargo, cuando Docker crea la carpeta $(pwd)/data , todavía se crea como perteneciente a la root del grupo y, nuevamente, el usuario dentro del contenedor no puede modificar los datos dentro de él.
En este momento, he solucionado esto creando las carpetas requeridas antes de ejecutar el contenedor. Sin embargo, esta es una solución sucia y estoy buscando una solución más limpia. ¿Alguien más se ha enfrentado a este problema? ¿Es un problema que Docker no respete la configuración de permisos de grupo en la carpeta principal o me estoy perdiendo algo aquí o estoy haciendo algo mal?
No considero que hacer las carpetas primero sea una solución sucia, esa es una mejor práctica para mí. Docker está ejecutando un montaje de enlace para usted, y esto fallará cuando el directorio de origen no exista. Para comodidad del usuario, la ventana acoplable creará este directorio por usted cuando realice un montaje de host y falte el directorio, pero no es necesario utilizar esta funcionalidad y encontrará que otros tipos de montajes no realizarán la creación del directorio por usted (p. ej. la sintaxis --mount utilizada a menudo por el modo swarm).
Puede iniciar su contenedor como root y corregir los permisos en el directorio con un punto de entrada, antes de ejecutar algo como un exec gosu app_user app_server al final para pasar de la raíz al usuario. Hago esto en el punto de entrada de mis imágenes de la base acoplable , lo cual es útil para un flujo de trabajo de desarrollador en el que los desarrolladores a menudo necesitan actualizar dinámicamente el contenedor para que funcione con su entorno de host.
De lo contrario, puede cambiar a volúmenes con nombre. Estos se inicializarán cuando sean nuevos o estén vacíos usando el contenido del directorio y los permisos de la imagen. Son una mejor práctica cuando necesita persistencia pero no acceso directo al sistema de archivos al contenido del volumen de los usuarios en el host. En su lugar, accedería al volumen con nombre desde el interior de los contenedores que montan el volumen.