tower - Ansible Playbooks vs Roles

ansible vars (5)

Según los documentos de Ansible, un Playbook es:

... la base para una administración de configuración realmente simple y un sistema de implementación de máquinas múltiples, a diferencia de cualquiera que ya exista, y que sea muy adecuado para implementar aplicaciones complejas.

Y, de nuevo, de acuerdo con esos mismos documentos, los Roles son:

... formas de cargar automáticamente ciertos vars_files, tareas y controladores basados en una estructura de archivos conocida. Agrupar el contenido por roles también permite compartir fácilmente los roles con otros usuarios.

Sin embargo, la distinción entre estos y sus diferentes casos de uso no me resulta obvia de inmediato. Por ejemplo, si configuro mi /etc/ansible/hosts para que se vea así:

[databases] mydb01.example.org mydb02.example.org [mail_servers] mymail01.example.org mymail_dr.example.org

... entonces, ¿qué es esta entrada " [databases] " ... un papel ? ¿O el nombre de un archivo YAML de libro de jugadas en alguna parte? ¿¡¿O algo mas?!?

Si alguien pudiera explicarme las diferencias en estos, ¡mi comprensión de Ansible mejoraría enormemente!

Playbook vs Role vs [databases] y entradas similares en /etc/ansible/hosts
Si los Playbooks se definen dentro de los archivos YAML, ¿dónde se definen los Roles?
Además del ansible.cfg vive en el servidor Ansible, ¿cómo agrego / configuro Ansible con Playbooks / Roles disponibles? Por ejemplo, cuando ejecuto ansible-playbook someplaybook.yaml , ¿cómo sabe Ansible dónde encontrar ese playbook?

Playbook vs Role vs [bases de datos] y entradas similares en / etc / ansible / hosts

Los roles son una forma de agrupar tareas en un solo contenedor. Podría tener un rol para configurar MySQL, otro para configurar Postfix, etc.

Un libro de jugadas define qué está sucediendo dónde . Este es el lugar donde define los hosts (grupos de hosts, ver más abajo) y los roles que se aplicarán a esos hosts.

[databases] y las otras entradas en su inventario son grupos de hosts. Los grupos de hosts definen un conjunto de hosts en los que se ejecutará una obra.

Una obra de teatro es un conjunto de tareas o roles (o ambos) dentro de un libro de jugadas. En la mayoría de los casos (y ejemplos), un libro de jugadas contendrá una sola jugada. Pero puedes tener tantos como quieras. Eso significa que podría tener un libro de jugadas que ejecute la función postfix en los servidores de mail_servers del grupo mail_servers y el rol mysql en las bases de databases host:

- hosts: mail_servers roles: - postfix - hosts: databases roles: - mysql

Si los Playbooks se definen dentro de los archivos YAML, ¿dónde se definen los Roles?

En Ansible, casi todo está definido en YAML, eso cuenta para roles y libros de jugadas.

Además del ansible.cfg que vive en el servidor Ansible, ¿cómo agrego / configuro Ansible con Playbooks / Roles disponibles? Por ejemplo, cuando ejecuto ansible-playbook someplaybook.yaml, ¿cómo sabe Ansible dónde encontrar ese playbook?

AFAIK tiene que proporcionar el camino hacia el libro de jugadas al invocar ansible-playbook . Entonces ansible-playbook someplaybook.yaml esperaría que someplaybook.yaml esté en su directorio actual. Pero puede proporcionar la ruta completa: ansible-playbook /path/to/someplaybook.yaml

Playbook vs Role vs [bases de datos] y entradas similares en / etc / ansible / hosts

[databases] es un nombre único para un grupo de hosts. Le permite hacer referencia a múltiples hosts por un solo nombre.

El rol es un conjunto de tareas y archivos adicionales para configurar el host para servir para un determinado rol .

Playbook es un mapeo entre hosts y roles.

El ejemplo de la Roles describe un proyecto de ejemplo. Contiene dos cosas:

Playbooks site.yml , webservers.yml , fooservers.yml son libros de jugadas.
Roles: roles/common/ y roles/webservers/ contienen definiciones de roles common y de webservers consecuencia.

Dentro del libro de jugadas ( webservers.yml ) tienes algo como:

--- - hosts: webservers <- this group of hosts defined in /etc/ansible/hosts, databases and mail_servers in example from your question roles: <- this is list of roles to assign to these hosts - common - webservers

Si los Playbooks se definen dentro de los archivos YAML, ¿dónde se definen los Roles?

Se definen dentro de los directorios roles/* . Los roles se definen principalmente utilizando archivos YAML, pero también pueden contener recursos de cualquier tipo ( files/ , templates/ ). De acuerdo con la documentation definición del rol se estructura de esta manera:

Si los roles / x / task / main.yml existen, las tareas enumeradas allí se agregarán a la obra

Si los roles / x / handlers / main.yml existen, los controladores enumerados allí se agregarán a la obra

Si los roles / x / vars / main.yml existen, las variables enumeradas allí se agregarán a la obra

Si existen roles / x / meta / main.yml, las dependencias de roles enumeradas allí se agregarán a la lista de roles (1.3 y posteriores)

Cualquier tarea de copia puede hacer referencia a archivos en roles / x / files / sin tener que enrutarlos de manera relativa o absoluta

Cualquier tarea de script puede hacer referencia a scripts en roles / x / archivos / sin tener que enrutarlos de forma relativa o absoluta

Cualquier tarea de plantilla puede hacer referencia a archivos en roles / x / templates / sin tener que enrutarlos de manera relativa o absoluta

Cualquier tarea de inclusión puede hacer referencia a archivos en roles / x / task / sin tener que enrutarlos de manera relativa o absoluta

El archivo más importante es roles/x/tasks/main.yml , aquí define las tareas, que se ejecutarán cuando se ejecute el rol.

Además del ansible.cfg que vive en el servidor Ansible, ¿cómo agrego / configuro Ansible con Playbooks / Roles disponibles? Por ejemplo, cuando ejecuto ansible-playbook someplaybook.yaml, ¿cómo sabe Ansible dónde encontrar ese playbook?

$ ansible-playbook someplaybook.yaml

Buscará un libro de jugadas dentro del directorio actual.

$ ansible-playbook somedir/somedir/someplaybook.yaml

Buscará un libro de jugadas dentro del somedir/somedir/ .

Es su responsabilidad poner su proyecto con todos los libros de jugadas y roles en el servidor. Ansible no tiene nada que ver con eso.

Es una terminología / pregunta semántica. Puede ser subjetivo, aunque haya una definición de línea de base.

Mi opinión es la siguiente:

Cualquier sistema de gestión / implementación de configuración tiene:

source data : datos utilizados para crear la configuración del host de destino
target data : datos utilizados para identificar hosts de destino
config changes : lista / conjunto de reglas / acciones que aplicamos con los source data sobre el host de target data en función de target data

En términos Ansibles:

source data - son los diversos lugares donde podemos poner datos - group_vars , playbook vars, role vars, etc., estos lugares afectan la precedencia (si una variable llamada igual se redefine en diferentes ubicaciones, hay reglas muy específicas de lo que sería ser el valor de la variable durante la ejecución de ansible / ansible-playbook
target data : es el inventario (¡Y también es posible definir variables de inventario / grupo de host dentro del inventario!)
config changes : ansible tiene 4 niveles de abstracción para ello:
1. tarea: acción única
2. lista de tareas - lista de acciones
3. rol: lista de acciones (o lista de listas) agrupadas por el mismo ''sujeto'', generalmente todos los objetivos están operando en el mismo host / grupo de hosts
4. libro de jugadas: lista de jugadas, cada una operando en un grupo de host posiblemente diferente, aplicando varios role s / task s / tasklists (y tareas especiales como handlers )

Desde el aspecto del ''software'', el rol debe ser lo suficientemente genérico como para ser reutilizado .

También en algunas organizaciones (bastante grandes), los ''roles'' son enviados por el grupo A, mientras que se usan en libros de jugadas mantenidos por el grupo B.

resumen

Todo lo anterior permite la agrupación de configuraciones similares, en un role . agrupando subsistemas / componentes relacionados en un playbook . Además, vale la pena mencionar que 1 elemento de YAML en un libro de jugadas (incluidos los hosts: y o tasks , pre_tasks , post_tasks , roles ) se llama play

Ahora para tu pregunta:

Sí, es confuso al principio.

Por lo general, conecta los source data a la semántica de su rol, por lo que cuando ve que el rol setup_db se aplica en una jugada en un grupo host relacionado (por ejemplo, db_hosts ) Pero una play puede ejecutarse en una unión de varios grupos host. Es solo una cuestión de convención versus flexibilidad.

PD

Por favor escríbame si esto se sumó a la confusión o se aclaró. Gracias.

Simplemente pon:

Un libro de jugadas es como el programa principal, contiene instrucciones completas para finalizar el trabajo. Sin embargo, para grandes proyectos, no es deseable poner realmente todos los detalles en él. Entonces necesitas un rol.

Un rol es una subrutina y generalmente logra un objetivo, por ejemplo, configurar un servidor de base de datos. Puede ponerlo en roles/ directorio, o descargar roles de terceros proporcionando URI en rolesfile.yml y pedirle a ansible-galaxy que los descargue por usted.

La [database] es un grupo de hosts definido en un archivo de inventario que enumera los hosts que pertenecen al grupo de database . También puede especificar un grupo de servidores web especificando algo como

[web] web1.example.com web2.example.com

La web grupal o la database se pueden usar en libros de jugadas o roles para especificar los hosts a aplicar.

Los grupos también se pueden usar en el comando ansible para ejecutar comandos ad-hoc.

También tenga en cuenta que un libro de jugadas puede invocar más de un rol si se utiliza un metaarchivo que pretende afectar los diferentes roles.

Ejemplo de libro de jugadas: dual_role-playbook.yml

- name: Some Action for two roles hosts: localhost vars_files: - roles/dual_role/meta/main.yml roles: - dual_role/container-1 - dual_role/container-2

La carpeta de roles y el esquema de archivos se verán así:

dual_role-playbook.yml -- roles -- dual_role -- meta/main.yml -- container-1 -- tasks/main.yml -- templates/template.j2 -- container-2 -- tasks/main.yml -- templates/template.j2