Jinja4Config — Générateur de configuration

Contexte

Sur le projet Argon, modifier manuellement les fichiers .env de chaque service dès qu'une valeur changeait — ou qu'on switchait d'environnement — devenait vite fastidieux. La première solution était un script shell qui propageait les valeurs communes, mais elle n'était pas très propre et ne fonctionnait pas sur Windows.

J'ai décidé de repartir sur quelque chose de plus solide : des templates Jinja2 pour avoir de vraies capacités de formatage (conditions, boucles, références entre valeurs), et Python + Docker pour rendre l'outil portable sur tous les environnements. On écrit les valeurs une seule fois dans un fichier de config central, et les .env de chaque service sont générés à partir des templates. Changer d'environnement revient à pointer vers un autre fichier de config — tous les fichiers suivent.

Cas d'usage

Argon

Sur le projet Argon, un micro-ERP en microservices, les services tournent dans trois environnements : local, démo et prod. Chaque environnement a son propre config.yaml avec les valeurs qui varient — URL des services, credentials, noms de base de données. Les templates .env.j2 sont communs à tous les environnements. Un seul appel régénère tous les .env du monorepo :

python build.py --config config.prod.yaml $(find . -name "*.env.j2")

Switcher du local à la prod revient à changer config.prod.yaml en config.local.yaml.

Kairo

Sur le projet Kairo, une plateforme d'apprentissage pour développeurs basée sur des tests automatiques, Jinja4Config génère les fichiers de configuration pour les tests d'intégration : identifiants de base de données partagés, URLs de connexion entre services, secrets de test. Les services de test partagent les mêmes valeurs sans les dupliquer dans chaque projet.

Fonctionnement

L'outil prend en entrée un fichier de config (YAML ou JSON) et un ou plusieurs templates Jinja2, et produit les fichiers correspondants en retirant l'extension .j2 :

Exemple concret :

config.yaml

database:
  host: localhost
  port: 5432
  name: argon_db
api:
  base_url: "https://api.example.com"
  v1_url: "{{ api.base_url }}/v1"

service.env.j2

DATABASE_URL=postgresql://{{ database.host }}:{{ database.port }}/{{ database.name }}
API_URL={{ api.v1_url }}
GENERATED_AT={{ now() }}

service.env (résultat)

DATABASE_URL=postgresql://localhost:5432/argon_db
API_URL=https://api.example.com/v1
GENERATED_AT=2025-06-14 10:22:00

Les valeurs du config peuvent se référencer entre elles — api.v1_url utilise api.base_url et la résolution est récursive.

Fonctionnalités Jinja2

Jinja4Config expose des filtres et fonctions supplémentaires dans les templates.

Lecture des variables d'environnement :

{{ 'DATABASE_HOST' | env('localhost') }}
{{ env.PATH }}

Utile pour injecter des valeurs sensibles (mots de passe, clés d'API) sans les écrire dans le fichier de config.

Logique conditionnelle (Jinja2 natif) :

{% if ssl.enabled %}
SSL_CERT={{ ssl.cert }}
SSL_KEY={{ ssl.key }}
{% endif %}

Validation du config (optionnelle) :

python build.py --config config.yaml --schema schema.json service.env.j2

Un schéma JSON Schema peut être fourni pour valider le fichier de config avant la génération — pratique pour détecter une valeur manquante avant que le déploiement ne parte en erreur.

Docker

Pour l'intégration en CI/CD sans installation Python :

docker run -v $(pwd):/workspace \
  -e DB_PASSWORD=secret \
  ghcr.io/flavien-chenu/jinja4config \
  --config config.prod.yaml service.env.j2