cela dit, le journal est clair et bien présenté, j'approuve totalement, merci JulienG !
De rien :)
Sauf qu'il faut trouver le bon curseur entre complexificatifier son module pour gérer plein de cas, et traiter des cas différents depuis un bout de programmation Yaml/Jinja2, ce qui n'est pas toujours d'une complète évidence.
Beaucoup de débats sur Ansible dans les commentaires, plus que j'aurais pensé. Je pense faire un journal supplémentaire sur ce sujet (état désiré vs programmation) dès ces prochains jours.
La syntaxe de Yaml est basée sur l'indentation, et ça rend presque forcément le résultat illisible, qu'on aime ou pas, le code Yaml se ressemble, et même avec de l'habitude il faut s'y reprendre à plusieurs fois pour bien savoir quelle est la structure représentée.
Pourquoi ?
Ou plutôt : Comment avoir autant raté son design ?
Comment réussir au final à être moins lisible que du bête JSON qui n'impose rien en terme de présentation du code ?
Idem, ça nécessite un journal en soi pour répondre avec exhaustivité.
Chaque format a été prévu avec un objectif - comme toute chose -, et souvent la créature dépasse le créateur. L'usage du Yaml pour Ansible, me semble intimement lié à cette approche d'état désiré. Cependant ce n'est là qu'un avis tout personnel.
Pour le JSON justement, ce n'est pas prioritairement un langage de représentation "humain" (fusse pouvant être lu par lui), qu'un langage d'échange entre app'. Tu n'as pas non plus la complexité d'un XML : le JSON n'a peu de types, fixés à l'avance, aucune notion de définition d'élément, etc. Cette simplicité au moins apparente, le rend pour beaucoup plus lisible que le XML (et le LISP par définition).
Le Yaml a tenté le compromis entre le peu de types à la JSON, mais la représentation lisible par l'homme à la Python - ce qui conduit à une complexité effectivement.
Et franchement, faire de la programmation en Yaml/Jinja2 c'est du pur masochisme, sadique pour le reste de l'équipe.
Ces derniers mois j'ai fait plus de la moitié de mon temps pro sur un projet complexe d'intégration en Ansible. Zéro (0, mais vraiment 0) "programmation" au sein de Jinja : pas d'usage de fonctions, pas de Python dissimulé, etc.
Étant Tech Lead, j'ai pu par contre imposer à l'équipe - et elle ne s'est pas plainte, loin de là -, l'obligation d'avoir des modules dédiés pour tout (rien en Shell dans le Yaml). Le Yaml est donc là pour porter l'état désiré, jamais une commande (je bannis l'usage du module "Shell / Win_Shell"). Si un module n'existe pas, on le créé (Python ou PS1, selon la destination).
De fait je peux t'assurer que toute la complexité est ramené à des scripts (modules) parfaitement clairs et correctement découpés, avec Ansible pour les appels et l'orchestration.
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil. Évalué à 7.
De rien :)
Beaucoup de débats sur Ansible dans les commentaires, plus que j'aurais pensé. Je pense faire un journal supplémentaire sur ce sujet (état désiré vs programmation) dès ces prochains jours.
Idem, ça nécessite un journal en soi pour répondre avec exhaustivité.
Chaque format a été prévu avec un objectif - comme toute chose -, et souvent la créature dépasse le créateur. L'usage du Yaml pour Ansible, me semble intimement lié à cette approche d'état désiré. Cependant ce n'est là qu'un avis tout personnel.
Pour le JSON justement, ce n'est pas prioritairement un langage de représentation "humain" (fusse pouvant être lu par lui), qu'un langage d'échange entre app'. Tu n'as pas non plus la complexité d'un XML : le JSON n'a peu de types, fixés à l'avance, aucune notion de définition d'élément, etc. Cette simplicité au moins apparente, le rend pour beaucoup plus lisible que le XML (et le LISP par définition).
Le Yaml a tenté le compromis entre le peu de types à la JSON, mais la représentation lisible par l'homme à la Python - ce qui conduit à une complexité effectivement.
Ces derniers mois j'ai fait plus de la moitié de mon temps pro sur un projet complexe d'intégration en Ansible. Zéro (0, mais vraiment 0) "programmation" au sein de Jinja : pas d'usage de fonctions, pas de Python dissimulé, etc.
Étant Tech Lead, j'ai pu par contre imposer à l'équipe - et elle ne s'est pas plainte, loin de là -, l'obligation d'avoir des modules dédiés pour tout (rien en Shell dans le Yaml). Le Yaml est donc là pour porter l'état désiré, jamais une commande (je bannis l'usage du module "Shell / Win_Shell"). Si un module n'existe pas, on le créé (Python ou PS1, selon la destination).
De fait je peux t'assurer que toute la complexité est ramené à des scripts (modules) parfaitement clairs et correctement découpés, avec Ansible pour les appels et l'orchestration.