Et citons dans les alternatives (plus flexibles) à Ansible: https://propellor.branchable.com/
de Joey Hess (etckeeper, mr, git-annex et git-remote-gcrypt)
Alors, j'ai croisé pour le moment personne qui utilise propellor. Et pourtant, je passe mon temps à zoner dans les meetups et ce genre de choses. Pour dire, j'ai croisé plus de gens avec cfengine, ou bcfg2 que propellor.
Dire "y a pas besoin d'apprendre un langage particulier, suffit juste de connaitre haskell" est un chouia trompeur :)
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'une manière générale, tu peux difficilement avoir la configurabilité que propose la configuration d'un logicial sous forme d'une liste d'options, donc tu va jamais aller très loin avec les roles/formules/modules/cookbooks des autres. Si tu veux réutiliser, il faut construire au dessus, ou prendre des trucs de bases ( example, ntpd me parait le truc qu'on peut réutiliser sans souci, vu que les gens vont changer au mieux 2/3 trucs )
Et pouvoir injecter tes propres fichiers, c'est globalement chercher les emmerdes, car le fichier deviens parti intégrante de l'interface du soft avec le reste du monde.
Exemple, tu veux déployer mediawiki. Dans un monde idéal, tu devrais pouvoir reprendre un role apache et voila. En pratique, vu que mediawiki doit toucher à la config apache ( pour se placer dans un vhost, ou avec une url particuliére ), il y a un couplage entre les 2. Et pire encore, le couplage est non exprimé de façon formel donc risque de casser à tout moment. J'utilise une convention d'avoir /etc/httpd/conf.d/$vhost.conf.d/ pour qu'un soft dépose un fichier de configuration apache, qui s'applique à $vhost.
Si tu décides de prendre une autre convention ou de changer le templates, tu peux casser ça. Mais comme c'est pas exprimé comme le serait une fonction ( ce que puppet propose ) avec verification à la compilation, tu dois déployer et voir que ça ne marche pas. Et même, une fois que tu as une fonction, tout ce que tu peux rajouter comme argument doit être supporté à jamais, donc les gens évitent d'en mettre trop. Et du coup, tu es limité.
C'est la ou Puppet a un avantage, via le fait d'avoir une phase de compilation capable de vérifier ce genre de choses. Mais ça ne rends pas les choses beaucoup plus réutilisables si tu veux sortir du cadre décidé par le créateur du module, et si un module puppet fait pas ce que tu veux, tu as pas le choix, il faut forker.
Tout le jeu est de trouver le bon niveau d'abstraction.
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.
C'est du défoncage de porte ouverte. Encore une fois, tu as des interfaces non exprimés ( exemple, le chemin d'un fichier de configuration ), et soit tu gères ça dans le rôle lui même ( exemple, tu choisi l'emplacement du fichier de configuration via la méthode d'installation ), soit c'est un standard qui ne va pas bouger et que tu ne pas configurer sans tout casser. Donc soit le role impose la façon de faire, soit elle est imposé de façon externe. C'est comme un paquet de distrib, si tu veux le binaire d'apache dans "/usr/bin/sioux", tu peux pas ( sauf à tout refaire, et/ou modifier les choses à un autre niveau ). Il y a une cohérence interne au paquet/role à garder.
Un autre problème est la duplication souvent d'apparence
inutile des modules Ansible.
Comme ?
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.
[^] # Re: alt et p-
Posté par Misc (site web personnel) . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 3.
Alors, j'ai croisé pour le moment personne qui utilise propellor. Et pourtant, je passe mon temps à zoner dans les meetups et ce genre de choses. Pour dire, j'ai croisé plus de gens avec cfengine, ou bcfg2 que propellor.
Dire "y a pas besoin d'apprendre un langage particulier, suffit juste de connaitre haskell" est un chouia trompeur :)
D'une manière générale, tu peux difficilement avoir la configurabilité que propose la configuration d'un logicial sous forme d'une liste d'options, donc tu va jamais aller très loin avec les roles/formules/modules/cookbooks des autres. Si tu veux réutiliser, il faut construire au dessus, ou prendre des trucs de bases ( example, ntpd me parait le truc qu'on peut réutiliser sans souci, vu que les gens vont changer au mieux 2/3 trucs )
Et pouvoir injecter tes propres fichiers, c'est globalement chercher les emmerdes, car le fichier deviens parti intégrante de l'interface du soft avec le reste du monde.
Exemple, tu veux déployer mediawiki. Dans un monde idéal, tu devrais pouvoir reprendre un role apache et voila. En pratique, vu que mediawiki doit toucher à la config apache ( pour se placer dans un vhost, ou avec une url particuliére ), il y a un couplage entre les 2. Et pire encore, le couplage est non exprimé de façon formel donc risque de casser à tout moment. J'utilise une convention d'avoir /etc/httpd/conf.d/$vhost.conf.d/ pour qu'un soft dépose un fichier de configuration apache, qui s'applique à $vhost.
Si tu décides de prendre une autre convention ou de changer le templates, tu peux casser ça. Mais comme c'est pas exprimé comme le serait une fonction ( ce que puppet propose ) avec verification à la compilation, tu dois déployer et voir que ça ne marche pas. Et même, une fois que tu as une fonction, tout ce que tu peux rajouter comme argument doit être supporté à jamais, donc les gens évitent d'en mettre trop. Et du coup, tu es limité.
C'est la ou Puppet a un avantage, via le fait d'avoir une phase de compilation capable de vérifier ce genre de choses. Mais ça ne rends pas les choses beaucoup plus réutilisables si tu veux sortir du cadre décidé par le créateur du module, et si un module puppet fait pas ce que tu veux, tu as pas le choix, il faut forker.
Tout le jeu est de trouver le bon niveau d'abstraction.
C'est du défoncage de porte ouverte. Encore une fois, tu as des interfaces non exprimés ( exemple, le chemin d'un fichier de configuration ), et soit tu gères ça dans le rôle lui même ( exemple, tu choisi l'emplacement du fichier de configuration via la méthode d'installation ), soit c'est un standard qui ne va pas bouger et que tu ne pas configurer sans tout casser. Donc soit le role impose la façon de faire, soit elle est imposé de façon externe. C'est comme un paquet de distrib, si tu veux le binaire d'apache dans "/usr/bin/sioux", tu peux pas ( sauf à tout refaire, et/ou modifier les choses à un autre niveau ). Il y a une cohérence interne au paquet/role à garder.
Comme ?
Bah, tu peux mettre passer des arguments à un rôle ou un include ( http://docs.ansible.com/playbooks_roles.html#task-include-files-and-encouraging-reuse et plus bas ). J'ai un role httpd qui le fait que j'utilise sur 3 projets indépendants, donc je vois pas en quoi ça serait pas faisable.
La, ça semble un peu du FUD...