Polarys
Automatisation avec Ansible/Les bases d'Ansible

Les bases d'Ansible

Variables et templates Jinja2

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 .j2 sur 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_vars par 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.

Quiz de validation

Quiz - 2 questions

1. À quoi sert un template Jinja2 dans Ansible ?

2. Comment adapter automatiquement une configuration selon l'environnement (dev/production) sans dupliquer le playbook ?

Suis ta progression

Crée un compte gratuit pour suivre ta progression et accéder à toutes les leçons.