Solution Ansible vs sur mesure
J'ai un pool d'une dizaine de postes de travail sous Linux et j'ai besoin d'un système pour les maintenir en quelque sorte synchronisés (même logiciel installé, même configuration, mêmes utilisateurs, ...) et aussi me permettre de les faire évoluer dans le temps (pensez aux changements de configuration , mises à jour de pilotes, nouveau logiciel ...). L'astuce est que parfois, certains d'entre eux sont mis hors ligne et ne sont réactivés qu'après des semaines, voire des mois, et parfois de nouveaux postes de travail sont ajoutés et doivent être configurés à partir de zéro.
Je cherchais à utiliser Ansible et cela semble génial, mais pour mon cas d'utilisation, cela présente deux inconvénients:
- il n'a pas de fonction de mise à jour automatique (lorsqu'une boîte est démarrée après une longue période d'inactivité, je dois exécuter manuellement le playbook sur la station de contrôle)
- après des années de production, le playbook devenait vraiment long. Devoir l'exécuter sur un poste de travail qui ne manquait que quelques mises à jour serait très inefficace. Même si toutes les tâches sont idempotentes, chacune d'elles devrait être envoyée au poste de travail juste pour voir si elle a été exécutée ou non. Diviser le playbook en parties plus petites n'est pas non plus idéal car il faudrait garder une trace de ce qui a été exécuté et où.
L'alternative à laquelle je pense est d'avoir un référentiel de scripts et d'utiliser GNU Make pour les exécuter. Make est utilisé pour mettre à jour les cibles à partir des sources, il exécute essentiellement une commande sur un fichier source pour produire une sortie (par exemple, compiler un programme C en un binaire). Si je traite les scripts comme des sources, un Makefile comme celui-ci ferait l'affaire:
TASKS= \
install_apps \
start_services \
add_users
TARGETS=$(TASKS:=.done) all: $(TARGETS)
%.done: %.sh
echo "running $<" ./$<
touch $@
Lorsque l'un des postes de travail démarre, il peut automatiquement extraire le référentiel de scripts et exécuter make . Avec ce système en place, les tâches ne sont exécutées qu'une seule fois et dans l'ordre dans lequel elles sont répertoriées.
Des questions
- Pensez-vous que les inconvénients que j'ai énumérés sont faux? Il existe peut-être un moyen / une solution de contournement pour atteindre mon objectif en utilisant Ansible
- Voyez-vous des problèmes avec l'alternative que j'ai proposée? Gardez à l'esprit que le Makefile ci-dessus est simplifié et n'est pas prêt pour la production.
Réponses
Le premier inconvénient, Ansible étant un système basé sur push, peut être atténué en utilisant ansible-pull .ansible-pull
extrait les playbooks d'un dépôt VCS et les exécute pour l'hôte local
ansible-pull pourrait être déclenché par cron ou un script de démarrage.
Le deuxième inconvénient des playbooks de longue durée est en quelque sorte vrai. Ansible n'est pas le système de gestion de configuration le plus rapide du marché. Cependant, le temps d'exécution d'Ansible peut être réduit en utilisant un mitogène et il est relativement facile d'implémenter des conditions pour sauter des parties d'un playbook afin d'accélérer la lecture comme ceci:
- name: Register a variable
ansible.builtin.shell: cat /etc/motd
register: motd_contents
- name: Use the variable in conditional statement to run long running play
include: otherplays.yaml
when: motd_contents.stdout.find('hi') != -1
Si vous écrivez des playbooks en tenant compte du temps d'exécution, cela peut être aussi rapide que le simple bash.
En général, Ansible fournit de nombreux outils utiles pour configurer les systèmes. Il n'y a probablement rien dans Ansible qui ne puisse pas être implémenté en utilisant quelque chose comme Makeet Bash. L'avantage d'Ansible par rapport à Bash est que beaucoup de gens trouvent qu'il est plus facile de travailler avec et que le code est plus lisible.