Índice de contenidos
1. Introducción
Estamos en una época en la que cada vez más vivimos el desarrollo y la creación de infraestructuras como código.
Esto nos trae una serie de ventajas cómo:
- Capacidad de replicar de forma fiable un entorno determinado.
- Uso de herramientas de versionado para tener un control de la evolución del sistema en el tiempo.
- Uso de las herramientas de integración continua para gestionar la evolución de la infraestructura de la misma forma que gestionamos la evolución del código.
- Uso de prácticas del desarrollo del software para nuestra infraestructura, como el testing y uso de TDD.
En este tutorial se explica qué es Kitchen CI y cómo funciona su ciclo de vida.
2. Entorno
El tutorial está escrito usando el siguiente entorno:
- Hardware: Portátil MacBook Pro Retina 15′ (2.5 Ghz Intel Core I7, 16GB DDR3).
- Sistema Operativo: Mac OS Sierra 10.12.6
- KitchenCI 1.20.0
3. KitchenCI
3.1. ¿Qué es?
KitchenCI es un framework que te permite realizar testing unitarios para gestionar todo el ciclo de vida de tu infraestructura: creación, aprovisionamiento y testing.
Además esta creada de forma modular, permitiendo:
- Probar tu infraestructura con distintas herramientas de virtualización (Vagrant, Docker).
- Está preparada para distintos sistemas operativos (Ubuntu, Centos, Windows…)
- Permite el uso de varios proveedores (Chef, Puppet, Ansible)
- Permite el uso de varias herramientas para probar la infraestructura (InSpec, ServerSpec, RSpec, BATS)
3.2. Ciclo de vida
Entender el ciclo de vida de KitchenCI nos permitirá comprobar «Cómo prepara la cocina» para montar nuestra infraestructura y
cómo ayuda el tener una herramienta que gestione cada una de las fases de la prueba de forma que te permita parar en cualquier parte del proceso y ver el estado de la máquina.
Suponiendo que estamos utilizando Docker como herramienta de virtualización y Ansible como herramienta de aprovisionamiento;
cuando queremos probar que nuestra configuración de aprovisionamiento está correcta por ejemplo, en una máquina virtual seguimos los siguientes pasos:
- Creamos el contenedor en el queremos probar nuestros playbooks.
- Creamos la configuración de Ansible pertinente para instalar lo que deseemos.
- Ejecutamos Ansible apuntando a nuestro contenedor.
- Entramos en el contenedor y comprobamos que todo está a nuestro gusto.
KitchenCI usa un procedimiento parecido en el que gestiona y coordina gran parte de la configuración de estos pasos de forma automática.
Esta configuración se lee del fichero .kitchen.yml que contiene:
- driver: la herramienta de virtualización que utilizaremos para nuestras pruebas.
- transport: la comunicación entre el host y la máquina virtual (SSH/WinRM).
- provisioner: herramienta de provisionamiento a utilizar, como Ansible, Puppet o Chef.
- verifier: aquí ponemos el componente encargado de verificar que se ha provisionado correctamente el entorno, como InSpec.
- platforms: listado de sistemas operativos donde realizamos las pruebas.
- suites: batería de test que serán aplicados en estos entornos.
A partir de esta configuración KitchenCI creará un listado de contenedores a partir de la suite de test y las plataformas de ejecución que se podrán ver con el comando kitchen list
Cada una de estas instancias se corresponde con una máquina virtual en caso de Vagrant o un contenedor en caso de Docker o LXD, con un sistema operativo y un test. De forma que si nuestra suite de pruebas se conforma por un solo test y tenemos dos plataformas tendríamos dos instancias de nuestro driver, cada una con una plataforma.
Después crearíamos nuestra configuración con nuestra herramienta de provisionamiento preferida, asegurándonos de que nuestro .kitchen.yml esté bien configurado.
Para crear el contenedor se utiliza el comando kitchen create.
Para aplicar estos cambios en nuestras instancias ejecutamos el comando kitchen converge.
Para comprobar de forma manual que todo funciona podemos entrar de forma manual a la máquina con el comando kitchen login.
Si queremos confirmar que se ha provisionado de forma correcta, tenemos que crear el test con la herramienta de prueba que hayamos elegido. Para ello ejecutamos el comando kitchen verify.
Vemos como es muy sencillo ir paso por paso por las fases de probar la infraestructura. Ahora bien, si queremos ejecutar el ciclo de vida completo, podemos utilizar el comando kitchen test, donde se añaden el paso kitchen destroy tanto al principio como al final de forma que crea las instancias de cero si ya están creadas y al final las destruye.
4. Conclusiones
KitchenCI mejora muchísimo la gestión de la infraestructura a la hora de crear y gestionar pruebas de la infraestructura.
Además su diseño modular permite que se puedan añadir herramientas en cada uno de los ciclos de vida, dotándola de una gran capacidad de persistir a lo largo del tiempo debido a que no se casa con ninguna herramienta de provisionamiento.
En el siguiente tutorial comprobaremos cómo gestionar esta configuración en un ejemplo práctico.
