KVM, Ansible y como hacer un entorno de pruebas 1

KVM, Ansible y como hacer un entorno de pruebas

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%
Volver arriba