Variables et templates Jinja2
Pourquoi des variables
Un playbook codé en dur pour un seul environnement (une seule IP, un seul nom de domaine) n'est pas réutilisable. Les variables permettent d'écrire un playbook générique, appliqué différemment selon le contexte (dev, staging, production).
Définir des variables
# group_vars/web.yml
nginx_port: 80
app_domain: "exemple.com"
- name: Configurer nginx
hosts: web
vars:
max_connections: 1000
tasks:
- name: Déployer la configuration
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
Templates Jinja2 : générer des fichiers dynamiques
# nginx.conf.j2
server {
listen {{ nginx_port }};
server_name {{ app_domain }};
events {
worker_connections {{ max_connections }};
}
}
Ansible remplace {{ nginx_port }} et {{ app_domain }} par les valeurs réelles au moment du déploiement, générant un fichier de configuration adapté à chaque environnement.
Variables par environnement
group_vars/
production.yml # nginx_port: 443, app_domain: exemple.com
staging.yml # nginx_port: 8443, app_domain: staging.exemple.com
Le même playbook, appliqué à des groupes différents, produit des configurations différentes automatiquement.
Cas concret
Une équipe gère 3 environnements (dev, staging, production) avec des configurations nginx légèrement différentes (port, nom de domaine, niveau de logs). Sans variables, ce sont 3 playbooks quasi-identiques à maintenir en parallèle, source d'erreurs de copier-coller. Avec des group_vars par environnement et un seul playbook générique, une seule source de vérité existe pour la logique, seules les valeurs changent.
Erreurs fréquentes
- Dupliquer un playbook pour chaque environnement au lieu d'utiliser des variables : chaque correction doit alors être répétée dans chaque copie, source d'incohérences.
- Coder des secrets en clair dans les variables (mots de passe, clés API) : à chiffrer avec Ansible Vault plutôt que versionner en clair dans Git.
- Oublier l'extension
.j2sur un fichier censé être un template : Ansible le copie tel quel sans remplacer les variables.
À retenir
- Les variables permettent un playbook générique réutilisable sur plusieurs environnements.
- Les templates Jinja2 (
.j2) génèrent des fichiers de configuration dynamiques avec{{ variable }}. group_varspar groupe d'inventaire adapte automatiquement les valeurs selon l'environnement ciblé.
Mini-exercice
Le même playbook nginx doit produire une configuration différente en dev (port 8080) et en production (port 443). Comment structurer ça sans dupliquer le playbook ?
Réponse : définir nginx_port dans group_vars/dev.yml (8080) et group_vars/production.yml (443), et utiliser {{ nginx_port }} dans un template Jinja2 partagé par le playbook unique, appliqué aux deux groupes.