Il faut tout de même pondérer par le fait que l'on ne fait pas la même chose avec un langage de programmation classique et avec un langage pour déployer/configurer. En termes d'algorithmes, le second a en gros besoin de boucles pour faire x fois une tâche sur chaque machine, et parfois de trouver où est le serveur maître dans un cluster.
Bien sur.
Enfin pour un outil de configuration management être capable de stocker de la config sous la forme
conf:
- foo: x1
bar: y1
baz: z1
- foo: x2
bar: y2
baz: y3
puis vouloir appliquer une action pour chaque élément de la liste en utilisant foo et bar. Ne semble pas inconcevable. Pourtant l'année dernière tu tombais encore sur des bugs liés aux loops pour le faire...
Ansible semble toujours rempli de bug comme ça. Je suis un petit utilisateur et pourtant je suis déjà tombé sur plus de 10 bugs dans les boucles, when & co. Je parle de trucs ou tu finis par identifier une entrée dans le bug tracker qui te confirme que c'est un bug qui est du au fait qu'on a utilisé X pour faire Y mais qu'en fait c'est incompatible avec la sémantique alors si on patche ces trois lignes ca va le faire C'est juste effrayant de bricolage. En regardant les dernières issues ça à toujours l'air d'être la cas.
Après on peut disserter sur le fait que tu deviens un expert Jinja2 avant de devenir vaguement compétent en Ansible. La plaisir des templates de templates de templates.
Une des explications du succès d'Ansible, c'est que c'est assez facile à installer, utiliser et apprendre (ie courbe d'apprentissage à pente douce)
C'est là ou je suis à la fois d'accord et pas d'accord.
On peut rapidement bricoler quelque chose qui tombe en marche. D'ailleurs la doc n'est constituée que d'exemples. Par contre si tu veux comprendre le truc la doc donne envie de te tirer une balle. La sémantique précise des choses n'est jamais spécifiée tout est exemple et débrouille toi pour inférer la spec. Dans mon monde, ça tombe dans la catégorie des joe le bricolo, ie. nan mais c'est du (json|yaml) c'est simple cough.
Le nivellement part le bas, hello devops, est totalement en marche :D
Finalement exposer une API utilisable dans n'importe quel langage de programmation semble à postériori plus viable. Ça permet permet de construire le plan logique avec un outil expressif et robuste qui sera ensuite compilé et exécuté par l'outil spécialisé. Des approches comme https://pulumi.io/ plutôt que les bricolages type Ansible ou Terraform qui mènent à des kilomètres de (Yaml|JSON|HCL) anti-DRY.
[^] # Re: Cool.
Posté par ckyl . En réponse au journal Ansible: la version 2.7 beta 1 est disponible. Évalué à 5.
Bien sur.
Enfin pour un outil de configuration management être capable de stocker de la config sous la forme
puis vouloir appliquer une action pour chaque élément de la liste en utilisant
fooetbar. Ne semble pas inconcevable. Pourtant l'année dernière tu tombais encore sur des bugs liés aux loops pour le faire...Ansible semble toujours rempli de bug comme ça. Je suis un petit utilisateur et pourtant je suis déjà tombé sur plus de 10 bugs dans les boucles, when & co. Je parle de trucs ou tu finis par identifier une entrée dans le bug tracker qui te confirme que c'est un bug qui est du au fait qu'on a utilisé
Xpour faireYmais qu'en fait c'est incompatible avec la sémantique alors si on patche ces trois lignes ca va le faire C'est juste effrayant de bricolage. En regardant les dernières issues ça à toujours l'air d'être la cas.Après on peut disserter sur le fait que tu deviens un expert Jinja2 avant de devenir vaguement compétent en Ansible. La plaisir des templates de templates de templates.
C'est là ou je suis à la fois d'accord et pas d'accord.
On peut rapidement bricoler quelque chose qui tombe en marche. D'ailleurs la doc n'est constituée que d'exemples. Par contre si tu veux comprendre le truc la doc donne envie de te tirer une balle. La sémantique précise des choses n'est jamais spécifiée tout est exemple et débrouille toi pour inférer la spec. Dans mon monde, ça tombe dans la catégorie des joe le bricolo, ie. nan mais c'est du (json|yaml) c'est simple cough.
Le nivellement part le bas, hello devops, est totalement en marche :D
Finalement exposer une API utilisable dans n'importe quel langage de programmation semble à postériori plus viable. Ça permet permet de construire le plan logique avec un outil expressif et robuste qui sera ensuite compilé et exécuté par l'outil spécialisé. Des approches comme https://pulumi.io/ plutôt que les bricolages type Ansible ou Terraform qui mènent à des kilomètres de (Yaml|JSON|HCL) anti-DRY.