Le 27/11/20 à 12h16, Faustin Lammler faustin@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 !