Agregar un directorio de host compartido a un contenedor LXC / LXD


19

He estado experimentando con LXC / LXD en Ubuntu 14.04 y todo funciona muy bien. Solo necesito descubrir cómo hacer que los directorios compartidos funcionen entre mi máquina host y un contenedor para poder deshacerme de Virtualbox de una vez por todas.

He visto esta página: https://wiki.gentoo.org/wiki/LXD

Lo que proporciona instrucciones, pero sigo recibiendo errores.

¿Alguien sabe de instrucciones simples y claras para que esto funcione? Cualquier ayuda muy apreciada.


2
Me las he arreglado para montar un directorio del servidor utilizando: lxc config device add confexample sharedtmp disk path=/tmp source=/tmp/shared. Pero mirando el directorio en el contenedor, el propietario y el grupo de los archivos están configurados en 'nobody' y 'nogroup' y el montaje es de solo lectura.
usuario47227

¿Podría por favor agregar un poco más de detalles? ¿Qué hiciste exactamente , qué quisiste lograr y qué sucedió en su lugar? ¿Encontró algún mensaje de advertencia o error? Reproduzca en su totalidad en su pregunta. Puede seleccionar, copiar y pegar el contenido del terminal y la mayoría de los mensajes de diálogo en Ubuntu. (ver ¿Cómo hago una buena pregunta? )
David Foerster

Suponiendo que está utilizando un contenedor sin privilegios y que la asignación de UID / GID es el problema, eche un vistazo a esta sección de un artículo sobre las asignaciones de usuarios con LXD. Sin embargo, esto probablemente se agregó a LXD después de que hizo su pregunta.
0xC0000022L

No sé qué versión agregó esto (estoy en 2.18) pero si es posible, también podría usar lxc filepara transferir archivos entre el host y el contenedor, usando pushy pull.
code_dredd

Respuestas:


21

Las instrucciones en https://wiki.gentoo.org/wiki/LXD que mencionas son correctas pero pueden necesitar un poco más de explicación.

En el host, primero verifica la propiedad del directorio en el que se almacenan los datos del contenedor. correr

sudo ls -l /var/lib/lxd/containers

y marque el propietario del contenedor con el que desea compartir el directorio. En mi caso, el uidy gidambos fueron 100000.

Luego, utilícelos para cambiar la propiedad del directorio que desea compartir:

sudo chown 100000:100000 /tmp/share_on_host

Comparta el directorio con el contenedor de la manera que indicó en su comentario:

lxc config device add mycontainer sharedtmp disk \
                  path=/tmp/share_on_guest source=/tmp/share_on_host

Ahora, en el contenedor, verá que el directorio /tmp/share_on_guest(no recomendaría montar su directorio /tmpporque el sistema lo utiliza para otras cosas y tiene permisos especiales) es propiedad de root. A partir de aquí, puede usar chownen el contenedor para cambiar la propiedad a la apropiada uidy gidpara su usuario en el contenedor.

Como nota al margen, después de cambiar la propiedad del contenedor a, por ejemplo, un usuario con uid33, verá en el host que uidahora hay 100033, lo que tiene mucho sentido.


No estoy seguro de si es solo mi configuración, pero con LXD v3.0.3 LTS (Ubuntu 18.04 LTS) no encontré nada más que enlaces simbólicos dentro de /var/lib/lxd/containerseso /var/lib/lxd/storage-pools/lxd/containers(en este caso, el último lxdbit es el nombre de mi grupo de almacenamiento ZFS). Todos los contenedores parecían tener el mismo 165536 uid / gid cuando se ejecutaban y pertenecían root:rootcuando estaban apagados.
deoren

1
Me doy cuenta de que esta es una vieja pregunta + respuesta, pero en Ubuntu 18.04, no tuve que meterme con ningún permiso. ¡Simplemente agregue la carpeta con lxc configy funcionó de maravilla!
Apache

4

Aquí hay una respuesta actualizada a esta pregunta.

Monte la carpeta del host /var/wwwcomo /var/testen el contenedor.

lxc config device add mycontainer vartest disk source=/var/www path=/var/test

Bienvenido a Ask Ubuntu! Recomiendo editar esta respuesta para expandirla con detalles específicos sobre cómo hacerlo. (Consulte también ¿Cómo escribo una buena respuesta? Para obtener consejos generales sobre qué tipo de respuestas se consideran más valiosas en AskUbuntu.)
David Foerster

3

Puede asignar dispositivos adicionales al contenedor, y estos pueden ser carpetas accesibles para el host.

$ lxc config ## display help
...
lxc config device add [<remote>:]<container> <device> <type> [key=value...]
    Add a device to a container.
...

Tenga en cuenta que <device>es solo un nombre arbitrario que usted asigna, que se usará como ID para la administración posterior del dispositivo.

Por ejemplo, para montar la carpeta del host "./host" como "/ mnt / host" en el contenedor ...

lxc config device add mycontainer vartest disk source=$(pwd)/host path=/mnt/host

Sigue habiendo un problema : si desea que el host y el contenedor puedan escribir en esta carpeta, la propiedad y los permisos deben configurarse en consecuencia. Esto se complica por el modo predeterminado de LXD que virtualiza los rangos numéricos para los idvalores de usuario y grupo . Sin embargo, existe una solución fácil : evitar esta virtualización configurando el contenedor para que se ejecute con privilegios equivalentes de host ...

lxc config set <container> security.privileged true

Las implicaciones completas de seguridad del host de este enfoque no me quedan claras en este momento, pero parece estar algo "contenido" por la virtualización. El riesgo práctico depende de cómo y por qué usará el contenedor. Consulte las notas técnicas en https://insights.ubuntu.com/2017/06/15/custom-user-mappings-in-lxd-containers

Además, tenga en cuenta que este enfoque probablemente funciona mejor si normalmente opera en el contenedor como un usuario no root, como si se conecta con ...

lxc exec zesty -- su --login ubuntu

Hay un problema con el inicio de sesión no root: el enves diferente, en particular http_proxy. Un ejemplo Solución: sudo http_proxy=http://[fe80::1%eth0]:13128 apt-get update.
nobar

Al respecto http_proxy, creo que la solución más fácil es probablemente habilitar IPV4 como se explica aquí .
nobar

... seguido por sudo dhclienten el contenedor - o cambiar manuala dhcpin 50-cloud-init.cfg. Buenas pistas aquí: github.com/lxc/lxd/issues/1298
nobar

1
Esta es una idea evidentemente mala . Recomendar cambiar a contenedores privilegiados subvierte uno de los avances que trajo LXD. Si bien LXC 1.x también ofreció la posibilidad de utilizar contenedores sin privilegios (y sí, incluso como root), fue un poco más complicado ordenar los detalles. Con LXD esto ahora es cosa del pasado. Además, ¿qué tiene de complicado configurar ACL en alguna carpeta para permitir el acceso requerido al UID del lado del host o usar el método descrito aquí ? Sí, mapear UID / GID no es la única forma.
0xC0000022L

1

Basado en la excelente respuesta de ph0t0nix , propongo el siguiente enfoque paso a paso para mi servidor Ubuntu 18.04:

  1. En el host, determine el UID del propietario de rootfs:

    sudo ls -l /var/lib/lxd/storage-pools/lxd/containers/webserver/rootfs  
    id -u root    100000
  2. En el contenedor, determine el UID de ubuntu (es decir, el usuario en el contenedor):

    id -u ubuntu    1000
  3. Cree una carpeta compartida en el host y agréguela al contenedor:

    lxc config device add webserver mydevicename disk path=/home/share_on_guest source=/home/share_on_host
  4. Ajuste en el UID del host de la carpeta compartida (UID = host UID + invitado UID):

    sudo chown 101000:101000 /home/share_on_host
  5. Guest (usuario ubuntu) ahora tiene acceso a la carpeta compartida y puede ajustarse dentro del acceso del contenedor a la carpeta compartida usando chmod.


0

Ahora tengo una solución segura y funcional para este problema, utilizando perfiles LXD para manejar la asignación entre UID y GID en el contenedor y en el host.

Una esencia muy útil se puede encontrar aquí:

https://gist.github.com/bloodearnest/ebf044476e70c4baee59c5000a10f4c8


55
Tenga en cuenta que, desde un punto de vista de seguridad, hacer que las cosas se puedan escribir en todo el mundo suele ser una mala idea. Probablemente debería considerar el uso de ACL POSIX en la ruta del host, otorgando acceso al usuario del contenedor agregando una ACL específica para ese uid, y luego para cualquier otro usuario del host que también necesite acceso de escritura.
stgraber

1
@stgraber, aunque estoy de acuerdo con lo que dijiste, no tengo idea de cómo configurarlo. Algunos enlaces serían útiles.
s3v3n

¡Por favor, no recomiende los 0777permisos aka "por favor, hackea mi sistema y destruye mis datos" sin razón aparente! Casi nunca hay una razón para eso porque se puede evitar con modificaciones más sensatas como cambiar la propiedad (de grupo). -1
David Foerster

Entiendo su punto de vista, pero solo lo usé como una solución temporal en una máquina de desarrollo de un solo usuario, en ausencia de cualquier otra forma de hacerlo funcionar. Desde entonces descubrí que usar perfiles es la forma de manejar esto, ¡mira mi respuesta editada arriba!
user47227

1
¿Qué tiene de difícil usar ACL o el método descrito aquí ?
0xC0000022L
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.