Petites questions à propos de #Ansible et des mises à jours.
Comment utilisez-vous Ansible pour gérer les mises à jour de vos logiciels et OS ?
Pour les mises à jour logiciels, utilisez-vous le playbook de déploiement ou un playbook à part ?
Effectuez-vous des vérifications et notifications ?
Un mécanisme de rollback ?
Il existe différentes solutions et je suis curieux de savoir comment vous faites et pourquoi vous le faites de cette façon.
N'hésitez pas à être généreux en détails.
L'avantage est que je peux exécuter le même playbook régulièrement avec cron. Et le playbook est déclaratif plutôt qu'impératif.
Mais si le processus de mise à jour ce complexifie ? Par exemple avec des vérifications, des rollback, des redémarrages d'autres services, des notifications, etc ?
Mais certaines de ces actions, pas toutes, seraient aussi utiles en cas de première installation. Comment différencier les 2 situations, installation et mises à jour, pour adapter les tâches exécutées ?
Je viens de découvrir que les "block" Ansible ont une section "rescue". Un block "rescue" est exécuté si une tâche du block précédent échoue.
Je me demande si je peux m'en servir pour du rollback.
Par exemple, la tâche qui installe ou met à jour le paquet notifie un handler nommé "restart XXX or rollback".
Ce hanler posséderait un "block" et un "rescue". Le "block" redémarre le service et vérifie qu'il est accessible. Le "rescue" s'occupe du rollback à l'ancienne version.
Et avant de mettre à jour, on récupère le numéro de version déployé dans une variable.
Qu'en pensez-vous ?
@postroutine
Je ping @Troupier et @Katyucha
Ils ont essuyé de m'expliquer, résultat je fais encore tout à la main, de manière pas reproductible 😅
@postroutine
J'utilise de moins en moins Ansible mais par principe, je cale les versions dans le defaults/main.yml de mon role ansible et j'upgrade au besoin
Le Rollback, c'est toujours relou pour la simple raison qu'il faut que ça soit accepté par l'OS au niveau configuration et tout..
@Troupier
@postroutine
Salut.
Je crée déjà des rôles/collections génériques nommés Pseudo_os_fonction.
Mes playbooks appellent donc des rôles seulement. Ils restent facilement lisible.
@postroutine
Pour le cas première installé j'ajouterai une variable a mes hôtes dans l'inventaire.
Ex: ansible_first_install: true
Cette variable sera modifiée par le playbook ( via un rôle) qui viendrait modifier la variable a 'false' dans l'inventaire ( via delegate_to: localhost)
@postroutine Pour ma part Ansible ne s'occupe pas des mises a jours. il Deploye une configuration, et après le serveur fait ces mise a jour tout seul. Ansible ne va intervenir que si il y a une configuration a modifier.
par exemple j'utilise unatended-upgrades pour mes debian et des script voir des hook parfois.
@sebseb01
Je faisais comme toi et sur certains OS j'avais des loupés. L'avantage d'ansible c'est que mes tâches planifiées viennent d'un seul poste et publie sur l'ensemble.
J'ai même une notification sur mon compte xmpp des postes 'OFF' et du nombre de mise à jour.
En cas de pépin du script je peux debugger grâce à 'ARA'
@postroutine
C'est un logiciel de reporting pour ansible. C'est pas compliqué à mettre en place et a chaque 'playbook' de lancé il log le résultat dans un mini web service qui stocke le résultat des tâches, le type de script etc...
@ohsupertramp @sebseb01 merci, je vais regarder. 🙂
@postroutine @ohsupertramp @sebseb01 Je gère "que" 4 petits serveurs perso avec ansible, donc les màj ne sont pas une trop grande tâche.
Pour les paquets que j'ai fait moi même, je change la version, rebuild le paquet, met à jour le playbook et lance le tout.
Pour les màj système je lance un script de backup, apt update et apt ugprade avec une commande ad hoc ansible.
Un peu comme toi, sauf que je précise pas la version pour les paquets de la distrib.
@postroutine @ohsupertramp @sebseb01 Donc je fait une vérification manuelle de la màj, j'ai un backup en cas de pépin, mais pas de notification vu que la vérification est manuelle
De mon coté, c'est généralement le playbook de déploiement qui s'occupe de faire les mises à jour.
Plus précisément: À la tâche qui installe le paquet, ou qui télécharge l'image de conteneur, je précise la version souhaitée. En cas de changement de la tâche, ce qui signifie l'installation ou la mise à jour, j'utilise un handler pour démarrer ou redémarrer le service.
La version peut être:
* Un numéro précis, exemple 2.5.7
* Une branche, exemple 2.7.x
* La dernière version (mais c'est rare)