* Variable normale :
Déclarée dans group_vars/all (globale) ou dans roles/<role_name>/vars/main.yml (local au rôle) et utilisée dans un template, par exemple : {{ var_name }}
Déclarée pour une machine dans le fichier hosts et utiliser dans un template : {{ hostvars[host].var_name }}
* Dans un template : itérer sur tous les membres d'un groupe dans une variable sauf la machine actuelle elle-même :
{% for host in groups['rr'] %}
{% if hostvars[host].inventory_hostname != inventory_hostname %}
lala
lolo
{% endif %}
{% endfor %}
* Itérer sur une variable (de "type" liste) dans un template :
Dans group_vars/all (globale) ou dans roles/<role_name>/vars/main.yml (local au rôle) :
rrclient:
- 192.0.2.1
Dans roles/<role_name>/templates/<template_name.j2 :
{% for host in rrclient %}
neighbor {{ host }} peer-group rrclient
{% endfor %}
* Itérer sur une variable contenant une liste d'associations, dans un template :
Dans group_vars/all (globale) ou dans roles/<role_name>/vars/main.yml (local au rôle) :
rrclient:
- { hostname: 'dochost', ip: '192.0.2.1' }
Dans roles/<role_name>/templates/<template_name.j2 :
{% for host in rrclients %}
neighbor {{ host.ip }} description {{ host.hostname }}
{% endfor %}
* Hiéarchie d'hôtes
[name:children]
rr
[rr:children]
titi-rr
toto-rr
[titi-rr]
machine1 ansible_ssh_host=192.0.2.1 task=lala autrevar=lili
[toto-rr]
machine2 ansible_ssh_host=192.0.2.2 task=lele autrevar=lili
Il peut y avoir d'autres niveaux aka titi-rr et toto-rr peuvent eux même avoir des enfants.
* Exemple de liste de tasks :
- name: Install Quagga
apt: name=quagga state=present
tags: quagga
- name: Copy Quagga daemons
copy: src=daemons dest=/etc/quagga/ owner=quagga group=quagga mode=0644
tags: quagga
- name: Configure Quagga
template: src=bgpd.conf.j2 dest=/etc/quagga/bgpd.conf owner=quagga group=quagga mode=0644
tags: quagga
notify: restart quagga
- name: Start Quagga
service: name=quagga state=started enabled=true
tags: quagga
* Pour jouer le catalogue (il peut y avoir plusieurs fichiers « hosts » d'inventaire des machines, d'où la précision) : ansible-playbook -i hosts site.yml
* Pour jouer le catalogue pour une machine : ansible-playbook -i hosts site.yml --limit=machine1 . Même principe pour un groupe de machines (--limit=machine1,machine2,machine3 ou --limit=groupnameInInventory) .
* Pour jouer le catalogue pour toutes les machines mais uniquement les tasks qui ont le tags « lala » : ansible-playbook -i hosts site.yml --tags "lala". On peut mettre plusieurs tags séparés par des virgules.
* Variable contenant le nom de la machine tel que défini dans l'inventaire : inventory_hostname , par opposition à ansible_hostname qui est le nom récupéré sur la machine elle-même par Ansible.
* Dans un template : évidemment, les opérateurs de comparaison habituels et le cumul de plusieurs conditions sont utilisables :
{% if hostvars[host].inventory_hostname != inventory_hostname
and hostvars[host].task == task %}
* Dans un template : contenu d'une variable de type "list" dont le nom est obtenu par le contenu d'une autre variable :
blabla:
titi: 9010
toto: 9011
tutu: 9012
set community {{ asn }}:{{ blabla[inventory_hostname.split('.').0] }}
Ici le hostname est de la forme (titi|toto|tutu).lala.lele.example, d'où le split ;)
* Ne pas utiliser plusieurs modules dans une même tâche (exemple ci-dessous), le résultat est chaotique : certaines actions sont exécutées, d'autres non...
- name: 'Copy apt conf files'
copy: src=apt.conf dest=/etc/apt/apt.conf owner=root group=root mode=0744
copy: src=preferences dest=/etc/apt/preferences owner=root group=root mode=0744
copy: src=sources.list dest=/etc/apt/sources.list owner=root group=root mode=0744
tags: apt
* L'action en « notify: » d'une task n'est pas exécutée si l'action de la tâche n'a pas produit un changement. Exemple : l'action de la tache est un copy mais le fichier était déjà présent dans sa dernière version sur la machine "ansiblisée", alors l'action indiquée en notify ne sera pas exécutée.
* Dans un template, produire une suite comme 1:2:3 (et pas 1:2:3: ;) ):
{% for host in groups['lala'] %}
{{ hostvars[host].id }}
{%- if not loop.last %}
{{':'}}
{% endif %}
{% endfor %}
* Itérer sans retour à la ligne. Exemple : on veut obtenir une ligne de la forme : groups=1:2:3 :
groups=
{%- for host in groups['toto'] -%}
{{ hostvars[host].id }}
{%- if not loop.last -%}
{{':'}}
{%- endif -%}
{%- endfor %}
Explication : « %- » : pas de retour à la ligne avant ce bloc ; « -% » = pas de retour à la ligne après ce bloc
* Inclure un template dans un template (son contenu sera parsé) :
{% if (inventory_hostname in groups['lolo']) %}
{% include "iptables_subtemplates/iptables_lolo-group.j2" with context %}
{% endif %}
Les variables comme hostvars sont accessibles, les variables définies dans le template appelant ne le sont pas.
* Variable locale à un fichier : {% set var = [] %} (ici une liste, = "" ça serait un string, ...). Ne sont pas propagées aux templates inclus.
* Savoir les machines concernées par un déploiemenbt et les tasks qui seront exécutées : --list-hosts ; --list-tasks
* Récupérer des infos mais que pour certains types d'installation (ici : Wheezy ou supérieur) :
- shell: grep "model name" /proc/cpuinfo | head -n1
register: result
when: ansible_lsb.major_release|int >= 7
tags: collecte
- debug: var=result
tags: lala
* Dry run : ansible-playbook -C ; -D pour voir les fichiers templatés qui seront modifiés.
* Rolling update (ne pas reload/restart tous les serveurs d'un même groupe pour ne pas provoquer une interruption de service) : il indiquer « serial: 1 » dans le playbook. Attention à le positionner sur le bon groupe sinon ça ne fonctionnera pas. Exemple : un groupe avec serial mais un sous-groupe dans --limit= et hop, ça bypass serial du sur-groupe...
Tue Jan 13 18:49:56 2015 - permalink -
-
http://shaarli.guiguishow.info/?XB7dfg