Objetivo del capítulo y requisitos

Ansible ya está instalado y sus servidores están preparados para aceptar conexiones SSH con el sistema de claves. Ahora es el momento de empezar a administrar sus máquinas.

1. Contexto y requisitos

A partir de ahora, Ansible ya estará instalado y disponible en el contexto del usuario. Los intercambios de claves ya se han realizado con los servidores remotos.

2. Archivos para descargar

Puede encontrar los ejemplos de los directorios inventarios y variables en el archivo comprimido capitulo-02.tar.gz que se encuentra en la página del libro en el sitio de Ediciones ENI.

Ansible en modo ad hoc

Ansible está disponible y listo para hacer los primeros tests. El modo que verá primero es el modo en el que la operación debe especificarse individualmente, llamado ad hoc.

Este modo viene muy bien para asegurarse de que la comunicación es operativa o para realizar operaciones simples, como por ejemplo la creación de un directorio o de un usuario.

1. Creación de un archivo de inventario

Sin embargo, antes de empezar con el lanzamiento de Ansible en las máquinas, hay que crear un archivo de inventario que incluirá las máquinas que se querrá administrar. Este archivo se puede escribir en distintos formatos como, por ejemplo:

formato INI
formato YAML

El formato INI es el formato histórico de los inventarios Ansible. En los inventarios escritos bajo ese formato, cada máquina ocupa una línea. Esas máquinas también pueden agruparse en secciones. Estos aspectos se verán un poco más tarde.

En los inventarios bajo formato YAML, las máquinas se agrupan en estructuras específicas que también se verán más tarde en el capítulo de presentación del formato YAML.

Para empezar, cree un archivo rec-apache.inv (se encuentra disponible en los archivos del ejercicio). Éste contendrá una única línea con el nombre de la máquina rec-apache-1. Además del nombre de la máquina, añada la declaración ansible_user=root (en la misma línea). Así indicará que la conexión a la máquina se hará con el usuario root. He aquí el contenido del archivo:

rec-apache-1 ansible_user=root

Si ha hecho el intercambio de clave con otro usuario que no sea root, cámbielo por el que ha utilizado.

Para comprobar que la comunicación funciona correctamente, puede ejecutar el comando ansible con las siguientes opciones:

el módulo ping (-m ping);
el archivo inventario (-i rec-apache-1.inv);
el grupo donde quiere trabajar (aquí all para seleccionar todas las máquinas).

He aquí el comando correspondiente:

$ ansible -i rec-apache-1.inv -m ping all

Si la comunicación funciona correctamente, debería ver el mensaje siguiente:

rec-apache-1 | SUCCESS => { 
   "changed": false, 
   "ping":...

Las otras herramientas de Ansible: playbook y doc

Hasta ahora, usted ha utilizado Ansible principalmente en modo ad hoc para comprobar la comunicación con sus servidores remotos (módulo setup y ping) y también para modificar el contenido de un archivo (lineinfile).

Ahora verá que existen distintas herramientas que pueden ser utilizadas con Ansible. El modo playbook será el que se va a utilizar. También existe la herramienta ansible-doc que se presentará más adelante.

Esta última ofrece la posibilidad de consultar la documentación de diferentes módulos sin tener que conectarse al sitio oficial de Ansible a través de Internet.

Vuelva a la máquina de test apache rec-apache-1. Puesto que consigue comunicar con esta máquina y realizar una escalada de privilegios root, va a realizar las operaciones siguientes:

instalación del paquete apache;
activación e inicio del servicio apache;
copiar un archivo en la raíz del servidor.

Esta máquina está basada en una distribución cuya herramienta de gestión de paquetes es RPM (Red Hat, Fedora o CentOS). En esos casos, se tiene que llamar al módulo yum para proceder a la instalación (en el caso de una distribución derivada de Debian, hubiera sido el módulo apt). Va a utilizar como argumento el nombre del paquete que quiera instalar...

Algunas nociones sobre el formato YAML

Antes de seguir profundizando en el descubrimiento de Ansible, hay que conocer algunas nociones sobre el formato YAML. En efecto, es el formato usado por Ansible por muchas razones:

los archivos de variables (nombre de usuario, contraseña, etc.);
la descripción de las operaciones que realizarán (especialmente con los playbooks);
los inventarios y la configuración de Ansible (desde la versión 2.4).

Esencialmente, YAML permite escribir estructuras de datos. Estos datos se pueden especificar en forma de listas o de diccionarios. Este lenguaje también propone muchas maneras de escribir las estructuras en función de lo que usted quiera resaltar: legibilidad o compactibilidad de su descripción (aunque generalmente hay que privilegiar la legibilidad).

Hay que tener en cuenta que el formato JSON permite el mismo tipo de almacenamiento (Ansible lo acepta también). Estos dos lenguajes comparten muchas características comunes ya que YAML es una extensión del lenguaje JSON. La diferencia principal entre JSON y la notación YAML reside, sobre todo, en la legibilidad.

1. Declaración de variables simples

El lenguaje YAML sirve para declarar variables. Por defecto, no hay ninguna limitación con respecto al nombre de las variables excepto que tiene que haber un nombre seguido de dos puntos (:) seguido de un espacio (‘ ‘). Por otro lado, Ansible no acepta cualquier declaración. Un nombre de variable válido deberá estar compuesto, obligatoriamente, por una cadena de caracteres alfanuméricos y/o de guiones bajos (_). El primer carácter siempre tendrá que empezar por una letra o por un guion bajo:

ejemplo de variable válida para Ansible: _42, var1, a_b;
ejemplo de variable válida para YAML, pero inutilizable para...

Introducción a la noción de playbook

Esta parte del capítulo está dedicada a la reescritura de la instalación de Apache que se vio anteriormente. Los cuatro comandos que se tenían que ejecutar eran relativamente complejos:

Utilización de opciones de seguridad.
Opciones largas y numerosas para hacer funcionar los módulos (uso de las comillas para las opciones y separación usando espacios).
Encadenamiento manual de los comandos.

Todas estas prácticas van en contra de la creación de procedimientos simples y rápidos fácilmente reutilizables. Se presenta otro problema, estos aspectos no son implícitos aunque sería interesante almacenarlos en algún sitio (Git por ejemplo).

Ahí es donde la noción de playbook interviene para dar respuesta a esta situación.

Un playbook es un archivo en formato YAML. Este va a dar una lista de instrucciones. Estas instrucciones se envían a Ansible en el mismo orden de su declaración. La ventaja con respecto al modo ad hoc es que todo estará descrito en un archivo, incluso el encadenamiento de las operaciones.

1. Estructura de un playbook

Un playbook puede contener mucha información, pero la mayoría de las veces solamente necesitará un subconjunto relativamente pequeño de esta información. Aquí abajo encontrará una lista de campos...

Combinación con Git

Ha descubierto la noción de playbook. Antes de seguir avanzando, parece necesario abordar un elemento crucial de este tipo de proyecto: el almacenamiento de los scripts en un depósito de código fuente.

Este capítulo presentará brevemente el uso de Git. Pero tenga en cuenta que esto no es, en ningún caso, una guía completa de Git. Si quiere completar los puntos que se verán aquí, el lector podrá estudiar algunas obras que traten este tema (gestión de las ramas, tags, etc.).

Si usted está acostumbrado a usar un depósito de código fuente (como Subversion, por ejemplo), es posible adaptar estas instrucciones a ese tipo de depósito.

1. Creación del depósito

Si ya posee un depósito Git, puede pasar al capítulo siguiente.

Va a crear una ubicación de almacenamiento Git para su configuración. Esta operación se hace ejecutando el comando git init seguido del directorio donde querrá almacenar el referencial.

En el ejemplo que encontrará a continuación se utilizará el directorio ~/infrastructure-as-a-code:

$ mkdir -p ~/infrastructure-as-a-code 
$ git init ~/infrastructure-as-a-code 
Initialized empty Git repository in /home/yannig/ 
infrastructure-as-a-code/.git/

Aviso: en caso de fallo perderá todo su trabajo si no lo ha guardado en el exterior.

Por eso se recomienda añadir un espacio de almacenamiento remoto. Esta operación se realiza ejecutando git remote add seguido del nombre de la ubicación remota (generalmente origin) seguido de la URL de la ubicación remota (ejemplo: http://servidor-git/repos/iaac).

Una vez añadido el espacio de almacenamiento, se puede consultar con el comando git remote -v. Aquí encontrará un ejemplo de adición de una fuente externa con comprobación de la definición:

$ cd ~/infrastructure-as-a-code 
$ git remote add origin  http://servidor-git/repos/iaac 
$ git remote -v 
origin  http://servidor-git/repos/iaac (fetch) 
origin  http://servidor-git/repos/iaac (push)

2. Comandos básicos

a. Obtención de un depósito Git

Si posee un depósito Git, puede descargar su contenido. En Git se habla de clonado de un depósito (comando git clone seguido...

Uso de Ansible