Jinja + Templates¶

Le module copy déploie un fichier tel quel, sans interprétation. Dès qu'un fichier de configuration doit contenir des valeurs qui dépendent de l'hôte cible, copy ne suffit plus : ou alors il faudrait maintenir une variante du fichier par cible.

Le module template résout ce problème en faisant passer le fichier source par le moteur Jinja2 avant de l'écrire sur la cible. Les expressions {{ variable }}, {% for %}, {% if %}… sont évaluées avec le contexte de l'hôte (variables d'inventaire, facts, vars…), exactement comme dans un playbook.

Mise en place du lab¶

On démarre les VM de l'atelier puis on se connecte au Control Host :

cd $HOME/git/gh/formation-ansible/atelier-18
vagrant up
^up^ssh ansible

# sur le control host
cd ansible/projets/ema/playbooks/

La structure du projet contient déjà un dossier templates/ avec deux templates de démonstration, et un playbook ansible-03.yml qui les déploie comme page d'accueil Apache sur chaque cible.

Premier exemple : variables dans un template¶

Le template index.html.j2 injecte une variable ansible {{ inventory_hostname }} dans le contenu d'une page HTML. Le playbook ansible-03.yml le copie sur chaque Target Host avec le module template, puis je valide le résultat avec curl depuis le Control Host :

ansible-playbook ansible-03.yml
for target in rocky debian suse ubuntu; do curl "$target"; done

Chaque cible renvoie une page personnalisée preuve que le rendu est bien fait par hôte, à partir d'un seul fichier source.

Deuxième exemple : boucles Jinja2¶

index-2.html.j2 va plus loin : il utilise une boucle {% for %} pour générer dynamiquement une liste HTML à partir d'une variable de type liste (all).

À vous de jouer¶

L'objectif est de reprendre le déploiement de Chrony du Workshop 13 qui dupliquait le fichier chrony.conf via le module copy et de le remplacer par un seul template Jinja2. Le fichier de configuration n'a pas besoin d'être différent par distribution, mais son emplacement (/etc/chrony/chrony.conf sous Debian, /etc/chrony.conf partout ailleurs...) et le nom du service (chrony vs chronyd) varient. On reprend donc l'approche include_vars du workshop précédent.

1. Création du template et des variables par famille d'OS¶

On crée le template chrony.conf.j2 dans templates/, ainsi que les fichiers de variables par famille d'OS (vars/chrony_debian.yml, vars/chrony_redhat.yml, vars/chrony_suse.yml). La seule expression Jinja2 utilisée ici est {{ chrony_confdir }} dans l'en-tête du fichier, à titre de marqueur, l'essentiel est que la destination dépend de la distribution.

cat > templates/chrony.conf.j2 <<'EOF'
# {{ chrony_confdir }}/chrony.conf - managed by ansible
server 0.fr.pool.ntp.org iburst
server 1.fr.pool.ntp.org iburst
server 2.fr.pool.ntp.org iburst
server 3.fr.pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony
EOF

mkdir -p vars
for f in debian redhat suse; do
  [ "$f" = "debian" ] && s=chrony c=/etc/chrony || s=chronyd c=/etc
  cat > vars/chrony_${f}.yml <<EOF
---
chrony_package: chrony
chrony_service: ${s}
chrony_confdir: ${c}
EOF
done

2. Le playbook chrony.yml¶

Le playbook charge les variables spécifiques à l'OS, installe le paquet chrony via le module générique package, déploie la configuration avec template (qui notifie un handler de redémarrage en cas de changement), démarre le service, puis vérifie l'application de l'état instruit avec chronyc tracking et chronyc sources. L'appel explicite à meta: flush_handlers force l'exécution du handler avant les tâches de vérification, sinon chronyc interrogerait un démon qui n'a pas encore relu sa configuration...

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

---
# chrony.yml
- name: configure chrony ntp sync with jinja2 template
  hosts: all
  become: true
  tasks:

    - name: load distribution-specific vars
      ansible.builtin.include_vars: "vars/chrony_{{ ansible_os_family | lower }}.yml"

    - name: update apt cache (debian based)
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600
      when: ansible_os_family == "Debian"

    - name: install chrony
      ansible.builtin.package:
        name: "{{ chrony_package }}"
        state: present

    - name: deploy chrony.conf from jinja2 template
      ansible.builtin.template:
        src: chrony.conf.j2
        dest: "{{ chrony_confdir }}/chrony.conf"
        owner: root
        group: root
        mode: "0644"
      notify: restart chrony

    - name: start + enable chrony
      ansible.builtin.service:
        name: "{{ chrony_service }}"
        state: started
        enabled: true

    - name: flush handlers to apply restart now
      ansible.builtin.meta: flush_handlers

    - name: read deployed chrony.conf
      ansible.builtin.slurp:
        src: "{{ chrony_confdir }}/chrony.conf"
      register: chrony_conf_file

    - name: show deployed chrony.conf content
      ansible.builtin.debug:
        msg: "{{ (chrony_conf_file.content | b64decode).split('\n') }}"

    - name: wait a bit for chrony to reach sources
      ansible.builtin.pause:
        seconds: 5

    - name: check chrony tracking
      ansible.builtin.command: chronyc tracking
      register: chrony_tracking
      changed_when: false

    - name: show chrony tracking
      ansible.builtin.debug:
        var: chrony_tracking.stdout_lines

    - name: check chrony sources
      ansible.builtin.command: chronyc -n sources
      register: chrony_sources
      changed_when: false

    - name: show chrony sources
      ansible.builtin.debug:
        var: chrony_sources.stdout_lines

  handlers:
    - name: restart chrony
      ansible.builtin.service:
        name: "{{ chrony_service }}"
        state: restarted
...

3. Exécution et validation¶

À la première exécution, la tâche template passe en changed (le fichier est créé), le handler restart chrony est notifié puis joué via flush_handlers, et les tâches chronyc tracking et chronyc sources confirment la synchronisation effective sur chacune des quatre distributions.

Une seconde exécution affiche changed=0 : template compare le rendu Jinja2 au contenu déjà présent sur la cible et ne touche au fichier que s'il diffère (c'est ce qui rend le playbook idempotent malgré son apparente complexité...).

Cheatsheet¶

Vu par expérience post-playbook.

Sources (principales)¶

• Docs ansible Templating with Jinja2
• Docs ansible ansible.builtin.template module
• Docs ansible Filters (liste complète des filtres Jinja2 utilisables)
• Docs ansible Tests (is defined, is match, etc.)
• Docs ansible Lookups (charger des données externes dans un template)
• Jinja2 Template designer documentation
• Jinja2 Whitespace control ({%- / -%}, trim_blocks, lstrip_blocks)
• Docs ansible ansible.builtin.copy module (pour comparaison)

Précédent : Heterogeneous Targets