LXC: primeros pasos

Hola a todos. Llevo un tiempo dándole vueltas a dar un salto más en la virtualización. Teóricamente con KVM conseguimos muy buen rendimiento, pero con contenedores reduciríamos al máximo la diferencia entre la máquina anfitriona y sus invitados.

Ahora todos los hispters gritarán de alegría coreando al unísono Docker! Docker! Docker!, pues guardad los fulares porque por ahora simplemente vamos a realizar una pequeña prueba y lo más natural es probar la tecnología que es más parecida a mi forma de administrar los sistemas, LXC. Para los más viejos del lugar, LXC vendría a ser como un chroot hipervitaminado. También hay que decir que Docker se basó inicialmente en LXC para su desarrollo y que su concepto de instancia es un poco diferente.

En un horizonte más lejano tenemos OpenStack, pero cualquier tecnología de virtualización que aprendamos nos servirá en ese ecosistema por lo que es tiempo bien aprovechado.

Para esta pequeña prueba vamos a crearnos un par de máquinas, una con Debian (Stretch, que es la testing actualmente) y otra con Ubuntu (Xenial, es decir la reciente 16.04), evidentemente no utilizaremos dos máquinas físicas, bastará con que sean dos máquinas virtuales con *KVM, sí, habéis oído bien, contenedores dentro de máquinas virtuales, una locura.

Crearé estas dos instancias porque quiero comparar la configuración de ambas aproximaciones para ver cuál es más cómoda de administrar. Ambas distribuciones tienen el paquete LXC en la versión 2.0 por lo que la comparación será justa. Una vez que tengamos listos estos servidores crearemos un contenedor en cada una de ellas, con la misma configuración y dentro de ellos haremos una instalación rápida de PostgreSQL para comparar su rendimiento.

En este punto supondremos que tenemos ambas distribuciones limpias y funcionando, ya que la configuración de KVM la tenemos más que superada por posts anteriores. En orden de antigüedad: 1, 2, 3, 4, 5 y 6.

La configuración de la base de LXC es similar tanto en Debian como en Ubuntu, así que estos comandos podemos ejecutarlos en ambos sistemas. Primero instalamos el paquete principal:

# apt-get install lxc

Ahora, para asegurarnos que todo funciona correctamente disponemos de una orden que se instala junto con la base:

# lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...  
Kernel configuration found at /boot/config-4.4.0-31-generic  
--- Namespaces ---
Namespaces: enabled  
Utsname namespace: enabled  
Ipc namespace: enabled  
[...]

Si la instalación ha sido exitosa todos los parámetros nos deben aparecer con un tranquilizador enabled y en un agradable verde lima. Listo, ya podemos crear nuestro primer contenedor:

# lxc-create -t download -n ubuntu-test
Setting up the GPG keyring  
Downloading the image index

---
DIST    RELEASE ARCH    VARIANT BUILD  
---
alpine    3.0 amd64   default 20160630_17:50  
alpine    3.0 i386    default 20160630_17:50  
[...]
ubuntu    yakkety s390x   default 20160717_03:49  
---

Distribution: ubuntu  
Release: xenial  
Architecture: amd64

Downloading the image index  
Downloading the rootfs  
Downloading the metadata  
The image cache is now ready  
Unpacking the rootfs

---
You just created an Ubuntu container (release=xenial, arch=amd64, variant=default)

To enable sshd, run: apt-get install openssh-server

For security reason, container images ship without user accounts  
and without a root password.

Use lxc-attach or chroot directly into the rootfs to set a root password  
or create user accounts.  

Como véis hemos elegido Ubuntu para nuestro contenedor y en la versión estable, la 16.04, Xenial, por suspuesto la de 64 bits. Cuando lancemos el contenedor veremos una pequeña diferencia entre los dos anfitriones, primero Debian:

# lxc-start -n ubuntu-test
# lxc-info -n ubuntu-test
Name:           ubuntu-test  
State:          RUNNING  
PID:            2878  
CPU use:        0.51 seconds  
BlkIO use:      8.00 KiB  
# lxc-ls -f
NAME        STATE   AUTOSTART GROUPS IPV4 IPV6  
ubuntu-test RUNNING 0         -      -    -  

Y ahora Ubuntu:

# lxc-start -n ubuntu-test
# lxc-info -n ubuntu-test
Name:           ubuntu-test  
State:          RUNNING  
PID:            4459  
IP:             10.0.3.162  
CPU use:        0.71 seconds  
BlkIO use:      8.00 KiB  
Memory use:     12.52 MiB  
KMem use:       0 bytes  
Link:           vethYR5TMW  
 TX bytes:      1.27 KiB
 RX bytes:      1.40 KiB
 Total bytes:   2.67 KiB
# lxc-ls -f
NAME        STATE   AUTOSTART GROUPS IPV4       IPV6  
ubuntu-test RUNNING 0         -      10.0.3.162 -  

La diferencia es que la red no se ha levantado automáticamente en el primer caso. Vamos a arreglar esto. Creamos el archivo /etc/default/lxc-net en nuestro anfitrión Debian con el siguiente contenido:

USE_LXC_BRIDGE="true"  
LXC_BRIDGE="lxcbr0"  
LXC_ADDR="10.0.3.1"  
LXC_NETMASK="255.255.255.0"  
LXC_NETWORK="10.0.3.0/24"  
LXC_DHCP_RANGE="10.0.3.2,10.0.3.254"  
LXC_DHCP_MAX="253"  
LXC_DHCP_CONFILE=""  
LXC_DOMAIN=""  

Y activamos el servicio:

# systemctl enable lxc-net
# systemctl start lxc-net
# reboot

Si ejecutamos un ifconfig vemos que ha aparecido la interfaz de red lxcbr0. Ahora debemos asignarle esta interfaz a nuestro contenedor editando el fichero /var/lib/lxc/ubuntu-test/config en el anfitrión Debian y cambiando las últimas líneas por éstas:

[...]
# Network configuration
lxc.network.type = veth  
lxc.network.link = lxcbr0  
lxc.network.flags = up  
lxc.network.hwaddr = 00:16:3e:43:1a:7e  

Tened en cuenta que la MAC de la tarjeta de red sería recomendable cambiarla si váis a crear varios contenedores. La primera vez que probé a reiniciar el contenedor con la nueva configuración no cogió una ip por lo que opté por la decisión más rápida, reiniciar por completo el anfitrión y una vez arrancado lancé la instancia:

# lxc-stop -n ubuntu-test
# lxc-start -n ubuntu-test
# lxc-info -n ubuntu-test
Name:           ubuntu-test  
State:          RUNNING  
PID:            2813  
CPU use:        0.29 seconds  
BlkIO use:      0 bytes  
Link:           vethP7PUAB  
 TX bytes:      850 bytes
 RX bytes:      634 bytes
 Total bytes:   1.45 KiB

Si alguien sabe porqué LXC no reparte direcciones ip en Debian cambiando el servicio lxc-net, activándolo y reiniciándolo todos le agradeceremos el comentario, de momento seguiremos con nuestra solución salomónica y reiniciaremos todo el anfitrión.

Ahora ya volvemos a tener una parte que podemos aplicar a ambos anfitriones. Lo primero que vamos a hacer es conectarnos a ellos y comprobar que tenemos acceso a internet:

# lxc-attach -n ubuntu-test
[email protected]:/# apt update  
Hit:1 http://archive.ubuntu.com/ubuntu xenial InRelease  
Get:2 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [95.7 kB]  
[...]

Bien, todo esto está muy bien, pero necesitamos un poco de acción, PostgreSQL estaría bien. Vamos a instalar el servidor en ambos huéspedes y hacer un pequeño test. Los pasos son iguales en ambos contenedores, añadiremos las fuentes oficiales del proyecto e instalaremos el paquete:

[email protected]:/# echo "deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg main" > /etc/apt/sources.list.d/pgdg.list  
[email protected]:/# apt install wget  
[email protected]:/# wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -  
[email protected]:/# apt update  
[email protected]:/# apt install postgresql-9.5  

Una vez instalado el servidor ya podemos realizar un test de rendimiento pero primero, para facilitar las cosas. vamos a cambiar el fichero /etc/postgresql/9.5/main/pg_hba.conf y ponemos todos los métodos de autenticación a trust:

[...]
# Database administrative login by Unix domain socket
local   all             postgres                                trust

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     trust  
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust  
# IPv6 local connections:
host    all             all             ::1/128                 trust  
# Allow replication connections from localhost, by a user with the
[...]

Ya podemos seguir con el test:

[email protected]:/# systemctl restart postgresql  
[email protected]:/# su - postgres  
[email protected]:~$ createdb performance_tests  
[email protected]:~$ exit  
logout  
[email protected]:/# pgbench -i -s 10 -h localhost -U postgres performance_tests  
NOTICE:  table "pgbench_history" does not exist, skipping  
NOTICE:  table "pgbench_tellers" does not exist, skipping  
NOTICE:  table "pgbench_accounts" does not exist, skipping  
NOTICE:  table "pgbench_branches" does not exist, skipping  
creating tables...  
100000 of 1000000 tuples (10%) done (elapsed 0.08 s, remaining 0.70 s)  
200000 of 1000000 tuples (20%) done (elapsed 0.16 s, remaining 0.63 s)  
300000 of 1000000 tuples (30%) done (elapsed 0.37 s, remaining 0.86 s)  
400000 of 1000000 tuples (40%) done (elapsed 0.59 s, remaining 0.88 s)  
500000 of 1000000 tuples (50%) done (elapsed 0.81 s, remaining 0.81 s)  
600000 of 1000000 tuples (60%) done (elapsed 1.02 s, remaining 0.68 s)  
700000 of 1000000 tuples (70%) done (elapsed 1.10 s, remaining 0.47 s)  
800000 of 1000000 tuples (80%) done (elapsed 1.18 s, remaining 0.29 s)  
900000 of 1000000 tuples (90%) done (elapsed 1.26 s, remaining 0.14 s)  
1000000 of 1000000 tuples (100%) done (elapsed 1.34 s, remaining 0.00 s)  
vacuum...  
set primary keys...  
done.  
[email protected]:/# pgbench -c 16 -j 16 -T 60 -h localhost -U postgres performance_tests  
starting vacuum...end.  
transaction type: TPC-B (sort of)  
scaling factor: 10  
query mode: simple  
number of clients: 16  
number of threads: 16  
duration: 60 s  
number of transactions actually processed: 15284  
latency average: 62.811 ms  
tps = 254.090037 (including connections establishing)  
tps = 254.363806 (excluding connections establishing)  

Podemos tunear un poco la configuración de PostgreSQL pero el tema del post no es ése, vamos a comparar el comportamiento de la base de datos en los anfitriones frente a sus contenedores para comprobar hasta qué punto se pierde rendimiento.

Para instalarlo en los anfitriones el proceso es el mismo que hemos explicado antes. Según mis pruebas, realizadas varias veces, la media de transacciones procesadas estaban en torno a las quince mil, con lo que sí, parece que realmente la penalización en los contenedores es prácticamente nula. Lo ideal sería realizar una batería de pruebas cortesía de los chicos de phoronix, pero este pequeño experimento nos ha servido para confirmar lo que se viene comentando de esta tecnología y para animarnos a seguir investigando por esta vía.

Y a partir de aquí qué?, os preguntaréis, pues yo también. De momento se me ocurre montar una prueba con Docker, sobre este mismo laboratorio de máquinas, ver si es igual de simple de configurar y realizar los tests. Luego tenemos la opción de desarrollar habilidades con alguna herramienta de orquestación de máquinas virtuales/contenedores como puede ser Ansible, Puppet o similares. A partir de ahí el cielo es el límite y una cosa que realmente quiero investigar es el sistema OverlayFS que se utiliza con LXC para permitir que varios contenedores compartan una parte del sistema de ficheros común y así reducir el mantenimiento de este tipo de infraestructuras.

También podríamos hablar de cómo tunear todos estos recursos una vez que ya tenemos los conceptos básicos claros, pero esto ya será en próximos capítulos.

Vamos a despedirnos yéndonos arriba y bailando por la convulsa inglaterra de 1984 junto con el pequeño Billy Elliot al son de The Clash y su perfecta London Calling de su disco homónimo, aunque hoy prefiero aconsejaros la impresionante recopilación hecha para la banda sonora de la película.

Dance!