Si escribe o usa playbooks de Ansible, entonces está acostumbrado a leer archivos de configuración YAML. YAML puede ser engañosamente simple y, sin embargo, extrañamente abrumador, todo a la vez, especialmente cuando considera los infinitos módulos Ansible posibles a su disposición. Parece que debería ser fácil anotar algunas opciones en un archivo YAML y luego ejecutar Ansible, pero ¿qué opciones requiere su módulo favorito? ¿Y por qué algunos pares clave-valor mientras que otros son listas?
YAML para Ansible puede volverse complejo, por lo que comprender cómo se traducen los módulos de Ansible a YAML es una parte importante para mejorar en ambos. Antes de que pueda comprender cómo funciona YAML para los módulos de Ansible, debe comprender los conceptos básicos de YAML.
Si no conoce la diferencia entre un bloque de mapeo y un bloque de secuencia en YAML, lea esta breve introducción a los conceptos básicos del artículo YAML.
Sintaxis de comandos
Aparte del uso ad-hoc, Ansible se usa a través de libros de estrategias . Un libro de jugadas se compone de una o más jugadas en una lista ordenada (una secuencia YAML ). Cada juego puede ejecutar una o más tareas y cada tarea invoca un módulo de Ansible.
Los módulos de Ansible son básicamente interfaces para comandos. Si está familiarizado con la terminal de Linux o Powershell de Microsoft, entonces sabe cómo construir un comando usando opciones (como --long o -s ) junto con argumentos (también llamados parámetros ).
He aquí un ejemplo sencillo:
$ mkdir foo
Este comando usa el mkdir comando para crear un directorio llamado foo .
Un libro de jugadas de Ansible también construye comandos. Son los mismos comandos, pero se invocan usando una sintaxis diferente a la que estás acostumbrado en una terminal.
[ También puede disfrutar: Introducción a Ansible ]
Módulos de Ansible y YAML
Sin embargo, como tarea en un libro de jugadas de Ansible, la sintaxis es muy diferente. Primero, se le da un nombre a la obra, que es una descripción legible por humanos de lo que se está representando. Una obra acepta muchas palabras clave, incluidos hosts para limitar en qué hosts debe ejecutarse y remote_user para definir el nombre de usuario que Ansible debe usar para acceder a hosts remotos.
Ansible define las palabras clave para las reproducciones, y hay una lista de claves (y los tipos de información que cada una espera como su valor) disponible en la documentación de Ansible Play Keywords .
Estas claves no son elementos de lista separados. En terminología YAML, son asignaciones incrustado en la secuencia de reproducción .
Aquí hay una declaración de juego simple:
---
- name: “Create a directory”
hosts: localhost
El bloque de mapeo final en una declaración de juego es tasks palabra clave, que abre una nueva secuencia para definir qué módulo de Ansible se ejecutará y con qué argumentos. Es aquí donde está usando comandos familiares de una manera desconocida y YAML-ified. De hecho, es tan poco familiar para usted que probablemente necesite leer sobre el módulo para descubrir qué argumentos espera de usted.
En este ejemplo, uso el módulo de archivo integrado. En la documentación del módulo, puede ver que el parámetro requerido es path , que espera una ruta de archivo POSIX válida. Armado con esa información, puede generar un libro de jugadas de Ansible muy simple que se ve así:
---
- name: "Create a directory"
hosts: localhost
tasks:
- name: "Instantiate"
file:
path: "foo"
Si todavía te estás acostumbrando a la importancia de la sangría de YAML, observa que el nombre de la tarea no está sangrado en relación con tasks porque name es el comienzo de un nuevo bloque de secuencia YAML (que, como suele suceder, sirve como valor para las tasks llave). La palabra file identifica qué módulo se está utilizando, cuál es parte de la definición de la tarea y path es un parámetro obligatorio del file módulo.
En otras palabras, la tarea de un juego es un bloque de secuencia YAML. (es decir, una lista ordenada) de definiciones que invocan un módulo y sus parámetros.
Puede probar esta reproducción para verificar que funciona como se esperaba, pero primero, ejecute yamllint en él para evitar sorpresas sintácticas:
$ yamllint folder.yaml || echo “fail”
$ ansible-playbook folder.yaml
[…]
TASK [Instantiate] ******************
fatal: [localhost]:
FAILED! => {“changed”: false,
“msg”: “file (foo) is absent, cannot continue” …
El libro de jugadas se procesó, pero la tarea falló. Lectura de la lista de parámetros del file módulo revela que su comportamiento depende en gran medida del valor de state . Específicamente, la acción predeterminada es devolver el estado de path .
Modifique su archivo YAML de muestra para incluir un state asignación:
---
- name: "Create a directory"
hosts: localhost
tasks:
- name: "Instantiate"
file:
path: "foo"
state: directory Vuelva a ejecutarlo para tener éxito:
$ yamllint folder.yaml || echo “fail”
$ ansible-playbook folder.yaml
[…]
$ ls
foo Módulos de control
No todos los módulos de Ansible se asignan directamente a un solo comando. Algunos módulos modifican cómo Ansible procesa su libro de jugadas. Por ejemplo, el with_items El módulo enumera los elementos sobre los que desea que opere otro módulo. Puede pensar en ello como una especie de do while o for bucle.
Su documentación indica que solo acepta un parámetro:una lista de elementos. Una "lista" en terminología YAML es una secuencia , para que sepa sin ni siquiera mirar el código de muestra en los documentos que cada elemento debe comenzar con un guión de espacio (- ).
Aquí hay una nueva iteración de creación de carpetas, esta vez con múltiples subcarpetas (usando el recurse parámetro en el file módulo) y un parámetro adicional para establecer permisos de archivo. No dejes que las líneas adicionales te engañen. Este es esencialmente el mismo código que antes, solo que con parámetros adicionales como se describe en el file documentación del módulo, más el with_items módulo para habilitar la iteración:
---
- name: "Create directory structure"
hosts: localhost
tasks:
- name: "Instantiate"
file:
path: "{{ item }}"
recurse: true
mode: "u=rwx,g=rwx,o=r"
state: directory
with_items:
- "foo/src"
- "foo/dist"
- "foo/doc" Ejecute el libro de jugadas para ver los resultados:
$ yamllint folder.yaml
$ ansible-playbook folder.yaml
[…]
$ ls foo
dist doc src [ ¿Necesita más información sobre Ansible? Realice un curso gratuito de descripción técnica de Red Hat. Ansible Essentials:descripción técnica de la simplicidad en la automatización. ]
Principios de Ansible
Un playbook de Ansible es una secuencia YAML , que a su vez consta de asignaciones y secuencias .
Los libros de jugadas también contienen módulos de Ansible, cada uno de los cuales acepta parámetros definidos por su desarrollador. Tanto los parámetros obligatorios como los opcionales se enumeran en la documentación de un módulo.
Para construir un libro de jugadas de Ansible, inicie una secuencia YAML que nombre la jugada y luego enumere (en una secuencia) una o más tareas. En cada tarea se pueden invocar uno o más módulos.
Preste mucha atención a la sangría al comprender el tipo de datos que está ingresando en su archivo YAML. Podría ayudar a evitar pensar en la sangría como una indicación de herencia lógica y, en cambio, ver cada línea como su tipo de datos YAML (es decir, una secuencia o una asignación).
Usa yamllint para verificar sus archivos YAML.
Una vez que comprenda la estructura de un libro de jugadas, solo es cuestión de seguir la documentación del módulo para ejecutar las tareas que desea que realice su libro de jugadas. Hay cientos de módulos disponibles, así que comience a explorarlos y vea qué cosas increíbles puede hacer con esta increíble herramienta.