Automatización de servidores con Ansible

Ansible es una herramienta de gestión de configuración que automatiza la tarea de dejar uno o muchos servidores en un estado deseado: con ciertos paquetes instalados, ciertos servicios corriendo, ciertos archivos de configuración en su lugar y ciertos usuarios creados. Sirve para resolver el problema que aparece cuando hay que administrar más de un servidor, donde hacerlo a mano se vuelve lento, tedioso y propenso a que cada máquina termine sutilmente distinta de las demás, algo conocido como deriva de configuración y que causa problemas difíciles de diagnosticar. En lugar de entrar por SSH a cada servidor y repetir los comandos manualmente, con Ansible se describe una sola vez el estado deseado y la herramienta lo aplica de forma consistente a todos los servidores indicados, dejándolos configurados exactamente igual en minutos. Además, esa descripción queda versionada, sirviendo como documentación siempre actualizada de cómo debe ser cada servidor.

Porque, a diferencia de muchas herramientas de gestión de configuración que requieren instalar y mantener un programa especial —un agente— corriendo en cada servidor gestionado, Ansible no instala absolutamente nada en las máquinas que administra. En su lugar, se conecta a ellas usando SSH, que es el mecanismo estándar y seguro con el que un administrador entra normalmente a un servidor, y ejecuta las tareas de forma remota desde el nodo de control, que es la única máquina donde Ansible está instalado. La consecuencia práctica de este diseño sin agente es muy importante: para empezar a gestionar un servidor con Ansible alcanza con tener acceso SSH a él, sin necesidad de preparar, instalar ni mantener nada del otro lado. Esto reduce mucho la barrera de entrada y la complejidad operativa, y es una de las razones por las que Ansible se volvió tan popular frente a alternativas que sí dependen de agentes.

La idempotencia es la propiedad por la cual ejecutar el mismo playbook una vez o muchas veces lleva siempre exactamente al mismo estado final, sin efectos acumulados ni duplicados. Esto es posible porque las tareas de Ansible no están redactadas como órdenes imperativas del tipo «instalá este paquete», sino como declaraciones del estado deseado del tipo «asegurate de que este paquete esté instalado». Antes de actuar, cada tarea comprueba el estado actual del sistema: si el paquete ya está instalado, no hace nada; si falta, lo instala; si un archivo ya tiene el contenido correcto, no lo toca. Gracias a esto, correr un playbook de más nunca rompe nada, sino que simplemente confirma que todo sigue en el estado deseado, informando en cada tarea si hubo un cambio o no. Esta propiedad es lo que hace seguro usar Ansible no solo para establecer una configuración una vez, sino para garantizarla de forma continua: si un servidor se desvió, volver a correr el playbook lo devuelve al estado descrito.

Son las dos piezas con las que se trabaja en Ansible. Un playbook es un archivo de texto en formato YAML, pensado para ser legible, en el que se describen en orden las tareas que Ansible debe aplicar: por ejemplo asegurar que cierto paquete esté instalado, copiar un archivo de configuración o garantizar que un servicio esté corriendo y habilitado para arrancar con el sistema. El inventario es el archivo donde se listan y agrupan los servidores que se van a gestionar, por ejemplo definiendo un grupo llamado web con varios servidores y otro grupo llamado base de datos con otros. Al ejecutar un playbook, se le indica sobre qué grupo del inventario debe aplicarse, y Ansible ejecuta esas tareas en todos los servidores de ese grupo a la vez. Ambos, playbooks e inventario, son texto y deben guardarse en un control de versiones, lo que los convierte en una descripción versionada, revisable y reproducible de cómo debe configurarse cada tipo de servidor.

Con Ansible Vault, una funcionalidad incorporada que permite cifrar valores sensibles como contraseñas, claves y tokens, de modo que puedan guardarse cifrados junto al resto del código y descifrarse únicamente en el momento de ejecutar el playbook, mediante una clave que no se versiona. Lo que nunca hay que hacer es escribir secretos en texto plano dentro de los playbooks o del inventario, porque esos archivos se guardan en un control de versiones y se comparten con el equipo, de manera que cualquier credencial escrita sin cifrar quedaría expuesta a quien tenga acceso al repositorio. Con Ansible Vault, en cambio, el contenido sensible viaja cifrado y solo se revela en tiempo de ejecución. Es la aplicación concreta, dentro de Ansible, de la regla universal que rige para el código fuente, los contenedores, los pipelines y la infraestructura como código: los secretos viven protegidos por un mecanismo pensado para ello y jamás se incrustan en texto plano en lo que se versiona o distribuye.

Resuelven problemas distintos y complementarios, y muchas veces se usan juntos. Terraform se ocupa de aprovisionar la infraestructura, es decir de crear y gestionar los recursos: levantar los servidores, definir las redes, crear las bases de datos. Ansible se ocupa de la gestión de configuración, es decir de preparar lo que corre dentro de esos servidores una vez que ya existen: instalar paquetes, configurar servicios, desplegar aplicaciones y mantener el sistema en el estado deseado. Una forma clara de recordarlo es que Terraform construye la casa y Ansible la amuebla y la deja lista para vivir. En un flujo de trabajo típico, Terraform crea primero la infraestructura y después Ansible configura las máquinas resultantes. Aunque existe cierto solapamiento y cada herramienta puede invadir un poco el terreno de la otra, la práctica más limpia y mantenible es usar cada una para aquello en lo que es mejor, en lugar de forzar una sola a cubrir ambos roles.