Gestion des Mises à Jour

Parce qu'une mise à jour système n'est généralement pas juste un yum update -y, gestion_mises_a_jour est un rôle Ansible pour gérer facilement le processus de mise à jour et tout ce qui l'entoure pour les serveurs sous RedHat, CentOS, Debian ou Ubuntu.

Lors d'une gestion de mise à jour, si vous voulez :

• mettre la cible en mode de maintenance dans votre supervision
• envoyer un message au début ou à la fin du processus
• réagir en cas d'échec
• etc.

ce rôle vous facilitera la tâche.

Dans tous les cas, rappelez-vous qu'il ne faut jamais se connecter à un serveur pour effectuer sa mise à jour.

Exigences

Rien de spécial.

Fonctionnalités

• Prendre des notes sur le système - adresse IP et routes, processus en cours, points de montage (pour le dépannage ! N'oubliez pas !)
• Exécuter des tâches personnalisées pour tous les serveurs (voir la variable pm_before_update_tasks_file)
• Exécuter des tâches personnalisées pour le serveur cible (voir le chapitre exemple de playbook)

Notre objectif principal :

• Mettre à jour le serveur avec apt ou yum

Et ensuite :

• Définir des faits Ansible avec la date actuelle et, si voulu, une variable d'environnement.
• Exécuter des tâches personnalisées pour le serveur cible (voir le chapitre exemple de playbook)
• Exécuter des tâches personnalisées pour tous les serveurs (voir la variable pm_after_update_tasks_file)

Variables de Rôle

• pm_restart_after_update: par défaut true

Le serveur cible redémarrera-t-il après la gestion des mises à jour ? Cela garantit que le dernier noyau est en cours d'exécution et que le serveur et ses services peuvent redémarrer. Pensez à le faire régulièrement.

• pm_logpath: par défaut /etc/ansible/facts.d/PM.log

Où stocker les dates des mises à jour réussies ou échouées.

• pm_date_format: par défaut "{{ ansible_date_time.date }}-{{ ansible_date_time.time }}"

Comment formater la date dans les faits et le chemin du log ?

• pm_fact_name: par défaut pm

Quel est le nom du fait que nous voulons ?

• pm_set_env_variable: par défaut true
• pm_env_file_path: par défaut /etc/profile.d/last_pm_date.sh

Doit-on définir une variable d'environnement avec la date de la dernière mise à jour et où stocker le script ?

• pm_manage_yum_clean_all: par défaut true

Lancer un yum clean all avant de mettre à jour. Vous devriez le définir sur false si, par exemple, vous avez déjà téléchargé les RPM.

• pm_manage_apt_clean: true

Lancer un apt clean avant de mettre à jour.

• pm_manage_apt_autoremove: true

Supprimer automatiquement les paquets deb.

• pm_apt_verbose_package_list: false

Afficher la liste des résultats d'apt.

• pm_before_update_tasks_file:

Par exemple custom_tasks/pm_before_update_tasks_file.yml. Vous pouvez configurer le rôle pour exécuter ce fichier de tâches avant de mettre à jour le serveur. Chaque tâche dans le fichier ciblé sera exécutée.

Pensez à inclure des tâches comme envoyer un message, prendre un instantané, mettre en mode de maintenance, etc.

• pm_after_update_tasks_file:

Par exemple custom_tasks/pm_after_update_tasks_file.yml. Vous pouvez configurer le rôle pour exécuter ce fichier de tâches après la mise à jour du serveur. Chaque tâche dans le fichier ciblé sera exécutée.

Exemple de Playbook

Configurer un playbook est assez simple comme vous pouvez le voir :

- name: Démarrer une Gestion des Mises à Jour
  hosts: serveurs
  vars:
    pm_before_update_tasks_file: custom_tasks/pm_before_update_tasks_file.yml
    pm_after_update_tasks_file: custom_tasks/pm_after_update_tasks_file.yml
  tasks:
    - name: "Inclure gestion_mises_a_jour"
      include_role:
        name: "alemorvan.gestion_mises_a_jour"

En plus de ce playbook, vous pouvez créer 2 autres fichiers de tâches par serveur qui seront exécutés avant et après leur mise à jour. C'est utile, par exemple, pour retirer un nœud d'un équilibre de charge, vider des caches, redémarrer des services, etc.

Contrairement aux variables pm_before_update_tasks_file et pm_after_update_tasks_file (qui ciblent des fichiers de tâches effectuant des actions pour tous les cibles), ces fichiers se concentrent sur des actions spécifiques à un seul serveur.

Dans le répertoire du playbook, créez le répertoire custom_tasks et les fichiers nommés before_pm_{{ inventory_hostname_short }}_custom_tasks.yml et after_pm_{{ inventory_hostname_short }}_custom_tasks.yml.

  - name: Exécuter une tâche personnalisée pour ce serveur définie grâce au fichier after_pm_{{ inventory_hostname_short }}_custom_tasks.yml.
    debug:
      msg: "Cette tâche est une tâche personnalisée définie dans le fichier after_pm_{{ inventory_hostname_short }}_custom_tasks.yml"

Test de Molecule

Vous pouvez tester ce rôle via molecule et docker :

  $ molecule test

Voir molecule/default/converge.yml pour un bon exemple sur la façon d'utiliser ce rôle.

Licence

MIT

Informations sur l'Auteur

Ce rôle a été écrit à l'origine par Antoine Le Morvan pour Vivalto Santé, basé sur le travail de Nicolas Martin et l'équipe Ansible de Claranet France / BU RMP (Ismaël Ouattara et EliE Deloumeau).