Salut!
Je recommande saltstack ( https://github.com/saltstack/salt )
Pour ce qui est de l'interface graphique pour salt (jamais utilise perso mais merite un coup d'oeil), il y a halite ( https://github.com/saltstack/halite )
J'utilise Salt depuis un moment et ca marche plutot bien !
Val
Feron Valentin valferon@gmail.com 0474 225 521
Le 19 août 2015 23:43, Jean-Yves LENHOF jean-yves@lenhof.eu.org a écrit :
Le 2015-08-19 13:59, Rémy Sanchez a écrit :
On Wed, Aug 19, 2015 at 12:08 PM Wallace wallace@morkitu.org wrote:
En fait y a les deux extrêmes, d'un côté on voit les docs qui
disent faut factoriser à fond pour pouvoir réutiliser au maximum en changeant juste quelques variables et d'un autre la doc officielle qui montre en exemple un simple listing d'actions à faire sans prendre en compte différentes versions de Debian ou les adaptations nécessaires vis à vis d'Ubuntu. Les exemples de la doc sont effectivement simple et permettent de rapidement mettre en place des actions mais est ce le bon exemple, je n'en suis pas convaincu quand je vois le travail de debops qui là à mon goût est peu flexible si je veux changer une façon de faire sans forker leur git.
Pour moi la stratégie est la suivante : faire le script pour la/les machines cibles, et quand de nouvelles machines avec des distros/versions différentes apparaissent, je rajoute des conditions pour faire des actions appropriées en fonction de.
En fait je vais un poil plus loin encore... Mes premières lignes d'un rôle testent la distribution et si personne n'a encore testé ce rôle sur cette distribution dans la version précisée je sors en failed avec un message du genre vas modifier le rôle pour autoriser cette version et du coup jeter un oeil s'il n'y aurait pas de lignes spécifiques à la version du genre un apt ou un yum avec un repository spécifique à une version.
Si vous avez d'autres bonnes pratiques à partager n'hésitez pas, pour ma part, en voici deux :
- je préfixe toutes les variables d'un rôle par le nom du rôle pour éviter
les surcharges par un autre rôle...
- une variable ne comprend pas de tiret ni de point, et donc par rapport à
la règle juste au-dessus les rôles n'ont donc pas non plus de tiret et de point dans leur nom (Le tiret et le point ont des significations spécifiques en python et donc en ninja2 & ansible... cette connerie m'a fait perdre une bonne demi-journée)
Cdlt,
JYL
Liste de diffusion du FRsAG http://www.frsag.org/