ça fait quelques temps déjà que j’ai mis en place un petit bricolé maison pas bien poussé pour faire du versioning (avec git) des fichiers de configurations des serveurs. Maintenant ça me parait inconcevable de faire autrement dans une gestion collaborative (+ 1 administrateur) ça évite les « mais pourquoi ça marche plus alors que ça marchait hier », « mais qui ka fait ça, pourquoi… »
Est-ce que vous utilisez / que vous avez connaissance d’un petit outil pour faire ça mais en mieux que mon script maison ?
Pourquoi ne pas commencer à utiliser Ansible et arrêter de faire des modifications « à la main » ?
Couplé à git pour le versionning c’est très efficace !
Oui il faut que je creuse parce que ça semblait bien fait pour le /etc mais si tu veux surveiller autre chose il faut bricoler j’ai l’impression… (genre /root/.ssh/authorized_keys /var/spool/cron/crontabs…)
Ansible c’est chouette quand tu as un parc de serveur (+ serveur homogène). De notre côté on a 3 serveurs qui ne font (presque) rien de pareil. Donc Ansible se limite à la gestion des mises à jours, rkhunter, munin, portsentry, fail2ban… mais pour le reste (postfix, apache…) je vois pas l’utilité d’Ansible quand t’as pas 2 « postfix » qui n’ont pas la même config/rôle par exemple… (peut être que c’est une méconnaissance)
un repo git dans /root si etckeeper est que pour /etc
gérer les authorized_keys avec le module Ansible « user » ; tu peux faire des trucs dans le style « cette clé là doit être présente, cette clé là doit être absente »
/var/spool/cron/crontabs :
module Ansible cron
Ansible c’est déjà chouette à partir du premier serveur. J’irai même plus loin, dès que tu modifies un quelconque paramètre même sur ton ordi de tous les jours, Ansible peut être utilisé pour « remonter » les paquets installés et les paramètres modifiés depuis l’install de base.
Mais (car il y a toujours des « mais »), il faut veiller à ce que les modifs éventuelles en mode « non Ansible » directement sur le/les serveurs soient réintégrées à postériori dans les playbooks / roles Ansible. Ca peut être chronophage, mais le temps passé à écrire ces « états de configurations » font gagner un temps fou lors de la mise en place d’autres serveurs / services.
A un moment on voyait fleurir sur le net des « postinstall scripts » ou autre. Chaque postinstall script étant spécifique à son auteur et sa façon d’installer / configurer selon son point de vue. Transposé avec Ansible, ça fait des roles, appelés par des playbooks, utilisant des variables et des fichiers / templates différents selon les hosts / targets.
Exemples :
un jour tu perds tes 3 serveurs, si c’était 3 serveurs dédiés chez des fournisseurs, tu vas demander à ce qu’ils soient réinstallés de base ou en créer ailleurs. À partir du moment où le password root et la conf ssh seront ok pour Ansible, tu lance ton playbook principal, ça défile et pouf, fini, plus qu’à récupérer les data depuis les sauvegardes.
un jour, tu veux déplacer ou redonder des services d’un serveur A à un serveur B, ça fait ajouter le serveur B dans le groupe correspondant à / aux services. Lancement du / des playbooks concernés, ça défile et re-pouf, fini !
L’avantage par rapport à suivre une procédure / documentation est incommensurable ; la doc / proc, c’est tes fichiers yaml, les évolutions et l’historique, c’est git.
Le problème avec Ansible (que j’utilise pour Enough) c’est à mon avis la courbe d’apprentissage, plus que l’utilité en fonction du nombre de serveurs. Pour quelqu’un qui maîtrise parfaitement ansible, gérer un seul serveur a du sens. Mais pour quelqu’un qui doit apprendre ansible, il faut minimum dix ou vingt serveurs à gérer sur au moins un an pour que ça soit rentable.
Pourtant je trouve qu’il s’agit de loin de l’outil de provisioning le plus simple à prendre en main, cela me semble d’ailleurs plus simple que de devoir passer par un script fait maison à maintenir.
Ca dépend du contexte. La courbe d’apprentissage de Ansible n’est pas de quelque heures ni de quelque jours mais plutôt de quelques semaines. Je le préfère à tout les autres et je pense qu’il est plus simple que tout les autres. Mais je pense qu’il serait faux de dire qu’on arrive a se sentir à l’aise en quelque jours. Du coup faire une poignée de scripts à la main pour maintenir trois machines, ce n’est pas forcément un mauvais pari.
Sur le long terme si. Si l’infra évolue, le script va s’étoffer de nouvelles fonctions et devenir impossible à maintenir avec le temps. A noter que j’ai vu le problème avec du code ruby dans chef. La question n’est pas tellement celle de l’outil utilisé, mais de privilégier une approche déclarative.
Une connaissance d’ansible offre aussi l’intérêt d’être plus générique et potentiellement réemployable, alors que l’investissement de temps passé sur un système spécifique comme des scripts maison l’est beaucoup moins…
Les chatons posent un cadre intéressant, des playbooks communs auraient une vraie valeur, mais l’environnement me semble un peu trop hétérogène (quoi qu’on retrouve beaucoup de debian et proxomox dans le coin il me semble)
