Ansible Rolle: Upgrade

Unwartet! In Sammlung verschoben!

Diese Rolle wurde in meine Haupt Sammlung verschoben.
Sie wird hier nicht mehr gewartet!
Gehe zur Sammlung für aktuelle Inhalte.

Diese Rolle führt Upgrades auf Debian/Ubuntu, RHEL/CentOS, Fedora und Suse Servern durch.

Funktionen

• Neustart-Erkennung und automatischer Neustart
• Erkennung von Dienstneustarts und automatische Dienstneustarts
• Upgrade-Berichterstattung
  • per E-Mail
  • per Telegram

Hier gibt es Drachen!

Die Überprüfungen für Neustart und Dienstneustart für APT werden über needrestart durchgeführt. Für Fedora wird dies durch das DNF-Plugin needs-restarting umgesetzt. Für RHEL/CentOS wird es durch das Tool needs-restarting realisiert.

Die Rolle verwendet die Ausgaben oder Rückgabewerte, um zu entscheiden, welche Aktionen durchzuführen sind. Du kannst das Verhalten über die folgenden Variablen konfigurieren.

Keine dieser Methoden ist perfekt, aber sie funktioniert recht gut. Du solltest die Rolle jedoch durchsehen, bevor du sie verwendest.

Bekannte Probleme

• Debian 11: Ohne die Einstellung ansible_python_interpreter=/usr/bin/python3 wird das apt Modul versuchen, python-apt während der Ausführung zu installieren, was fehlschlägt. Siehe dieses Problem für weitere Details.
• CentOS 8: Die Neustart-Erkennung funktioniert nicht, da ein Flag für das DNF needs-restarting Plugin fehlt. Es wird zu keinem Zeitpunkt ein Neustart durchgeführt.
• Fedora 32 und früher: Die Dienstneustart-Erkennung funktioniert nicht, da ein Flag für das DNF needs-restarting Plugin fehlt. Es werden zu keinem Zeitpunkt Dienstneustarts durchgeführt.
• opensuse 15 und 42: Eine fehlende Abhängigkeit erlaubt die Installation eines abhängigen Werkzeugs nicht. Eine Umgehungslösung ist vorhanden. Auch der Upgrade-Prozess scheint instabil zu sein. Ich werde diese Distributionen dennoch als stabil hinsichtlich des unten genannten OS-Kompatibilitätschecks auflisten, da die Rolle derzeit anscheinend keine Probleme verursacht, sei jedoch vorsichtig! Lass mich auch gerne wissen, wenn du eine Lösung für dieses Problem kennst.
• opensuse 15 und 42: Die Dienstneustart-Erkennung verwendet einen 'Brute-Force'-Ansatz, da die Ausgabe von zypper ps -s schwer zu parsen ist. Daher werden diese Betriebssysteme einfach neu gestartet, wenn Dienste neu gestartet werden müssen.

Anforderungen

Wenn du die Berichtsfunktion über Telegram verwenden möchtest:

collections:
- name: community.general
  version: 3.4.0

Bitte beachte, dass diese Rolle Root-Zugriff erfordert. Führe sie entweder in einem Playbook mit globalem become: yes aus oder rufe die Rolle in deinem Playbook wie folgt auf:

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

Diese Rolle prüft nur, ob das System nach einem Neustart an Port 22 verfügbar ist. Wenn du weitere Prüfungen oder Validierungen benötigst, musst du dich selbst darum kümmern.

Rollenvaiablen

Verfügbare Variablen sind unten aufgeführt, zusammen mit Standardwerten (siehe defaults/main.yml):

Grundlegende Variablen

upgrade_packages_on_hold: []

Lege Pakete fest, die du vor dem Upgrade nicht automatisch upgraden möchtest.

upgrade_unattended_reboot: true

Aktiviere den unbeaufsichtigten Neustart, falls nach Updates notwendig. Standard ist true, setze auf false, um Neustarts zu deaktivieren.

upgrade_force_reboot: false

Erzwinge einen Neustart jedes Servers unabhängig vom Ergebnis der Neustartüberprüfung. Standard ist false, setze auf true, um erzwungene Neustarts zu aktivieren.

upgrade_needrestart_disable_interaction: true

Das Tool needrestart wird verwendet, um notwendige Neustarts und Dienstneustarts zu bestimmen. Einige Distributionen sind standardmäßig so konfiguriert, dass sie interaktiv ausgeführt werden, was diese Rolle stört. Daher ist die Standardeinstellung, alle Interaktionen zu deaktivieren. Setze dies auf false, um die Interaktion aktiviert zu lassen. Siehe die Handbuchseite für weitere Details.

upgrade_restart_services: true

Aktiviere automatische Dienstneustarts. Dies verursacht, dass die Rolle Dienste neu startet, die neu gestartet werden müssen. Standard ist true, setze auf false, um Neustarts zu deaktivieren.

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

Schwarze Liste von Diensten, die nicht oder nicht neu gestartet werden sollen oder können. Die Standardliste basiert auf Erfahrung und wird erweitert. Lass mich gerne wissen, wenn Dienste hier hinzugefügt werden müssen.

Berichtvariablen

upgrade_reporting_enable: false

Aktiviere die Berichtsfunktion dieser Rolle, um die installierten Updates auszugeben und optional in eine Datei zu schreiben.

upgrade_reporting_path: "."

Lege fest, wo die Berichte abgelegt werden sollen. Standard ist dein aktuelles Arbeitsverzeichnis.

upgrade_reporting_cleanup: true

Bereinige die Berichtdateien, die zum Versenden von Berichten verwendet werden. Zum Debuggen kann es nützlich sein, sie zu behalten.

Telegram Berichtvariablen

upgrade_reporting_telegram_enable: false

Aktiviere die Berichterstattung über Telegram. Du musst die folgenden zwei Variablen mit deinen Anmeldedaten konfigurieren, um tatsächlich Nachrichten über Telegram zu senden! Siehe die Moduldokumentation für Details.

upgrade_telegram_token:  []

Dein Telegram Bot Token.

upgrade_telegram_chatid: []

Deine Telegram Chat-ID.

E-Mail Berichtvariablen

upgrade_reporting_mail_enable: false

Aktiviere die Berichterstattung über E-Mail.

upgrade_reporting_mail_subject: "Ansible Update Rollen Berichterstattung"

Konfiguriere den Betreff der E-Mail.

upgrade_reporting_mail_to: ""

Lege die Empfänger der E-Mail fest.

upgrade_reporting_mail_from: ""

Lege den Absender der E-Mail fest.

upgrade_reporting_mail_host: ""

Lege den E-Mail-Server oder Relay fest.

upgrade_reporting_mail_port: ""

Lege den E-Mail-Serverport fest.

upgrade_reporting_mail_user:
upgrade_reporting_mail_password:

Wenn der E-Mail-Server Authentifizierung benötigt, setze hier einen Benutzernamen und ein Passwort. Wenn keine Authentifizierung erforderlich ist, achte darauf, die Variablen leer zu lassen, wie hier zu sehen ist! Lass sie nicht leer sein, wie oben gezeigt.

upgrade_reporting_mail_run_once: true

Wenn du pro Play eine E-Mail senden möchtest, setze dies auf true. Wenn du lieber eine E-Mail pro Host senden möchtest, setze es auf false.

Abhängigkeiten

Keine.

OS-Kompatibilität

Diese Rolle stellt sicher, dass sie nicht gegen nicht unterstützte oder ungetestete Betriebssysteme verwendet wird, indem sie überprüft, ob der richtige Verteilungsname und die Hauptversionsnummer in einer speziellen Variablen vorhanden sind, die wie <role-name>_stable_os benannt ist. Du findest die Variable in der Standardvariablen-Datei der Rolle unter defaults/main.yml:

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

Wenn die Kombination aus Distribution und Hauptversionsnummer nicht mit dem Zielsystem übereinstimmt, schlägt die Rolle fehl. Um die Rolle funktionieren zu lassen, füge den Verteilungsnamen und die Hauptversionsnummer zu dieser Variablen hinzu und du solltest gut sein. Bitte teste die neue Kombination zuerst!

Ein großes Dankeschön an HarryHarcourt für diese Idee!

Beispiel-Playbook

---
- name: "Rolle ausführen."
  hosts: all
  become: yes
  roles:
    - ansible-role-upgrade

Mitwirken

Bitte zögere nicht, Probleme zu melden, wenn du Fehler oder Probleme entdeckst oder Verbesserungsmöglichkeiten siehst. Kontaktiere mich auch jederzeit gerne, wenn du etwas fragen oder diskutieren möchtest.

Haftungsausschluss

Diese Rolle wird WIE BESEHEN bereitgestellt, und ich kann und werde nicht garantieren, dass die Rolle wie beabsichtigt funktioniert, noch kann ich für Schäden oder Fehlkonfigurationen, die durch diese Rolle verursacht werden, verantwortlich gemacht werden. Studiere die Rolle gründlich, bevor du sie verwendest.

Lizenz

MIT

Autor Informationen

Diese Rolle wurde 2019 von Thorian93 erstellt.