Examen_RH294

Capítulo 1 Presentación de Ansible

Ansible es una plataforma de automatización de código abierto. Es un lenguaje
de automatización simple que puede describir perfectamente una
infraestructura de aplicaciones de TI en Ansible Playbooks. También es un
motor de automatización que ejecuta Ansible Playbooks.
Las guías ejecutan tareas en orden.
Ansible tiene varios puntos fuertes importantes:
• Compatible con diversas plataformas: Ansible proporciona soporte
sin agentes para Linux, Windows, UNIX y dispositivos de red, en
entornos físicos, virtuales, de nube y en contenedores.
• Automatización legible por el ojo humano: Las Ansible Playbooks,
escritas como archivos de texto YAML, son fáciles de leer y
permiten garantizar que todos entiendan lo que harán.
• Perfecta descripción de aplicaciones: Las guías de Ansible pueden
realizar todas las modificaciones, y se pueden describir y
documentar todos los aspectos de su entorno de aplicaciones.
• Fácil de administrar en el control de versiones: Las guías de
Ansible y los proyectos son texto sin formato. Puede considerarse
código fuente y colocarse en su sistema de control de versiones
existente.
• Compatibilidad con inventarios dinámicos: La lista de máquinas
que administra Ansible puede actualizarse de forma dinámica desde
fuentes externas para capturar la lista actual y correcta de todos los
servidores administrados todo el tiempo, independientemente de la
infraestructura o la ubicación.
• Orquestación que se integra fácilmente con otros sistemas: HP SA,
Puppet, Jenkins, Red Hat Satellite y otros sistemas que existen en
su entorno pueden aprovecharse e integrarse en su flujo de trabajo
de Ansible.
Conceptos y arquitectura de Ansible
nodos de control: esta máquina también tiene copias de sus
archivos de proyecto de Ansible. Un nodo de control podría ser un
portátil de administrador, un sistema compartido por varios
administradores o un servidor que ejecuta Red Hat AnsibleTower.
 Los hosts administrados aparecen en un inventario, que también
organiza estos sistemas en grupos para una administración
colectiva más sencilla. El inventario puede definirse en un archivo
de texto estático, o se puede determinar de forma dinámica
mediante scripts que obtienen información de fuentes externas.
Capítulo 2 Implementación de una guía de
reproducción Ansible
Definición de inventario
Un inventario define un conjunto de hosts que Ansible administrará. Estos
hosts también puedenser asignados a grupos, que pueden ser gestionados
colectivamente. Los grupos pueden contener grupos secundarios, y los hosts
pueden ser miembros de múltiples grupos. El inventario también puede
establecer variables que se apliquen a los hosts y grupos que define.
Los inventarios de host se pueden definir de dos maneras diferentes. Un
inventario de hosts estático puede definirse por un archivo de texto. Un
inventario de hosts dinámico puede estar generado por un script u otro
programa, según sea necesario, mediante proveedores de información
externos.
Especificación de hosts administrados con un inventario estático
Un archivo de inventario estático es un archivo de texto que especifica los
hosts administrados a los que apunta Ansible. Puede escribir este archivo
usando varios formatos diferentes, incluido un estilo INI o YAML. El formato
estilo INI es muy común y se usará para la mayoría de los ejemplos en este
curso.
En su forma más simple, un archivo de inventario estático estilo INI es una lista
de nombres de host o direcciones IP de hosts administrados, cada uno en una
línea única:

Los grupos de hosts le permiten ejecutar Ansible de manera más efectiva en

comparación con un conjunto de sistemas.
 Existen siempre dos grupos de hosts:
• El grupo de hosts all contiene todos los hosts detallados de manera
explícita en el inventario.
• El grupo de hosts ungrouped contiene todos los hosts detallados de
manera explícita en el inventario que no son miembros de ningún otro
grupo.
Definición de grupos anidados
Esto se logra creando un nombre de grupo de host con el sufijo :children.

Simplificación de las especificaciones de hosts con rangos

Puede especificar rangos en los nombres de hosts o direcciones IP para
simplificar inventarios de hosts de Ansible. Puede especificar rangos
 numéricos o alfabéticos. Los rangos tienen la siguiente sintaxis:

Verificación del inventario

Reemplazo de la ubicación del inventario

El archivo /etc/ansible/hosts se considera el archivo de inventario estático
predeterminado del sistema. Sin embargo, la práctica habitual es no utilizar
ese archivo, sino definir una ubicación diferente para los archivos de inventario
en su archivo de configuración de Ansible.
Descripción de un inventario dinámico
 La información de inventario de Ansible también puede generarse de forma
dinámica con la información provista por bases de datos externas. La
comunidad de código abierto ha escrito varios scripts de inventario dinámicos
que están disponibles desde el proyecto upstream de Ansible. Si estos scripts
no satisfacen sus necesidades, también puede escribir sus propios scripts.

Administración de archivos de configuración de Ansible

Una opción más flexible es definir la ubicación del archivo de configuración

con la variable de entorno ANSIBLE_CONFIG. Cuando esta variable está
definida, Ansible usa el archivo de configuración que especifica la variable en
lugar de alguno de los archivos de configuración mencionados anteriormente.
Precedencia de archivos de configuración
Los archivos especificados por la variable de entorno ANSIBLE_CONFIG
reemplazan todos los demás archivos de configuración. Si no se establece esa
variable, a continuación, se verifica el directorio en el que se ejecutó el
comando ansible en busca de un archivo ansible.cfg. Si ese archivo no está
presente, el directorio principal del usuario se verifica en busca de un archivo
.ansible.cfg. El archivo /etc/ansible/ansible.cfg global se usa únicamente si no
se encuentra ningún otro archivo de configuración. Si el archivo de
configuración /etc/ansible/ansible.cfg no está presente, Ansible usa los valores
predeterminados que contiene.
Administración de parámetros en el archivo de configuración
•[defaults] establece valores predeterminados para la operación de Ansible
• [privilege_escalation] configura el modo en que Ansible realiza la escalación de
privilegios en hosts administrados
Configuración de conexiones
• La ubicación del inventario que muestra los hosts y grupos de hosts
administrados.
• Qué protocolo de conexión se debe usar para comunicarse con los hosts
administrados (de forma predeterminada, SSH), y si se necesita un puerto de
red no estándar para conectarse con el servidor.
• Qué usuario remoto se debe usar en los hosts administrados; este podría ser
root o podría ser un usuario sin privilegios.
• Si el usuario remoto no tiene privilegios, Ansible debe saber si debe intentar
escalar los privilegios a root y cómo hacerlo (por ejemplo, mediante el uso de
sudo).
• Si se debe solicitar o no una contraseña SSH o una contraseña sudo para
iniciar sesión u obtener privilegios.

También puede usar una guía de Ansible para implementar su clave pública en
la cuenta remote_user en todos los hosts administrados con el módulo
authorized_key.

Por motivos de seguridad y auditoría, Ansible puede tener que conectarse a

hosts remotos como un usuario sin privilegios antes de escalar privilegios para
obtener acceso administrativo como root. Esto se puede configurar en la
sección [privilege_escalation] del archivo de configuración de Ansible.
Conexiones no SSH
puede querer que todos sus hosts administrados de Microsoft Windows utilicen el
protocolo winrm y el puerto 5986 para las conexiones. Para configurar esto, puede
colocar todos los hosts administrados en el grupo windowsy, luego, crear un archivo
denominado group_vars/windows que contenga las   siguientes líneas:

Ejecución de comandos ad hoc

Uno de los comandos ad hoc más simples usa el módulo ping. Este módulo no
realiza un ping ICMP, sino que verifica para ver si lpuede ejecutar os módulos
basados en Python en hosts administrados.
Puede encontrar la lista de argumentos disponibles para un módulo en la
documentación del módulo. Los comandos ad hoc pasan argumentos a los
módulos con la opción -a. Cuando no se necesite ningún argumento, omita la
opción -a del comando ad hoc
 Use la opción -o para mostrar la salida de los comandos ad hoc de
Ansible en un formato de una sola línea.

El módulo command permite a los administradores ejecutar rápidamente

comandos remotos en hosts administrados.

Configuración de conexiones para comandos ad hoc   

Escritura y ejecución de guías
Si usa el editor de texto vi, puede aplicar algunos parámetros que pueden
facilitar la edición de sus guías de reproducción. Por ejemplo, puede agregar la
siguiente línea a su archivo $HOME/.vimrc y, si vi detecta que usted está
editando un archivo YAML, realiza una sangría de dos espacios cuando
presiona la tecla Tab y realiza una sangría automática de las líneas posteriores.

Formato Playbook.yml
Ejecución de guías
 Verificación de la sintaxis

Ejecución de un simulacro
Puede usar la opción -C para realizar un simulacro de la ejecución de la guía de
reproducción. Esto hace que Ansible reporte los cambios que habrían ocurrido si se
hubiese ejecutado la guía, aunque  no realiza ningún cambio real a los hosts
administrados.
Implementación de varias reproducciones
El siguiente ejemplo muestra una guía simple con dos reproducciones.
 Usuarios remotos y aumento de privilegios en las reproducciones

La palabra clave booleana become se puede usar para habilitar o deshabilitar el aumento
de privilegios, independientemente de cómo se define en el archivo de configuración
Ansible. Puede seleccionar yes (sí) o true (verdadero) para habilitar el aumento de
privilegios, o no o false (falso) para deshabilitarlo.

Si se habilita el aumento de privilegios, la palabra clave become_method se puede utilizar

para definir el método de aumento de privilegios para usar durante una reproducción
específica. En el siguiente ejemplo, se especifica que se use sudo para el aumento de
privilegios.

la palabra clave become_user puede definir la cuenta del usuario que debe usarse para el
aumento de privilegios dentro del contexto de una reproducción específica.

Documentación de módulos
Mantenimiento de módulos
Ansible se proporciona con una gran cantidad de módulos que pueden usarse para
muchas tareas.
 Ansible también busca módulos personalizados en el directorio ./library,
relacionados con la guía de reproducción que se está ejecutando actualmente.

Comentarios en YAML

Cadenas en YAML
 Existen dos formas de escribir cadenas de líneas múltiples. Puede usar el carácter
de barra vertical (|) para denotar que deben preservarse los caracteres de nueva
línea dentro de una cadena.

También puede escribir cadenas de líneas múltiples usando el carácter mayor que
(>) para indicar que los caracteres de nueva línea se deben convertir a espacios y
que se deben quitar los espacios en blanco en las líneas.

Listas en YAML

Abreviatura de guía de clave=valor obsoleto

capítulo 3 Administración de variables y
hechosGestión de variables
Las variables brindan una forma conveniente de gestionar los valores dinámicos
para un entorno dado en su proyecto Ansible. Los ejemplos de valores que pueden
contener las variables incluyen:
• Usuarios para crear
• Paquetes para instalar
• Servicios para reiniciar
• Archivos para eliminar
• Colección de archivos para recuperar de Internet

Definición de variables
Puede establecer una variable que afecte a un grupo de hosts o solo a hosts
individuales. También puede establecer variables adicionales en la línea de
 comandos ansible-playbook con la opción --extra-vars o -e y especificar esas
variables, que anulan todos los demás valores para ese nombre de variable.
• Variables de grupo definidas en el inventario.
• Agrupar variables definidas en archivos en un subdirectorio group_vars en el
mismo directorio
que el inventario o la guía de reproducción.
• Variables de host definidas en el inventario.
• Variables de host definidas en archivos en un subdirectorio host_vars en el
mismo directorio
que el inventario o la guía de reproducción.
• Datos del host, descubiertos en tiempo de ejecución.
• Reproducir variables en la guía de reproducción (vars y vars_files).
• Variables de tareas.
• Variables adicionales definidas en la línea de comandos.
Variables en guías

Uso de variables en guías

 Cuando se utiliza una variable como el primer elemento para iniciar un valor, las
comillas son obligatorias. De esta manera, se evita que Ansible interprete que la
referencia de la variable inicia un diccionario YAML. Si faltan las comillas, aparece el
siguiente mensaje:

Variables de hosts y variables de grupos

• Definición de la variable de host ansible_user para demo.example.com:

• Definición de la variable de grupo user para el grupo de hosts servers.

• Definición de la variable de grupo user para el grupo servers, que consta de dos
grupos de hosts, cada uno con dos servidores.
Uso de directorios para completar variables de host y de grupo
Para definir variables de grupo para el grupo servers, debería crear un archivo YAML
denominado group_vars/servers y, luego, el contenido de ese archivo establecería
variables para valores con la misma sintaxis que en una guía de reproducción:

• Si se debe definir un valor general para todos los servidores en los dos centros de
datos, se puede establecer una variable de grupo para el grupo de hosts datacenters:
 • Si el valor a definir varía para cada centro de datos, establezca una variable de grupo
para cada grupo de hosts del centro de datos:

• Si el valor por definir varía para cada host en cada centro de datos, se deben definir las
variables en archivos de variables de host diferentes:

Si la estructura de directorios para el proyecto de ejemplo, project, contuviera todos los

archivos de ejemplo anteriores, se mostraría de la siguiente manera:

Reemplazo de las variables de la línea de comandos

Uso de matrices como variables
En lugar de asignar datos de configuración que se relacionen con el mismo elemento (una
lista de paquetes, una lista de servicios, una lista de usuarios, etc.) con múltiples
variables, los administradores pueden usar matrices. Una consecuencia de esto es que
un arreglo se puede examinar.

|. |
|  |
      \        /

|    |
|    |
  \.              /                                                O
 Captura de salida de comando con variables registradas
Puede usar la declaración register para capturar la salida de un comando. El resultado se guarda en una
variable temporal que puede utilizarse posteriormente en la guía con motivos de depuración u otros
motivos, como una configuración particular basada en el resultado de un comando.

Ejemplo:
 Gestión de secretos
Creación de un archivo cifrado
Para crear un nuevo archivo cifrado, use el comando ansible-vault create filename.
El comando le solicitará la nueva contraseña de Vault y abrirá un archivo con el editor predeterminado, vi.

En lugar de ingresar la contraseña de Vault mediante el ingreso estándar, se puede usar un archivo de
contraseña de Vault para almacenar la contraseña. Este archivo se deberá proteger cuidadosamente
mediante permisos de archivo y por otros medios.

El código usado para proteger archivos es AES256 en las versiones recientes de Ansible, pero los
archivos cifrados con versiones anteriores aún pueden utilizar AES de 128 bits.
Edición de un archivo cifrado existente

Cifrado de un archivo existente

Use la opción --output=OUTPUT_FILE para guardar el archivo cifrado con un nombre nuevo Solo puede
usar un archivo de entrada con la opción --output.
Descifrado de un archivo existente

Cambio de contraseña de un archivo cifrado

Al usar un archivo de contraseña de Vault, use la opción --new-vault-password-file:

Guías y Ansible Vault

O bien, puede usar la opción --vault-password-file para especificar un archivo que almacene la
contraseña de cifrado en texto sin formato. La contraseña debe ser una cadena

Para simplificar la administración, tiene sentido configurar su proyecto de Ansible, de modo que las
variables confidenciales y todas las demás variables se guarden en archivos separados.
Los archivos que contienen las variables confidenciales se pueden proteger con el comando ansible-vault.
Sin embargo, en lugar de usar archivos en group_vars o host_vars, puede usar directorios para cada
grupo de hosts o host administrado. Aquellos directorios pueden contener varios archivos de variables,
que son usados por el grupo de hosts o el host administrado.
 Gestión de datos
Los datos de Ansible son variables detectadas automáticamente por Ansible en un host administrado. Los
datos contienen información específica del host que puede usarse como variables regulares en
reproducciones, condicionales, bucles o cualquier otra declaración que dependa de un valor recopilado
de un host administrado.
Algunos de los datos recopilados para un host administrado pueden incluir los siguientes:
• El nombre del host
• La versión del kernel
• Las interfaces de red
• Las direcciones IP
• La versión del sistema operativo
• Diferentes variables de entorno
• La cantidad de CPU
• La memoria disponible o libre
• El espacio de disco disponible
Esto se informa como la tarea Gathering Facts
Cuando un dato se usa en una guía, Ansible sustituye de manera dinámica el nombre de la variable para
el dato con el valor correspondiente:

Datos de Ansible inyectados como variables

los datos se inyectaban como variables individuales prefijadas con la  cadena ansible_ en lugar de ser
parte de la variable ansible_facts.
Puede utilizar un comando ad hoc para ejecutar el módulo setup para imprimir el valor de todos los datos
en este formulario.
 Desactivación de la recopilación de datos
Puede ser que no esté usando los datos y desee acelerar la reproducción o reducir la carga provocada
por la reproducción en los hosts administrados. Puede ser que los   hosts administrados no puedan
ejecutar el módulo setup por algún motivo, o deba instalar algún software de requisito previo antes de
recopilar datos.

Creación de datos personalizados

Los datos personalizados permiten a los administradores definir determinados valores para hosts
administrados, qué reproducciones pueden usar para completar archivos de configuración o ejecutar
tareas de forma condicional. Los datos personalizados dinámicos permiten que los valores para estos
datos se determinen de manera programática, o incluso qué datos se suministran, cuando se ejecuta la
reproducción.
De forma predeterminada, el módulo setup carga datos personalizados de archivos y scripts en el
directorio /etc/ansible/facts.d de cada host administrado.
Este es un ejemplo de un archivo de datos personalizados estáticos escrito en formato INI.

Los mismos datos podrían proveerse en formato JSON.

Puede inspeccionar la estructura de sus datos personalizados mediante la ejecución del módulo setup en
los hosts administrados con un comando ad hoc.

Los datos personalizados pueden usarse de la misma manera que los datos predeterminados en las guías:
 Uso de variables mágicas
A continuación, se detallan cuatro de las más útiles:
hostvars
Contiene las variables para hosts administrados y puede usarse para obtener los valores
para
las variables de otro host administrado. No incluye los datos del host administrado si no
se
recopilaron aún para ese host.
group_names
Enumera todos los grupos en los que se encuentra el host administrado actual.
groups
Enumera todos los grupos y hosts en el inventario.
inventory_hostname
Contiene el nombre de host para el host administrado actual, según se configuró en el
inventario. Este puede ser diferente del nombre de host informado por los datos por
diversos motivos.
capítulo 4 Implementación del control de
tareas
Escritura de bucles y tareas condicionales       
El uso de bucles elimina la necesidad de los administradores de escribir varias tareas que usen el mismo
módulo.
Bucles simples
Un bucle simple itera una tarea sobre una lista de elementos. Se agrega la palabra clave loop a la tarea, y
esta toma como valor la lista de elementos sobre los cuales se debería iterar la tarea. La variable de bucle
item contiene el valor usado durante cada iteración.
 |.   |

Bucles sobre una lista de hashes o diccionarios

La lista loop no necesita ser una lista de valores simples. En el siguiente ejemplo, cada elemento de la
lista es en realidad un hash o diccionario. Cada diccionario o hash en el ejemplo tiene dos claves, name y
groups, y el valor de cada clave en la variable de bucle item actual puede obtenerse con las variables
item.name e item.groups, respectivamente.
Palabras clave de bucle del estilo anterior
 Uso de variables de registro con bucles
La palabra clave register también puede capturar la salida de una tarea que realiza un bucle.
A continuación, la guía se modifica de modo que la segunda tarea itera en esta lista:

Ejecución de tareas de forma condicional

Los condicionales permiten que los administradores diferencien entre hosts administrados y les asignen
roles funcionales según las condiciones que cumplen. Las variables de la guía, las variables registradas y
los datos de Ansible se pueden probar con condicionales. Los operadores paracomparar cadenas, datos
numéricos y valores booleanos están disponibles.
El enunciado when se usa para ejecutar una tarea de forma condicional. Toma como valor la condición
para realizar pruebas. Si se cumple la condición, se ejecuta la tarea. Si no se cumple la condición, se
omite la tarea.

El siguiente ejemplo es un poco más sofisticado y prueba si la variable my_service tiene un valor.
Realización de pruebas de varias condiciones
 Combinación de bucles y tareas condicionales
Puede combinar los bucles y los condicionales.
El dato ansible_mounts es una lista de diccionarios, cada uno de los cuales representa información
acerca de un sistema de archivos instalado. El bucle realiza la iteración de cada diccionario en la lista, y la
declaración condicional no se cumple, a menos que se determine que un diccionario representa un
sistema de archivos montado en donde ambas condiciones son verdaderas.
 Implementación de manejadores
Los módulos Ansible están diseñados para ser idempotentes. Esto implica que en una guía programada
adecuadamente, la guía y sus tareas se pueden ejecutar múltiples veces sin cambiar el host
administrado, a menos que necesiten realizar un cambio para llevar al host administrado asu estado
deseado.
Los manejadores son tareas que responden a una notificación desencadenada por otras tareas. Las
tareas solo notifican a sus manejadores cuando la tarea cambia algo en un host administrado.
Cada controlador (handler) se activa por su nombre después del bloque de tareas de la guía. Si ninguna
tarea notifica al manejador por nombre, no se ejecutará el manejador. Si una o más tareas notifican al
manejador, el manejador se ejecutará exactamente una vez después de que todas las demás tareas en la
reproducción se hayan completado. Debido a que los manejadores son tareas, los administradores
pueden usar los mismos módulos en manejadores que utilizarían para cualquier otra tarea. Generalmente,
los manejadores se utilizan para reiniciar los hosts y los servicios.
 Descripción de los beneficios del uso de manejadores
• Los manejadores se ejecutan siempre en el orden especificado por la sección handlers de la
reproducción. No se ejecutan en el orden en que aparecen en la lista por la declaración notify en una
tarea ni en el orden en que las tareas los notifican.
• Los manejadores se ejecutan después de que se hayan completado todas las demás tareas en la
reproducción. Un manejador invocado por una tarea en la parte tasks de la guía no se ejecutará hasta que
se hayan procesado todas las tareas en tasks. (Hay algunas excepciones menores a esto).
• Los nombres de los manejadores se encuentran en un espacio de nombres por reproducción. Si
erróneamente se asigna a dos manejadores el mismo nombre, se ejecutará uno solo.
• Inclusive si más de una tarea notifica a un manejador, este se ejecuta una sola vez. Si ninguna tarea lo
notifica, no se ejecutará el manejador.
• Si una tarea que incluye una declaración notify no informa un resultado changed (por ejemplo, un
paquete ya se encuentra instalado y la tarea muestra ok), no se notificará al manejador. Se omitirá el
manejador, a menos que otra tarea lo notifique. Ansible notifica a los manejadores solo si la tarea muestra
el estado CHANGED.

Los manejadores están diseñados para realizar una acción adicional cuando una tarea realiza un cambio
en un host administrado. No deben usarse como sustituto de las tareas normales.
Gestión de errores de tareas en reproducciones
Ansible evalúa los códigos de retorno de cada tarea para determinar si una tarea se realizó
satisfactoriamente o con errores.
Fallas de tareas ignoradas
De forma predeterminada, si una tarea falla, se cancela la reproducción. Sin embargo, el comportamiento
puede anularse si se ignoran las tareas fallidas. Puede usar la palabra clave ignore_errors en una tarea
para lograr esto.

Forzado de la ejecución de manejadores después de la falla de una

tarea
Si establece la palabra clave force_handlers: yes en la reproducción, se llama a los manejadores
notificados incluso si se canceló la reproducción porque falló una tarea posterior.
 Especificación de las condiciones de falla de tareas
Puede usar la palabra clave failed_when en una tarea para especificar las condiciones que indican que la
tarea falló.

El módulo fail también se puede utilizar para forzar una falla de tarea.
 Especificación cuando una tarea informa resultados "changed"
Cuando una tarea realiza un cambio a un host administrado, informa el estado changed y notifica a los
manejadores. Cuando una tarea no necesita realizar un cambio, informa ok y no notifica a los
manejadores.
La palabra clave changed_when puede usarse para contr
olar cuando una tarea informa que se ha modificado.

El siguiente ejemplo usa el módulo shell que informa changed (modificado) según la salida del módulo
recopilada por una variable registrada:

Bloques Ansible y manejo de errores

En las guías, los blocks (bloques) son cláusulas que agrupan tareas de forma lógica, y se pueden usar
para controlar cómo se ejecutan las tareas.

• block: define las tareas principales para ejecutar.

• rescue: define las tareas que se ejecutarán si fallan las tareas definidas en la cláusula
block.
• always: define las tareas que se ejecutarán siempre, independientemente del éxito o de
la falla de las tareas definidas en las cláusulas block y rescue.
Inclusive si las tareas definidas en la cláusula block fallan, se ejecutan las tareas definidas en las
cláusulas rescue y always.
capítulo 5 Implementación de archivos en
hosts administrados
Modificación y copia de archivos a hosts
La librería de módulos Files incluye módulos que permiten realizar la mayoría de las tareas relacionadas
con la administración de archivos de Linux, como crear, copiar, editar y modificar permisos y otros
atributos de archivos.
Garantía de que exista un archivo en los hosts administrados
 Modificación de los atributos del archivo

Realización de los cambios de contexto del archivo SELinux como

persistentes

Copia y edición de archivos en hosts administrados

De forma predeterminada, este módulo supone que force: yes está configurado. Eso obliga al módulo a
sobrescribir el archivo remoto si existe, pero tiene un contenido diferente del archivo que se está
copiando. Si se configura force: no, solo copia el archivo al host administrado si no existe.
Para recuperar archivos de hosts administrados, use el módulo fetch. Esto puede usarse para recuperar
un archivo como una clave pública SSH de un sistema de referencia antes de distribuirlo a otros hosts
administrados.

Para asegurarse de que existe una línea de texto específica en un archivo existente, use el módulo
lineinfile:

Para agregar un bloque de texto a un archivo existente, use el módulo blockinfile:

Al usar el módulo blockinfile, los marcadores de bloque comentados se insertan al principio y al final del
bloque para garantizar la idempotencia.
 Eliminación de un archivo de los hosts administrados
Un ejemplo básico para eliminar un archivo de los hosts administrados es usar el módulo file con el
parámetro state: absent. El parámetro state es opcional para muchos módulos. Siempre debe aclarar si
desea state: present o state: absent por varias razones.

Recuperación del estado de un archivo en hosts administrados

El módulo stat recupera datos para un archivo, de manera similar al comando stat de Linux.
El módulo stat devuelve un diccionario de hash de los valores que contienen datos de estado del archivo,
lo que le permite referirse a partes individuales de información mediante variables separadas.
 Sincronización de archivos entre el nodo de control y los hosts
administrados
El módulo synchronize es un contenedor alrededor de la herramienta rsync, que simplifica las tareas
comunes de administración de archivos en sus guías de reproducción. La herramienta rsync debe
instalarse en el host local y remoto. De forma predeterminada, cuando utiliza el módulo synchronize, el
"host local" es el host en el que se origina la tarea de sincronización (por lo general, el nodo de control),
y el "host de destino" es el host al que se conecta synchronize.

Implementación de archivos personalizados con plantillas Jinja2

Una forma mucho más poderosa de administrar archivos es utilizar una plantilla. Con este método, puede
escribir un archivo de configuración de plantilla que se personaliza automáticamente para el host
administrado cuando se implementa el archivo, usando datos y variables de Ansible. Esto puede ser más
fácil de controlar y menos propenso a errores.

Introducción a Jinja2
Ansible usa el sistema de plantillas Jinja2 para los archivos de plantilla.
Uso de delimitadores
Las variables y expresiones lógicas se colocan entre etiquetas, o delimitadores. Por ejemplo, las plantillas
Jinja2 usan {% EXPR %} para expresiones o lógica (por ejemplo, bucles), mientras que {{ EXPR }} se usan
para obtener los resultados de una expresión o una variable al usuario final. La última etiqueta, cuando se
representa, se reemplaza con un valor o con valores y son visibles para el usuario final. Use la sintaxis {#
COMMENT# } para encerrar los comentarios que no deberían aparecer en el archivo final.

Desarrollo de una plantilla Jinja2

En el siguiente ejemplo, se muestra cómo crear una plantilla para /etc/ssh/sshd_config con variables y
datos recuperados por Ansible de los hosts administrados. Cuando la guía asociada se ejecuta, los datos
se reemplazan por sus valores en el host administrado que se está configurando.
 Implementación de plantillas Jinja2
Las plantillas Jinja2 son una herramienta valiosa para personalizar archivos de configuración para ser
implementados en los hosts administrados. Cuando se ha creado la plantilla Jinja2 para un archivo de
configuración, se puede implementar a los hosts administrados usando el módulo template, el cual
soporta la transferencia de un archivo local en el nodo de control a los hosts administrados.
 Administración de archivos con plantillas
Para evitar que los administradores del sistema modifiquen los archivos implementados por Ansible, se
aconseja incluir un comentario en la parte superior de la plantilla para indicar que el archivo no debe
editarse manualmente.
La directiva ansible_managed se establece en el archivo ansible.cfg:

Para incluir la cadena ansible_managed dentro de una plantilla Jinja2, use la siguiente sintaxis:

Estructuras de control
Uso de bucles
Jinja2 usa la instrucción for para proporcionar la funcionalidad de bucles. En el siguiente ejemplo, la
variable user se reemplaza con todos los valores incluidos en la variable users, un valor por línea.

La variable loop.index se expande al número de índice en el que se encuentra actualmente el bucle. Tiene
un valor de 1 la primera vez que se ejecuta el bucle, y se va incrementando de a 1 en cada iteración.
Con la siguiente sentencia for, todos los hosts en el grupo myhosts del inventario se enumeran en el
archivo.

Para un ejemplo más práctico, puede usar esto para generar un archivo /etc/hosts
de datos de host de forma dinámica.
La siguiente plantilla templates/hosts.j2 de tres líneas crea el archivo de todos los hosts del grupo all.  Se
repite en cada host del grupo para obtener tres datos para el archivo /etc/hosts.

Uso de condicionales
Jinja2 usa la instrucción if para proporcionar control condicional. Esto le permite
colocar una línea en un archivo implementado si se cumplen ciertas condiciones.

Filtros de variables
Jinja2 proporciona filtros que cambian el formato de salida de las expresiones de plantillas

Formatean con                                                                  Formatean en                                   

                         Formatean respectivamente

Pruebas de variables
Las pruebas incorporadas de Ansible que se usan para probar los valores recibidos incluyen failed,
changed, succeeded y skipped.
capítulo 6 Administración de reproducciones
y guías complejas
Selección de hosts con patrones de hosts
 Hosts administrados
Cuando se ejecuta la guía, la primera tarea Recopilación de datos debe ejecutarse en todos
los hosts administrados que coincidan con el patrón de host. Un error durante esta tarea
puede hacer que el host administrado se elimine de la reproducción.
Es posible apuntar a un alias en una dirección IP específica en su inventario si establece la
variable de host ansible_host.

Especificar hosts usando un grupo

Cuando el nombre de un grupo se usa como patrón de host, especifica que Ansible actuará
en los hosts que son miembros del grupo.
También hay un grupo especial llamado ungrouped que incluye todos los hosts
administrados en el inventario que no son miembros de ningún otro grupo

Coincidencia con varios hosts con comodines

Otro método de lograr lo mismo que con el patrón del host all es usar el carácter comodín
asterisco (*), que coincide con cualquier cadena.
Del mismo modo, si usa caracteres comodín o de lista especiales en una Ansible Playbook,
debe colocar su patrón de host entre comillas simples para asegurarse de que se analice
correctamente.

Los patrones de host comodín coinciden con todos los nombres de inventario, hosts y
grupos de hosts. No distinguen entre nombres que son nombres de DNS, direcciones IP o
grupos, lo que puede generar ciertas coincidencias inesperadas.

Listas
Se puede hacer referencia a varias entradas en un inventario con listas lógicas. Una lista de
patrones de hosts separados por comas coincide con todos los hosts que coinciden con
cualquiera de esos patrones de hosts.
Si usted proporciona una lista de grupos separados por comas, se apuntará a todos estos
hosts en cualquiera de esos grupos

También puede combinar hosts administrados, grupos de hosts y comodines

Si un elemento en una lista comienza con un carácter &, los hosts deben coincidir con ese
elemento para coincidir con el patrón de host. Funciona de manera similar que un AND
lógico.
Puede excluir hosts que coincidan con un patrón de una lista si usa el signo de exclamación
o carácter "bang" (!) delante del patrón de host. Esto funciona como un NOT lógico.

Gestión de guías grandes- Inclusión e importación de archivos

Cuando una guía se torna larga o compleja, puede dividirla en archivos más pequeños para
que sea más fácil de administrar. Puede combinar varias guías en una guía principal de
manera modular, o insertar listas de tareas de un archivo a una reproducción. Esto puede
facilitar la reutilización de reproducciones o secuencias de tareas en diferentes proyectos.
La palabra clave import_playbook le permite importar archivos externos que contienen listas
de reproducciones en una guía. En otras palabras, puede tener una guía maestra que
importa una o más guías adicionales.
 Importación e inclusión de tareas
Puede importar de forma estática un archivo de tareas en una reproducción dentro de una
guía usando la función import_tasks. Cuando importa un archivo de tareas, las tareas de ese
archivo se insertan directamente cuando se analiza la guía. La ubicación de import_tasks en
los controles de la guía donde se insertan las tareas y el orden en que se ejecutan las
importaciones múltiples.
 • Al usar la función import_tasks, las declaraciones condicionales
establecidas en la importación, como when, se aplican a cada una de las
tareas que se importan.
• No se puede usar bucles con la función import_tasks.
• Si usa una variable para especificar el nombre del archivo por importar,
no puede usar una variable de inventario de host o grupo.
Inclusión de archivos de tareas
También puede incluir de forma dinámica un archivo de tarea en una reproducción dentro de
la guía usando la función include_tasks.

La función include_tasks no procesa el contenido en la guía hasta que se ejecuta la

reproducción y se alcanza esa parte de esta. El orden en el que se procesa el contenido de
la guía afecta el funcionamiento de la función de incluir tareas.
• Al usar la función include_tasks, las declaraciones condicionales, como
when, establecidas determinan si las tareas están incluidas en la reproducción.
• Si ejecuta ansible-playbook --list-tasks para enumerar las tareas de la guía
de
reproducción, no se muestran las tareas en los archivos de tareas incluidos.
Se muestran las tareas que incluyen los archivos de tareas. En comparación, la
función import_tasks no enumera las tareas que importan archivos de tareas,
sino las tareas individuales de los archivos de tareas importados.
• No puede usar ansible-playbook --start-at-task para iniciar la ejecución de la
guía de reproducción desde una tarea que se encuentra en un archivo de
tareas incluido.
• No puede usar una declaración notify para desencadenar un nombre de
controlador que se encuentra en un archivo de tarea incluido. Puede
desencadenar un controlador en la guía principal que incluye un archivo de
tareas completo, en cuyo caso se ejecutarán todas las tareas en el archivo
incluido.
Casos de uso para archivos de tareas
• Si los servidores nuevos requieren una configuración completa, los
administradores pueden crear diferentes conjuntos de tareas para crear
usuarios, instalar paquetes, configurar servicios, configurar privilegios,
configurar el acceso a un sistema de archivos compartido, reforzar los
 servidores, instalar actualizaciones de seguridad e instalar un agente de
monitoreo. Cada uno de estos conjuntos de tareas se puede administrar a
través de un archivo autónomo de tareas separado.
• Si los desarrolladores, administradores de sistema y administradores de
bases de datos gestionan los servidores de manera colectiva, cada
organización puede programar su propio archivo de tareas que el
administrador de sistemas luego puede revisar e integrar
• Si un servidor requiere una configuración en particular, se la puede integrar
como un conjunto  de tareas ejecutado en función de un condicional. En otras
palabras, las tareas se incluyen solo si se cumplen criterios específicos.
• Si un grupo de servidores tiene que ejecutar una tarea o un conjunto de
tareas en particular, las tareas solo se pueden ejecutar en un servidor si este
es parte de un grupo específico de hosts.
Definición de variables para reproducciones y tareas externas
Para maximizar la posibilidad de reutilización, estos archivos de tareas y reproducciones
deben ser tan genéricos como sea posible. Las variables se pueden usar para parametrizar
elementos de reproducciones y tareas a fin de expandir la aplicación dereproducciones y
tareas.

Si parametriza el paquete y los elementos de servicio

Puede usar la misma técnica para hacer que los archivos de reproducción sean más
reutilizables.

capítulo 7 Simplificación
Los roles Ansible tienen los siguientes beneficios:
de guías con roles
• Contenido del grupo de roles, lo que permite intercambiar el código fácilmente
con otros
• Los roles se pueden escribir para definir los elementos fundamentales de un tipo
de sistema: servidor web, servidor de base de datos, repositorio git u otro propósito
• Los roles hacen que los proyectos más grandes sean más manejables
• Los roles se pueden desarrollar en paralelo por diferentes administradores

Análisis de la estructura de roles de Ansible

El directorio de nivel superior define el nombre del rol. Los archivos se organizan en
subdirectorios que se nombran de acuerdo con el propósito de cada archivo en el rol, como
tasks y handlers.
Los subdirectorios files y templates contienen archivos a los que hacen referencia las tareas
en otros archivos YAML.
 Definición de variables y valores predeterminados
Las variables del rol se definen mediante la creación de un archivo vars/main.yml con pares
clave-valor en la jerarquía del directorio del rol. Son nombrados en el archivo YAML del rol
como cualquier otra variable: {{VAR_NAME}}. Estas variables tienen una alta prioridad y no
se las puede reemplazar por variables de inventario. La intención de estas variables es que
sean utilizadas por el funcionamiento interno del rol.
Uso de los roles de Ansible en una guía

Control del orden de ejecución

Los manejadores de rol se agregan a las reproducciones de la misma manera que las tareas
de rol se agregan a las reproducciones. Cada reproducción define una lista de manejadores.
Los manejadores de rol se agregan primero a la lista de manejadores, seguidos de los
manejadores definidos en la sección handlers de la reproducción.

La tarea my handler se ejecuta tres veces:

• después de que se hayan ejecutado todas las tareas de pre_tasks
• después de que se hayan ejecutado todas las tareas de la sección tasks
• después de que se hayan ejecutado todas las tareas de post_tasks
Los roles se pueden agregar a una reproducción con una tarea común, no solo incluyéndolos
en la sección roles de una reproducción. Use el módulo include_role para incluir
dinámicamente un rol y use el módulo import_role para importar estáticamente un rol.
Reutilización de contenido con roles de    sistema

Instalación de roles de sistema RHEL

1. Instale los roles de sistema RHEL.

Después de la instalación, los roles de sistema RHEL se encuentran en el directorio

/usr/share/ansible/roles:

Acceso a la documentación para roles de sistema RHEL

El directorio de documentación de cada rol contiene un archivo README.md. El archivo

README.md contiene una descripción del rol, junto con la información de uso del rol.

Ejemplo de rol de sincronización de tiempos

Considere un proyecto de guía con la siguiente estructura:

Ejemplo de rol de SELinux

A continuación se detallan algunas de las tareas que puede realizar este rol:
• Establecer el modo de ejecución o permisivo
• Ejecutar restorecon en partes de la jerarquía del sistema de archivos
• Configurar valores booleanos de SELinux
• Configurar de manera persistente los contextos de archivos de SELinux
• Configurar asignaciones de usuarios de SELinux
El rol establecerá una variable booleana, selinux_reboot_required, en true y fallará si se
necesita un reinicio. Puede usar una estructura block/rescue para recuperarse de la falla, ya
sea que falle la reproducción porque la variable no se configura en true, o que reinicie el
host administrado y vuelva a ejecutar el rol porque está en true.

La variable selinux_state establece el modo en que se ejecuta SELinux. Se puede configurar

en modo de enforcing (cumplimiento), permissive (permisivo) o disabled (deshabilitado).
Si no está configurada, el modo no se cambia.

La variable selinux_booleans toma una lista de valores booleanos de SELinux para

ajustarse.
Cada ítem de la lista es un hash/diccionario de variables: el nombre (name) del
booleano, el estado (state), ya sea on u off, y si el ajuste debe ser persistente
(persistent) en los reinicios.

la política tenga una regla para establecer el tipo de SELinux predeterminado para todos los
archivos de /srv/www en httpd_sys_content_t.

La variable selinux_restore_dirs especifica una lista de directorios en los que se puede

ejecutar restorecon.
La variable selinux_ports toma una lista de puertos que deben tener un tipo específico de
SELinux.

Creación de roles
Crear roles en Ansible no requiere herramientas de desarrollo especiales. Crear y usar un rol
es un proceso de tres pasos:
1. Cree la estructura del directorio de roles.
2. Defina el contenido de los roles.
3. Use el rol en una guía.
De manera predeterminada, Ansible busca roles en un subdirectorio llamado roles en el
directorio que contiene su guía de reproducción Ansible.
Si Ansible no puede encontrar el rol allí, buscará en los directorios especificados por lac
configuración de Ansible roles_path, en orden.

Cada rol tiene su propio directorio con una estructura de directorios estandarizada.
 Creación de un esqueleto de roles
Puede crear todos los subdirectorios y archivos necesarios para un rol nuevo mediante
comandos estándares de Linux.
La herramienta de línea de comandos ansible-galaxy (que se analiza en más detalle más
adelante en este curso) se usa para administrar los roles de Ansible, incluida la creación de
nuevos roles. Puede ejecutar ansible-galaxy init para crear la estructura de directorios para
un nuevo rol. Especifique el nombre del rol como argumento del comando, lo que crea un
subdirectorio para el nuevo rol en el directorio de trabajo actual.

Definición del contenido de los roles

El siguiente archivo tasks/main.yml gestiona el archivo /etc/motd en los hosts
administrados.
Usa el módulo template para implementar la plantilla denominada motd.j2 en el
host administrado. Como el módulo template se configura dentro de una tarea de
rol, en lugar de una tarea de guía de reproducción, la plantilla motd.j2 se recupera
del subdirectorio templates del rol.
El siguiente comando muestra el contenido de la plantilla motd.j2 del rol motd Menciona
datos de Ansible y una variable system_owner

El archivo defaults/ main.yml de la estructura de directorio del rol es donde se configura este
valor.

• Mantenga cada rol en su propio repositorio de control de versiones.

Ansible funciona bien con repositorios basados en git.
• La información confidencial, como las contraseñas o claves SSH, no
debe almacenarse en el repositorio de roles. Los valores
confidenciales deben parametrizarse como variables con valores
predeterminados que no son confidenciales. Las guías de
reproducción que usan el rol son responsables de definir variables
sensibles a través de archivos de variables de Ansible Vault, variables
de entorno u otras opciones de ansible-playbook.
• Use ansible-galaxy init para iniciar su rol y elimine los directorios y
archivos que no necesite.
 • Cree y mantenga los archivos README.md y meta/main.yml para
documentar para qué sirve su rol, quién lo escribió y cómo usarlo.
• Mantenga su rol enfocado en un propósito o una función
específicos. En lugar de escribir un rol que haga muchas cosas,
puede escribir más de un rol.
• Reutilice y refactorice los roles a menudo. Evite crear nuevos roles
para las configuraciones perimetrales. Si un rol existente sirve para la
mayoría de la configuración requerida, refactorice el rol existente para
integrar el nuevo escenario de configuración

Definición de las dependencias del rol

Las dependencias del rol permiten que un rol incluya otros roles como dependencias..
El siguiente es un archivo meta/main.yml de muestra.

De manera predeterminada, los roles se agregan solamente como una dependencia a una
guía solo una vez. Si otro rol también lo enumera como una dependencia, no se lo ejecutará
nuevamente. Este comportamiento se puede reemplazar estableciendo la variable
allow_duplicates como yes en el archivo meta/main.yml.
Uso del rol en una guía
Para acceder a un rol, menciónelo en la sección roles: de una reproducción. La siguiente
guía se refiere al rol motd.
En el siguiente ejemplo de salida, se muestra esto con el prefijo motd : en el nombre de la tarea:

Cambio del comportamiento de un rol con variables

Un rol bien redactado usa variables predeterminadas para alterar el comportamiento del rol
para que coincida con un escenario de configuración relacionado.
El valor de cualquier variable definida en el directorio defaults de un rol se sobrescribirá si se
define esa misma variable:
• en un archivo de inventario, como una variable de host o una variable de
grupo
• en un archivo YAML en los directorios group_vars o host_vars de un
proyecto de guía
• como una variable anidada en la palabra clave vars de una reproducción
• como una variable cuando se incluye el rol en la palabra clave roles de una
reproducción
Cuando se define de esta manera, la variable system_owner reemplaza el valor de la variable
predeterminada del mismo nombre. Todas las definiciones de variables anidadas dentro de
la palabra clave vars no reemplazarán el valor de la misma variable si se la define en el
directorio vars de un rol.

La precedencia de variables puede causar confusión al trabajar con variables de rol en una
reproducción.
• Casi cualquier otra variable anulará las variables predeterminadas de un rol:
variables de inventario, vars de reproducción, parámetros de rol en línea, etc.
• Menos variables pueden anular las variables definidas en el directorio vars
de un rol. Los datos, las variables cargadas con include_vars, las variables
registradas y los parámetros de rol son algunas de las variables que pueden
hacer eso. Las variables de inventario y vars de reproducción no pueden
hacerlo. Esto es importante porque ayuda a evitar que la reproducción
modifique accidentalmente el funcionamiento interno del rol.
• No obstante, las variables declaradas en línea como parámetros de rol, como
en el último de los ejemplos anteriores, tienen precedencia muy alta. Pueden
anular las variables definidas en el directorio vars de un rol. Si un parámetro de
 rol tiene el mismo nombre que una variable establecida en vars de la
reproducción, un vars de rol o una variable de inventario o guía de
reproducción, el parámetro de rol anulará a la otra variable.

Implementación de roles con Ansible Galaxy

Ansible Galaxy [https://galaxy.ansible.com] es una librería pública de contenido de Ansible
programada por una variedad de administradores y usuarios de Ansible.
Ansible Galaxy incluye enlaces a la documentación y videos para nuevos usuarios y
desarrolladores de roles de Ansible.
Herramienta de línea de comando de Ansible Galaxy
La herramienta de línea de comando ansible-galaxy se puede usar para buscar, instalar,
enumerar, eliminar o iniciar roles, así como para mostrar información acerca de ellos.
El subcomando ansible-galaxy search busca roles en Ansible Galaxy.

El subcomando ansible-galaxy info muestra información más detallada acerca de un rol.

Ansible Galaxy obtiene esta información de varios lugares, incluido el archivo meta/main.yml
del rol y su repositorio de GitHub
 Instalación de roles desde Ansible Galaxy
El subcomando ansible-galaxy install descarga un rol de Ansible Galaxy y lo instala a nivel
local en el nodo de control.
De manera predeterminada, los roles se instalan en el primer directorio que se puede
escribir en el roles_path del usuario. Según el roles_path predeterminado configurado para
Ansible, normalmente el rol se instalará en el directorio ~/.ansible/roles del usuario. El
roles_path predeterminado puede ser anulado por el archivo de configuración actual de
Ansible o por la  variable de entorno ANSIBLE_ROLES_PATH, lo que afecta el
comportamiento de ansiblegalaxy.
También puede especificar un directorio específico para instalar el rol usando la opción -p
DIRECTORY.

Instalación de roles con un archivo de requisitos

También puede usar ansible-galaxy para instalar una lista de roles basados en definiciones
en un archivo de texto. Por ejemplo, si tiene una guía de reproducción en la que se deben
instalar roles específicos, puede crear un archivo roles/requirements.yml en el directorio del
proyecto que especifica los roles que son necesarios. Este archivo actúa como manifiesto d
dependencias para el proyecto de guía, lo que permite desarrollar y probar las guías por
separado desde cualquier rol de soporte.

El atributo src especifica la fuente del rol, en este caso, el rol geerlingguy.redis de Ansible
Galaxy.
Debe especificar la versión del rol en su archivo requirements.yml, en especial para las guías
de reproducción en producción.
Si no especifica una versión, obtendrá la última versión del rol. Si el autor en sentido
ascendente realiza cambios en el rol que son incompatibles con su guía, puede causar una
falla de automatización u otros problemas.
Para instalar los roles con un archivo de roles, use la opción -r REQUIREMENTS-FILE:

Puede alojar sus propios roles internos o propietarios en un repositorio privado de Git o en
un servidor web.
Para instalar los roles asociados con un proyecto de guía de reproducción,
 Gestión de roles descargados

Un rol se puede eliminar de manera local con el subcomando ansible-galaxy remove.

Los roles descargados e instalados se pueden utilizar en guías como cualquier otro rol.
Pueden mencionarse en la sección roles utilizando el nombre de rol de descarga. Si un rol no
está en el directorio roles del proyecto, el roles_path se verificará para ver si el rol está
instalado enuno de esos directorios; se usará la primera coincidencia.
Al rastrear la última versión de un rol en un proyecto, vuelva a instalar el rol periódicamente
para actualizarlo. Esto asegura que la copia local se mantenga actualizada con correcciones
de errores, parches y otras características.

Obtención de roles y módulos de las colecciones de contenido

Las colecciones de contenido permiten que las actualizaciones del código Ansible principal
se separen de las actualizaciones de módulos y complementos (plug-ins). Esto permite a los
proveedores y desarrolladores mantener y distribuir sus colecciones a su propio ritmo,
independientemente de las versiones de Ansible. Puede desarrollar sus propias colecciones
para proporcionar roles y módulos personalizados a sus equipos.
Instalación de colecciones de contenido
En el siguiente ejemplo se usa el comando ansible-galaxy con el argumento collection para
descargar e instalar la colección community.crypto en el sistema local.

La directiva de configuración de Ansible collections_paths especifica una lista separada por 

dos puntos de rutas en el sistema donde Ansible busca colecciones instaladas. Puede
establecer esta directiva en el archivo de configuración ansible.cfg.
El valor predeterminado para collections_paths es
~/.ansible/collections:/usr/share/ansible/collections.

Instalación de colecciones con un archivo de requisitos

Puede crear un archivo requirements.yml para enumerar todas las colecciones que necesita
instalar.
 Configuración de fuentes de colecciones
Para que el comando también use Ansible Automation Hub, agregue las siguientes directivas
al archivo ansible.cfg.
Es posible que no desee exponer sus credenciales en el archivo ansible.cfg porque el
archivo podría llegar a confirmarse usando el control de versiones. En ese caso, elimine los
parámetros de autenticación del archivo ansible.cfg y defínalos como variables de entorno.

Uso de colecciones
El siguiente comando ad hoc llama al módulo mail desde la colección community.general

La siguiente guía de reproducción invoca el módulo mysql_user de la colección

community.mysql.
La siguiente guía de reproducción usa el rol organizations de la colección redhat.satellite.

Uso de colecciones incorporadas de Ansible posteriores a Ansible 2.9

capítulo 8 Resolución de problemas de Ansible
El módulo Debug (Depuración)
El módulo debug (depuración) proporciona una visión de lo que está sucediendo en la
reproducción. Este módulo puede mostrar el valor de una determinada variable en cierto
punto de la reproducción. Esta función es clave para depurar tareas que usan variables para
comunicarse entre sí
 Gestión de errores
Muchos problemas pueden ocurrir durante la ejecución de una guía, principalmente
relacionados con la sintaxis de la guía o de cualquiera de las plantillas que utiliza, o debido a
problemas de conectividad con los hosts administrados

También puede usar la opción --step para recorrer una guía de reproducción una tarea a la
vez.

La opción --start-at-task le permite iniciar la ejecución de una guía de reproducción desde

una tarea específica.

Depuración
La salida dada por la ejecución de una guía de reproducción con el comando ansible-
playbook es un buen punto de partida para la solución de problemas relacionados con hosts
administrados por Ansible.
El comando ansible-playbook -v aporta  información de depuración adicional, con hasta
cuatro niveles totales.

Estas son algunas de las prácticas recomendadas para el desarrollo de guías:

• Use una descripción concisa del propósito de la reproducción o tarea para
nombrar las reproducciones y las tareas. El nombre de la reproducción o tarea
se muestra cuando se ejecuta la guía. Esto también ayuda a documentar lo
que se supone que debe lograr cada reproducción o tarea, y posiblemente por
qué se necesita.
• Incluye comentarios para agregar documentación en línea adicional acerca
de tareas.
• Haga un uso eficaz del espacio en blanco vertical. En general, organice los
atributos de las tareas verticalmente para que sean más fáciles de leer.
• Una sangría horizontal consistente es fundamental. Use espacios, no
tabulaciones, para evitar errores de sangría. Configure su editor de texto para
insertar espacios cuando presione la tecla Tab para hacer esto más fácil.
• Intente mantener la guía lo más simple posible. Solo use las funciones que
necesita.
Solución de problemas en hosts administrados de Ansible
Uso del modo de verificación como herramienta de prueba
Puede usar el comando ansible-playbook --check para ejecutar pruebas de humo en una
guía de reproducción. Esta opción ejecuta la guía sin realizar cambios en la configuración de
los hosts administrados.

También puede controlar si las tareas individuales se ejecutan en el modo de verificación

con el ajuste check_mode. Si una tarea tiene configurado check_mode: yes, se ejecuta
siempre en modo de verificación, independientemente de que haya pasado la opción --
check a ansibleplaybook.
El comando ansible-playbook también proporciona una opción --diff. Esta opción informa
los cambios realizados a los archivos de plantillas en hosts administrados. Si se usan con la
opción --check, estos cambios se muestran en la salida del comando, pero no se realizan.

Pruebas con módulos

• El módulo uri aporta una forma de verificar que una RESTful API esté devolviendo el
contenido requerido.

• El módulo script admite la ejecución de un script en un host administrado, y falla si el

código de retorno para el script es diferente a cero

• El módulo stat recopila datos para un archivo muy similar al comando stat. Puede usarlo
para registrar una variable y luego hacer una prueba para determinar si el archivo existe, o
para obtener otra información sobre el archivo.

• El módulo assert es una alternativa al módulo fail. El módulo assert es compatible con la
opción that que toma una lista de condicionales. Si alguno de esos condicionales es falso, la
tarea falla. Puedes usar las opciones success_msg y fail_msg para personalizar el mensaje
que imprime si informa éxito o fracaso.

Solución de problemas de conexiones

Asegúrese de que become esté correctamente configurado y de que está usando el usuario
become_user correcto (que es root de forma predeterminada). Debe confirmar que está
RH294-RHEL8.4-es-1-20210818 351 capítulo 8 | Resolución de problemas de Ansible
ingresando la contraseña sudo correcta y que sudo en el host administrado esté
configurado correctamente.
Prueba de hosts administrados con comandos ad hoc
Ha usado el módulo ping para probar si puede conectarse a hosts gestionados.
Este ejemplo devuelve el espacio actualmente disponible en los discos configurados en el
host administrado demohost.

Este ejemplo devuelve la memoria libre actualmente disponible en el host administrado

demohost.
capítulo 9 Automatización de tareas de
administración de Linux
Administración de paquetes con Ansible
El módulo yum de Ansible usa Yum Package Manager en los hosts administrados para
manejar las operaciones de paquetes.

Optimización de la instalación de varios paquetes

Recopilación de datos sobre paquetes instalados
 Revisión de módulos alternativos para administrar paquetes
Por ejemplo, el módulo dnf administra los paquetes en sistemas operativos como Fedora
con el administrador de paquetes DNF. El módulo apt usa la herramienta de paquetes APT
disponible en Debian o Ubuntu. El módulo win_package puede instalar software en sistemas
de Microsoft Windows.

Registro y suscripción de nuevos sistemas

Sin Ansible, estas tareas se realizan con el comando subscription-manager:
 Habilitación de repositorios de software de Red Hat

Recuerde que puede enumerar los repositorios disponibles con el comando

subscriptionmanager repos --list.

Configuración de un repositorio de Yum

Importación de una clave GPG de RPM
 Administración de usuarios y autenticación
Puede administrar una serie de parámetros que incluyen eliminar usuario, configurar
directorio de inicio, configurar el UID para las cuentas del sistema, administrar contraseñas y
agrupaciones asociadas.

Ejemplo de módulo user que genera una clave ssh

El módulo group
El módulo known hosts (host conocido)

El módulo authorized key (clave autorizada)

Programación con el módulo at

Anexión de comandos con el módulo cron
 Administración de servicios con los módulos systemd y service
El módulo service ofrece un conjunto básico de opciones: iniciar, detener, reiniciar, habilitar.
El módulo systemd ofrece más opciones de configuración. Systemd permite recargar un
daemon, mientras que el módulo service no lo permite.
 El módulo reboot (reiniciar)

Los módulos shell y command (comando)

El módulo command se considera más seguro, pero algunas variables de entorno no están
disponibles. Además, los operadores de flujo no funcionan. Si necesita transmitir sus
comandos, el módulo shell lo hará.
Ejemplo del módulo shell:

Ejemplo del módulo command:

Administración del almacenamiento
Configuración de intercambio con módulos
Para agregar memoria de intercambio a un sistema con Ansible con volúmenes lógicos, debe
crear un grupo de volúmenes y un volumen lógico nuevos con los módulos lvg y lvol. Cuando
esté listo, debe formatear como intercambio el nuevo volumen lógico con el módulo
command y el comando mkswap. Por último, debe activar el nuevo dispositivo de
intercambio con el módulo command y el comando swapon. Ansible incluye la variable
ansible_swaptotal_mb que incluye la memoria total de intercambio. Puede usar esta variable
para desencadenar la configuración de intercambio y la habilitación cuando la memoria de
intercambio es baja. Las siguientes tareas, crear un grupo de volúmenes y un volumen
lógico para la memoria de intercambio, formatean ese volumen lógico como intercambio y lo
activan.

Datos de Ansible para la configuración de almacenamiento

Puede usar el módulo de Ansible setup (configuración) para recuperartodos los datos de
Ansible para un host administrado.
La opción filter (filtrar) para el módulo setup admite filtrado detallado basado en comodines
de tipo shell.
El elemento ansible_devices incluye todos los dispositivos de almacenamiento disponibles
en el host administrado.
El elemento ansible_device_links incluye todos los vínculos disponibles para cada
dispositivo de almacenamiento.

El elemento ansible_mounts incluye información sobre los dispositivos montados

actualmente en el host administrado, como el dispositivo montado, el punto de montaje y las
opciones
 Administración de la configuración de red
El paquete rhel-system-roles instala los roles de sistema que, por ejemplo, admiten la
configuración de sincronización de tiempo o redes. Puede enumerar los roles de sistema
instalados actualmente con el comando ansible-galaxy list.
El rol de red se configura con dos variables, network_provider y network_connections.
El módulo hostname (nombre de host) establece el nombre de host para un host
administrado sin modificar el archivo /etc/hosts.

El módulo firewalld admite la administración de FirewallD en hosts administrados. Estos

módulos admiten la configuración de las reglas de FirewallD para servicios y puertos.
También admite la administración de zona, incluida la asociación de interfaces y reglas de
red a una zona específica.
 Datos de Ansible para la configuración de red
Todas las interfaces de red para un host administrado están disponibles en el elemento
ansible_interfaces. Puede usar el parámetro gather_subset=network para el módulo setup a
fin de restringir los hechos a los incluidos en el subconjunto network (red).
Puede recuperar información adicional sobre la configuración de una interfaz de red con el
filtro ansible_NIC_name para el módulo setup.