Introducción a Ansible con ejemplos para los administradores de sistemas

¿Es el típico administrador de sistemas con mucho trabajo y poco tiempo? ¿Le genera escalofríos la sola idea de aplicar una modificación sencilla en el servidor DNS o de ajustar los parámetros del kernel en todo el servidor? O aún peor, ¿tener que implementar cambios en función de las características variables del sistema, como la memoria instalada o la versión de lanzamiento? ¿Los desarrolladores en su empresa usan otro lenguaje distinto al suyo debido al contexto de DevOps?  

Red Hat Ansible Automation es una herramienta de automatización sin agentes que las personas pueden comprender y que usa el protocolo SSH para organizar la gestión de la configuración, la implementación de las aplicaciones y la preparación en un entorno con uno o varios niveles. Se basa en Ansible, una de las tecnologías de automatización de la TI open source más conocidas en todo el mundo.

En esta publicación del blog se describen los conceptos básicos de Ansible y la manera en que se los administradores de sistemas pueden utilizarla para optimizar su trabajo.

Antes de comenzar, debemos definir la terminología:

Nodo de control: el host en el cual se utiliza Ansible para ejecutar tareas en los nodos gestionados.

Nodos gestionados: los hosts que configura el nodo de control.

Inventario de hosts: la lista de los nodos gestionados.

Comando específico: tarea sencilla y puntual.

Playbook: conjunto de tareas que se pueden repetir para las configuraciones más complejas.

Módulo: el código que ejecuta una tarea común específica, como agregar a un usuario, instalar un paquete, etc.

Idempotencia: las operaciones idempotentes producen los mismos resultados si se ejecutan una o varias veces sin ninguna intervención.

Entorno

El entorno que se detalla en esta publicación contiene un nodo de control (vm1) y cuatro nodos gestionados (vm2, vm3, vm4, vm5), los cuales se ejecutan en un entorno virtual con una instalación mínima de Red Hat Enterprise Linux 7.4. Por razones de sencillez, el nodo de control tiene las siguientes entradas en el archivo /etc/hosts:

192.168.102.211 vm1 vm1.redhat.lab
192.168.102.212 vm2 vm2.redhat.lab
192.168.102.213 vm3 vm3.redhat.lab
192.168.102.214 vm4 vm4.redhat.lab
192.168.102.215 vm5 vm5.redhat.lab

Para facilitar el uso, brindaré a mi usuario de sistema un comando sudo sin contraseña en esta demostración. La política de seguridad puede variar, y Ansible es compatible con diversos casos prácticos de aumento de los privilegios. Esta cuenta de usuario se configuró para aumentar los privilegios con la siguiente entrada en el archivo /etc/sudoers:

%wheel ALL=(ALL) NOPASSWD: ALL

Este es solamente un ejemplo, así que puede utilizar su propia variante de configuración de sudo.  

Finalmente, se configuró y se probó la autenticación con la clave pública SSH para esta cuenta de usuario desde el nodo de control hasta cada uno de los nodos gestionados.

Instalación de Ansible

Ansible para Red Hat Enterprise Linux 7 se encuentra en el canal Extras. Si utiliza Red Hat Enterprise Linux 6, habilite el repositorio EPEL. Esta solución en el portal de clientes también puede ser útil para Extra Packages for Enterprise Linux (EPEL). En los sistemas Fedora, encontrará Ansible en el repositorio base.

Una vez que se haya configurado el repositorio adecuado, la instalación es rápida y sencilla:

[curtis@vm1 ~]$ sudo yum install -y ansible 

Démosle un vistazo a la versión:

[curtis@vm1 ~]$ ansible --version
ansible 2.4.1.0
 config file = /etc/ansible/ansible.cfg
 configured module search path = [u'/home/curtis/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
 ansible python module location = /usr/lib/python2.7/site-packages/ansible
 executable location = /bin/ansible
 python version = 2.7.5 (default, May 3 2017, 07:55:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-14)]

Observe el archivo de configuración predeterminado y tenga en cuenta que Python es un elemento obligatorio en la instalación mínima de Red Hat Enterprise Linux 7.4

Configuración de Ansible

Ya establecimos los ajustes de los nodos gestionados con una cuenta de usuario, el aumento de los privilegios y la autenticación con la clave pública SSH, ahora configuraremos el nodo de control.

Esta tarea incluye tanto el archivo de configuración como el archivo de inventario de hosts de Ansible.

Archivo de configuración de Ansible

Como descubrimos anteriormente, el archivo de configuración predeterminado es /etc/ansible/ansible.cfg.

También puede modificarlo o hacer una copia específica para un directorio en particular. Este es el orden en el que se ubica cada archivo de configuración:

• ANSIBLE_CONFIG (según el entorno)

• ansible.cfg (por directorio)

• ~/.ansible.cfg (directorio principal)

• /etc/ansible/ansible.cfg (global)

En esta publicación utilizaremos un archivo de configuración mínimo en el directorio principal de la cuenta de usuario que agregamos con anterioridad:

[curtis@vm1 ~]$ cat ansible.cfg
[defaults]
inventory = $HOME/hosts

Inventario de hosts

El archivo de inventario de hosts predeterminado es /etc/ansible/hosts, pero se puede modificar con el archivo de configuración (como se muestra anteriormente) o usando la opción -i en el comando ansible. Utilizaremos un archivo de inventario estático y sencillo. También es posible usar inventarios dinámicos, pero no abordaremos esa opción en esta publicación.

Nuestro archivo de inventario de hosts es el siguiente:

[webservers] 
vm2 
vm3 

[dbservers] 
vm4 

[logservers] 
vm5 

[lamp:children] 
webservers 
dbservers 

Definimos cuatro grupos: webservers en vm2 y vm3, dbservers en vm4, logservers en vm5, y lamp con grupos de webservers y dbservers.

Confirmemos que se puedan ubicar todos los hosts utilizando el archivo de configuración:

[curtis@vm1 ~]$ ansible all --list-hosts
 hosts (4):
   vm5
   vm2
   vm3
   vm4

Haremos lo mismo con los grupos individuales, como el grupo de webservers:

[curtis@vm1 ~]$ ansible webservers --list-hosts
 hosts (2):
   vm2
   vm3

Ya validamos el inventario de hosts, ahora utilizaremos el módulo ping para realizar una verificación rápida y garantizar que todos los hosts se estén ejecutando correctamente:

[curtis@vm1 ~]$ ansible all -m ping
vm4 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm5 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm3 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm2 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}

En este ejemplo se puede ver que todos los sistemas arrojaron un valor exitoso, no hay ningún cambio, y el resultado de cada "ping" fue "pong".

Puede obtener la lista de los módulos disponibles con este comando:

[curtis@vm1 ~]$ ansible-doc -l 

La cantidad de módulos integrados sigue aumentando con cada lanzamiento de Ansible:

[curtis@vm1 ~]$ ansible-doc -l | wc -l 
1378 

Encuentre la documentación de cada módulo en http://docs.ansible.com/ansible/latest/modules_by_category.html.

El último paso es configurar vm1 con Apache y un repositorio de yum de Red Hat Enterprise Linux 7 para que los nodos gestionados instalen paquetes adicionales:

[root@vm1 ~]# yum install -y httpd
[root@vm1 ~]# systemctl enable httpd
[root@vm1 ~]# systemctl start httpd
[root@vm1 ~]# mkdir /media/iso
[root@vm1 ~]# mount -o loop /root/rhel-server-7.4-x86_64-dvd.iso /media/iso
[root@vm1 ~]# ln -s /media/iso /var/www/html/rhel7

Todo listo para utilizar Ansible

Ahora que ya configuramos el entorno, tenemos todo preparado para trabajar con Ansible.

Dado que los nodos gestionados necesitarán que se instalen algunos paquetes adicionales, la primera tarea será configurar un repositorio de yum en cada host con el siguiente archivo de configuración:

[curtis@vm1 ~]$ cat dvd.repo
[RHEL7]
name = RHEL 7
baseurl = http://vm1/rhel7/
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
enabled = 1
gpgcheck = 1

Podemos copiar el archivo en cada uno de los nodos gestionados usando un comando específico con el módulo de copia y la opción -m, e indicar los argumentos obligatorios con la opción -a de la siguiente manera:

[curtis@vm1 ~]$ ansible all -m copy -a 'src=dvd.repo dest=/etc/yum.repos.d owner=root group=root mode=0644' -b
vm5 | SUCCESS => {
   "changed": true, 
   "checksum": "c15fdb5c1183f360ce29a1274c5f69e4e43060f5", 
   "dest": "/etc/yum.repos.d/dvd.repo", 
   "failed": false, 
   "gid": 0, 
   "group": "root", 
   "md5sum": "db5a5da08d1c4be953cd0ae6625d8358", 
   "mode": "0644", 
   "owner": "root", 
   "secontext": "system_u:object_r:system_conf_t:s0", 
   "size": 135, 
   "src": "/home/curtis/.ansible/tmp/ansible-tmp-1516898124.58-210025572567032/source", 
   "state": "file", 
   "uid": 0
}

[...]

Se eliminaron los resultados adicionales de los hosts restantes para que sea más breve.

Tenga en cuenta estos aspectos importantes:

1. Cada nodo arroja los resultados SUCCESS y "changed": true, lo cual significa que la ejecución del módulo fue exitosa y que se creó o se modificó el archivo. Si volvemos a ejecutar el comando, el resultado incluirá el valor "changed": false, es decir, el archivo ya existe y está configurado correctamente. En otras palabras, Ansible solo realizará los cambios necesarios si no se han aplicado antes. Esto se conoce como "idempotencia".

2. Con la opción -b (consulte http://docs.ansible.com/ansible/latest/become.html), la tarea remota utiliza el aumento de los privilegios (es decir, sudo) para copiar los archivos en el directorio /etc/yum.repos.d.

3. Puede conocer los argumentos que requiere el módulo de copia si utiliza:

[curtis@vm1 ~]$ ansible-doc copy 

Playbooks de Ansible

Si bien los comandos específicos sirven para las pruebas y las tareas sencillas y puntuales, los playbooks son útiles para recopilar un conjunto de tareas que se puedan repetir en el futuro. Contienen uno o más plays que definen el conjunto de hosts que se deben configurar y la lista de tareas que se ejecutarán.

En este ejemplo, debemos configurar los servidores web y de base de datos, y un servidor de inicio de sesión centralizado, con estos requisitos específicos:

1. El paquete httpd debe estar instalado en los servidores web, habilitado e iniciado.

2. Cada servidor web tiene una página predeterminada con el texto "Welcome to <hostname> on <ip address>".

3. Cada servidor web tiene una cuenta de usuario con el acceso adecuado para gestionar el contenido.

4. El paquete MariaDB debe estar instalado en los servidores de base de datos, habilitado e iniciado.

5. El host de servidor de registro está configurado para aceptar mensajes de registro remoto.

6. Los hosts en los grupos de webservers y dbservers envían una copia de los mensajes de registro al host de servidor de registro.

El playbook a continuación (myplaybook.yml) configurará todo lo que necesitamos.

Mientras lo revisa, tenga en cuenta lo siguiente:

1. El módulo de usuarios requiere un hash de la contraseña sin formato (consulte "ansible-doc user" para obtener más detalles), lo cual se puede lograr de la siguiente manera:

   • [curtis@vm1 ~]$ python -c "from passlib.hash import sha512_crypt; import getpass; print sha512_crypt.encrypt(getpass.getpass())" Password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.

2. El contenido predeterminado de la página web se crea usando los "hechos" que se obtienen del host. Puede descubrir y utilizar los hechos del host con el módulo de configuración:

[curtis@vm1 ~]$ ansible vm2 -m setup

---
- hosts: webservers
 become: yes
 tasks:
   - name: install Apache server
     yum:
       name: httpd
       state: latest

   - name: enable and start Apache server
     service:
       name: httpd
       enabled: yes
       state: started

   - name: open firewall port
     firewalld:
       service: http
       immediate: true
       permanent: true
       state: enabled

   - name: create web admin group
     group:
       name: web
       state: present

   - name: create web admin user
     user:
       name: webadm
       comment: "Web Admin"
       password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.
       groups: web
       append: yes

   - name: set content directory group/permissions 
     file:
       path: /var/www/html
       owner: root
       group: web
       state: directory
       mode: u=rwx,g=rwx,o=rx,g+s

   - name: create default page content
     copy:
       content: "Welcome to {{ ansible_fqdn}} on {{ ansible_default_ipv4.address }}"
       dest: /var/www/html/index.html
       owner: webadm
       group: web
       mode: u=rw,g=rw,o=r

- hosts: dbservers
 become: yes
 tasks:
   - name: install MariaDB server
     yum:
       name: mariadb-server
       state: latest

   - name: enable and start MariaDB server
     service:
       name: mariadb
       enabled: yes
       state: started

- hosts: logservers
 become: yes
 tasks:
   - name: configure rsyslog remote log reception over udp
     lineinfile:
       path: /etc/rsyslog.conf
       line: "{{ item }}"
       state: present
     with_items:
       - '$ModLoad imudp'
       - '$UDPServerRun 514'
     notify:
       - restart rsyslogd

   - name: open firewall port
     firewalld:
       port: 514/udp
       immediate: true
       permanent: true
       state: enabled

 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted

- hosts: lamp
 become: yes
 tasks:
   - name: configure rsyslog
     lineinfile:
       path: /etc/rsyslog.conf
       line: '*.* @192.168.102.215:514'
       state: present
     notify:
       - restart rsyslogd

 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted

Ejecución del playbook

Podemos ejecutar el playbook con este comando:

curtis@vm1 ~]$ ansible-playbook myplaybook.yml 

En el resultado que aparece a continuación, podemos ver que la configuración del servidor web solo está presente en vm2 y vm3 (play 1), mientras que la base de datos está instalada en vm4 (play 2) y el logserver (vm5) está configurado con el play 3. Finalmente, el play 4 configura los hosts de webservers y dbservers mediante el grupo "lamp" para los registros remotos.

PLAY [webservers] *********************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm2]
ok: [vm3]

TASK [install Apache server] **********************************************************
changed: [vm3]
changed: [vm2]

TASK [enable and start Apache server] *************************************************
changed: [vm2]
changed: [vm3]

TASK [open firewall port] *************************************************************
changed: [vm2]
changed: [vm3]

TASK [create web admin group] *********************************************************
changed: [vm3]
changed: [vm2]

TASK [create web admin user] **********************************************************
changed: [vm3]
changed: [vm2]

TASK [set content directory group/permissions] ****************************************
changed: [vm3]
changed: [vm2]

TASK [create default page content] ****************************************************
changed: [vm3]
changed: [vm2]

PLAY [dbservers] **********************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm4]

TASK [install MariaDB server] *********************************************************
changed: [vm4]

TASK [enable and start MariaDB server] ************************************************
changed: [vm4]

PLAY [logservers] *********************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm5]

TASK [configure rsyslog remote log reception over udp] ********************************
changed: [vm5] => (item=$ModLoad imudp)
changed: [vm5] => (item=$UDPServerRun 514)

TASK [open firewall port] *************************************************************
changed: [vm5]

RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm5]

PLAY [lamp] ***************************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm3]
ok: [vm2]
ok: [vm4]

TASK [configure rsyslog] **************************************************************
changed: [vm2]
changed: [vm3]
changed: [vm4]

RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm3]
changed: [vm2]
changed: [vm4]

PLAY RECAP ****************************************************************************
vm2                        : ok=11 changed=9 unreachable=0    failed=0 
vm3                        : ok=11 changed=9 unreachable=0    failed=0 
vm4                        : ok=6 changed=4 unreachable=0    failed=0 
vm5                        : ok=4 changed=3 unreachable=0    failed=0 

Ya está listo.

Puede comprobar los hosts de webserver con este comando:

[curtis@vm1 ~]$ curl http://vm2
Welcome to vm2 on 192.168.102.212
[curtis@vm1 ~]$ curl http://vm3
Welcome to vm3 on 192.168.102.213 

Y puede probar el registro remoto usando el comando de registro en los hosts de webservers y dbservers:

[curtis@vm1 ~]$ ansible lamp -m command -a 'logger hurray it works'
vm3 | SUCCESS | rc=0 >>

vm4 | SUCCESS | rc=0 >>

vm2 | SUCCESS | rc=0 >>

Confirmación en el servidor de registro central:

[curtis@vm1 ~]$ ansible logservers -m command -a "grep 'hurray it works$' /var/log/messages" -b
vm5 | SUCCESS | rc=0 >>
Jan 30 13:28:29 vm3 curtis: hurray it works
Jan 30 13:28:29 vm2 curtis: hurray it works
Jan 30 13:28:29 vm4 curtis: hurray it works

Recomendaciones y consejos

Si recién se está familiarizando con YAML, la sintaxis puede resultarle confusa, sobre todo el espaciado (sin tabulaciones).

Antes de ejecutar un playbook, puede verificar la sintaxis utilizando:

$ ansible-playbook --syntax-check myplaybook.yml 

El editor vim con la sintaxis resaltada es útil para aprender YAML y detectar los problemas en la sintaxis. Una forma rápida de habilitarlo es agregar la siguiente línea al archivo ~/.vimrc:

autocmd Filetype yaml setlocal tabstop=2 ai colorcolumn=1,3,5,7,9,80

Aquí encontrará un complemento para obtener más funciones, como los esquemas de color.
Si prefiere utilizar emacs en lugar de vim, habilite el repositorio EPEL e instale el paquete emacs-yaml-mode.

Puede probar un playbook sin modificar los hosts de destino:

$ ansible-playbook --check myplaybook.yml 

También puede resultarle útil ejecutar el playbook paso a paso:

$ ansible-playbook --step myplaybook.yml 

De manera similar a los scripts de shell, puede establecer que el playbook de Ansible sea ejecutable y agregar lo siguiente al comienzo del archivo:

#!/bin/ansible-playbook 

Para ejecutar los comandos específicos de shell arbitrarios, utilice el módulo de comando (que es el predeterminado si no se especifica -m). Si necesita usar el redireccionamiento, los canales, etc., opte por el módulo de shell.

Consulte la sección "EXAMPLES:" en la documentación de un módulo en particular para agilizar la escritura de los playbooks.

Utilice las comillas en las cadenas de los playbooks para evitar problemas con los caracteres especiales.

El registro está desactivado de forma predeterminada, pero puede habilitarlo utilizando el parámetro log_path en el archivo de configuración de Ansible.

Espero que esta publicación haya esclarecido el funcionamiento de Ansible y sus ventajas en cuanto al ahorro de tiempo y esfuerzo mediante el uso de los playbooks para documentar y repetir las tareas cotidianas con facilidad y precisión. Obtenga más información en http://docs.ansible.com y https://www.redhat.com/es/technologies/management/ansible.

Ya puede comenzar a automatizar los procesos.

Curtis Rempel, RHCA, es Technical Account Manager (TAM) sénior y el líder del equipo en Canadá, que además contaba con la certificación Red Hat Certified Instructor and Examiner (RHCI/RHCX). Su trayectoria con Linux comenzó en 1994 con un CD de Red Hat Linux 2.1 de Jon "maddog" Hall. En su trabajo como TAM, ha ayudado a los clientes empresariales en los sectores financiero, de telecomunicaciones y de aerolíneas con su experiencia en automatización, kernel y almacenamiento. Obtenga más información sobre Curtis.

Los profesionales con el título de Red Hat Technical Account Manager (TAM) son especialistas en el producto que trabajan en conjunto con las empresas de TI para planificar de forma estratégica las implementaciones exitosas y para optimizar el rendimiento y el crecimiento. Los TAM forman parte del grupo internacional Customer Experience and Engagement de Red Hat y ofrecen orientación y recomendaciones preventivas para que usted pueda identificar y abordar los problemas posibles antes de que ocurran. En caso de que se produzca un inconveniente, el TAM se hará cargo del asunto y convocará a los mejores recursos para resolverlo tan pronto como sea posible, con una interrupción mínima de sus actividades comerciales.

Póngase en contacto con los TAM en el evento Red Hat Convergence más cercano. Se trata de un evento gratuito con invitación que les ofrece a los usuarios técnicos la oportunidad para profundizar el conocimiento sobre los productos de Red Hat y descubrir nuevas formas de aplicar la tecnología de open source para lograr los objetivos empresariales. Estas convocatorias se realizan en distintas ciudades del mundo para brindar una experiencia local y cómoda de un día, donde podrá aprender conceptos nuevos y conocer a los especialistas de Red Hat y los colegas del sector.

El enfoque open source se basa en la curiosidad colaborativa. Participe en la Red Hat Summit del 8 al 10 de mayo en San Francisco para conocer a los TAM y otros especialistas de Red Hat en persona. Regístrese ahora por solo USD 1100 con el código CEE18.

Red Hat Cloud Success le ofrece la experiencia, la orientación y el soporte para los productos que le permitirán simplificar la transformación de la TI y agilizar la adopción de las tecnologías de nube. Desde la prueba de los conceptos hasta la producción, contará con la asistencia de un especialista técnico de la nube para garantizar la uniformidad y la implementación exitosa de la solución. La participación de tiempo limitado en Red Hat Cloud Success le permitirá planificar e implementar con eficacia las soluciones de la nube, además de prepararse de forma estratégica para el futuro.