* 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...