Reunión de Sudoers BCN de Noviembre

por Ignasi Fosch el en Ansible Eventos Sudoers BCN
sudo make me a sandwich

En la charla de este mes, Javier Arturo Rodríguez habló sobre Ansible, otra herramienta para la gestión de configuración. Aunque bien podría compararse en funcionalidad con Puppet o Chef, su diseño y las técnicas utilizadas la convierten en una herramienta muy sencilla, completa e interesante, incluso para sustituir a otras herramientas como Fabric o Capistrano.

Origen del nombre

El término Ansible lo utilizó Ursula K. Le Guin en sus relatos de ciencia ficción, para referirse a un dispositivo de comunicación instantánea y superluminal, y otros autores, como Orson Scott Card en Ender's Game, lo reaprovecharon. De todos modos, también es el término utilizado para referirse al director de una orquesta. No en vano, Ansible funciona desde un nodo central que suele ser la consola del administrador.

El proyecto

El proyecto es iniciado por Michael DeHaan, actual CTO de la empresa que da soporte. Tiene un diseño basado en KISS, utiliza SSH para conectarse a los clientes, que únicamente necesitan disponer de la versión 2.6 de python. Al utilizar el protocolo SSH, aprovecha su puerto de conexión y su infraestructura, como la de autenticación, para funcionar. Hay que destacar que para las tareas que requieran privilegios, puede utilizar sudo, pero no es capaz de funcionar con contraseña.

Aunque se trata de software open source, existe un modelo de negocio comercial, al que da soporte la empresa AnsibleWorks, que incluye ciertos componentes de pago.

Instalación

Instalación se puede realizar de diferentes formas:

  • Con paquetes nativos, existen incluso para BSD.
  • Se puede instalar usando pip, como tantos otros módulos de Python.
  • Tambié se puede instalar compilándolo desde el código fuente, que es descargable en un paquete o utilizando GitHub.

Es conveniente tener los siguientes elementos bien configurados:

  • Tener claves SSH adecuadas.
  • Utilizar ssh-agent en la estación de trabajo, asociando dichas claves.
  • Comprovar el fichero ~/.ssh/config, de modo que los accesos que requieran utilizar puertos alternativos estén bien configurados.

Configuración

La configuración es tan sencilla como disponer de uno o más ficheros de inventario. Estos ficheros tienen un formato muy sencillo: En cada línea se escribirá el nombre de un nodo a gestionar. En caso de que dicho nodo requiera el uso de un puerto distinto al habitual, convendrá indicarlo añadiéndolo al nombre del servidor con un : delante. En los nombres de los equipos se pueden utilizar ciertas expresiones para indicar, por ejemplo, rangos numéricos, indicando así una serie más grande de nodos en una sola línea.

Además, como si de un fichero INI se tratara, se pueden espeficar secciones, encabezadas con un nombre entre corchetes ([]) que corresponderán en grupos de servidores. En caso que sea necesario, se puede incluir otra sección para un grupo ya existente que contenga variables específicas para esos grupos.

Pueden disponerse de distintos ficheros, pero sólo uno se puede utilizar al mismo tiempo, debiendo indicar a Ansible cuál se desea utilizar con el atributo -i.

Módulos

Los módulos son los que le dan funcionalidad a Ansible. Estos módulos consisten en código que Ansible envía al nodo remoto y lo ejecuta, esperando que devuelva una estructura JSON con un conjunto de datos que variarán según el módulo. En cualquier caso, el JSON deberá contener un atributo llamado changed, consistente en un valor booleano que indicarà si la ejecución cambió algo o no. La ejecución de un módulo siempre debe ser idempotente, por lo que, si no es necesario, no debería realizar ningún cambio. Existe un comando ansible-doc que ofrece documentación en consola sobre los módulos y sus opciones.

En los siguientes comandos, se ejecuta el módulo setup en todos los servidores, en uno sólo llamado courseware o en todos los pertecientes a un grupo llamado webservers:

ansible -vvvv -i production all -m setup
ansible -vvvv -i production courseware -m setup
ansible -vvvv -i production webservers -m setup

Hay muchos módulos, algunos muy interesantes, permiten, por ejemplo, acceder a la información que el facter, de Puppet, o el ohai, de Chef, pueden recopilar del nodo. Esta información se podrá utilizar en la configuración del mismo.

Playbooks

Para evitar la ejecución consecutiva de órdenes, Ansible permite crear lo que denomina Playbooks. En ellos, se definen qué módulos se aplican y cómo. Pueden contemplarse como una descripción del estado deseado del nodo en cuestión. Esta definición se escribe en una variante de YAML, conteniendo cuatro secciones específicas:

  • vars donde, si es necesario se crearán las variables necesarias para la ejecución del playbook.
  • hosts donde se indicará a qué nodo, o nodos, se debe aplicar.
  • tasks que detallan los módulos con sus respectivas opciones.
  • handlers que, si es necesario, indicarán gestores para ciertas situaciones.

Los playbooks se organizan en directorios donde se pueden encontrar también:

  • ficheros individuales, que serán copiados tal cuál están al servidor configurado.
  • plantillas, escritas en Jinja2, para generar ficheros cuyo contenido puede variar según ciertos parámetros.
  • definiciones de roles, que son otro tipo de agrupaciones de servidores que permiten incluir variables, nodos, tareas, gestores y plantillas específicas.

Los playbooks, aunque utilicen YAML, pueden permitir cierto nivel de control de flujo o seleccciones interesantes. Por ejemplo, se puede aplicar un módulo sobre una lista de elementos sobre la que iterar, los cuales pueden modificar variables o parámetros. La aplicación de un playbook específico sobre un único servidor se hará con el comando ansible-play -l <nodo> <playbook>.

Modos

Uno de las principales desventajas que tiene Ansible por su diseño es la cantidad de nodos que se pueden gestionar simultáneamente. Especialmente, debido al coste de las sesiones SSH. Por ello se creó, inicialmente, lo que se denominó modo Fireball. Este modo consistía en arrancar un servidor persistente en el cliente que, mediante el uso de una instancia local de 0mq y claves propias, iba recibiendo las instrucciones y las iba ejecutando. De todos modos, esto quedó obsoleto y se sustituyó por el modo Accelerated que hace algo similar, pero por SSH de nuevo y sin 0mq. También se dispone de un modo llamado Local que es el utilizado para configurar con Ansible el mismo nodo en el que se encuentra.

Otra de las desventajas que se pueden producir es el acceso a nodos en ubicaciones con latencias muy altas, o con conectividad muy inestable. Para ello se suele utilizar un nodo bastión, como si de un proxy se tratara.

Versión comercial

La versión comercial incluye, a parte de las opciones de soporte correspondientes, dos módulos especiales:

  • AWX que es un interfaz web de gestión que permite ciertos niveles de configuración más fácilmente, como el concepto de organizaciones o proyectos.
  • El modo Callback que consiste en permitir el envío asíncrono de configuraciones.

Más información

Durante y posteriormente a la charla, se comentaron ciertas utilidades relacionadas con Ansible:

Con mucha probabilidad existan muchas más herramientas.

Comentarios con Disqus