Gestión de la configuración con Ansible

April 25th, 2022

Introducción: una breve descripción de la gestión de la configuración

La gestión de la configuración, también conocida como automatización de sistemas u orquestación de servidores, consiste en la centralización de la administración de todo un conjunto de servidores en un único nodo o varios, de forma que se facilita la administración del sistema sin descuidar el funcionamiento ni la seguridad. De esta forma se pueden ejecutar tareas en un conjunto de servidores sin necesidad de iniciar sesión en ellos y sin que haya que ejecutar la misma tarea en cada servidor tantas veces como servidores tengamos. También nos permite comprobar que cada uno de estos servidores tiene la configuración deseada a partir de las plantillas definidas y gestionadas en una aplicación principal.

Existen varias herramientas en el mercado que permiten la administración remota de servidores. Probablemente las más extendidas sean Chef, Puppet y Ansible. En esta publicación vamos a centrarnos en este último (Ansible), que probablemente sea el más sencillo de utilizar para usuarios con un conocimiento medio.

Una característica importante es que tan sólo es necesario instalar el software en el servidor que vamos a utilizar de nodo central (bastión) desde el que se van a lanzar las tareas a ejecutar en los nodos administrados. En estos no es necesario instalar ninguna aplicación ni agente, el nodo controlador se conecta a ellos mediante SSH y utilizará el intérprete de Python que viene instalado en todas las distribuciones de Linux, siendo este un requisito a tener presente a la hora de utilizar una herramienta de gestión de la configuración u otra, el sistema operativo destinos a administrar.

Instalación

Para ilustrar el tutorial vamos a utilizar 3 servidores UBUNTU 20.4. Uno de ellos, llamado controller, va a actuar de controlador; los otros dos, llamados managed1 y managed2 van a actuar de clientes y serán gestionados por el controlador. En las 3 máquinas vamos a utilizar un usuario con privilegios de sudo que hemos llamado Qualoom.

Ansible permite la administración de entornos mucho más heterogéneos, pero un entorno tan uniforme nos permite simplificar la demostración que queremos llevar a cabo y ejemplificar mejor aspectos relevantes.

El primer paso es la instalación de Ansible en el controlador. En UBUNTU lo podemos instalar desde sus repositorios con el comando APT:

ansible1

Y podemos comprobar que lo tenemos instalado listando los programas que hay en el servidor:

ansible2

Una vez instalado el siguiente paso sería editar el archivo de configuración /etc/ansible/hosts. Entre todos los ejemplos que contiene nosotros añadimos un grupo al que vamos a llamar servidores que va a contener los dos nodos que queremos administrar, indicando sus direcciones IP, que son la 172.26.1.42 y 172.26.1.43. Podríamos separar los nodos en grupos para ejecutar en cada uno diferentes tareas:

ansible3

Ya podemos probar la conectividad del controlador con los clientes con el comando ansible all -m ping. En este caso el parámetro -m indicaque vamos a ejecutar un módulo de los muchos con los que cuenta ansible, más adelante veremos cómo ejecutar comandos directamente en la máquina remota. El parámetro all indica a Ansible que queremos ejecutar el módulo sobre todos los servidores que tenemos en el inventario.

ansible4

Como podemos ver, el servidor no se puede conectar a los equipos remotos, el problema es que no se están proporcionando las credenciales para conectarse por SSH. En el siguiente apartado veremos cómo configurar la clave pública del controlador en los equipos que queremos administrar para evitar este problema.

Configuración SSH de los clientes

Para que el controlador se pueda conectar a los equipos automáticamente sin que se le soliciten credenciales hay que configurar estos de forma que el controlador pueda acreditar su identidad con una clave pública. Para ello generamos un par de claves con el comando ssh-keygen.

ansible5

En la imagen vemos que en la carpeta .ssh del usuario se han generado 2 archivos. El id_rsa.pub es el que contiene la clave pública. Su contenido es el que debemos pegar en el archivo authorized_keys de los equipos remotos, como podemos ver en la imagen.

ansible6

Ahora la prueba de conexión con el módulo ping funciona correctamente, la respuesta pong de los 2 servidores lo confirma.

ansible7

También podemos probar la ejecución de comandos remotos con la opción -a

ansible8

Playbooks

En Ansible los playbooks son una parte fundamental, sin ellos no se alcanzaría todo su potencial.

Los playbooks son archivos de texto en formato YAML en los que se definen varias tareas a ejecutar de forma secuencial.

Hasta ahora hemos ejecutado un módulo o un comando desde la consola de texto, esas órdenes las podemos poner en un playbook para ser ejecutadas una detrás de otra con una única orden o programar su ejecución. De esta manera los playbooks permiten configurar servidores o confirmar que un servidor está configurado como deseamos. Otra ventaja de los playbooks es que se puede hacer control de versiones, como se hace de cualquier código, y así probar y deshacer configuraciones.

Aquí tenemos un ejemplo de playbook muy sencillo para instalar y arrancar el servidor web Apache en los 2 nodos:

ansible9

Lo que en este ejemplo se puede ver es que:

Se va a aplicar a todos los nodos, pero podríamos seleccionar un grupo o un nodo.

Al grupo de nodos seleccionados (que en este caso son todos) se les aplica la opción become, que se utilizapara escalar privilegios en el caso de que hagan falta permisos especiales para llevar a cabo ciertas tareas. Esta opción permite ejecutar tareas en nombre de un usuario distinto al que estamos utilizando, pero en este caso se limita a utilizar la opción sudo del usuario remoto.

En último lugar tenemos las tareas que se va a aplicar a los nodos seleccionados, y que ya hemos visto cómo se podrían ejecutar desde la línea de comandos. En este caso son 2, la instalación de Apache y su arranque. Estas tareas se van a llevar a cabo a través de los módulos apt y service.

En el ejemplo también podemos ver que para hacer comentarios se utiliza el símbolo #, y podemos intuir como en un mismo playbook se pueden definir distintas tareas para servidores distintos.

Finalmente ejecutamos el playbook con el comando ansible-playbook:

ansible10

Hemos dejado que la ejecución falle en uno de los nodos para ilustrar cómo podemos evitar el problema que aparece en la imagen. El error se debe a que hay que proporcionar la contraseña de sudo del usuario del nodo administrado. Cuando se ejecuta un comando se puede indicar con la opción -- extra-vars como podemos ver en la siguiente imagen, pero por obvios motivos de seguridad es la opción menos aconsejable:

ansible11

En Ansible contamos con Ansible Vault para cifrar contraseñas, archivos y otros datos sensibles, pero para que este no deje de ser un documento de iniciación hemos optado por una opción que podríamos haber comentado cuando hemos tratado la configuración de los clientes, pero no lo hemos hecho porque no es algo necesario. Podemos evitar este problema configurando el archivo sudoers de cada uno de los clientes para que no se le solicite la contraseña al usuario local cuando ejecuta comandos como sudo.

ansible12

Conclusión

En esta documentación hemos visto como podemos instalar Ansible, probar la conexión con los equipos remotos y ejecutar en ellos comandos y playbooks.

A partir de aquí queda mucho por aprender. Afortunadamente Ansible cuenta con una documentación extensa, que puedes ver a través de este enlace, y presume de tener una curva de aprendizaje suave en comparación con la de sus competidores.

Te animamos a seguir nuestras publicaciones en los medios habituales para seguir aprendiendo sobre aspectos básico y avanzados de tecnología de administración de sistemas.

Blog Twitter LinkedIn