Notoire ? Faudra en parler à la plupart des gens qui font de la CI/CD.
Ok, j'ai un peu tiré la définition de cet antipattern. L'explication est qu'on veut que le code soit statique et validé, non modifiable et séparé de la configuration qui elle peut bouger. Si la configuration est dans du code, ça veut dire que toute modification de la configuration peut potentiellement permettre de modifier le reste du code ou d'ajouter du code. Dhall n'est pas un langage de programmation complet et ne rajoutera pas de comportements dans l'appli, donc effectivement mon argument est invalide.
La CI/CD est par définition du code vu que c'est littéralement du scripting. Qu'est-ce qu'il y a de plus code que exécute ça puis ça et si 1 échoue, alors fait ça ? Suffit de regarder Luminar en bash, Buildbot avec python, Jenkins avec Groovy.
Donc tu montre bien que tu l'a cette complexité. La mettre dans un moteur de template ou dans le fichier de configuration c'est relativement subtile en fin de compte, il y a des arguments pour les 2. D'autant que les moteurs de templates sont généralement bien plus complexes que dahll. Le mettre dans la configuration simplifie drastiquement les déploiements, mais il ne marche pas avec tous les outils, l'utilisation d'un template permet de capitaliser, mais laisse passer des erreurs (si tu as déjà fais des templates yaml tu as déjà eu la contrainte par exemple sur le typage).
Malheureusement, on ne choisit pas entre les formats de conf et les moteurs de templates. On a forcément besoin des deux lors des déploiements d'applis. On a forcément besoin de générer ou de valoriser de la conf et quoi de mieux qu'un moteur de templates pour faire ça. Suffit de regarder les templates de cloud init, par exemple, qui regénèrent la conf des VMs à chaque démarrage, qui en sont un bon exemple.
Donc mon point est que vu qu'on a de toute façon besoin d'un moteur de template pour les déploiements, il vaut mieux que la configuration soit la plus simple possible syntaxiquement afin de faciliter la création des templates et d'éviter de faire des échappements problématiques.
Ce qui me gène aussi avec Dhall, j'insiste, c'est la complexité. Ils appellent ça un language de configuration, pour moi c'est juste un deuxième moteur de template empilé sur le premier et un deuxième langage de programmation. Ça donne de bonnes choses, comme le système de types et de moins bons, la complexité et la diversité du code qu'on peut faire. Peut-être que c'est un super moteur de templating, avec de géniaux outils de validation et de refactoring, mais ça reste juste un moteur de templating pour faire du json ou du yaml, à moins sans doute d'embarquer une lib. Et si vous dites à vos sysadmins que c'est un meilleur moteur de templating que celui intégré à Ansible, je pense que vous obtiendrez juste un lever de sourcil, et que votre sysadmin adoré (j'adore les miens, en tous cas) retournera à ses scripts ansible et ses templates jinja2.
J'en reviens à la même question :
- Quel problème résout cet outil qui n'est pas résolu par des outils ou des process existants, qui marchent déjà ?
Probablement les soucis de structure et de typage de conf, mais de toute façon, vu qu'on a besoin d'un autre moteur de templating pour le déploiement, ça ne résout pas les problèmes générés par cet autre moteur de templating. Et de toute façon, même si la validation de Dhall dit que tout va bien, ça ne veut pas dire que l'appli va fonctionner avec cette conf, donc ça ne dispense pas de tester en pré-prod ou de faire du A/B testing.
Ma conclusion serait donc, pourquoi pas l'utiliser si c'est intégré à Ansible et ses amis pour remplacer partiellement jinja2, mais hormis ce cas d'usage, j'ai du mal à voir les bénéfices réels.
[^] # Re: Où est l'intérêt ?
Posté par damaki . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 3.
Ok, j'ai un peu tiré la définition de cet antipattern. L'explication est qu'on veut que le code soit statique et validé, non modifiable et séparé de la configuration qui elle peut bouger. Si la configuration est dans du code, ça veut dire que toute modification de la configuration peut potentiellement permettre de modifier le reste du code ou d'ajouter du code. Dhall n'est pas un langage de programmation complet et ne rajoutera pas de comportements dans l'appli, donc effectivement mon argument est invalide.
La CI/CD est par définition du code vu que c'est littéralement du scripting. Qu'est-ce qu'il y a de plus code que exécute ça puis ça et si 1 échoue, alors fait ça ? Suffit de regarder Luminar en bash, Buildbot avec python, Jenkins avec Groovy.
Malheureusement, on ne choisit pas entre les formats de conf et les moteurs de templates. On a forcément besoin des deux lors des déploiements d'applis. On a forcément besoin de générer ou de valoriser de la conf et quoi de mieux qu'un moteur de templates pour faire ça. Suffit de regarder les templates de cloud init, par exemple, qui regénèrent la conf des VMs à chaque démarrage, qui en sont un bon exemple.
Donc mon point est que vu qu'on a de toute façon besoin d'un moteur de template pour les déploiements, il vaut mieux que la configuration soit la plus simple possible syntaxiquement afin de faciliter la création des templates et d'éviter de faire des échappements problématiques.
Ce qui me gène aussi avec Dhall, j'insiste, c'est la complexité. Ils appellent ça un language de configuration, pour moi c'est juste un deuxième moteur de template empilé sur le premier et un deuxième langage de programmation. Ça donne de bonnes choses, comme le système de types et de moins bons, la complexité et la diversité du code qu'on peut faire. Peut-être que c'est un super moteur de templating, avec de géniaux outils de validation et de refactoring, mais ça reste juste un moteur de templating pour faire du json ou du yaml, à moins sans doute d'embarquer une lib. Et si vous dites à vos sysadmins que c'est un meilleur moteur de templating que celui intégré à Ansible, je pense que vous obtiendrez juste un lever de sourcil, et que votre sysadmin adoré (j'adore les miens, en tous cas) retournera à ses scripts ansible et ses templates jinja2.
J'en reviens à la même question :
- Quel problème résout cet outil qui n'est pas résolu par des outils ou des process existants, qui marchent déjà ?
Probablement les soucis de structure et de typage de conf, mais de toute façon, vu qu'on a besoin d'un autre moteur de templating pour le déploiement, ça ne résout pas les problèmes générés par cet autre moteur de templating. Et de toute façon, même si la validation de Dhall dit que tout va bien, ça ne veut pas dire que l'appli va fonctionner avec cette conf, donc ça ne dispense pas de tester en pré-prod ou de faire du A/B testing.
Ma conclusion serait donc, pourquoi pas l'utiliser si c'est intégré à Ansible et ses amis pour remplacer partiellement jinja2, mais hormis ce cas d'usage, j'ai du mal à voir les bénéfices réels.