Instalación y configuración de AnsibleEPS

Como vimos en la entrada anterior, AnsibleEPS es una colección de playbooks de Ansible de la EPS que permite centralizar y automatizar las configuraciones de la infraestructura IT del centro. Para su instalación lo primero que debemos realizar es la descarga del contenido del directorio install El contenido del fichero ansibleEPS.tgz es el mismo que encontramos en el directorio de la aplicación en el repositorio  El fichero install.py es un guión de Python que nos permitirá instalar los playbooks de Ansible en nuestro equipo que actuará de servidor central de configuraciones que mencionábamos anteriormente (servidor Ansible).

Tras la instalación, debemos configurar la aplicación. Lo primero será indicarle qué host actuarán como nodo: host directamente accesible por el servidor de Ansible con un usuario predefinido y sin contraseña (por defecto, usuario ‘ansible’, pero se puede cambiar modificando la variable ‘ansible_ssh_user’ en el fichero de configuración inicial /etc/ansibleEPS/group_vars/all/all). Para ello simplemente seleccionaremos la opción ‘add node’ del menú (que lanzaremos ejecutando la orden /etc/ansibleEPS/menu.py). Un detalle a tener en cuenta es que para crear el usuario necesario para AnsibleEPS, la conexión se establecerá como root y, por tanto, tendremos que teclear la contraseña del administrador del host y, obviamente, tener habilitada la conexión por ssh para root.

El segundo paso será añadir nodos al inventario y, posteriormente, modificar las variables que necesitemos para lo que tendremos que tener en cuenta los siguientes directorios:

• /etc/ansibleEPS/group_vars/all  donde residen los datos globales de lo nodos a administrar,
• /etc/ansibleEPS/group_vars datos por grupos de nivel,
• /etc/ansibleEPS/host_vars datos por host.

Playbooks

Los playbooks son los ficheros de más alto nivel, los guiones que llamamos desde la línea de comandos (o desde el menú proporcionado) para ejecutar alguna operación en los servidores. En él se definen:

• hosts -> la lista de servidores en los que se ejecutará el código
• roles -> los roles (conjuntos de tareas relacionadas y agrupadas) que se van a ejecutar

Para ejecutar un playbook desde línea de comandos, debemos invocar la orden ansible-playbook fichero.yml con la que estaremos llamando al playbook fichero.yml, que mandará ejecutar el código definido en roles para los servidores definido en hosts, según las variables de group_vars y hosts_vars (que pueden cambiar sus valores dependiendo del servidor y de los grupos en los que se haya definido en el inventario). La tabla1 de la entrada anterior muestra la lista de playbooks de la infraestructura de ejemplo proporcionada.

Inventario de servidores

En el fichero /etc/ansibleEPS/eps tenemos definidos los servidores sobre los que se podrán ejecutar  playbooks. Un servidor que no se encuentre en este fichero no podrá ser administrado con Ansible con nuestra implementación. Este fichero se divide en tres grandes partes que definen grupos diferentes (todos los nombres entre corchetes son nombre de grupos). La idea general es poder agrupar los servidores tanto por tipo(s) de servicio(s) realizado(s) (roles a llevar a cabo), como por la ubicación (P1, P2…, donde P1 es la ubicación Politécnica I, P2, Politécnica II).

Las agrupaciones nos permiten acotar el ámbito sobre el que se ejecutará un playbook y definir el valor de las variables que se usarán en el código. Esta valor puede variar según el grupo al que pertenezca un servidor.

Las tres partes en las que se divide el fichero son:

• Servidores por roles y ubicación. Para definir los grupos del tipo: [P1-Mysql], que nos indica un grupo de servidores con Mysql que se encuentran situados en P1

• Servidores por roles. Para definir los grupos del tipo [mysql:children], que nos indica todos los servidores con Mysql. En lugar de volver a escribir el nombre de los servidores, lo que haremos serán escribir el nombre (sin corchetes) de los grupos (por roles y ubicación) antes escritos: P1-Mysql, P2-Mysql, etc.

• Servidores por ubicación. Para definir los grupos del tipo [P1:children], que nos indica todos los servidores de P1. Como en el caso anterior, en lugar de volver a escribir el nombre de los servidores, lo que haremos serán escribir el nombre (sin corchetes) de los grupos (por roles y ubicación) antes escritos: P1-Mysql, P1-Apache, P1-DNS, etc.

Hay una última parte en el fichero donde definimos los grupos adicionales. Estos son grupos que añadiremos porque nos sean necesarios para la inclusión o exclusión de servidores en la ejecución de algún playbook. Por ejemplo, suponiendo que tengamos un playbook que configura las iptables en todos los servidores podemos declarar un grupo noiptables con los equipos que no queramos configurar. En este caso, además deberíamos añadir la coletilla en el apartado hosts del playbook indicando que se ejecutará en todos los equipos excepto los del grupo noiptables.

Agrupando por Sistemas Operativo

Todos los playbooks llaman al fichero group_by.yml antes de realizar sus tareas. En este playbook de apoyo se agrupan los servidores en los que se va a ejecutar el playbook, en grupos según el sistema operativo, la distribución y la versión de los servidores.

Esta agrupación tiene sentido desde el momento en que podemos definir valores a las variables de los playbooks según estas agrupaciones. Por ejemplo, una variable que incluya el path al servidor Apache, en Centos sería /etc/httpd mientras que para Debian sería /etc/apache2

Agrupando por Subred

En el fichero group_by.yml al que antes hacíamos referencia, además de agrupar los servidores según el sistema operativo, la distribución y la versión de los servidores, también se agrupan según la subred en la que se encuentra su tarjeta principal (eth0). Esta agrupación tiene sentido desde el momento en que podemos definir valores a las variables de los playbooks según estas agrupaciones. Por ejemplo, para una subred 17.16.40.0 puede que necesitemos un servidor DNS específico, unas reglas IPTables diferentes, etc.

Variables

Una de las características más importantes de los playbooks es el uso de variables dentro del código (roles). Con ellas podemos definir cualquier aspecto del código que queramos definir: path de comandos, configuraciones, scripts, etc. Las variables se definen en ficheros dentro de los directorios group_vars (variables generales y por grupos) y hosts_vars (variables por servidor).

Tendremos variables a varios niveles, desde un fichero general con los valores por defecto, que valdrán para todos los servidores, pasando por ficheros ‘por cada grupo’, donde se pueden definir nuevas variables para ese grupo concreto o bien sobreescibir valores de las variables generales, o incluso definir o sobreescribir variables por cada servidor particular.

Estos son los niveles de declaración de ficheros:

• General -> en el directorio group_vars/all/ se encuentran los ficheros que contienen todas las variables que serán de aplicación para todos los servidores. El fichero general se llama all y luego habrá un fichero separado por cada una de las estructuras de variables (sudo, ipTables, pamAccess, wrappers, etc.). Es bueno definir las variables a este nivel aunque luego se les cambie el valor en otro nivel, ya que así dispone de un valor ‘por defecto’.

• Por grupo -> los ficheros group_vars/nombreGrupo contendrán las variables que se utilizarán para los servidores definidos en el grupo ‘nombreGrupo’ (los grupos se definían en el fichero de inventario eps). Se pueden definir variables nuevas que sólo tengan sentido para el grupo de servidores, o bien cambiar los valores de las variables generales.

IMPORTANTE: Además de crear el fichero con el nombre del grupo, habrá que crear también enlaces al fichero con los nombres de los subgrupos por edificio: ‘P1-fichero’, ‘P2-fichero’ (tantos como subgrupos existan). En caso contrario puede que no tenga en cuenta las variables del fichero (si el host pertenece a más de un grupo).

• Por servidor -> los ficheros hosts_vars/nombreServidor contendrán las variables que se utilizarán para el servidor de nombre ‘nombreServidor’ (por supuesto, el servidor habrá tenido que darse de alta en el fichero de inventario eps). Al igual que en el anterior nivel, se pueden definir variables nuevas que sólo tengan sentido para el servidor concreto, o bien cambiar los valores de las variables generales o grupales.

Roles

El código que se ejecutará en los servidores se agrupa en roles según las tareas que vaya a realizar. Puede haber roles que configuren las iptables, que actualicen los servidores, etc. Dentro de cada rol se definen tareas diferentes, pero todas persiguen un fin común que es el que define el significado de los roles.

Estos roles son llamados dentro de los playbooks. Un playbook puede llamar a un rol o a varios de ellos.

Los roles se definen en el directorio roles, creando un subdirectorio para cada uno de ellos. Dentro de cada uno de ellos se crearán cuatro subdirectorios (si son todos necesarios, que puede no ser así):

• subdirectorio tasks -> En el crearemos ficheros yml con código a ejecutar. Suele haber un fichero principal ‘main.yml‘ desde el que se llama al resto de ficheros con tareas.

• subdirectorio files -> Si alguna de las tareas necesita copiar un fichero fijo (un fichero cuyo contenido es estático y no contiene variables que puedan hacerlo variar) a los servidores, estos ficheros se colocarán en este directorio para que las tareas pueden saber su ubicación y disponer de él.

• subdirectorio templates -> Se trata del mismo caso que el anterior, sólo que esta vez los ficheros no son estáticos, sino que contienen variables, cuyos valores harán que el contenido de los ficheros no sea fijo (variarán según los valores de las variables). Estos ficheros tendrán la extensión j2 (que indican el lenguaje que se utilizará para la utilización de las variables -> jinja2).

• subdirectorio handlers -> En este directorio se definen unas tareas especiales que se encargan de interactuar con los servicios: parando, arrancando o reiniciando un servicio). Estas tareas especiales serán llamadas desde los ficheros de tareas de ‘task’.

Para completar la configuración, en la entrada sobre AnsibleEPS, disponemos de la tabla de playbooks mencionada anteriormente en la que, además de listar y describir todos los playbooks de la infraestructura de ejemplo, se dispone de un enlace por playbook con una entrada específica en la que se explica el playbook.

¡Esperamos que os sea útil!