Icono del sitio Disaster Project

KVM, Ansible y como hacer un entorno de pruebas

KVM, Ansible y como hacer un entorno de pruebas 1

En los entornos de desarrollo locales siempre hace falta la simulación de entornos más potentes como pasa habitualmente en la realización de demos.

Para ello vamos a seguir siempre la filosofía “KISS” (keep it simple stupid!) y usaremos aquellos servicios para que nuestro linux requiera el menor uso de recursos posibles. Vamos a utilizar dos herramientas para simplificar el trabajo que son Ansible para el despliegue y KVM como hipervisor.

Imágenes para el entorno de pruebas

El primer paso es hacernos con un sistema que nos suministre imágenes de la manera más simple posible y nos vamos a encontrar con que Vagrant es una fuente maravillosa de imágenes. Tenemos dos maneras de hacerlo:

  1. Descargar de https://www.vagrantup.com/downloads.html e instalar con sudo dpkg -i vagrant_VERSION_x86_64.deb en entornos Debian/Ubuntu o con sudo rpm -i vagrant_VERSION_x86_64.rpm en entornos RHEL/Centos), para obtener una imagen lo más pequeña posible vamos a hacer uso de una debian 9.9.0 con el siguiente comando:
    $ vagrant box add --provider libvirt debian/stretch64
    ==> box: Loading metadata for box 'debian/stretch64'
    box: URL: https://vagrantcloud.com/debian/stretch64
    ==> box: Adding box 'debian/stretch64' (v9.9.0) for provider: libvirt
    box: Downloading: https://vagrantcloud.com/debian/boxes/stretch64/versions/9.9.0/providers/libvirt.box
    box: Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
    ==> box: Successfully added box 'debian/stretch64' (v9.9.0) for 'libvirt'!
    La imagen descargada la tendremos en ~/.vagrant.d/boxes/debian-VAGRANTSLASH-stretch64/9.9.0/libvirt, en la forma de tres archivos, siendo el que nos interesa box.img que es una imagen con formato QCOW.

  2. Descargar directamente las imágenes que vamos a utilizar, por ejemplo una imagen Centos: http://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7.Libvirt.box y una imagen Debian: https://app.vagrantup.com/debian/boxes/stretch64/versions/9.9.0/providers/libvirt.box
    Para hacer más fácil el despliegue, se ha configurado Ansible para que haga la descarga automáticamente, guarde la imagen en /root/.images y al utilice directamente sin que necesitemos tener que hacer nada más.

Lo siguiente que necesitamos es descargar las tareas de Ansible que nos van a permitir lanzar nuestro entorno de pruebas, el “paquete” está formado por un archivo que será realmente importante llamado “inventory.yml” donde vamos a definir realmente como va a ser nuestra demo, está formado por un fichero de “creación” y otro de “destrucción” del entorno virtualizado. El resto de ficheros son variables y funciones (tareas) que ejecutarán lo necesario para levantar nuestro entorno. Procedemos a descargar el entorno:

$ git clone https://github.com/aescanero/disasterproject
$ cd disasterproject/ansible

Dentro del directorio “ansible” veremos un directorio “files” que tiene la clave privada insegura de Vagrant que nos va a servir para acceder a cada una de las máquinas que desplegaremos. Dicha clave se obtiene de https://raw.githubusercontent.com/hashicorp/vagrant/master/keys/vagrant, procedemos a cambiar los permisos para que la clave sea aceptada por SSH:

$ chmod 600 files/insecure_private_key

Obteniendo Ansible

Para poder ejecutar las tareas de Ansible debemos obtener e instalar Ansible siguiendo las instrucciones de la guía de instalación de Ansible (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html), por ejemplo para Debian hay que seguir las siguientes instrucciones:

$ sudo sh -c 'echo "deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main" >>/etc/apt/sources.list'
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
$ sudo apt-get update && sudo apt-get install -y ansible 

Instalando libvirt y KVM

Procedemos además a instalar el resto de paquetes que vamos a necesitar, en debian son:

$ sudo apt-get install -y libvirt-daemon-system python-libvirt python-lxml

Y en CentOS son:

$ sudo yum install -y libvirt-daemon-kvm python-lxml

Para iniciar el servicio haremos $ sudo systemctl enable libvirtd && sudo systemctl start libvirtd

Crear un inventario para el entorno

En el siguiente paso editaremos el archivo “inventory.yml” que debe tener un formato parecido al siguiente:

all:
  children:
    vms:
      hosts:
        debian:
          memory: 1024
          vcpus: 1
          vm_ip: "192.168.8.2"
          linux_flavor: "debian"
      vars:
        domain: disasterproject.com
        network: "192.168.8"

En él vemos la definición de la máquina (nombre: debian, memoria en MB, número de vcpus, la ip, y el tipo – por ahora solo debian o centos-) y una serie de valores globales, como el dominio, la red sin el último octeto (va a ser clase C, mascará /24), donde {{ network }}.1 es la IP sirve de puerta de enlace a todos las máquinas virtuales que desplegaremos, las IPs de las máquinas virtuales se configurarán vía DHCP y deben pertenecer a dicha red. Tanto {{ network }}.1 como el rango {{ network }}.240/28 están reservados y no pueden usarse para las máquinas virtuales.

Desplegar las máquinas virtuales

El siguiente paso es lanzar las MVs con Ansible para ello ejecutamos:

$ ansible-playbook -i inventory.yml create.yml --ask-become-pass

Podemos ver todos los pasos para la creación de la máquina virtual:

Al terminar la ejecución, la maquina/s virtuales están arrancadas y listas para acceder a las mismas, en nuestro ejemplo accedemos a la MV con la IP 192.168.8.2 con:

$ ssh -i files/insecure_private_key vagrant@192.168.8.2

El usuario vagrant dispone de sudo por lo que no tenemos problemas para gestionar la máquina virtual.

Comparando KVM y VirtualBox. ¿Porque KVM?

Por último un comentario sobre el rendimiento de KVM y VIrtualBox, aunque es cierto que la consola de VirtualBox es eficiente, el rendimiento de está solución de virtualización sufre cuando hay mucho acceso a disco y/o CPU, aunque en la última versión (6.x) ha mejorado claramente, sigue estando por detrás de KVM y no es recomendable para desarrollo o demos. Más información en openbenchmarking: https://openbenchmarking.org/result/1812203-PTS-VIRTUALI66 y también unos resultados de iozone (/usr/bin/iozone -s24m -r64 -i 0 -i 1 -+u -t 1) que nos indican mejora rendimiento en 3 de las 4 pruebas realizadas:

KVMVirtualBox
Avg throughput per process Avg throughput per process
Throughput for 1 initial writers
922105.38 kB/sec
Throughput for 1 initial writers
712577.69 kB/sec
Mejor
22.7%
Throughput for 1 rewriters
1097535.38 kB/sec
Throughput for 1 rewriters
1244981.12 kB/sec
Peor
13.4%
Throughput for 1 readers
2971712.50 kB/sec
Throughput for 1 readers
1833079.75 kB/sec
Mejor
38.1%
Throughput for 1 re-readers
2219869.75 kB/sec
Throughput for 1 re-readers
559970.25 kB/sec
Mejor
74.7%
Salir de la versión móvil