Ansible, Un problème des solutions

**Sur cette page sera regroupé toute une série de tips et réponses à vos questions fréquentes. Cette page sera mise à jour régulièrement !

Si vous avez une question sans réponse Posez la en commentaire. J’essaierai d’y répondre.**

Tips

Je vous propose en plus de tous les billets sur Ansible de regrouper ici les tips et les solutions aux questions que l’on se pose souvent lors d’écriture de playbooks ou de rôles Ansible. Il pourra s’agir de liens vers d’autres billets mais aussi de réponses directes.

Si vous ne trouvez pas la réponse vous posez m’envoyer un message sur mon compte Linkedin ↗ et j’essaierai d’y répondre. Cela viendra enrichir ce billet.

Simplifier l’écriture des playbooks

module_defaults

Si vous utilisez souvent le même module avec les mêmes arguments, il peut être utile de définir ces arguments par défaut au début de celui-ci à l’aide du mot-clé module_defaults.

Par exemple ici on vient créer des droits par défaut pour le module file.

- hosts: localhost
  module_defaults:
    ansible.builtin.file:
      owner: root
      group: root
      mode: 0755
  tasks:
    - name: Create file1
      ansible.builtin.file:
        state: touch
        path: /tmp/file1

    - name: Create file2
      ansible.builtin.file:
        state: touch
        path: /tmp/file2

    - name: Create file3
      ansible.builtin.file:
        state: touch
        path: /tmp/file3

Les ancres et alias YAML

Ici on va utiliser un tip YAML: Les ancres et les alias YAML ↗

Les ancres YAML permet de référencer un élément pour l’utiliser ailleurs dans votre fichier. Les ancres sont créées à l’aide du signe &. Le signe est suivi d’un nom d’alias. Vous pouvez utiliser cet alias ultérieurement avec une * devant. Pour fusionner une propriété il faut ajouter l’opérateur merge << devant.

---
...
vars:
    app1:
        jvm: &jvm_opts
            opts: '-Xms1G -Xmx2G'
            port: 1000
            path: /usr/lib/app1
    app2:
        jvm:
            <<: *jvm_opts
            path: /usr/lib/app2
...

app1 et app2 utilisent les même valeurs pour port et opts mais pas pour path qui est écrasé par l’opérateur merge <<

Cibler les hôtes et groupes avec les modèles

Lorsque vous utilisez les commandes ansible et ansible-playbook, vous devez indiquer sur quels nœuds ou quels groupes sur lesquels ils devront s’exécuter. Les modèles peuvent faire référence à un seul nœud, une adresse IP, un groupe d’inventaire, un ensemble de groupes ou tous les nœuds de votre inventaire. Il est aussi possible :

d’exclure des cible avec le caractère !
de faire des intersections de groupe avec le caractère &

Cible(s)	modèle(s)
Tous les hosts	all
Un noeud	host1
Plusieurs noeuds	host1:host2 ou host1,host2
Un groupe	webservers
Plusieurs groupes	webservers:dbservers
Exclusion de groupes	all:!host1
Intersection de groupes	webservers:&staging

Questions fréquentes

Est il possible de gérer les exceptions?

OUI Ansible propose un mécanisme permettant de gérer les erreurs via les blocks et rescue

Comment ignorer des erreurs de hosts inaccessibles?

Il est possible d’ignorer un échec de tâche en raison du fait que l’instance hôte est « UNREACHABLE » avec ignore_unreachable.

Elle ne sera exclue définitivement, les taches suivantes tomberont en erreur si elle ne possède pas cette propriété!

- name: Cette tache ne tombera pas en erreur si un des cibles est inaccessible
  ansible.builtin.command: /bin/true
  ignore_unreachable: yes

- name: Pour ici oui
  ansible.builtin.command: /bin/true

Pour généraliser ce comportement à tout un playbook il suffit de l’utiliser à ce niveau. Pour exclure une tache il faudra la mettre à no sur celle-ci.

- hosts: all
  ignore_unreachable: yes
  tasks:
  - name: This executes, fails, and the failure is ignored
    ansible.builtin.command: /bin/true

  - name: This executes, fails, and ends the play for this host
    ansible.builtin.command: /bin/true
    ignore_unreachable: no

Est il possible de lancer des taches asynchrones avec Ansible?

OUI. Ansible propose un système de tache asynchrone