TroisiĂšme partie consacrĂ©e Ă  l’outil Ansible, nous allons attaquer l’Ă©criture et l’exĂ©cution de playbooks.

Un premier playbook

Nous avons pas mal parlĂ© des exĂ©cutions ad hoc d’Ansible permettant de lancer unitairement un module et obtenir le rĂ©sultat. Les Playbooks ont pour intĂ©rĂȘt d’Ă©crire un scĂ©nario complet d’exĂ©cution de plusieurs modules avec des conditions et des critĂšres de succĂšs/Ă©chec et des actions selon l’Ă©vĂšnement dĂ©clenchĂ©. Les playbooks sont Ă©crits en YAML et utilisent un langage dĂ©claratif simple propre Ă  Ansible.

Un playbook est constituĂ© Ă  minima de deux instructions : les hosts sur qui jouer et la tĂąche Ă  exĂ©cuter. Les hosts sont soit un des groupes dĂ©finis dans votre inventaire (comme nous avons vu dans le prĂ©cĂ©dent billet), soit la totalitĂ© de vos hosts avec l’instruction all.

Prenons un exemple simple d’un playbook installant le serveur web Apache en derniĂšre version, dĂ©ployant une configuration voulue et redĂ©marrant le service si nĂ©cessaire. (exemple issu de la documentation officielle Ansible)

---
- hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: ensure apache is at the latest version
    yum:
      name: httpd
      state: latest
  - name: write the apache config file
    template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf
    notify:
    - restart apache
  - name: ensure apache is running
    service:
      name: httpd
      state: started
  handlers:
    - name: restart apache
      service:
        name: httpd
        state: restarted

Un playbook peut contenir des exécutions pour différents hosts, exemple sur une installation de serveur web et base de données.

---
- hosts: webservers
  remote_user: root

  tasks:
  - name: ensure apache is at the latest version
    yum:
      name: httpd
      state: latest
  - name: write the apache config file
    template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf

- hosts: databases
  remote_user: root

  tasks:
  - name: ensure postgresql is at the latest version
    yum:
      name: postgresql
      state: latest
  - name: ensure that postgresql is started
    service:
      name: postgresql
      state: started

Un playbook vide entraĂźnera une erreur Ansible indiquant qu’il n’a pas trouvĂ© d’action Ă  faire.

DĂ©taillons les instructions.

DĂ©claration hosts et utilisateurs

Un playbook commence toujours par le groupe de hosts sur lequel il doit agir. Cela peut ĂȘtre all si celui-ci doit attaquer la totalitĂ© des hosts de l’inventaire. On peut ensuite lui indiquer l’utilisateur distant avec lequel l’action sera dĂ©clenchĂ©e. A noter que si le remote_user n’est pas spĂ©cifiĂ©, il se connectera avec le profil courant qui exĂ©cute la commande ansible-playbook.

---
- hosts: webservers
  remote_user: root

Dans le cas oĂč l’utilisateur distant n’a pas assez de pouvoir, on peut lui spĂ©cifier qu’il doit faire une escalade de privilĂšges si cet utilisateur a les droits suffisants.

---
- hosts: webservers
  remote_user: jeanmichel
  become: yes

Par dĂ©faut, l’instruction become passera en root. On peut spĂ©cifier un utilisateur particulier.

---
- hosts: webservers
  remote_user: jeanmichel
  become: yes
  become_user: maurice

Les actions become et become_user peuvent ĂȘtre spĂ©cifiĂ©es au niveau d’une tĂąche pour ne s’appliquer qu’Ă  celle-ci.

---
- hosts: webservers
  remote_user: jeanmichel
  tasks:
    - service:
        name: httpd
        state: started
      become: yes

DĂ©claration des tĂąches

La liste des tĂąches d’un playbook commence par l’instruction tasks. Les tĂąches sont des appels de modules Ansible, configurĂ©s avec diffĂ©rentes options variant selon les modules.

Exemple de tùche démarrant Apache HTTPD.

tasks:
  service:
    name: httpd
    state: started

Une bonne pratique est de toujours nommer ses tĂąches avec l’instruction name pour avoir une meilleure lisibilitĂ©.

tasks:
  - name: "Start httpd"
    service:
      name: httpd
      state: started

Si les modules ont leur propres arguments, les tùches peuvent avoir une liste de paramÚtres généraux :

  • tags : permet d’attribuer un libellĂ© Ă  une tĂąche pour cibler ou exclure celle-ci lors de l’exĂ©cution du playbook
  • become : activer l’Ă©lĂ©vation de privilĂšge
  • become_user: exĂ©cuter en tant que le user spĂ©cifiĂ©
  • ignore_errors : permet d’ignorer une Ă©ventuelle erreur
  • changed_when / failed_when : permet de conditionner le changement d’Ă©tat changed ou failed de la tĂąche (pratique pour une tĂąche shell arbitraire par exemple)
  • environment : pour charger des variables d’environnement
  • notify : dĂ©clenche un handler (voir aprĂšs)

La liste est non exhaustive, j’ai indiquĂ© les plus courants dans mon utilisation.

Les handlers pour exécuter une action sur changement

Les handlers sont une action qui se dĂ©clenche sur un Ă©tat changed d’une tĂąche. Ils sont appelĂ©s par l’instruction notify d’une tĂąche Ă  laquelle on indique le name du handler.

Exemple sur une tĂąche rechargeant le serveur Apache HTTPD sur mise Ă  jour de config.

tasks:
  - name: "Deploy httpd configuration"
  template:
      src: etc_httpd_conf_httpd.conf.j2
      dest: /etc/httpd/conf/httpd.conf
  notify:
      - reload httpd

# handler pour prise en charge du reload
handlers:
  - name: "reload httpd"
    service:
      name: httpd
      state: reloaded

Si le template httpd.conf a modifiĂ© le fichier sur le host distant, il notifiera au handler “reload httpd” de s’exĂ©cuter. Les handlers sont exĂ©cutĂ©s aprĂšs les tĂąches du playbook, indiquĂ©s par l’action “HANDLERS” Ă  la fin de l’exĂ©cution gĂ©nĂ©ralement.

Il est possible de mettre plusieurs handlers Ă  une tĂąche. A noter que ceux-ci seront exĂ©cutĂ©s dans l’ordre oĂč sont Ă©crits dans le playbook et non dans l’ordre oĂč ils sont listĂ©s sur la tĂąche.

Bien que plusieurs tĂąches peuvent notifier le mĂȘme handler (exemple : on dĂ©ploie la configuration httpd.conf + plusieurs vhosts avec plusieurs tĂąches sĂ©parĂ©es), celui-ci ne sera jouĂ© qu’une seule fois.

Conclusion

Le Playbook est l’un des principaux Ă©lĂ©ments avec l’inventaire pour utiliser Ansible. Vous pouvez rĂ©diger des playbooks faisant de nombreuses actions avec beaucoup de conditions, mais cela ne sera pas forcĂ©ment la mĂ©thode la plus efficiente. Dans le prochain billet, nous verrons les rĂŽles Ansible, un moyen d’avoir du code rĂ©utilisable et pouvant ĂȘtre orchestrĂ© via les Playbooks.