Normaliser sa configuration là où le templating n'existe pas

Temps de lecture estimé : 2 minutes

Lorsqu’on produit une pile technique avec plusieurs environnements, nous devons variabiliser les configurations de nos outils pour différencier les contextes d’exécution. Pour cela, comment procède-t-on ? Est-on condamné à créer autant de fichiers que d’environnements (ex: mysql.{local,testing,prod}.cnf) pour ne téléverser et n’exploiter que le bon ?

Ça pose des problèmes évidents, dont le plus grave est que vous ne verrez que le fichier X est mauvais qu’au moment de l’utiliser, donc après son déploiement, pas avant.

Une façon élégante de faire est de définir les éléments changeants comme variables d’environnement, puis de faire en sorte que vos outils consomment ces variables. Certains outils comme Apache embarquent directement cette fonctionnalité :

# /usr/local/apache2/conf/extra/httpd-redwatch.conf
<VirtualHost *:80>
    DocumentRoot "/usr/local/apache2/docs/redwatch.io"
    ServerName ${SERVER_NAME}
</VirtualHost>

Mais pas tous, à l’instar de Redis, MySQL ou Nginx. C’est d’ailleurs en étudiant le docker de ce dernier que je suis tombé sur l’outil qui nous intéresse aujourd’hui : envsubst.

Le fonctionnement de envsubst est des plus simples : il substitue les variables d’environnement d’un input et l’envoie vers un output :

/ # echo $HOSTNAME
d0c3fe075146
/ # envsubst
Hello, my server name is $HOSTNAME
Hello, my server name is d0c3fe075146

Ainsi, nous pouvons créer un template de notre configuration :

# /etc/mytool/config.tmpl
[server]
memory_limit = ${MEMORY_LIMIT}

Puis construire le fichier final :

$ envsubst < /etc/mytool/config.tmpl > /etc/mytool/final.cfg
$ cat /etc/mytool/final.cfg
[server]
memory_limit = 2G
$ mytool restart

NB: Attention, seules les variables d’environnement exportées sont exploitables. Pour les lister, faites export -p

Ce que j’aime avec envsubst c’est qu’il est ultra léger et qu’il s’adapte à tout type de situations. Là où un Ansible n’est pas adapté (comme à l’intérieur d’un Docker par exemple), il vous aidera à augmenter la parité de vos systèmes via la création de templates de configuration. Notez qu’il est pré-installé sur la plupart des distributions, sinon vous le trouverez dans le package gettext.

Comme d’habitude, vous pouvez retrouver le code pour essayer par vous-même sur le dépôt d’exemple.


Sources :


    Ce billet vous a plu ? Partagez-le sur les réseaux…


    … Ou inscrivez-vous à la newsletter pour ne manquer aucun article (Si vous ne voyez pas le formulaire, désactivez temporairement uBlock).

    Voir aussi