LXD (Español)

From ArchWiki
Jump to navigation Jump to search
Estado de la traducción: esta traducción de LXD fue revisada el 2021-01-30. Si existen cambios puede actualizarla o avisar al equipo de traducción.

LXD es un es un administrador/hipervisor para contenedores (a través de LXC) y máquinas virtuales (a través de QEMU).

Preparación

Software requerido

Instale el paquete lxd, entonces active lxd.service.

Configuración para contenedores sin privilegios

Se recomienda utilizar contenedores sin privilegios (véase Linux Containers#Privileged containers or unprivileged containers para obtener una explicación de la diferencia).

Para poder utilizarlos, necesita activar el soporte para ejecutar contenedores sin privilegios.

Una vez activado, todos los contenedores se iniciarán unpriviledged (sin privilegios) de forma predeterminada.

Para ver la alternativa, véase cómo configurar contenedores con privilegios.

Configurar LXD

En el primer arranque, es necesario configurar LXD.

Ejecute como superusuario:

# lxd init

Esto iniciará una configuración interactiva y guiada en el terminal, que cubre diferentes temas como almacenamientos, redes, etc.

Puede encontrar una descripción general en Guía de inicio.

Accediendo a LXD como un usuario sin privilegios

Por defecto, el demonio LXD permite el acceso a los usuarios del grupo lxd, así que añada su usuario al grupo:

# usermod -a -G lxd usuario
Advertencia: Cualquiera añadido al grupo lxd es equivalente al superusuario. Para más información véase [1] y [2].

Utilización

LXD consta de dos partes:

  • el demonio (el binario lxd)
  • el cliente (el binario lxc)
Nota: lxc no es LXC; el nombre es un poco confuso, puede leer la publicación del foro sobre la comparación de LXD vs LXC con respecto a la diferencia.

El cliente se utiliza para controlar uno o varios demonios.

El cliente también se puede utilizar para controlar servidores LXD remotos.

Resumen de las órdenes

Puede obtener una descripción general de todas las órdenes disponibles escribiendo:

$ lxc

Crear un contenedor

Puede crear un contenedor con lxc launch, por ejemplo:

$ lxc launch ubuntu:20.04

Los contenedores se basan en imágenes, que se descargan de servidores de imágenes o servidores LXD remotos.

Puede ver la lista de servidores ya añadidos con:

$ lxc remote list

Puede listar todas las imágenes en un servidor con lxc image list, por ejemplo:

$ lxc image list images:

Esto le mostrará todas las imágenes en uno de los servidores predeterminados: images.linuxcontainers.org

También puede buscar imágenes añadiendo términos como el nombre de la distribución:

$ lxc image list images:debian

Lanza un contenedor con una imagen de un servidor específico con:

$ lxc launch servername:imagename

Por ejemplo:

$ lxc launch images:centos/8/amd64 centos

Para crear un contenedor Arch de amd64:

$ lxc launch images:archlinux/current/amd64 arch

Crear una máquina virtual

Simplemente añada la opción --vm a lxc launch:

$ lxc launch ubuntu:20.04 --vm
Nota:
  • Por ahora, las máquinas virtuales admiten menos funciones que los contenedores (véase Diferencia entre contenedores y máquinas virtuales por ejemplo).
  • Solo las variantes cloud de las imágenes oficiales activan el lxd-agent listo para usar (que es necesario para las órdenes habituales de lxc como lxc exec).
    Puede buscar imágenes en la nube con lxc image list images: cloud o lxc image list images: nombre-distribución cloud.
    Si utiliza otras imágenes o encuentra problemas, eche un vistazo a #lxd-agent dentro de una máquina virtual.

Utilizar y administrar un contenedor o VM

Véase Gestión de instancias en la Guía de introducción oficial de LXD.

Configuración de contenedor/VM (opcional)

Puede añadir varias opciones a las instancias (contenedores y VM).

Véase Configuración de instancias en la Guía avanzada oficial de LXD para obtener más detalles.

Consejos y trucos

Acceder a los contenedores por nombre de host

Esto supone que está utilizando el puente predeterminado, que se llama lxdbr0 y que está utilizando systemd-resolved.

 # systemd-resolve --interface lxdbr0 --set-domain '~lxd' --set-dns $(lxc network get lxdbr0 ipv4.address | cut -d / -f 1)

Ahora puede acceder a los contenedores por su nombre:

 $ ping nombrecontenedor.lxd

Otra solución

Parece que la solución systemd-resolve deja de funcionar después de un tiempo.

Otra solución es crear un /etc/systemd/network/lxd.network que contenga (reemplace x e y para que coincida con la IP de su bridge):

 [Match]
 Name=lxdbr0
 [Network]
 DNS=10.x.y.1
 Domains=~lxd
 IgnoreCarrierLoss=yes
 [Address]
 Address=10.x.y.1/24
 Gateway=10.x.y.1

Y luego active) e inicie systemd-networkd.service.

Utilizar las aplicaciones Wayland y Xorg

Nota: Considere siempre las implicaciones de seguridad, ya que algunos de los métodos descritos pueden debilitar la separación entre el contenedor y el host.

Existen varios métodos para utilizar aplicaciones GUI dentro de contenedores.

Puede encontrar una descripción general en el Foro oficial de LXD: https://discuss.linuxcontainers.org/t/overview-gui-inside-containers/8767

Método 1: Utilice el servidor Wayland o Xorg del host

Nota: La utilización de Xorg podría debilitar la separación entre el contenedor y el host, porque Xorg permite que las aplicaciones accedan a otras ventanas de aplicaciones. Por lo tanto, las aplicaciones de contenedor pueden tener acceso a las ventanas de las aplicaciones de host. Utilice Wayland en su lugar (pero tenga en cuenta que las desventajas de Xorg también se aplican a XWayland).

Resumen: En este método otorgamos a los contenedores acceso a los sockets del host de Wayland (+ XWayland) o Xorg.

1. Añada los siguientes dispositivos a un perfil de contenedores.

Véase también: Documentación LXD sobre dispositivos

Dispositivo general para la GPU:

mygpu:
   type: gpu
Nota: La ruta debajo de "listen" es diferente, porque las carpetas /run y /tmp pueden estar anuladas, véase: https://github.com/lxc/lxd/issues/4540

Dispositivo para Wayland Socket: Notas:

  • Ajuste la pantalla (wayland-0) en consecuencia.
  • Añada las carpetas en /mnt y /tmp dentro del contenedor, si aún no existen.
Waylandsocket:
    bind: container
    connect: unix:/run/user/1000/wayland-0
    listen: unix:/mnt/wayland1/wayland-0
    uid: "1000"
    gid: "1000"
    security.gid: "1000"
    security.uid: "1000"
    mode: "0777"
    type: proxy

Dispositivo para el socket Xorg (o XWayland): 'Nota:' Ajuste el número de pantalla en consecuencia (por ejemplo, X1 en lugar de X0).

Xsocket:
    bind: container
    connect: unix:/tmp/.X11-unix/X0
    listen: unix:/mnt/xorg1/X0
    uid: "1000"
    gid: "1000"
    security.gid: "1000"
    security.uid: "1000"
    mode: "0777"
    type: proxy

2. Vincule los sockets a la ubicación correcta dentro del contenedor .

Nota: Estos scripts deben ejecutarse después de cada inicio del contenedor; puede automatizar esto con systemd, por ejemplo.

Shell-Script para vincular el socket Wayland:

#!/bin/sh
mkdir /run/user/1000
ln -s /mnt/wayland1/wayland-0 /run/user/1000/wayland-0

Vincula el socket Xorg (o XWayland):

#!/bin/sh
ln -s /mnt/xorg1/X0 /tmp/.X11-unix/X0

3. Añada variables de entorno a la configuración de los usuarios dentro del contenedor.

Nota: Ajuste los números de pantalla y/o el nombre del archivo (.profile) según corresponda.

Para Wayland:

$ echo "export XDG_RUNTIME_DIR=/run/user/1000" >> ~/.profile
$ echo "export WAYLAND_DISPLAY=wayland-0" >> ~/.profile
$ echo "export QT_QPA_PLATFORM=wayland" >> ~/.profile

Para Xorg (or XWayland):

$ echo "export DISPLAY=:0" >> .profile

Recargue el .profile:

$ . .profile

4. Instale el software necesario en el contenedor.

Nota: Es necesario añadir el software necesario. Por ahora puede instalar una aplicación GUI de ejemplo, esto probablemente también instalará todos los paquetes necesarios.

5. Inicie aplicaciones GUI.

Ahora debería poder iniciar aplicaciones GUI dentro del contenedor (a través del terminal, por ejemplo) y hacer que aparezcan como una ventana en la pantalla de su host.

Puede probar "glxgears", por ejemplo.

Contenedores con privilegios

Nota: Los contenedores privilegiados no están aislados del anfitrión.

El usuario root del contenedor es el usuario root del host.

En su lugar, utilice contenedores sin privilegios siempre que sea posible.

Si desea configurar un contenedor privilegiado, debe proporcionar la clave de configuración security.privileged=true.

O durante la creación del contenedor:

$ lxc launch ubuntu:20.04 ubuntu -c security.privileged=true

O para un contenedor ya existente, puede editar la configuración:

$ lxc config edit ubuntu
name: ubuntu
profiles:
- default
config:
  ...
  security.privileged: "true"
  ...

Solución de problemas

lxd-agent dentro de una máquina virtual

Dentro de algunas imágenes de máquinas virtuales, el lxd-agent no está activado de forma predeterminada.

En este caso, debe activarlo manualmente, por ejemplo, montando un recurso compartido de red 9p. Esto requiere acceso a la consola con un usuario válido.

Inicie sesión con lxc console y reemplace nombre-máquinavirtual en consecuencia:

 $ lxc console nombre-máquinavirtual

Inicie sesión como root:

Nota: En algunos sistemas, primero debe configurar una contraseña de root para poder iniciar sesión como root. Puede utilizar cloud-init para esto, por ejemplo.
$ su root

Monte el recurso compartido de red:

$ mount -t 9p config /mnt/

Vaya a la carpeta y ejecute el script de instalación (esto activará el agente lxd dentro de la VM):

$ cd /mnt/
$ ./install.sh 

Después de una instalación exitosa, reinicie con:

$ reboot

Luego, el lxd-agent estará disponible y lxc exec debería funcionar.

Verificar la configuración del kernel

Por defecto, el kernel de Arch Linux está compilado correctamente para contenedores de Linux y su interfaz LXD. Sin embargo, si está utilizando un kernel personalizado o ha cambiado las opciones del kernel, es posible que el kernel esté configurado incorrectamente. Verifique que su kernel esté configurado correctamente:

$ lxc-checkconfig

Los límites de recursos no se aplican cuando se ven desde dentro de un contenedor

Instale lxcfs y inicie lxcfs.service.

LXD deberá reiniciarse. Active lxcfs.service para que el servicio se inicie en el momento del arranque.

Falla el inicio de una máquina virtual

Si observa el error: Error: Required EFI firmware settings file missing: /usr/share/ovmf/x64/OVMF_VARS.ms.fd

Arch Linux no distribuye el firmware ovmf firmado para inicio seguro, así que para arrancar máquinas virtuales debe desactivar el arranque seguro por el momento.

$ lxc launch ubuntu:18.04 test-vm --vm -c security.secureboot=false

Esto también se puede añadir al perfil predeterminado haciendo:

$ lxc profile set default security.secureboot=false

Sin IPv4 con systemd-networkd

A partir de la versión 244.1, systemd detecta si los contenedores pueden escribir en /sys. Si es así, udev se inicia automáticamente y rompe IPv4 en contenedores sin privilegios. Véase commit bf331d8 y el debate en linuxcontainers.

En los contenedores creados a partir de 2020, ya debería haber un anulador de systemd.networkd.service para solucionar este problema, debe crearlo si no es así:

/etc/systemd/system/systemd-networkd.service.d/lxc.conf
[Service]
BindReadOnlyPaths=/sys

También podría solucionar este problema estableciendo raw.lxc: lxc.mount.auto = proc:rw sys:ro en el perfil del contenedor para asegurarse de que /sys es de solo lectura para todo el contenedor, aunque esto podría ser problemático, según el debate vinculado arriba.

Desinstalar

Detenga y desactive lxd.service y lxd.socket. Luego desinstale el paquete lxd.

Si desinstaló el paquete sin desactivar el servicio, es posible que tenga un enlace simbólico roto en /etc/systemd/system/multi-user.wants/lxd.service.

Si desea eliminar todos los datos:

 # rm -r /var/lib/lxd

Si utilizó alguna de las configuraciones de red de ejemplo, debería eliminarla también.

Véase también