Le 27/11/20 à 12h16, Faustin Lammler <[email protected]> a écrit :
> Bonjour,
> ça fait un moment que je travaille avec des outils de gestion de
> déploiement et de gestion de configuration (puppet, saltstack et
> maintenant ansible).
>
> Mon expérience est que quand ça devient trop compliqué, l'approche est
> souvent mauvaise (c'est d'ailleurs souvent vrai pour d'autres aspects de
> l'informatique).
Ça je suis bien d'accord, stay kiss !
> Voici quelques recommandations que j'essaie de garder en tête au moment
> de développer des nouveaux rôles/tasks, peut-être qu'elles pourront te
> servir :
> - éviter au maximum de mettre de l'intelligence dans des rôles (sinon ça
> devient rapidement plus portable et c'est le début de la complexité
> inutile).
> - privilégier le plus possible une approche descriptive de l'infra (dans
> group_vars/host_vars), cela simplifie énormément les développements et
> la lisibilité des rôles. Pourquoi vouloir détecter des IP qui ne
> changent pas ?
Mmmh, je vois, mais vu que ces ips sont déjà dans une zone locale de mes
résolveurs (qui est générée à partir d'un fichier unique qui liste
host=>ip), je voulais pas mettre l'association host/ip à deux endroits,
toujours un risque d'oublier de màj un des deux.
Du coup, je devrais peut-être décrire cette liste host/ip dans ansible et
utiliser ansible pour générer la zone unbound.
> - utiliser le plus possible des variables raw, ça permet de simplifier
> drastiquement les templates ;
> - essayer d'éviter les `| default("")` et passer par `defaults/main.yml`
> pour documenter la valeur par défaut des variables (et documenter le
> rôle finalement).
Vu, merci.
> En ce qui concerne Ansible, son problème principal selon moi c'est sa
> première qualité. C'est extrêmement facile à utiliser (notamment, car il
> est agentless et n'a besoin que d'une connexion SSH). Du coup on se
> lance tête baissée dans des déploiements/développements sans commencer
> par structurer les choses proprement.
>
> En ce qui concerne l'utilisation du `--check`, c'est évidemment très bien
> mais je t'invite à regarder le projet molecule qui permet de tester
> rapidement et proprement les rôles, ça fait gagner un temps fou pendant
> la phase de développement (même si le setup est un peu plus long).
>
> Si tu lis l'anglais, je te conseille ce livre (et les productions
> en général de son auteur) : https://www.ansiblefordevops.com/
>
> Finalement, voici un rôle que j'ai développé qui illustre ce qui me
> semble être des bonnes pratiques pour ansible (il n'est surement pas
> parfait mais je crois qu'il est assez simple à lire). Ce rôle contient
> également les mécanismes de tests molecule dont je parle plus haut.
> https://github.com/fauust/ansible-role-mariadb
>
> Mes 2 centimes.
>
> Faustin
>
> PS : pour ceux qui trouvent ansible un peu long (et quand on vient de
> saltstack, on pleure), je vous recommande d'essayer mitogen
> (https://mitogen.networkgenomics.com/ansible_detailed.html), le gain en
> performance est assez bluffant.
Merci bcp pour tous ces conseils et pointeurs judicieux !
--
Daniel
Les biographes ne connaissent pas la vie sexuelle intime de
leur propre épouse, mais ils croient connaître celle de
Stendhal ou de Faulkner.
Milan Kundera
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
