Mi experiencia con Ansible

01 Nov 2020
Mi experiencia con Ansible

En el departamento que me encuentro desempeñando actualmente cada vez se formalizan mas múltiples servicios de IT, a pesar que la institución esta mas cercana a lo académico, es inevitable que los servicios de IT se basen en estándares utilizados en la industria. Es algo que eh tratado de impulsar, y mas aún que en el ambiente académico podemos darnos la oportunidad de experimentar y jugar con distintas herramientas, y si no funciona, podemos cambiar el rumbo sin realmente haber tener la presión que se da en ambientes empresariales.

En este crecimiento nos podemos apoyar con el uso de herramientas que faciliten el trabajo y por supuesto que nos vuelvan más eficientes.

En especifico dentro de los distintos servicios que ofrece el grupo con el que trabajo, atiendo el despliegue de maquinas virtuales, el hospedaje de sitios web, y en general preparar servidores para distintos ambientes, como aplicaciones R, python, o de HPC (Cómputo de altas prestaciones).

Al día de hoy la conexión a clusters de virtualización de código abierto, el preparar servidores con requerimientos básicos de seguridad, la gestión de servidores para hospedaje web y la configuración de sitios, entre otras tareas están completamente automatizadas usando Ansible. Estamos hablando ahora de que nuestra infraestructura esta definida por código (Infraestructure as code), de los objetivos que ah dejado la ola tan grande y necesaria del DevOps.

¿Pero qué es Ansible?

Ansible es una herramienta para la configuración y administración de servidores tipo Unix (recientemente soporta windows powershell), desarrollada en su totalidad en python, solo requiere la definición de archivos de texto en formato YML que se ejecutan, empujando operaciones en los servidores destino que se desean configurar.

No requiere de instalar ningún agente en los servidores destino, solo debe de estar permitida una conexión SSH (ó Windows Remote Management).

El modo en que Ansible define las tareas o cambios en los servidores destino son en estados o idempotentes, es decir, la operación se ejecuta una vez produciendo un resultado, pero si se ejecuta una segunda o tercera vez, no hay cambios pues el servidor destino está configurado con el estado solicitado. Lo anterior lo hace una solución muy confiable para su uso.

Ansible por ser una herramienta que ya tienen algunos años siendo un líder en el soluciones para la automatización, tiene ahora un amplio listado de módulos para la configuración de distintos servicios, por ejemplo los hay para meter textos en archivos, reiniciar servicios systemd, gestionar mysqld, firewalld, ufw, etc, lo que busques seguramente lo hay.

¿Qué necesito para usar Ansible?

En realidad no mucho, solo requieres un sistema operativo que te permite instalar python, su manejador de paquetes [pip](), y correr el siguiente comando para instalar Ansible.

$ pip install ansible

Y estas listo para empezar.

Ansible en acción.

Ahora que ya tienes tu instalación de Ansible lista puedes empezar a empujar operaciones a servidores destino, estos pueden ser servidores, fisicos, maquinas virtuales, contenedores, etc, lo que quieras mientras tengas una conexión preconfigurada a este servidor.

Por ejemplo, expongo el caso de una maquina virtual creada en VirtualBox con un servidor Centos instalación minima. con IP 192.168.56.103.

Lo primero que tenemos que hacer es configurar una conexión ssh con llave publica al servidor virtual, para lograr esto hay algunos métodos, lo que me funciona a mí esta descrito en este snippet.

Teniendo el acceso por SSH a la VM, hay que crear (si es que no existen) nuestro par de llaves (publica/privada) ssh con el siguiente comando.

$ ssh-keygen -t ed25519 -C “tucorreo@correo.com”

El anterior comando preguntara sobre la ruta donde depositara el par de llaves, e ingresar un ‘passphrase’, que podemos dejar en valores por defecto para motivos de esta prueba, cuando la seguridad sea una prioridad si hay que atenderlo.

Una vez creada el par de llaves, hay que copiar nuestra llave publica al servidor destino, y agregarla al archivo de llaves autorizadas, esto se puede hacer igualmente de varias maneras, pero el método mas sencillo es correr:

$ ssh-copy-id operador@192.168.56.103 

Hecho esto, ahora podremos hacer una conexión ssh sin necesidad de ingresar una contraseña, la autenticación se hara comprobando que las llaves coincidan.

Mi hola mundo Ansible

Bien tenemos todo dispuesto, la primer cosa que debemos hacer es crear un archivo con el inventario de los servidores destino que vamos a configurar, este archivo puede llamarse como sea, pero tiene que seguir el siguiente esquema:

inventario

[servers]
192.168.56.102 ansible_user=operador

Donde [servers] es la etiqueta para el listado posterior de servidores, y ansible_user es el usuario que utilizara Ansible en el servidor destino para realizar operaciones (De requerir escalamiento de privilegios, este usuario debe de poder utilizar sudo). El IP es la dirección de nuestra VM en la que vamos a trabajar.

Ejecutemos lo siguiente:

$ ansible -i inventario servers -m ping                

192.168.56.102 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Ansible ejecuto el modulo ping, que por defecto, sin parametros hace un ping al listado de servidores especificados en -i inventario servers y con la etiqueta ‘servers’.

El comando nos regresa detalles del servidor destino, y el resultado de la operación, en este caso, se obtuvo el pong del servidor destino.

Ahora algo mas:

$ ansible -i inventario servers b -K —m yum -a ‘name=vim' 
BECOME password: xxxxx

Con el comando anterior usamos el modulo yum, para instalar el vim en el servidor destino, pero para ello especificamos que escalaremos privilegios -b y que nos pregunte por la contraseña del usuario sudoer -K, por lo que este comando antes de iniciar nos solicita la contraseña del usuario operador y asi poder instalar el paquete.

El comando entonces nos regresa:

192.168.56.103 | CHANGED => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Installed: vim-enhanced-2:8.0.1763-13.el8.x86_64",
        "Installed: vim-filesystem-2:8.0.1763-13.el8.noarch",
        "Installed: gpm-libs-1.20.7-15.el8.x86_64",
        "Installed: vim-common-2:8.0.1763-13.el8.x86_64"
    ]
}

Indicándonos que el paquete ah sido instalado.

Ahora bien, ¿Qué pasa si volvemos a correr el mismo comando?

$ ansible -i centos servers -b -K -m yum -a 'name=vim'
BECOME password: 
192.168.56.103 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "msg": "Nothing to do",
    "rc": 0,
    "results": []
}

Ansible nos regresa el mensaje Nothing to do, pues el paquete ya se encuentra instalado en el servidor destino.

Con lo anterior nos podemos dar cuenta que podemos ejecutar operaciones en los servidores, escalar privilegios de ser necesario, y mejor aún estas operaciones pueden ser ejecutadas en multiples servidores que estén anotados en nuestro archivo de inventario.

Ansible playbooks o recetas

Un concepto bien interesante de esta herramienta, es la posibilidad de definir lo que ansible llama roles que es un framework para la definición de alguna operación de configuración, que contiene variables, listado de tareas, plantillas de archivos de texto, archivos, entre otras cosas. Y que son una unidad independiente que permite definir bloques de construcción para recetas más complejas.

Por ejemplo, un rol muy sencillo que digamos instale un listado de paquetes con yum o apt, se especifica de la siguiente manera:

miprimerrole
├── defaults
│   └── main.yml
└── tasks
    └── main.yml

El archivo tasks/main.yml contiene el listado de tareas que de manera secuencial se ejecutaran en el servidor, en este caso revisaria la familia del sistema operativo en una condición para decidir si utilizar YUM o APT para instalar el listado de paquetes.

El listado por paquetes estaria definido en defaults/main.yml. Que estas variables pueden ser redefinidas en otro nivel de ejecución para modificar esa lista, e instalar paquetes distintos a los por defecto.

Estos roles pueden se pueden instanciar en los playbooks, que ejecutan uno o más roles para construir configuraciones más complejas. Como lo pudiera ser, el prepara un servidor de hospedaje web compartido que requiere de la instalación y configuración en producción de un servidor web apache httpd, un servidor de mysql, la instalación de php, el enjaulado de cuentas, instalación de paquetes de seguridad como fail2ban, firewalld, selinux. Donde cada uno de estos elementos puede estar definido en un rol configurable que permita la orquestación entre ellos.

Aquí es donde comienza lo interesante de Ansible, que nos permite armar nuestros bloques básicos de configuración y combinarlos para producir distintos resultados.

Pero ademas Ansible ya tiene un listado grande de roles que la comunidad de usuarios a construido, los cuales pueden ser consultados en el repositorio web y descargados con ansible-galaxy.

En conclusión por hoy, es una gran herramienta que no requiere de mucho compromiso por los grupos de trabajo, su manejo y configuración solo requiere del manejo de archivos de texto en formatos muy legibles como YML, y el templating con jinja2 (Esto le gusta mucho a GIT). Ademas de ser ya un estándar casi como docker para el DevOps.

Si eres desarrollador, o si eres administrador de sistemas, esta herramienta provee de un lenguaje común entre ambos que al final del día nos facilita mucho mas la vida y nos deja con tiempo para definir estrategias y mejorar nuestros servicios.

Recursos:

  • Sandbox de Ansible en linea: https://www.katacoda.com/courses/ansible
  • Preparar virtualbox para acceso SSH: https://gitlab.com/-/snippets/2013182
  • Listado módulos ansible


Blog Comments powered by Disqus.

 Anterior