Como ya explicamos en una ocasión anterior los contenedores aportan varias ventajas respecto a la virtualización completa estilo KVM, esta vez vamos a instalar LXD que no es mas que un wrapper sobre LXC que nos facilitará ciertas tareas.

Primero consultaremos si tenemos todo lo necesario en nuestro kernel para que LXD funcione:

Si queremos clonar contenedores tendremos que tener Rsync compilado con las siguientes use flags:

net-misc/rsync acl iconv -ipv6 -static xattr

app-emulation/lxd ~amd64

Instalamos todo el software necesario:

Permitimos que un usuario regular pueda gestionar los contenedores:

Si queremos tener autocompletado de los comandos de LXD:

Configuramos la red, básicamente consiste en meter la interfaz en un bridge y configurar la ip en dicho bridge:

bridge_lxcbr0="enp1s0"
config_lxcbr0="A.B.C.D/24"
routes_lxcbr0="default via E.F.G.H"
dns_servers_lxcbr0="8.8.8.8 8.8.4.4"

Metemos el bridge en el arranque y quitamos la interfaz física:

Hacemos que los usuarios del 0-65535 dentro de los contenedores sean mapeados a los UIDs del host de arriba: 1000000+uid y 1000000+gid

Arrancamos el servicio de LXD y lo metemos en el arranque:

Añadimos el repo de imágenes de linuxcontainers:

Consultamos que se haya añadido correctamente:

images <https://images.linuxcontainers.org:8443>
local <unix:///var/lib/lxd/unix.socket>

Consultamos las imágenes disponibles:

Lanzamos un CT:

Consultamos la lista de CTs:

+----------+---------+----------------+------+------------+-----------+
|   NAME   |  STATE  |      IPV4      | IPV6 |    TYPE    | SNAPSHOTS |
+----------+---------+----------------+------+------------+-----------+
| gentoo00 | RUNNING | 192.168.40.165 |      | PERSISTENT | 0         |
+----------+---------+----------------+------+------------+-----------+

Podemos acceder al CT directamente:

Los perfiles no son mas que opciones de configuración, estos se aplican en cascada, es decir el último en aplicarse añade, elimina o sobreescribe la configuración anterior.

default
migratable

name: default
config: {}
devices:
  eth0:
    nictype: bridged
    parent: lxcbr0
    type: nic

LXD nos permite limitar ciertos recursos, por ejemplo el uso de CPU:

name: cpusandboxed
profiles:
- default
- cpusandbox

Para limitar la RAM:

name: cpusandboxed
profiles:
- ramsandbox

Si queremos aplicarle varios profiles simultáneamente:

Profiles default,ramsandbox,cpusandbox applied to cpusandboxed

Podemos editar la config para algo concreto, por ejemplo cambiar la MAC:

profiles:
- default
config:
  volatile.base_image: 7a983015256a485891940af71b475612fa97f87173d044daab5d003950372312
  volatile.eth0.hwaddr: 02:00:00:57:ce:6f
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":100000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":100000}]'
devices: {}
ephemeral: false

LXD utiliza un rango de IDs de usuario para ejecutar cada uno de los CTs, esto es una medida de seguridad en caso de que algún atacante consiga escapar del CT, pero hay ciertas funcionalidades sobre todo a la hora de acceder a /proc que no funcionan de este modo, si queremos hacer el CT privilegiado:

 security.privileged: "true"

Los snapshots son una de las funcionalidades mas interesantes de las que dispone LXD-Btrfs, ya que Btrfs los soporta de forma nativa estos se realizan prácticamente en realtime sin penalización alguna.

Solo debemos asegurarnos de disponer de una versión reciente del kernel(4.X) y soporte para dicho sistema de ficheros.

Lo mas recomendable es montar /var del siguiente modo:

/dev/sda4 on /var type btrfs (rw,relatime)

Para crear un snapshot es tan sencillo como:

Con lxc list podemos ver a simple vista si el contenedor tiene snapshots:

+----------------+---------+----------------+------+------------+-----------+
|     NAME       |  STATE  |      IPV4      | IPV6 |    TYPE    | SNAPSHOTS |
+----------------+---------+----------------+------+------------+-----------+
+----------------+---------+----------------+------+------------+-----------+
| testkr0m       | RUNNING | X.X.X.X (eth0) |      | PERSISTENT | 1         |
+----------------+---------+----------------+------+------------+-----------+

Podemos consultar los snapshots de un CT en particular con:

Snapshots:
 limpio (taken at 2016/11/23 15:40 UTC) (stateless)

Para restaurar el CT a un estado anterior:

Para borrar un snapshot:

Otro tema a que todo sysadmin debe contemplar son los backups, se pueden realizar sin necesidad de montar otro LXD y mover el CT, tan solo comprimimos el rootfs:

Si queremos arrancar el CT en otro LXD:

Los CTs LXD tienen algunas limitaciones entre ellas los puntos de montaje NFS, para solventar esto montaremos el recurso compartido en el server de LXD y lo añadiremos al CT:

NFS_SERVER_IP:/data /mnt/nfs/data nfs rw,vers=4,async,noatime,nodiratime,soft,timeo=3,intr,bg 0 0

Otra limitación puede ser el uso de dispositivos loop, para poder montar una imagen ISO por ejemplo:

Miramos el UID del user del CT:

total 20
drwxr-xr-x+ 4 100000 100000 4096 may 17 15:52 .

Cambiamos el propietario del directorio externo:

Mapeamos el directorio externo con el del CT:

NOTA: Si el CT es privileged no hace falta hacer el cambio de permisos en /mnt/iso en el servidor LXD

Una de las grandes ventajas de utilizar LXD es que se puede partir de una infraestructura básica e ir creciendo, en cualquier momento se pueden migrar CTs entre servidores sin problemas.

Tenemos dos servers:

• SERVER1
• SERVER2

Ponemos a la escucha el socket de gestión en SERVER2:

Añadimos SERVER2 como lacayo de SERVER1:

Ahora podemos consultar los CTs de SERVER2 desde SERVER1:

Arrancar CTs remotos:

Movemos el CT de SERVER2 a SERVER1:

Lxd es un sistema muy potente y con muchas posibilidades, en este artículo solo se han comentado las funcionalidades básicas, para mas información siempre podemos consultar la web del proyecto .