tuto2: add parts on notify, playbooks, ...

tutorial/ansible/ansible.md

@@ -241,3 +241,188 @@ disposition](http://docs.ansible.com/ansible/latest/modules_by_category.html)
 de copier vos fichiers de configuration à leur place et avec les bons droits
 (`authorized_keys`, `.bashrc`, ...). Installez également les paquets que vous
 aviez installé à la main (client DHCP, `htop`, ...).
+
+
+Les notifications
+-----------------
+
+Au sein d'un *playbook*, il est possible de définir des tâches particulières
+(nommées *handlers* dans le vocabulaire Ansible), qui ne seront exécutées que
+si un changement à eu lieu. Par exemple, nous pourrions déclarer une tâche de
+redémarrage du serveur web, seulement lorsque sa configuration est mise à
+jour.
+
+Pour se faire, il faut ajouter un élément `notify` à sa tâche :
+
+<div lang="en-US">
+```yaml
+    - name: template configuration file
+      template: src=template.j2 dest=/etc/httpd.conf
+      notify:
+        - restart cherokee
+```
+</div>
+
+Puis, au même niveau que les *tasks*, on déclare nos *handlers* :
+
+<div lang="en-US">
+```yaml
+    handlers:
+      - name: restart cherokee
+        service: name=cherokee state=restarted
+```
+</div>
+
+Il est attendu que le nom de la notification corresponde à l'attribut `name`
+d'un handler.
+
+Voir [la
+documentation](http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change)
+pour davantage de détails et d'exemples.
+
+La configuration de votre serveur SSH laisse à désirer. Corriger les problèmes
+énoncés par ces deux articles :
+
+- <https://ringyt.wordpress.com/2017/05/23/default-hardened-ssh-server-config/> ;
+- <https://stribika.github.io/2015/01/04/secure-secure-shell.html>.
+
+Mettez en place un *handler* pour relancer votre serveur SSH en cas de
+modification de sa configuration.
+
+
+Les variables
+-------------
+
+Les variables peuvent provenir de très nombreux emplacements : définies
+spécifiquement pour l'hôte, chargées depuis des fichiers lié au groupe auquel
+appartient la machine, liées à la recette ou à la tâche en cours d'exécution,
+récupérée par un module (comme le module `setup`).
+
+
+### Définition
+
+#### Dans l'inventaire
+
+<div lang="en-US">
+```yaml
+    all:
+      hosts:
+        192.168.0.106
+      vars:
+        ntp_server: ntp.epitech.eu
+```
+</div>
+
+Cet inventaire définit une variable `ntp_server` qui pourra ensuite être
+utilisée par une recette installant un serveur NTP. Le cadre d'utilisation de
+ce genre de variable est adapté lorsqu'un hôte ou un groupe d'hôte seulement
+partagent des caractéristiques, comme par exemple leur localisation ou
+datacenter de rattachement, etc.
+
+
+#### Dans un *playbook*
+
+De la même manière que dans l'inventaire, il est possible de définir des
+variables dans une recette :
+
+<div lang="en-US">
+```yaml
+    - hosts: webservers
+      vars:
+        http_port: 80
+```
+</div>
+
+Ces variables peuvent être placées dans un fichier, pour plus de lisibilité :
+
+<div lang="en-US">
+```yaml
+    - hosts: webservers
+      vars_files:
+        - /vars/webservers_common.yml
+```
+</div>
+
+Le format correspond au sous arbre que l'on pourrait trouver sous `vars` :
+
+<div lang="en-US">
+```yaml
+    http_port: 80
+    https_port: 443
+```
+</div>
+
+
+### Utilisation
+
+#### Modèles
+
+Ces variables peuvent être utilisées pour remplir un emplacement de texte dans
+un modèle. Ansible utilise [Jinja2](http://jinja.pocoo.org/) comme moteur de
+template, un format très courant dans le milieu du développement Python.
+
+<div lang="en-US">
+```
+    I'm running {{ ansible_system }} {{ ansible_os_family }} on {{ ansible_system_vendor }},
+      with {{ ansible_memory_mb.swap.free }} MB Swap available.
+```
+</div>
+
+Ce format est relativement générique. Ainsi, pour accéder aux éléments d'une
+table de hash/dictionnaire, on utilise le caractère `.` ;
+
+Les crochets `[x]` sont utilisés principalement pour accéder aux éléments des
+tableaux :
+
+```
+    My first nameserver is: {{ ansible_dns.nameservers[0] }}.
+```
+
+ou d'un dictionnaire lorsque la clef doit être récupérée d'une variable :
+
+```
+    My disks are: {% for disk in ansible_device_links.uuids %}
+      - {{ disk }}: {{ ansible_device_links.uuids[disk] }}, {{ ansible_device_links.ids[disk]|join(', ') }}
+    {% endfor %}
+```
+
+Notez dans ce dernier exemple l'utilisation d'un filtre `join` permettant
+d'aplatir la liste retournée.
+
+#### Dans les recettes
+
+Au sein même de votre description YAML, vous pouvez utiliser la puissance de
+Jinja2 :
+
+<div lang="en-US">
+```yaml
+    - hosts: webservers
+      vars_files:
+        - /vars/webservers_common.yml
+        - /vars/webservers_{{ ansible_os_family }}.yml
+```
+</div>
+
+Dans cet exemple, les variables des fichiers `/vars/webservers_common.yml`,
+puis celles de `/vars/webservers_Debian.yml` seront chargées dans le contexte.
+
+
+#### Conditions
+
+Une autre utilisation possible des variables est d'appliquer ou de passer des
+tâches. Par exemple :
+
+<div lang="en-US">
+```yaml
+    tasks:
+      - name: "pkg setup (Debian)"
+        apt: name=chrony state=present
+        when: ansible_os_family == "Debian"
+      - name: "pkg setup (CentOS)"
+        yum: name=chrony state=present
+        when: ansible_os_family == "CentOS"
+```
+</div>
+
+Vous trouverez bien d'autres cas d'utilisation dans [la
+documentation](http://docs.ansible.com/ansible/latest/playbooks_conditionals.html).