PatchManagement

Da ein Systemupdate selten nur ein yum update -y ist, ist patchmanagement eine Ansible-Rolle, um den Aktualisierungsprozess und alles, was damit zu tun hat, für Server unter RedHat, CentOS, Debian oder Ubuntu OS einfach zu verwalten.

Während des Patchmanagements, wenn Sie möchten:

• das Ziel in einen Wartungsmodus in Ihrer Überwachung setzen
• eine Nachricht zu Beginn oder am Ende des Prozesses senden
• reagieren, wenn etwas schiefgeht
• usw.

wird diese Rolle Ihnen das Leben erleichtern.

In jedem Fall denken Sie daran, dass Sie sich nie mit einem Server verbinden sollten, um dessen Upgrade durchzuführen.

Anforderungen

Nichts Besonderes.

Funktionen

• Notizen über das System machen - IP-Adresse und Routen, laufende Prozesse, Einhängepunkte (zur Fehlersuche! Vergessen Sie das nicht!)
• Benutzerdefinierte Aufgaben für alle Server ausführen (siehe pm_before_update_tasks_file-Variable)
• Benutzerdefinierte Aufgaben für den Zielserver ausführen (siehe Kapitel zum Playbook-Beispiel)

Unser Hauptziel:

• Den Server mit apt oder yum aktualisieren

Und danach:

• Ansible-Fakten mit dem aktuellen Datum setzten und, falls gewünscht, eine Umgebungsvariable festlegen.
• Benutzerdefinierte Aufgaben für den Zielserver ausführen (siehe Kapitel zum Playbook-Beispiel)
• Benutzerdefinierte Aufgaben für alle Server ausführen (siehe pm_after_update_tasks_file-Variable)

Rollenvariablen

• pm_restart_after_update: Standard true

Wird das Ziel nach dem PM neu gestartet? Dies stellt sicher, dass der letzte Kernel läuft und dass der Server und seine Dienste neu starten können. Erwägen Sie, dies regelmäßig zu tun.

• pm_logpath: Standard /etc/ansible/facts.d/PM.log

Wo sollen die Daten von erfolgreichen oder fehlgeschlagenen PMs gespeichert werden?

• pm_date_format: Standard "{{ ansible_date_time.date }}-{{ ansible_date_time.time }}"

Wie soll das Datum im Fakt und im Protokollpfad formatiert werden?

• pm_fact_name: Standard pm

Wie soll der Faktname lauten?

• pm_set_env_variable: Standard true
• pm_env_file_path: Standard /etc/profile.d/last_pm_date.sh

Setzen wir eine Umgebungsvariable mit dem Datum der letzten PM und wo soll das Skript gespeichert werden?

• pm_manage_yum_clean_all: Standard true

Führt ein yum clean all vor dem Update durch. Sie sollten es auf false setzen, wenn Sie beispielsweise bereits die RPMs heruntergeladen haben.

• pm_manage_apt_clean: true

Führt ein apt clean vor dem Update durch.

• pm_manage_apt_autoremove: true

Entfernt automatisch deb-Pakete.

• pm_apt_verbose_package_list: false

Gibt die apt-Ergebnisliste aus.

• pm_before_update_tasks_file:

Zum Beispiel custom_tasks/pm_before_update_tasks_file.yml. Sie können die Rolle so konfigurieren, dass diese Aufgaben vor dem Update des Servers ausgeführt werden. Jede Aufgabe in der angegebenen Datei wird ausgeführt.

Denken Sie daran, einige Aufgaben wie das Senden einer Nachricht, das Erstellen eines Snapshots, das Setzen eines Wartungsmodus usw. hinzuzufügen.

• pm_after_update_tasks_file:

Zum Beispiel custom_tasks/pm_after_update_tasks_file.yml. Sie können die Rolle so konfigurieren, dass diese Aufgaben nach dem Update des Servers ausgeführt werden. Jede Aufgabe in der angegebenen Datei wird ausgeführt.

Beispiel-Playbook

Ein Playbook zu konfigurieren ist recht einfach, wie Sie sehen können:

- name: Patch Management starten
  hosts: servers
  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: "Patchmanagement einbeziehen"
      include_role:
        name: "alemorvan.patchmanagement"

Zusätzlich zu diesem Playbook können Sie 2 weitere Aufgaben-Dateien pro Server erstellen, die vor und nach dem Upgrade ausgeführt werden. Dies ist zum Beispiel nützlich, um einen Knoten von einem LB zu entfernen, Caches zu leeren, Dienste neu zu starten usw.

Im Gegensatz zu den Variablen pm_before_update_tasks_file und pm_after_update_tasks_file (die Aufgaben für alle Ziele betreffen), konzentrieren sich diese Dateien auf Aktionen, die spezifisch für einen einzelnen Server sind.

Erstellen Sie im Verzeichnis des Playbooks das Verzeichnis custom_tasks und die Dateien mit den Namen before_pm_{{ inventory_hostname_short }}_custom_tasks.yml und after_pm_{{ inventory_hostname_short }}_custom_tasks.yml.

  - name: Führe benutzerdefinierte Aufgaben für diesen Server aus, die im after_pm_{{ inventory_hostname_short }}_custom_tasks.yml definiert sind.
    debug:
      msg: "Diese Aufgabe ist eine benutzerdefinierte Aufgabe, die in der after_pm_{{ inventory_hostname_short }}_custom_tasks.yml-Datei definiert ist."

Molecule-Tests

Sie können diese Rolle mit Molecule und Docker testen:

  $ molecule test

Siehe molecule/default/converge.yml für ein gutes Beispiel, wie Sie diese Rolle nutzen können.

Lizenz

MIT

Autoreninformationen

Diese Rolle wurde ursprünglich von Antoine Le Morvan für Vivalto Sante verfasst, basierend auf der Arbeit von Nicolas Martin und dem Ansible-Team bei Claranet Frankreich / BU RMP (Ismaël Ouattara und EliE Deloumeau).