Rôle Ansible : Mise à Niveau

Non maintenu ! Déplacé vers une collection !

Ce rôle a été déplacé vers ma collection principale.
Il n'est plus maintenu ici !
Allez sur la collection pour du contenu à jour.

Ce rôle effectue des mises à niveau sur les serveurs Debian/Ubuntu, RHEL/CentOS, Fedora et Suse.

Caractéristiques

• Détection de redémarrage et redémarrage automatique
• Détection de redémarrage de service et redémarrages automatiques de services
• Rapport de mise à niveau
  • par Mail
  • par Telegram

Attention !

Les vérifications de redémarrage et de redémarrage de service pour APT sont mises en œuvre via needrestart. Pour Fedora, cela est implémenté par le plugin dnf needs-restarting.
Pour RHEL/CentOS, cela est mis en œuvre via l'outil needs-restarting.

Le rôle utilise la sortie ou les codes de retour pour décider des actions à prendre. Vous pouvez configurer le comportement via les variables ci-dessous.

Aucune de ces méthodes n'est parfaite, mais cela fonctionne plutôt bien. Vous devriez jeter un œil au rôle avant de l'utiliser.

Problèmes connus

• Debian 11 : Si ansible_python_interpreter=/usr/bin/python3 n'est pas défini explicitement, le module apt essaiera d'installer python-apt en cours d'exécution, ce qui échouera. Voir ce problème pour plus de détails.
• CentOS 8 : La détection de redémarrage ne fonctionne pas car il manque un indicateur pour le plugin dnf needs-restarting. Aucun redémarrage ne sera effectué.
• Fedora 32 et précédents : La détection de redémarrage de service ne fonctionne pas car il manque un indicateur pour le plugin dnf needs-restarting. Aucun redémarrage de service ne sera effectué.
• opensuse 15 et 42 : Une dépendance manquante empêche l'installation d'un outil dépendant. Un contournement est en place. De plus, le processus de mise à niveau semble instable. Je vais tout de même lister ces distributions comme stables concernant la vérification de compatibilité OS mentionnée ci-dessous, car actuellement le rôle ne semble pas casser quoi que ce soit, mais veuillez être prudent ! N'hésitez pas à me faire savoir si vous savez comment résoudre ces problèmes.
• opensuse 15 et 42 : La détection de redémarrage de service utilise une approche "brute", car le format de sortie de zypper ps -s est difficile à analyser. Pour l’instant, ces systèmes d’exploitation redémarreront simplement si des services doivent être redémarrés.

Exigences

Lors de l'utilisation de la fonction de rapport via Telegram :

collections:
- name: community.general
  version: 3.4.0

Notez que ce rôle nécessite un accès root, donc soit exécutez-le dans un playbook avec un become: yes global, soit invoquez le rôle dans votre playbook comme suit :

- hosts: foobar
  roles:
    - role: thorian93.upgrade
      become: yes

De plus, ce rôle vérifie uniquement si le système est accessible sur le port 22 après un redémarrage. Si vous avez besoin de vérifications ou de validations supplémentaires, vous devrez vous en occuper vous-même.

Variables du rôle

Les variables disponibles sont énumérées ci-dessous, avec les valeurs par défaut (voir defaults/main.yml):

Variables de base

upgrade_packages_on_hold: []

Définissez les packages que vous ne souhaitez pas mettre à niveau automatiquement en attente avant la mise à niveau.

upgrade_unattended_reboot: true

Activez le redémarrage non assisté en cas de besoin après les mises à jour. La valeur par défaut est true, définissez sur false pour désactiver les redémarrages.

upgrade_force_reboot: false

Forcer un redémarrage de chaque serveur indépendamment du résultat de la vérification de redémarrage. La valeur par défaut est false, définissez sur true pour activer les redémarrages forcés.

upgrade_needrestart_disable_interaction: true

L'outil needrestart est utilisé pour déterminer les redémarrages et les redémarrages de services nécessaires. Certaines distributions le configurent pour fonctionner de manière interactive par défaut, ce qui casse ce rôle. Par conséquent, le paramètre par défaut est de désactiver toute interaction. Réglez ceci sur false pour activer l'interaction. Consultez la page de manuel pour plus de détails.

upgrade_restart_services: true

Activez les redémarrages de services automatiques. Cela entraîne le redémarrage des services qui doivent être redémarrés. La valeur par défaut est true, définissez sur false pour désactiver les redémarrages.

upgrade_restart_services_blacklist:
  - auditd.service
  - dbus.service
  - systemd-manager.service

Liste noire des services qui ne doivent pas ou ne peuvent pas être redémarrés. La liste par défaut est basée sur l'expérience. N'hésitez pas à signaler les services à ajouter ici.

Variables de rapport

upgrade_reporting_enable: false

Activez la fonction de rapport de ce rôle pour afficher les mises à jour installées et éventuellement les écrire dans un fichier.

upgrade_reporting_path: "."

Définissez l'emplacement où les rapports doivent être placés. La valeur par défaut est votre répertoire de travail actuel.

upgrade_reporting_cleanup: true

Supprimez les fichiers de rapport utilisés pour envoyer des rapports. Peut être utile pour le débogage de les conserver.

Variables de rapport Telegram

upgrade_reporting_telegram_enable: false

Activez le rapport via Telegram. Vous devez configurer les deux variables suivantes avec vos identifiants pour réellement envoyer des messages via Telegram ! Voir la documentation du module pour plus de détails.

upgrade_telegram_token:  []

Votre Token de Bot Telegram.

upgrade_telegram_chatid: []

Votre ID de chat Telegram.

Variables de rapport par Mail

upgrade_reporting_mail_enable: false

Activez le rapport par Mail.

upgrade_reporting_mail_subject: "Rapport de mise à jour Ansible"

Configurez le sujet de l'e-mail.

upgrade_reporting_mail_to: ""

Définissez le(s) destinataire(s) de l'e-mail.

upgrade_reporting_mail_from: ""

Définissez l'expéditeur de l'e-mail.

upgrade_reporting_mail_host: ""

Définissez le serveur ou le relais de mail.

upgrade_reporting_mail_port: ""

Définissez le port du serveur de mail.

upgrade_reporting_mail_user:
upgrade_reporting_mail_password:

Si le serveur de mail nécessite une authentification, définissez un nom d'utilisateur et un mot de passe ici. Si aucune authentification n'est requise, assurez-vous de laisser les variables vides comme indiqué ici ! Ne les rendez pas vides comme mentionné ci-dessus.

upgrade_reporting_mail_run_once: true

Si vous souhaitez envoyer un e-mail par play, définissez ceci sur true. Si vous préférez envoyer un e-mail par hôte, définissez-le sur false.

Dépendances

Aucune.

Compatibilité des OS

Ce rôle s'assure qu'il n'est pas utilisé contre des systèmes d'exploitation non pris en charge ou non testés en vérifiant si le bon nom de distribution et le numéro de version majeure sont présents dans une variable dédiée nommée comme <role-name>_stable_os. Vous pouvez trouver la variable dans le fichier de variables par défaut du rôle à defaults/main.yml :

role_stable_os:
  - Debian 10
  - Ubuntu 18
  - CentOS 7
  - Fedora 30

Si la combinaison de la distribution et du numéro de version majeure ne correspond pas au système cible, le rôle échouera. Pour permettre au rôle de fonctionner, ajoutez le nom de la distribution et le numéro de version majeure à cette variable et le tour est joué. Mais veuillez tester la nouvelle combinaison d'abord !

Un grand merci à HarryHarcourt pour cette idée !

Exemple de Playbook

---
- name: "Exécuter le rôle."
  hosts: all
  become: yes
  roles:
    - ansible-role-upgrade

Contribution

N'hésitez pas à ouvrir des problèmes si vous trouvez des bugs, des problèmes ou si vous voyez des possibilités d'amélioration. N'hésitez pas à me contacter à tout moment si vous souhaitez poser une question ou discuter de quelque chose.

Avertissement

Ce rôle est fourni EN L'ÉTAT et je ne peux pas garantir qu'il fonctionne comme prévu, ni assumer la responsabilité de tout dommage ou mauvaise configuration causé par ce rôle. Étudiez le rôle en profondeur avant de l'utiliser.

Licence

MIT

Informations sur l'Auteur

Ce rôle a été créé en 2019 par Thorian93.