set_fact - ansible playbook
Defina ''hacerse=sí'' por rol con Ansible (4)
En la documentación de Ansible para 2.4 , puede encontrar una manera de definir variables de conexión, como ansible_become
y ansible_user
. Se definen como variables habituales. A continuación se muestra un fragmento.
El primer rol prepare_user
conecta a los hosts
mediante el usuario root sin derechos de elevación. El segundo register
roles se conecta a los hosts
utilizando el conjunto de remote_user
través de ansible.cfg
(se buscó en un orden definido ; busque "en el siguiente orden").
---
- hosts: all
name: Prepare VMs for cluster
roles:
- role: prepare_user
vars:
- ansible_become: false
- ansible_user: root
- role: register
...
En el aprovisionamiento de mi sistema con Ansible, no quiero especificar Become become=yes
en todas las tareas, por lo que creé el siguiente ansible.cfg en el directorio principal del proyecto, y Ansible ejecuta automáticamente todo como root:
[privilege_escalation]
become = True
Pero a medida que el proyecto sigue creciendo, algunos roles nuevos no deben ejecutarse como root. Me gustaría saber si es posible tener alguna instrucción dentro del rol de que todas las tareas dentro de ese rol deben ejecutarse como root (por ejemplo, algo en vars /), en lugar de la solución global ansible.cfg anterior.
Hay una manera de hacer lo que está pidiendo, pero debe tener cuidado con la forma en que lo usa, porque Ansible evalúa la mayoría de las variables antes de ejecutar cualquier tarea. Si usa este truco, debe asegurarse de usarlo de manera consistente o podría usarlo involuntariamente para que no lo desee.
Bajo el capó, Ansible utiliza la variable ansible_become
para determinar si se debe utilizar para esa tarea. Dentro de su rol, puede crear un valor defaults/main.yml
y establecer ansible_become: [true/false]
Esto hará que ese rol completo acepte ese valor, a menos que se sobrescriba con una definición de precedencia más alta (importante para entender la precedencia de variables )
El "gotcha" crítico aquí es que si usas un rol donde está definido, afectará a todos los otros roles llamados debajo de él en el juego, a menos que también lo tengan definido.
Ejemplos:
role_default_become_true
tiene ansible_become: true
definido como verdadero en los valores predeterminados role_default_become_false
tiene ansible_become: false
definido como verdadero en los valores predeterminados role_no_default
no tiene un valor predeterminado ansible_become
---
- name: test1
hosts: localhost
connection: local
roles:
- role_default_become_true
- role_default_become_false
- role_no_default
- name: test2
hosts: localhost
connection: local
roles:
- role_default_become_false
- role_default_become_true
- role_no_default
- name: test3
hosts: localhost
connection: local
roles:
- role_default_become_false
- role_default_become_true
- { role: role_no_default, become: false }
En test1, role_no_default
se ejecutará sin convertirse, porque el rol anterior lo definió como falso y no tiene su propia definición.
En test2, role_no_default
se ejecutará con convertido, porque el rol anterior lo definió como verdadero y no tiene su propia definición.
En test3, role_no_default
se ejecutará sin convertirse, porque tiene su propia definición.
He encontrado una solución, aunque creo que el equipo de Ansible debe implementar una mejor solución. Cambie el nombre de main.yml a tasks.yml y luego escriba lo siguiente en main.yml :
---
- { include: tasks.yml, become: yes }
Otra solución es pasar el parámetro directamente en site.yml , pero la idea principal de la pregunta era reutilizar el rol en otros proyectos sin olvidar que necesita root:
---
- hosts: localhost
roles:
- { role: name, become: yes }
También puede envolver sus tareas en un bloque y ponerlas become: yes
en el bloque. Entonces, dentro de tus roles/role_name/tasks/main.yml
, harías esto:
- block:
- name: Tasks go here as normal
...
become: yes
Esto ejecutará todas las tareas dentro del bloque como root. Más detalles de los bloques de Ansible here .