Le 27/11/20 à 12h16, Faustin Lammler <faus...@fala.red> 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/

Répondre à