Category Archives: Work

All my work.

Ansible para la automatización de entornos IT

Ansible es un software open source para la automatización de entornos IT muy extendido en la creación de entornos de integración/despliegue continuo.

PROBLEMA: Se dispone de una infraestructura IT para el despliegue de una aplicación web “AAA”, que consta de varios servidores que dan el servicio necesario. Se quiere automatizar el despligue de la aplicación, pero nos damos cuenta de que cada nueva iteración requiere emplear un determinado tiempo en subir archivos, ejecutar scripts, reiniciar servicios, actualizar software, etc. ¿Qué hacemos para minimizar el impacto de los tiempos de ejecución de tareas repetitivas? Aplicar ansible.

La filosofía es la misma que ya hemos visto en puppet o chef: master-slave. Un host (master) controla una batería de servidores (slave). La principal ventaja de ansible frente a otros es que funciona sobre ssh y no necesita de ningún cliente instalado en los servidores que deseemos controlar.

Instalación

Empezamos instalando unos requirements(2), añadiendo el ppa de ubuntu (3,4) y actualizando la caché de packetes en apt (1,4) para finalmente instalar ansible(5).

Tenemos altnernativas para la instalación en otros escenarios en la documentación de ansible, como por ejemplo, con pip en un entorno virtual con virtualenvwrapper (Python 2):

Inventario

A continuación podemos probar la conexión a algún servidor mediante clave privada previamente configurada en el sistema:

Respuesta:

Si no requerimos de clave privada pero si de password probamos con el switch:

Existen workarounds para no introducir el password, pero la opción más recomendable es configurar la interconexión mediante clave privada, garantizando un canal seguro.

Si no tenemos la clave agregada al keyring podemos especificarla con el switch:

Creamos un directorio donde empezar nuestro proyecto:

Creamos un archivo de inventario:

Contenido:

Probamos la conexión pasando el archivo como parámetro:

Respuesta:

Por defecto Ansible busca el archivo con el listado de hosts en /etc/ansible/hosts, podemos usar ese archivo, pasar el al archivo por parámetro o sobre escribir el path por defecto agregándolo a la configuración global de ansible en ~/.ansible.cfg:

Podemos probar de nuevo, esta vez sin pasar el listado por parámetro:

Respuesta:

El archivo inventario con el listado de host admite muchas configuraciones (grupos, variables grupales, etc), lo recomendable es revisar la documentación para profundizar.

Playbooks

Los Playbooks son los scripts que se ejecutarán en todos los sistemas slave. Son el core de la aplicación y es donde invertiremos el tiempo.

El factor más determinante a considerar al desarrollar un Playbook es que éste tiene que ser idempotente, es decir, que no importe cuantas veces se ejecute siempre tendrá los mismos resultados sin efectos negativos por reiterar la ejecución.

Se pueden desarrollar playbooks para provisionar servidores, para agregar usuarios, directorios, etc. cualquier acción que sea susceptible de ser programada.

Los playbooks son procedurales y las tareas son ejecutadas secuencialmente de arriba a abajo (top-bottom). Un Playbook se programa en lenguaje YAML (Yet Another Markup Language).

En internet hay cantidad de Playbooks ya desarrollados para todo tipo de entornos, solo hace falta echar un vistazo en github, pero siempre es recomendable parar a ver el repositiorio de ejemplos oficial.

Para ejecutar un playbook:

Módulos

Cuando desarrollemos un Playbook no será necesario partir de cero, sino que podremos contar con una serie de módulos que vienen preinstalados. Podemos listarlos con:

La documentación de los módulos la podemos encontrar en el sitio web.

Uno de los éxitos de ansible es ofrecer una gran base Playbooks desarrollados por la comunidad que agilizan el proceso de adaptación de metodologías ágiles en en lo referente al área de devops. Especialmente si se combina con docker o vagrant da un control total sobre todo el stack de una forma accesible y elimina aquellos errores que pudieran producirse por la intervención de un operador en cada una de las microtareas que podrían (y deberían) de ser automatizadas.

Saludos,

Referencias
https://deployment-workflow.bocoup.com/
https://github.com/ansible/ansible
https://www.linode.com/docs/applications/ansible/getting-started-with-ansible
http://docs.ansible.com/
http://blog.takipi.com/production-tools-guide/deployment-management/