Et après tu utilises hiera ou tout autre node classifier pour gérer les différences entre les groupes de machines ou des exceptions.
J'avoue ne pas comprendre : tu peux avoir des inventaires automatiques ou des inventaires statiques ; avec des notions de groupes hiérarchisés entre eux (idem pour la gestion des varibles). Tu peux avoir cette faculté directement au sein d'Ansible. Je ne dis pas que c'est mieux qu'un autre applicatif de la même famille, mais en soi je retrouve ce potentiel dans Ansible, sans l'ombre d'un problème.
Ansible c'est juste bien pour remplacer des scripts bash de déploiement par dessus des trucs pas forcément bien gérés/administrés (...)
Si tu navigues sur Ansible-Galaxy, tu trouveras du sale. Comme tous les produits applicatifs de la planète, qui ont l'équivalent d'une place de marché aux modules.
A titre perso, je suis plutôt content que l'outil soit permissif sur les machines à qui il s'adresse. De plus ramener Ansible à un script Bash, comme cela a été dit dans les autres commentaires, c'est oublier la notion de description d'un état désiré lors de l'appel à un module - le fonctionnement normal - plutôt qu'un script impératif avec beaucoup d'embranchements.
Derrière le code exécuté peut être le même (au sens où l'action réalisée serait la même), mais l'orchestration, la maintenance et les déploiements sont radicalement différent. Ce sujet est en préambule de la doc officielle de l'outil.
Cela permet une généralisation très forte, en segmentant le module comme une opération ou un ensemble limité d'opérations dans un but déterminé. Les rôles permettent encore de produire des ensembles qui seront contextualisés par les playbooks. Ce but peut être technique ou davantage "métier".
(...) et ça plait beaucoup aux sysadmins du dimanche parce qu'ils peuvent continuer à faire de la merde comme avant, sauf que c'est en YAML donc ils peuvent dire qu'ils sont Devops et prétendre à un salaire plus élevé parce que les RH adorent ce mot.
Jugement de valeur non ? Les salariés de chez RedHat, c'est tous des sysadmins du dimanche ?
[^] # 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é à 4.
J'avoue ne pas comprendre : tu peux avoir des inventaires automatiques ou des inventaires statiques ; avec des notions de groupes hiérarchisés entre eux (idem pour la gestion des varibles). Tu peux avoir cette faculté directement au sein d'Ansible. Je ne dis pas que c'est mieux qu'un autre applicatif de la même famille, mais en soi je retrouve ce potentiel dans Ansible, sans l'ombre d'un problème.
Si tu navigues sur Ansible-Galaxy, tu trouveras du sale. Comme tous les produits applicatifs de la planète, qui ont l'équivalent d'une place de marché aux modules.
A titre perso, je suis plutôt content que l'outil soit permissif sur les machines à qui il s'adresse. De plus ramener Ansible à un script Bash, comme cela a été dit dans les autres commentaires, c'est oublier la notion de description d'un état désiré lors de l'appel à un module - le fonctionnement normal - plutôt qu'un script impératif avec beaucoup d'embranchements.
Derrière le code exécuté peut être le même (au sens où l'action réalisée serait la même), mais l'orchestration, la maintenance et les déploiements sont radicalement différent. Ce sujet est en préambule de la doc officielle de l'outil.
Cela permet une généralisation très forte, en segmentant le module comme une opération ou un ensemble limité d'opérations dans un but déterminé. Les rôles permettent encore de produire des ensembles qui seront contextualisés par les playbooks. Ce but peut être technique ou davantage "métier".
Jugement de valeur non ? Les salariés de chez RedHat, c'est tous des sysadmins du dimanche ?