Aller au contenu principal

Ansible, Un problème des solutions

· 4 minutes de lecture
Stéphane ROBERT
Consultant DevOps

logo ansible

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

Ansible-lint ne tient pas compte de ce format d'écriture. Donc vous verrez des erreurs remontées!

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 hostsall
Un noeudhost1
Plusieurs noeudshost1:host2 ou host1,host2
Un groupewebservers
Plusieurs groupeswebservers:dbservers
Exclusion de groupesall:!host1
Intersection de groupeswebservers:&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