Pour éditer sérieusement les fichiers de configuration (modif' légère sur un fichier de configuration à la syntaxe structurée et qu'on utilise pas les templates jinja2): https://github.com/paluh/ansible-augeas
Et citons dans les alternatives (plus flexibles) à Ansible: https://propellor.branchable.com/
de Joey Hess (etckeeper, mr, git-annex et git-remote-gcrypt)
L'un des défaut que je trouve à Ansible est la piètre ré-utilisabilité effective des rôles.
D'un part peu de rôles offrent la possibilité de spécifier son chemin de template de fichier de configuration, à la place c'est souvent une liste très sommaire d'options
D'autre part un rôle n'est souvent intéressant que par les commandes (templates) qu'il offre, plus que par les directives d'installation (ex: rôle fail2ban qui permet d'écrire facilement des tâches lisibles pour rajouter des filtres, mais dont la manière d'installer est insatisfaisante). Il n'est pas possible à ma connaissance de profiter des fonctionnalités d'un rôles sans qu'il n'impose aussi l'installation à sa manière.
Un autre problème est la duplication souvent d'apparence inutile des modules Ansible.
Enfin l'approche role-based est intéressante, mais les choses ne sont parfois pas aussi simples.
Par exemple une machine peut faire office de reverse-proxy supportant le SSL dans certains cas, mais pas dans d'autres et d'autres tâches et/ou variables en dépendront (monitoring, chemins, ...)
Je ne suis pas certain que Ansible se prête à se niveau de flexibilité.
Sur l'aspect future-proof, une config' Ansible dépendant d'une paire de modules est-elle plus pérenne qu'un paire de shell-scripts... hum. On verra jusqu'où le support et la compatibilité suivra au fil des années et des changements de version majeure.
# alt et p-
Posté par gibs . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 2.
Pour les aspects rôles ajoutés à Fabric:
https://github.com/sebastien/cuisine#readme
Pour éditer sérieusement les fichiers de configuration (modif' légère sur un fichier de configuration à la syntaxe structurée et qu'on utilise pas les templates jinja2):
https://github.com/paluh/ansible-augeas
Et citons dans les alternatives (plus flexibles) à Ansible: https://propellor.branchable.com/
de Joey Hess (etckeeper, mr, git-annex et git-remote-gcrypt)
L'un des défaut que je trouve à Ansible est la piètre ré-utilisabilité effective des rôles.
D'un part peu de rôles offrent la possibilité de spécifier son chemin de template de fichier de configuration, à la place c'est souvent une liste très sommaire d'options
D'autre part un rôle n'est souvent intéressant que par les commandes (templates) qu'il offre, plus que par les directives d'installation (ex: rôle fail2ban qui permet d'écrire facilement des tâches lisibles pour rajouter des filtres, mais dont la manière d'installer est insatisfaisante). Il n'est pas possible à ma connaissance de profiter des fonctionnalités d'un rôles sans qu'il n'impose aussi l'installation à sa manière.
Un autre problème est la duplication souvent d'apparence inutile des modules Ansible.
Enfin l'approche role-based est intéressante, mais les choses ne sont parfois pas aussi simples.
Par exemple une machine peut faire office de reverse-proxy supportant le SSL dans certains cas, mais pas dans d'autres et d'autres tâches et/ou variables en dépendront (monitoring, chemins, ...)
Je ne suis pas certain que Ansible se prête à se niveau de flexibilité.
Sur l'aspect future-proof, une config' Ansible dépendant d'une paire de modules est-elle plus pérenne qu'un paire de shell-scripts... hum. On verra jusqu'où le support et la compatibilité suivra au fil des années et des changements de version majeure.