Zum Inhalt

Ansible Server Maintenance Playbook

Mit diesem Ansible Playbook lassen sich wiederkehrende Aufgaben der täglichen Serveradministration einfach automatisieren.

Das Ziel

Das Ansible Playbook verwaltet die Raspberry Pi Server im eigenen Netzwerk und übernimmt die folgenden Aufgaben:

  1. die Raspberry Pis werden auf dem aktuellsten Stand gehalten (update && apt dist-upgrade && apt autoremove),
  2. die Temperatur der Server wird abgefragt und bei Überschreiten einer definierten Schwelle eine E-Mail an den Administrator gesendet,
  3. der Speicherplatzverbrauch der Festplatten wird abgefragt und bei Überschreiten einer definierten Schwelle eine E-Mail an den Administrator gesendet,
  4. das Gruppen- und Benutzermanagement inkl. deployen von SSH Keys.

Codeberg

Zum Ansible Play

Das Playbook kann auch den Speicherplatz von anderen Hardwaregeräten abfragen, wie z.B. einem Synology NAS. Weitere Aktionen auf diesen Geräten werden NICHT durchgeführt, da das Gruppen- und Benutzermanagement manuell über die grafische Benutzeroberfläche einfacher durchzuführen ist.

Die Rollen und Aufgaben sind so gestaltet, dass sie allgemein gehalten werden. Spezifische Informationen werden über den Ansible Vault abgerufen (ausgenommen Benutzer und Rollen).

Die Anmeldung

Ansible verwendet für die Anmeldung an den Servern ein SSH-Schlüsselpaar, welches auf einem YubiKey abgespeichert ist. Wie der Hardwaretoken dafür eingerichtet wird, findet ihr in meinem Blog:

Es werden bei dieser Form der Anmeldung keine Daten auf dem Client hinterlegt. Auf den Servern muss lediglich die ~/.ssh/authorized_keys angepasst werden. Der Benutzer, der auf dem entfernten Server die Ansible-Befehle ausführen soll, sollte über sudo-Rechte verfügen.

Ansible findet die Server über Einträge in der ~/.ssh/authorized_keys auf dem Client. Es können auch die IP-Adressen, wie am Beispiel von rpi1, oder DNS-Einträge, wie am Beispiel von nextcloud, direkt in der Datei inventory.ini vorgenommen werden.

Meine Empfehlung ist die Pflege der Server in der ~/.ssh/authorized_keys auf dem eigenen Client, da damit auch der "normale" SSH- oder mosh-Zugriff auf die Server funktioniert.

inventory.ini

In der inventory.ini werden alle Server aufgelistet und gruppiert.

Alle Raspberry Pi Server werden in die Gruppe [all_hosts] einsortiert.

Es werden die Untergruppen

  1. [raspberrypi_servers]
  2. [pihole_servers]
  3. [nextcloud_servers]
  4. [cctv_servers]
  5. [synology_servers]

für die Server angelegt, damit die Abfrage der Speicherplatzbelegung pro Servergruppe zielgenau erfolgen kann.

Die Synology NAS sind dabei NICHT in die [all_hosts] aufzunehmen, sondern nur im Abschnitt [synology_servers] zu listen. Die Zugriffsrechte auf die NAS unterscheiden sich von den Raspberry Pis, es wird z.B. kein sudo verwendet

update_upgrade.yml

Im Playbook wird vorgegeben welche Rollen (= role) für welche Servergruppe aufgerufen werden soll.

Die nachfolgenden Beispiele sollen das Vorgehen verdeutlichen. Die Abfragen sind so gestaltet, dass jeder Server der jeweiligen Gruppe abgefragt wird, es wird ein Loop (= with_items) genutzt. Das Playbook iteriert durch die Liste der Server einer Gruppe, d.h. es wiederholt jede Aufgabe für jeden Server in immer der gleichen Qualität.

Beispiel 1

Nur für Servergruppe [raspberrypi_servers] sollen die Rollen

  1. update_upgrade
  2. reboot-if-needed
  3. clean_server

aufgerufen werden.

Alle anderen Servergruppen werden ignoriert.

Beispiel 2

Für die Servergruppe [all_hosts] wird nur die Speicherbelegung dem Befehl df- h abgefragt. Es wird aber nur das Ergebnis für die Standardfestplatte ausgegeben, obwohl alle Festplatten Informationen vorliegen würden. Da aber ein einheitlicher Ansatz gewählt wurde, erfolgt die Auswertung mit awk das nur die zweite Zeile (= /dev/root) ausgibt.

Die Server der Gruppe [cctv] binden über den Mount Point /mnt/motioncode> ein zusätzliches externes USB-Speichermedium ein. Die Speicherbelegung wird in der Rolle roles/disk_usages_cctv ganz gezielt für diese Servergruppe abgefragt.

Beispiel 3

Für die Server der Gruppe [nextcloud_servers] wurden mehrere externe Speichermedien mit anderen Mount Point-Bezeichnungen eingebunden. Diese werden in der roles/disk_usages_nextcloud/vars/main.yml einzeln aufgelistet und dann in der Rolle roles/disk_usages_nextcloud/tasks/main.yml abgefragt.

vault.yml

Es wird Ansible Vault verwendet, um sensitive Informationen verschlüssel abzuspeichern.

Ein neues Ansible Vault lässt sich sehr einfach mit dem Befehl erstellen:

ansible-vault create /group_vars/all/vault.yml

Möchte man den Inhalt bearbeiten, dann kann das Vault mit dem Passwort geöffnet werden.

ansible-vault edit /group_vars/all/vault.yml

Inhalt des Ansible Vaults

Der Abschnitt enthält den Inhalt des Ansible Vaults. Die Einträge sind an die eigenen Anforderungen anzupassen und als neues Vault abzuspeichern /group_vars/all/vault.yml.

Gib mir gerne einen Kaffee ☕ aus ❗️

Wenn dir meine Beiträge gefallen und geholfen haben, dann kannst du mir gerne einen Kaffee ☕️ ausgeben.

Donation via PayPal • Donation via LiberaPay

Donation via Bitcoin
Bitcoin Address: bc1qfuz93hw2fhdvfuxf6mlxlk8zdadvnktppkzqzj

---
# Ansible Vault
# All data in the vault are protected by a password!


###########################
# Global Variables
###########################


###########################
# General E-Mail
###########################
vault_email: administrator@email.de


###########################
# DNS-Server
###########################
# used in roles/copy_files/vars/main.yml
vault_dns_server: 192.168.2.2


###########################
# NTP-Server
###########################
# used in roles/copy_files/vars/main.yml
vault_timesyncd_conf_ntp: 192.168.2.1


###########################
# Postfix Configuration
###########################
# Postfix Configuration File - main.cf
vault_postfix_myhostname_workgroup: fritz.box
vault_mail_domain: email-domain.de
vault_postfix_smtp: smtp.strato.de
vault_postfix_smtp_port: 465
vault_postfix_smtp_username: administrator@email.de
vault_postfix_smtp_password: supersecretpassword


###########################
# CC Recipients Of Notification Emails
###########################
# Uncomment the CC line in the task email.yml to activate the function

vault_cc:
  - recipient1@email.de
  - recipient1@email.de

Globale Variablen

Globale Variablen werden allen Rollen und Aufgaben zur Verfügung gestellt und sind in der Datei group_vars/all/vars.yml definiert.

Gruppenverwaltung

Die Rolle für die Verwaltung der Gruppen ist roles/groups_create_delete. Die Items sind in der Variablen-Datei der Rolle roles/groups_create_delete/vars/main.yml abgespeichert.

Benutzerverwaltung

Für die Benutzerverwaltung sind alle notwendigen Dateien im Verzeichnis group_vars/user_management zu finden. Die dort hinterlegten Items werden von den Rollen verwendet:

  1. roles/users_create
  2. roles/users_delete
  3. roles/users_delete_unknown

Möchte man die Gruppen ebenfalls in diesem Verzeichnis verwalten, ist die Datei roles/groups_create_delete/vars/main.yml dorthin zu verschieben und die Referenzen zu ändern.

Achtung

Die Rollen für

  1. die Gruppenverwaltung = roles/groups_create_delete
  2. die Benutzerverwaltung = roles/users_create, roles/users_delete, roles/users_delete_unknown
  3. SSH = roles/ssh

sind sehr eng aufeinander abgestimmt.

Es werden neue Gruppen angelegt, und die sshd_config überschrieben, damit nur noch Mitglieder der Gruppe sshadmin sich per SSH mit dem Server verbinden können.

Bevor das Playbook gestartet wird, sollte man sich dringend mit dem Ablauf vertraut machen und auch die sshd_config-Dateien im Verzeichnis roles/ssh/files genau betrachtet werden.

Achtet unbedingt darauf, dass euer Benutzer in der Datei group_vars/user_management/user_list.yml als aktiver Benutzer eingetragen ist. Fehlt der Eintrag, wird das Benutzerkonto auf den Server gelöscht.

Roles

In den einzelnen Rollen (roles) sind die Aufgaben, die Tasks, definiert.

Der Aufruf der Rollen erfolgt über die Hauptdatei update_upgrade.yml, über die auch das gesamte Playbook gestartet wird.

In den Rollen gibt es zwei wichtige Dateien, die (hoffentlich) ausreichend genug kommentiert sind, um die einzelnen Schritte nachvollziehen zu können.

  1. tasks/main.yml = In dieser Datei werden die Aufgaben (= tasks) definiert.
  2. vars/main.yml = In dieser Datei werden die Variablen definiert, die für die Aufgaben dieser Rolle benötigt werden. Für eine bessere Übersichtlichkeit werden auch die globalen Variablen aus dem Vault noch einmal aufgerufen.

E-Mail-Versand

Der E-Mail-Versand ist in jeder Rolle über die Datei tasks/email.yml frei konfigurierbar. Die "Hauptaufgabe" mail.yml ruft die Aufgabe für den E-Mail-Versand auf, wenn die Bedingung (z.B. Speicherbelegung > x%) erfüllt ist.

Die Anlage ist die Log-Datei meines sysstatus.sh-Skripts.

Codeberg

Dein Weg zur eigenen Nextcloud

Codeberg

Zum Ansible Play

Gib mir gerne einen Kaffee ☕ aus ❗️

Wenn dir meine Beiträge gefallen und geholfen haben, dann kannst du mir gerne einen Kaffee ☕️ ausgeben.

Donation via PayPal • Donation via LiberaPay

Donation via Bitcoin
Bitcoin Address: bc1qfuz93hw2fhdvfuxf6mlxlk8zdadvnktppkzqzj

Source

Foto von Simon Kadula auf Unsplash