Dentro de la Conferencia Agile Spain 2015 tuve la oportunidad de asistir a un taller de casi dos horas de Ansible impartido por David González. Ansible es una de esas herramientas a las que le echas el ojo pero por una cosa u otra (muchas veces pereza, de esto nadie se libra) acaba, por más tiempo del debido, en la lista "cuando tenga tiempo me hago un proyectito". Los primeros cantos de sirena serios vinieron en febrero, en la FOSDEM 2015, llegaba la hora de mancharse un poco.

Por lo visto un taller sobre Ansible no se veía cercano a las metodologías ágiles. Y por lo visto a menos de 10 personas, sobre las cerca de 700 que iban a la conferencia, nos interesaba el taller. Una pena, pero una suerte para los que pudimos aprender, probar, debatir y compartir ideas y experiencias. Por lo visto una herramienta de configuration management (CM) no aporta nada a tener software funcionando sobre documentación excesiva o tampoco facilita la respuesta ante el cambio frente a seguir un plan.

El estado del arte

Por primera vez hace unos cuatro años empezaba a leer sobre estas herramientas de CM, y hace un poco más de tres años me metía en el barro con Puppet. Hace poco se añadía al set de tecnologías a dominar Chef, y de paso Fabric (que complementa bastante algunas carencias). A día de hoy administrar un servidor en una empresa y no utilizar alguna de estas herramientas sería como plantearse desarrollar código sin tests o sin un control de versiones. Impensable. Mala idea.

En Frogtek todos trabajamos para sacar adelante TiendaTek y las aplicaciones que la complementan. El objetivo es crear valor y ayudar a los tenderos que usan la aplicación, y de paso intentar subsistir y crecer para poder ayudar a más tenderos. Toda la compañía trabaja en esa misma dirección, pero ¿qué pasa con los sistemas? Desde luego deben tratarse con la importancia que merecen. Un downtime, una actualización no controlada, una pérdida de datos, una baja de la "persona con más conocimiento sobre sistemas"... son muchos los factores que pueden hacer que todo se vaya al carajo, y muy rápido.

Ahí entra una herramienta de CM. Es cierto que no son triviales de aprender, pero desde aquí aseguro que cuesta menos aprender Puppet o Chef y entender unas recetas que heredar un sistema de pocos servidores sin documentación. ¿Qué es lo que hacen cosas como Puppet y Chef?

La respuesta rápida sería algo como: describir el estado de uno o varios servidores y proveer las herramientas para asegurar dicho estado. Grosso modo puedes definir qué paquetes quieres instalar, qué ficheros de configuración copiar y qué servicios reiniciar cuando se cambia alguno de ellos.

¿Y por qué no usamos unos scripts? A primera vista hay dos razones importantes. La primera es que utilizando un CM tus sistemas están autodocumentados. Una buena estructura de carpetas deja tus nodos con pocas líneas donde puedes leer qué servicios albergan. La segunda razón es la habilidad que tienen para reducir tus errores. Por múltiples razones. Puedes reproducir con muchísima facilidad el entorno de desarrollo con herramientas como Vagrant, las ejecuciones son idempotentes (cosa que no demasiado trivial con scripts), y por último, la reducción de errores a la hora del despliegue. Al final, cuanta menor sea la intervención humana, menor es la probabilidad de error.

En Frogtek nuestra infraestructura está siendo deployeada con Chef, que se asegura de la creación de usuarios, ficheros de configuración, reglas de firewall, ... Mientras que dejamos en manos de Python-Fabric la ejecución de tareas sobre los servidores. Ya sea con Puppet o con Chef, ya sea más "de andar por casa" o "mejor organizado", la mayoría de las empresas que usan una herramienta de CM funcionan parecido, ¿y Ansible?

Toma de contacto con Ansible

A pesar de que mi relación con Ansible todavía no ha durado demasiado, desde luego empiezo a ver sus bondades. Durante el taller un asistente comentaba que en su primera aproximación le pareció un cliente de SSH, y parte de la gracia está ahí, no necesitas más que Ansible en tu máquina y un servidor SSH en las máquinas que quieres administrar para que empiece la magia. Fuera Puppet agents o Chef clients. Pero no, no es un simple cliente SSH, o tal vez sí, pero le han hecho tomar tantos esteroides que cuando quitas la primera capa ves otra cosa.

Al igual que puede pasar con otros CM, la mejor forma de pensar cuando trabajas es hacerlo pensando en "estados". Ya no pretendes mandarle un "instala el paquete htop", la orden es más bien "asegúrate de que htop está presente". Tu te encargas, yo te describo el estado que quiero para la máquina. No pretendo añadir una línea a un fichero de configuración (o tirar un sed...), lo que quiero es que te asegures de que el fichero de configuración tiene "esta pinta". De nuevo las palabras ejecuciones idempotentes salen fáciles.

He hablado de asegurar la presencia de un paquete o del contenido de un paquete. Todo esto se realiza mediante módulos. Aquí es donde el SSH empieza desdibujarse, y empiezas a ver los esteroides. Este Ansible está muy cachas, y la documentación de su web ayuda. ¿Y los módulos de terceros? Pues aquí hay que andar con cuidado, pero los hay, y completísimos.

Así que utilizando un módulo u otro la idea es poner unas cuantas "tasks", una detrás de otra, formando una "play", una jugada. Un ejemplo de jugada podría ser deployear un servidor MySQL con todas las pequeñas tareas (tasks) que requiere. Pero en un deploy normalmente después de deployear los servidores de backend, querrás levantar los servidores de frontend. Adelante, muchas jugadas (plays) hacen un libro de jugadas, un "playbook". De forma que en un fichero puedes ver de un vistazo el workflow para levantar TODO tu entorno.

Pero falta seguramente la clave de Ansible. El fichero de inventario de servidores. Un fichero para gobernarlos a todos y asignarles roles. Puedes definir 2 ó 200 servidores con el rol de webserver, da igual cuantos, aplica el playbook que incluya una instrucción para ese grupo y... ¡hecho! No sólo eso, por defecto lanzará las tareas de forma paralela en todos los servidores a la vez, pero puedes decirle que lo haga sólo en el 25% de las máquinas cada vez, así que tenemos downtime zero sin esfuerzo. Parche crítico de Apache, actualizas la versión en la tarea, y ejecutas un play que saque a cada servidor de balanceador, actualice Apache, y lo vuelva a dar de alta en el balanceador. Y lo peor es que, es así de fácil. Por cierto, el fichero de inventario de servidores puede generarse dinámicamente de EC2 (entre otros).

Comparando Ansible con nuestro amado Chef

Como con muchas tecnologías nuevas al principio te emocionas, te parece genial, sacas las banderitas, lanzas fuegos artificiales, ... ¿es para tanto? Sí, y no. Tiene unas cuantas (y muy buenas) ventajas, pero cuando tienes todas tus recetas de Chef bien probadas y funcionando, igual el tiempo se puede dedicar a otras tareas. Tal vez puedes utilizar Chef para el deploy de máquinas y añadir Ansible para interactuar con los servidores de forma "masiva".

¿Ventajas? ¿Cuáles? A algunos que hemos sufrido la lentitud y carga del Puppet Agent, la rapidez y la facilidad de interacción con Ansible y su ligereza enamoran. Además en el servidor sólo necesitas un servidor SSH. Además el hecho de tener descrita tu arquitectura en el fichero de inventario es, simplemente maravilloso. Cuando tienes todo bien descrito y empiezas a jugar empiezas a recordar esa frase:

Un gran poder conlleva una gran responsabilidad

Más ventajas. Python vs. Ruby vs. Puppet DSL. Desarrollar un módulo es una tarea Python, tal vez no sea una gran ventaja frente a Ruby más allá de saber que estará de base en tu sistema casi seguro, pero contra Puppet DSL, seguro. Las tasks, plays y playbooks tienen el formato YAML, y se ejecutan en orden. Son muy fáciles de entender para un desarrollador, que podrá lanzarse su entorno de desarrollo sin problemas.

Por ahora no me he tropezado con grandes problemas. La comunidad cada vez es más grande, el proyecto muy activo. Todavía no te empujan demasiado a usar Ansible Tower (interfaz web de pago elaborada por los responsables de Ansible, Ansible Works). Desde luego el taller de dos horas de David ha desatado la curiosidad. ¡Muchas gracias!

Para el futuro todavía hay mucho que pensar, probar y valorar. Integrar Ansible con Jenkins, generar mejores entornos de desarrollo a medida con Vagrant, gestionar las tareas de mantenimiento y escalado, o incluso el failover de máquinas. Sí, ya siento ese cosquilleo en las llemas de los dedos, me gusta este superpoder. Muchas ganas de desksurfear para aprender y compartir con los demás.