Llevo años queriendo escribir sobre herramientas de automatización desde hace tiempo, el problema no es no haber encontrado tiempo sino considerar las herramientas de control de configuración o demasiado manuales (como Fabric) o demasiado dependientes de una estructura cliente/servidor... ¿En qué se diferencia Ansible?
En un artículo hace tiempo leí una comparativa de las principales herramientas de automatización de la configuración. Hacian dos grupos: más de programadores o más de administradores. Estos grupos indican que los de más de programadores requerirán conocer algún lenguaje de programación y tirar código, mientras que más de administradores se basarán principalmente en la configuración y poco en código.
En el grupo de más de programadores están Puppet y Chef, ambos programados en Ruby. Ambos se basan en escribir código en Ruby para indicar el estado de configuración de la máquina. También agregan información que puede almacenarse en ficheros YAML o en base de datos. Ambos tienen la posibilidad de ejecutarse localmente pero en entornos de trabajo normalmente se opta por una estructura de cliente/servidor.
En el otro grupo de más de administradores tenemos a Salt y Ansible. Ambos programados en Python. Este grupo se diferencia principalmente en no tener que escribir código como tal. Todo se especifica a través de ficheros YAML. Salt está basado en el modelo cliente/servidor igualmente aunque tiene la posibilidad de ejecutar tareas de forma local al igual que Puppet y Chef. Ansible por el contrario se ejecuta de una forma más parecida a Fabric, no es cliente/servidor, no requiere instalación de un cliente ni disponer de un servidor.
¿Qué es Ansible?
He estado leyendo el libro de Ansible: Up and Running y la sección de origen es curiosa. He visto películas como El Juego de Ender pero para mi había pasado desapercibido el dato del nombre de la consola con la que el protagonista controla todas las naves: Ansible. En Ciencia-Ficción parece que se popularizó este término por parte de Ursula K. Le Guin en 1966 como un instrumento de comunicación mucho más rápido que la luz, instantáneo de hecho.
Así, Ansible es en la administración de sistemas una herramienta que permite comunicarse de forma instantánea hacia los servidores para mantenerlos en un estado concreto, según la configuración.
Uno de los fuertes de Ansible es su cantidad de módulos. Podemos realizar de todo a través de estos módulos y todos están pensado para ser idempotentes. A diferencia de otras herramientas la ejecución en Ansible se realiza de forma controlada y se anuncian tres posibles estados (con sus colores):
- Rojo: estado erróneo, no se ha podido llevar hasta el estado deseado. La ejecución se detiene.
- Amarillo: el estado no ha cambiado. La ejecución ha encontrado que no ha hecho falta realizar cambios o no se han realizado cambios en sí.
- Verde: los cambios han sido realizados y se ha conseguido un nuevo estado.
¿Qué ventajas tiene Ansible con respecto a otros?
La ejecución desde una máquina cualquiera para provisionar un entorno de desarrollo (ya sea en Vagrant o servidores locales), un entorno de pruebas o producción. No se requiere la instalación de ningún servidor centralizado para ello. Un servidor de Integración Continua (CI) puede convertirse, gracias a Ansible, en un servidor de Despliegue Continuo (CD).
Podemos emplearlo como si se tratara de Fabric pero con un nivel de abstracción mucho más alto permitiéndonos definir no solo una máquina sino también un conjunto de clusters.
Nos da la posibilidad de realizar incluso la provisión de nuevas máquinas agregándolas en tiempo de ejecución para saltar a ellas y relizar su configuración. No se requiere una configuración de claves para acceder desde el cliente al servidor, por tanto, sino tan solo unas claves SSH para poder acceder desde el cliente al servidor, y esto es algo simple de conseguir y configurar para todos.
¿Qué desventajas tiene Ansible?
Al no disponer de un servidor como tal, perdemos centralización (tiene posibilidad de instalar la versión comercial con Ansible Tower, pero es algo caro). Podemos destinar un servidor con la configuración o incluso un sistema de CI o CD para llevar a cabo esta tarea, pero no es tan clara como en los servidores de Puppet, Salt o Chef.
Al especificarlo todo en YAML hay veces que necesitemos crear nuestro propio módulo. En sistemas como Chef o Puppet, crear un módulo propio es trivial porque ya escribimos en ese lenguaje normalmente para la configuración, pero en Salt o Ansible es un salto a lo desconocido y requiere de mayor tiempo para aprender cómo hacerlo.
Conclusiones
Desde mis comienzos con Chef allá en 2013, con Puppet y Fabric en 2014, Salt en 2015 y finalmente Ansible en 2016, me da la sensación de haber seguido una evolución. No siempre a mejor, considero cada herramienta con sus fortalezas y debilidades, haber trabajado con todas ellas me da el conocimiento para poder elegir en el futuro la que mejor se adapte al entorno que necesite instalar.
En el caso específico de Ansible, crear una receta sobre una instalación recién hecha en un servidor y mantenerla en el directorio de proyectos de software por si necesitase en un momento dado replicar eso mismo en otro servidor o reconfigurarlo, es algo que he valorado mucho. Me ha librado de la tarea de instalar un servidor por un lado en caso de haber elegido Puppet o Chef, y por otro lado me ha librado de la tarea de programar cada comando en línea en caso de haber empleado Fabric.
Para mi Ansible es esa herramienta base y polivalente de la que habría que partir y en caso de requerir algo diferente, entonces cambiar a otra.
¿Usas alguna herramienta de automatización de configuración?, ¿Has empleado Ansible?, ¿Alguna otra como Puppet, Chef, Salt o Fabric?, ¿Cuál te ha ayudado más? ¡Dejanos tu comentario!
