Ansible: common roles considered harmful
English version here
C’est un classique des projets Ansible: un rôle appelé common ou assimilé. Vous savez, ce genre de rôles où l’angoisse vous saisit quand vous l’ouvrez. Voyons ensemble les problèmes de ce type de rôle, et parlons de la granularité des rôles Ansible.
Les rôles poubelles
Ce rôle common est généralement un rôle poubelle. Tout ce que les gens ne savent pas où mettre va dans common. J’ai travaillé dans plusieurs entreprises faisant du Ansible, et toutes avaient un rôle common. J’ai moi même contribué à un rôle common pendant quelque temps lors de ma première mission Ansible avant de le détruire définiivement.
Cela donne généralement un rôle inmaintenable, faisant des tâches diverses et variées mais sans rapport entre elles.
Prenons un rôle common fictif. Ce rôle ferait peut être
-
La mise à jour de la distribuction Linux (Debian par exemple).
-
La configuration des clés SSH de la machine.
-
La configuration de base de syslog.
-
La configuration de DHCP.
Avec le temps, ce rôle va grossir, de nouvelles choses finiront dedans, et le rôle finit par devenir du gloubi boulga.
Vous ne voulez pas en manger du gloubi boulga ? Vraiment pas ?
Ce genre de rôle doit être explosé en plusieurs rôles, cbaque rôle devant faire une action spécifique. Vous pourriez par exemple avoir à la place de ce rôle common des rôles:
-
debian
-
ssh
-
syslog
-
dhcp
Ce sera beaucoup plus lisible, testable et maintenable.
La granularité des rôles
Finalement, tout est une question de granularité. Je suis partisan d’un découpage fin des rôles Ansible, chaque rôle ayant une petite responsabilité (cette expérience vient de l’écriture et de la maintenance de centaines de rôles dans différents contextes).
Beaucoup de gens essayent de faire trop de choses au sein des rôles. Prenons par exemple un rôle installant Kafka.
-
Vous utilisez Collectd dans votre entreprise. Est ce que ce rôle doit également déployer la configuration Collectd nécessaire pour monitorer Kafka ? La réponse est non. Cela donnerait un rôle inutilisable dans un autre contexte où Collectd n’est pas utilisé.
-
Est ce que la remontée des logs doit être gérée dans le rôle ? Là encore, je préfère externaliser (même si ça se discute pour logrotate/syslog), car peut être que j’utilise syslog-ng, ou bien filebeat, ou logstash. Je ne veux pas lier ces technologies à ce rôle.
Les rôles doivent rester simple, faire une seule chose et la faire bien.
Un autre exemple: Vous voulez déployer Kubernetes avec Ansible. A votre avis, c’est quoi le plus maintenable et le plus réutilisable niveau rôle:
-
common
-
master
-
worker
ou bien:
-
kubelet
-
kube-proxy
-
kube-dns
-
ssh
-
etcd
-
calico
-
…
Dans le second cas, il sera beaucoup plus simple de maintenir de petits rôles. Cela simplifiera aussi les déploiements, et évitera les accidents de type oups, j’ai redéployé kube-dns mais en fait ça a aussi upgrade etcd.
Les playbooks à la rescousse
On a tendance à oublier les playbooks, et à ne les utiliser que pour appeler des rôles. Mais les playbooks sont également un super moyen d’écrire des scénarios de déploiement.
Un rolling-upgrade d’un cluster doit vivre dans un playbook, et non dans le rôle de l’application par exemple. De même, pour de petites tâches comme lancer un dist-upgrade, les playbooks font sens (pas la peine d’utiliser un rôle pour ça).
Conclusion
Gardez des rôles simples, et vous aurez un déploiement simple.
Add a comment
If you have a bug/issue with the commenting system, please send me an email (my email is in the "About" section).