Ansible: Automatisierung von Serverbereitstellung und -konfiguration

Ansible ist ein Open-Source-Software-Tool zur Automatisierung von Serverbereitstellung, Konfigurationsmanagement und Anwendungsbereitstellung. Mit Ansible können Sie Aufgaben auf einem oder mehreren Servern automatisieren oder eine verteilte Anwendung über mehrere Server ausführen. Für eine Multi-Server-Umgebung kann die manuelle Durchführung der anfänglichen Servereinrichtung für jeden Server zeitaufwändig sein, während die Verwendung von Ansible diesen Prozess mithilfe von Automatisierungs-Playbooks erheblich beschleunigt.

Ansible benötigt keine Agenten, daher müssen auf den Zielservern keine Ansible-Komponenten installiert sein. Diese Server, die Ansible-Hosts heißen, müssen jedoch Python 3 und OpenSSH ausführen, die standardmäßig auf Ubuntu 22.04 und den meisten Linux-Distributionen vorinstalliert sind. Der Ansible-Steuerknoten ist die Maschine, die die Automatisierung startet und jedes kompatible Unix-ähnliche Betriebssystem oder Windows (mit installiertem Windows Subsystem for Linux, WSL) ausführen kann.

In diesem Tutorial verwenden Sie Ansible, um die anfängliche Serverkonfiguration mehrerer Ubuntu 22.04-Server zu automatisieren. Sie werden die folgenden anfänglichen Einrichtungsschritte auf allen Servern durchführen:

• Aktualisierung der installierten Pakete
• Hinzufügen eines Nicht-Root-Benutzers mit Administratorrechten
• Aktivierung des SSH-Zugriffs für diesen Nicht-Root-Benutzer
• Aktivierung der Firewall
• Ändern des Ports für den SSH-Zugriff und Verwendung der Firewall, um Brute-Force-Angriffe abzuwehren und die Serversicherheit zu erhöhen
• Deaktivierung der Remote-Anmeldung für das Root-Konto
• Sicherstellen, dass kritische Dienste aktiv sind
• Entfernen von nicht mehr benötigten Paketabhängigkeiten

Da Sie Ansible verwenden, um ein umfassendes Playbook auszuführen, das jede Aufgabe definiert, sind diese Aufgaben mit nur einem Befehl abgeschlossen, ohne dass Sie sich einzeln auf den Servern anmelden müssen. Sie können ein optionales sekundäres Playbook ausführen, um die Serververwaltung nach der anfänglichen Serverkonfiguration zu automatisieren.

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie:

• Ansible, das auf einer Maschine installiert ist, die als Steuerknoten fungiert. Dies kann Ihre lokale Maschine oder ein Remote-Linux-Server sein. Um Ansible auf Ubuntu 22.04 zu installieren und zu konfigurieren, können Sie sich auf den offiziellen Ansible Installationsleitfaden beziehen oder Anleitungen für andere Betriebssysteme nutzen.
• Wenn Ihr Steuerknoten ein Remote-Ubuntu-22.04-Server ist, richten Sie ihn mit der anfänglichen Serverkonfiguration ein und erstellen Sie dessen SSH-Schlüsselpaar.
• Git, das auf dem Steuerknoten installiert ist. Installieren Sie Git für gängige Linux-Distributionen.
• Zwei oder mehr Ubuntu-22.04-Server sowie die öffentliche IPv4-Adresse jedes Servers. Es ist keine vorherige Einrichtung erforderlich, da Sie Ansible verwenden, um die Einrichtung in Schritt 5 zu automatisieren. Sie müssen jedoch SSH-Zugriff auf diese Server vom oben genannten Ansible-Steuerknoten aus haben.
• Wenn Ihr Steuerknoten ein Remote-Ubuntu-22.04-Server ist, verwenden Sie ssh-copy-id, um das Schlüsselpaar mit den Hosts zu verbinden.

Schritt 1 — Modifizieren der SSH-Client-Konfigurationsdatei auf Ihrem Steuerknoten

In diesem Schritt ändern Sie eine Direktive in der SSH-Client-Konfigurationsdatei Ihres Steuerknotens. Nach dieser Änderung kommt keine Aufforderung mehr, den SSH-Schlüsselabdruck von Remote-Maschinen zu akzeptieren, da es zur automatischen Akzeptanz kommt. Das manuelle Akzeptieren der SSH-Schlüsselabdrücke für jede Remote-Maschine kann mühsam sein, sodass diese Änderung ein Skalierungsproblem beim Einsatz von Ansible zur Automatisierung der anfänglichen Einrichtung mehrerer Server löst.

Zwar können Sie das Ansible-Modul known_hosts verwenden, um den SSH-Schlüsselabdruck für einen einzelnen Host automatisch zu akzeptieren, doch in diesem Tutorial werden mehrere Hosts behandelt. Daher ist es effektiver, die SSH-Client-Konfigurationsdatei auf dem Steuerknoten (in der Regel Ihr lokaler Rechner) zu ändern.

Öffnen Sie zunächst ein Terminal auf Ihrem Steuerknoten und öffnen Sie die SSH-Client-Konfigurationsdatei mit Nano oder Ihrem bevorzugten Texteditor:

sudo nano /etc/ssh/ssh_config

Suchen Sie die Zeile, die die Direktive StrictHostKeyChecking enthält. Kommentieren Sie diese aus und ändern Sie den Wert, sodass sie wie folgt lautet:

StrictHostKeyChecking accept-new

Speichern und schließen Sie die Datei. Es ist nicht erforderlich, den SSH-Daemon neu zu laden oder neu zu starten, da Sie nur die SSH-Client-Konfigurationsdatei geändert haben.

Hinweis: Wenn Sie den Wert von StrictHostKeyChecking nicht dauerhaft von ask auf accept-new ändern möchten, können Sie ihn nach dem Ausführen des Playbooks in Schritt 7 wieder auf den Standardwert zurücksetzen. Durch die Änderung des Wertes wird Ihr System SSH-Schlüsselabdrücke automatisch akzeptieren, aber nachfolgende Verbindungen von denselben Hosts ablehnen, wenn sich die Abdrücke ändern. Diese Funktion bedeutet, dass die Änderung auf accept-new kein so großes Sicherheitsrisiko darstellt wie die Änderung auf no.

Nachdem Sie die SSH-Direktive aktualisiert haben, beginnen Sie mit der Konfiguration von Ansible, wie in den nächsten Schritten beschrieben.

Schritt 2 — Konfigurieren der Ansible-Hosts-Datei

Die Ansible-Hosts-Datei (auch Inventardatei genannt) enthält Informationen zu den Ansible-Hosts. Diese Informationen können Gruppennamen, Aliase, Domainnamen und IP-Adressen umfassen. Die Datei befindet sich standardmäßig im Verzeichnis /etc/ansible. In diesem Schritt fügen Sie die IP-Adressen der Ansible-Hosts hinzu, die Sie im Abschnitt „Voraussetzungen“ eingerichtet haben, damit Sie Ihr Ansible-Playbook gegen sie ausführen können.

Öffnen Sie die Hosts-Datei mit Nano oder Ihrem bevorzugten Texteditor:

sudo nano /etc/ansible/hosts

Fügen Sie nach den einleitenden Kommentaren in der Datei die folgenden Zeilen hinzu:

host1 ansible_host=host1-public-ip-address
host2 ansible_host=host2-public-ip-address
host3 ansible_host=host3-public-ip-address

[initial]
host1
host2
host3

[ongoing]
host1
host2
host3

host1, host2 und host3 sind Aliase für jeden Host, auf dem Sie die anfängliche Serverkonfiguration automatisieren möchten. Die Verwendung von Aliases erleichtert die Referenzierung der Hosts an anderer Stelle. ansible_host ist eine Ansible-Verbindungsvariable und zeigt in diesem Fall auf die IP-Adressen der Zielhosts.

[initial] und [ongoing] sind Beispielgruppennamen für die Ansible-Hosts. Wählen Sie Gruppennamen, die es einfach machen, zu erkennen, wofür die Verwendung der Hosts ist. Das Gruppieren von Hosts auf diese Weise ermöglicht es, sie als Einheit anzusprechen. Hosts können zu mehr als einer Gruppe gehören. Die Hosts in diesem Tutorial wurden zwei verschiedenen Gruppen zugeordnet, da sie in zwei verschiedenen Playbooks verwendet werden: [initial] für die anfängliche Serverkonfiguration in Schritt 6 und [ongoing] für die spätere Serververwaltung in Schritt 8.

hostN-public-ip-address ist die IP-Adresse für jeden Ansible-Host. Ersetzen Sie host1-public-ip-address und die nachfolgenden Zeilen durch die IP-Adressen der Server, die Teil der Automatisierung sein sollen.

Speichern und schließen Sie die Datei, nachdem Sie sie geändert haben.

Durch die Definition der Hosts in der Inventardatei können Sie angeben, welche Hosts mit der Ansible-Automatisierung eingerichtet werden. Im nächsten Schritt klonen Sie das Repository mit den Beispiel-Playbooks zur Automatisierung der Multi-Server-Einrichtung.

Schritt 3 — Klonen des Ansible-Ubuntu-Initial-Server-Setup-Repositorys

In diesem Schritt klonen Sie ein Beispiel-Repository von GitHub, das die für diese Automatisierung erforderlichen Dateien enthält.

Dieses Repository enthält drei Dateien für eine Beispiel-Multi-Server-Automatisierung: initial.yml, ongoing.yml und vars/default.yml. Die Datei initial.yml ist das Haupt-Playbook, das die Plays und Aufgaben enthält, die Sie gegen die Ansible-Hosts zur anfänglichen Einrichtung ausführen. Die Datei ongoing.yml enthält Aufgaben, die Sie nach der anfänglichen Servereinrichtung zur laufenden Wartung der Hosts ausführen. Die Datei vars/default.yml enthält Variablen, die sowohl in Schritt 6 als auch in Schritt 8 in beiden Playbooks aufgerufen werden.

Um das Repository zu klonen, geben Sie den folgenden Befehl ein:

git clone https://github.com/do-community/ansible-ubuntu.git

Alternativ, wenn Sie Ihren SSH-Schlüssel zu Ihrem GitHub-Konto hinzugefügt haben, können Sie das Repository mit dem folgenden Befehl klonen:

git@github.com:do-community/ansible-ubuntu.git

Jetzt haben Sie einen Ordner mit dem Namen ansible-ubuntu in Ihrem Arbeitsverzeichnis. Wechseln Sie in dieses Verzeichnis:

cd ansible-ubuntu

Das wird Ihr Arbeitsverzeichnis für den Rest dieses Tutorials sein.

In diesem Schritt haben Sie die Beispieldateien zur Automatisierung mehrerer Ubuntu-22.04-Server mit Ansible abgerufen. Um die Dateien mit Informationen zu Ihren Hosts vorzubereiten, werden Sie im nächsten Schritt die Datei vars/default.yml aktualisieren, damit sie mit Ihrem System funktioniert.

Schritt 4 — Anpassen der Ansible-Variablen

Dieses Playbook referenziert einige Informationen für die Automatisierung, die möglicherweise mit der Zeit zu aktualisieren sind. Es ist effizienter, diese Informationen in einer Variablendatei zu platzieren und sie in den Playbooks aufzurufen, anstatt sie direkt in den Playbooks fest zu codieren. In diesem Schritt passen Sie die Variablen in der Datei vars/default.yml an Ihre Präferenzen und Anforderungen an.

Öffnen und Überprüfen der Variablendatei

Öffnen Sie die Datei mit Nano oder Ihrem bevorzugten Texteditor:

nano vars/default.yml

Überprüfen Sie den Inhalt der Datei, der die folgenden Variablen enthält:

create_user: sammy

ssh_port: 5995

copy_local_key: "{{ lookup('file', lookup('env','HOME') + '/.ssh/id_rsa.pub') }}"

Erklärung der Variablen

Der Wert der Variablen create_user sollte der Name des sudo-Benutzers sein, der auf jedem Host erstellt wird. In diesem Fall ist es sammy, aber Sie können den Benutzer nach Belieben benennen.

Die Variable ssh_port enthält den SSH-Port, den Sie nach der Einrichtung für die Verbindung zu den Ansible-Hosts verwenden werden. Der Standardport für SSH ist 22, aber eine Änderung wird die Anzahl automatisierter Angriffe auf Ihre Server erheblich reduzieren. Diese Änderung ist optional, wird jedoch die Sicherheitslage Ihrer Hosts verbessern. Wählen Sie einen weniger bekannten Port, der zwischen 1024 und 65535 liegt und die keine anderen Anwendung auf den Ansible-Hosts vorweist. In diesem Beispiel kommt es zur Verwednung des Ports 5995.

Hinweis: Wenn Ihr Steuerknoten eine Linux-Distribution ist, wählen Sie eine Zahl größer als 1023 und durchsuchen Sie die Datei /etc/services. Zum Beispiel können Sie den Befehl grep 5995 /etc/services ausführen, um zu prüfen, ob 5995 verwendet wird. Wenn keine Ausgabe erscheint, besteht keine Verwendung des Ports. Wenn Ihr Steuerknoten kein Linux ist und Sie die entsprechende Datei nicht finden, können Sie das Service Name and Transport Protocol Port Number Registry konsultieren.

Die Variable copy_local_key referenziert die SSH-öffentliche Schlüsseldatei Ihres Steuerknotens. Wenn der Name dieser Datei id_rsa.pub ist, müssen Sie diese Zeile nicht ändern. Andernfalls ändern Sie den Namen, um mit der SSH-öffentlichen Schlüsseldatei Ihres Steuerknotens übereinzustimmen. Sie finden die Datei im Verzeichnis ~/.ssh Ihres Steuerknotens. Wenn Sie das Haupt-Playbook in Schritt 5 ausführen und nach der Erstellung eines Benutzers mit sudo-Rechten, kopiert der Ansible-Controller die öffentliche Schlüsseldatei in das Home-Verzeichnis des Benutzers. Dies ermöglicht es Ihnen, sich nach der anfänglichen Servereinrichtung über SSH als dieser Benutzer anzumelden.

Speichern und Anwenden der Änderung

Speichern und schließen Sie die Datei, nachdem Sie sie geändert haben.

Nachdem Sie Werte für die Variablen in vars/default.yml zugewiesen haben, kann Ansible diese Variablen beim Ausführen der Playbooks in Schritt 6 und Schritt 8 aufrufen. Im nächsten Schritt verwenden Sie Ansible Vault, um die Passwörter für den Benutzer zu erstellen und zu sichern, der auf jedem Host eingerichtet wird.

Schritt 5 — Verwenden von Ansible Vault zur Erstellung einer verschlüsselten Passwortdatei

Die Verwendung von Ansible Vault besetht daraus Dateien und Variablen zu erstellen und zu verschlüsseln bei denen es zur Referenzierung im Playbooks kommt. Dabei ist sicher gestellt, dass sensible Informationen während der Ausführung eines Playbooks nicht im Klartext übertragen sind. In diesem Schritt erstellen und verschlüsseln Sie eine Datei, die Variablen enthält, deren Werte für die Erstellung eines Passworts für den sudo-Benutzer auf jedem Host wichtig ist. Durch die Verwendung von Ansible Vault auf diese Weise ist sichergestellt, dasses zu keiner Referenzierung des Passwortes im Klartext während und nach der anfänglichen Servereinrichtung im Playbook kommt.

Erstellung und Konfiguration der Vault-Datei

Verwenden Sie den folgenden Befehl, um in Ihrem Verzeichnis ansible-ubuntu eine Vault-Datei zu erstellen und zu öffnen:

ansible-vault create secret

Wenn Sie dazu aufgefordert werden, geben Sie ein Passwort ein und bestätigen Sie es, das zur Verschlüsselung der Datei secret verwendet wird. Dies ist das Vault-Passwort. Sie benötigen das Vault-Passwort, um die Playbooks in Schritt 6 und Schritt 8 auszuführen. Vergessen Sie es also nicht.

Nach Eingabe und Bestätigung des Vault-Passworts wird die Datei secret im Texteditor geöffnet, der mit der Umgebungsvariablen EDITOR der Shell verknüpft ist. Fügen Sie diese Zeilen in die Datei ein, und ersetzen Sie die Werte für type_a_strong_password_here und type_a_salt_here:

password: type_a_strong_password_here
password_salt: type_a_salt_here

Der Wert der Variablen password wird das eigentliche Passwort für den sudo-Benutzer, den Sie auf jedem Host erstellen. Die Variable password_salt verwendet einen Salt als Wert. Ein Salt ist ein beliebiger langer, zufälliger Wert, der für die Erstellung von gehashten Passwörtern Verwendung findet. Sie können eine alphabetische oder alphanumerische Zeichenkette verwenden, aber eine numerische Zeichenkette allein funktioniert möglicherweise nicht. Das Hinzufügen eines Salts bei der Generierung eines gehashten Passworts erschwert das Erraten des Passworts oder das Knacken des Hashing.

Wichtige Hinweise zur Verwendung von Salt

Hinweis: In Tests haben wir festgestellt, dass ein Salt, der nur aus numerischen Zeichen besteht, zu Problemen beim Ausführen der Playbooks in Schritt 6 und Schritt 8 führen kann. Ein Salt, der nur aus alphabetischen Zeichen besteht, funktioniert jedoch einwandfrei. Ein alphanumerischer Salt sollte ebenfalls funktionieren. Beachten Sie dies bei der Angabe eines Salts.

Speichern und schließen Sie die Datei, nachdem Sie sie geändert haben.

Sie haben nun eine verschlüsselte Passwortdatei mit Variablen erstellt, die für die Erstellung eines Passworts für den sudo-Benutzer auf den Hosts ist. Im nächsten Schritt automatisieren Sie die anfängliche Einrichtung der Server, die Sie in Schritt 2 definiert haben, indem Sie das Haupt-Playbook ausführen.

Schritt 6 — Ausführen des Haupt-Playbooks auf Ihren Ansible-Hosts

In diesem Schritt verwenden Sie Ansible, um die anfängliche Servereinrichtung für so viele Server zu automatisieren, wie Sie in Ihrer Inventardatei angegeben haben. Sie beginnen damit, die in der Haupt-Playbook-Datei definierten Aufgaben zu überprüfen. Anschließend führen Sie das Playbook auf den Hosts aus.

Ein Ansible-Playbook besteht aus einem oder mehreren Plays, die jeweils mit einer oder mehreren Aufgaben verknüpft sind. Das Beispiel-Playbook, das Sie auf Ihren Ansible-Hosts ausführen, enthält zwei Plays mit insgesamt 14 Aufgaben.

Bevor Sie das Playbook ausführen, überprüfen Sie die darin enthaltenen Aufgaben. Öffnen Sie die Datei mit nano oder Ihrem bevorzugten Texteditor:

nano initial.yml

Play 1: Aufgaben für die anfängliche Servereinrichtung

Der erste Abschnitt der Datei enthält die folgenden Schlüsselwörter, die das Verhalten des Plays beeinflussen:

initial.yml
- name: Initial server setup tasks
  hosts: initial
  remote_user: root
  vars_files:
    - vars/default.yml
    - secret

name ist eine kurze Beschreibung des Plays, die während der Ausführung im Terminal zu sehen ist. Das Schlüsselwort hosts gibt an, welche Hosts das Ziel des Plays sind. In diesem Fall ist das Muster, das an das Schlüsselwort übergeben wird, der Gruppenname der Hosts, den Sie in Schritt 2 in der Datei /etc/ansible/hosts definiert haben. Mit dem Schlüsselwort remote_user geben Sie an, mit welchem Benutzernamen sich der Ansible-Controller bei den Hosts anmeldet (in diesem Fall root). Das Schlüsselwort vars_files verweist auf die Dateien, die Variablen enthalten, auf die während der Ausführung der Aufgaben verwiesen wird.

Mit diesem Setup versucht der Ansible-Controller, sich über den SSH-Port 22 als Benutzer root bei den Hosts anzumelden. Für jeden Host, bei dem dies gelingt, wird eine ok-Antwort gemeldet. Andernfalls meldet Ansible, dass der Server nicht erreichbar ist, und beginnt, die Aufgaben des Plays für die Hosts auszuführen, bei denen die Anmeldung erfolgreich war.

Nach dem Abschnitt mit den Schlüsselwörtern folgt eine Liste von Aufgaben, die später nacheinander ausgeführt sind. Wie das Play beginnt auch jede Aufgabe mit einem name, der eine kurze Beschreibung dessen liefert, was die Aufgabe erreichen soll.

Aufgabe 1: Aktualisieren des Paket-Cache

Die erste Aufgabe im Playbook aktualisiert die Paketdatenbank:

initial.yml
- name: update cache
  ansible.builtin.apt:
    update_cache: yes

Diese Aufgabe aktualisiert die Paketdatenbank mithilfe des ansible.builtin.apt–Moduls, weshalb sie mit update_cache: yes definiert ist. Diese Aufgabe erfüllt die gleiche Funktion wie das manuelle Ausführen von sudo apt update auf einem Ubuntu-Server, das oft ein Vorbereitungsschritt für die Aktualisierung aller installierten Pakete ist.

Aufgabe 2: Aktualisieren aller installierten Pakete

Die zweite Aufgabe im Playbook aktualisiert die Pakete:

initial.yml
- name: Update all installed packages
  ansible.builtin.apt:
    name: "*"
    state: latest

Wie die erste Aufgabe ruft auch diese Aufgabe das ansible.builtin.apt-Modul auf. Hier stellen Sie sicher, dass alle installierten Pakete aktualisiert sind, indem Sie ein Platzhalterzeichen verwenden (name: "*") und state: latest angeben, was dem manuellen Ausführen des Befehls sudo apt upgrade -y auf Ihren Servern entspricht.

Aufgabe 3: Sicherstellen, dass der NTP-Dienst aktiv ist

Die dritte Aufgabe im Playbook stellt sicher, dass der Netzwerkzeitprotokolldienst (NTP-Dienst) aktiv ist:

initial.yml
- name: Make sure NTP service is running
  ansible.builtin.systemd:
    state: started
    name: systemd-timesyncd

Diese Aufgabe ruft das ansible.builtin.systemd–Modul auf, um sicherzustellen, dass der systemd-timesyncd-Dienst aktiv ist (state: started). Dadurch wird sichergestellt, dass Ihre Server die gleiche Zeit behalten, was nützlich ist, wenn es zur verteilten Anwendung auf diesen Servern kommt.

Aufgabe 4: Sicherstellen, dass eine sudo-Gruppe vorhanden ist

Die vierte Aufgabe im Playbook überprüft, ob eine sudo-Gruppe vorhanden ist:

initial.yml
- name: Make sure we have a 'sudo' group
  ansible.builtin.group:
    name: sudo
    state: present

Diese Aufgabe ruft das ansible.builtin.group–Modul auf, um sicherzustellen, dass auf den Hosts eine Gruppe mit dem Namen sudo existiert (state: present). Da Ihre nächste Aufgabe davon abhängt, dass auf den Hosts eine sudo-Gruppe vorhanden ist, stellt diese Aufgabe sicher, dass sudo-Gruppen existieren, sodass die nächste Aufgabe nicht fehlschlägt.

Aufgabe 5: Erstellen eines Benutzers mit sudo-Berechtigungen

Die fünfte Aufgabe im Playbook erstellt einen nicht-root Benutzer mit sudo-Berechtigungen:

initial.yml
- name: Create a user with sudo privileges
  ansible.builtin.user:
    name: "{{ create_user }}"
    state: present
    groups: sudo
    append: true
    create_home: true
    shell: /bin/bash
    password: "{{ password | password_hash('sha512', password_salt) }}"
    update_password: on_create

In dieser Aufgabe wird mithilfe des ansible.builtin.user–Moduls ein Benutzer auf jedem Host erstellt und die sudo-Gruppe dem Benutzer hinzugefügt. Der Benutzername wird aus der in der Datei vars/default.yml definierten Variablen create_user abgeleitet. Diese Aufgabe stellt sicher, dass es zu einer Erstellung des Home-Verzeichnis für den Benutzer kommt und die Zuweisung der richtigen Shell.

Das password-Parameter in Kombination mit den Variablen password und password_salt generiert einen gehashten Passwortwert mithilfe der SHA-512-Hash-Funktion. Mit update_password wird sichergestellt, dass das gehashte Passwort nur beim erstmaligen Erstellen des Benutzers gesetzt wird. Wenn das Playbook erneut ausgeführt wird, wird das Passwort nicht neu generiert.

Aufgabe 6: Festlegen des autorisierten Schlüssels für den Remote-Benutzer

Die sechste Aufgabe im Playbook legt den SSH-Schlüssel für den Benutzer fest:

initial.yml
- name: Set authorized key for remote user
  ansible.posix.authorized_key:
    user: "{{ create_user }}"
    state: present
    key: "{{ copy_local_key }}"

In dieser Aufgabe wird der öffentliche SSH-Schlüssel des Steuerknotens auf den Hosts kopiert, indem das ansible.posix.authorized_key–Modul verwendet wird. Der Wert von user ist der Name des Benutzers, der in Aufgabe 5 auf den Hosts erstellt wurde. Der Wert von key zeigt auf den zu kopierenden Schlüssel, der in der Datei vars/default.yml definiert ist. Diese Aufgabe entspricht dem manuellen Ausführen des Befehls ssh-copy-id.

Aufgabe 7: Deaktivieren des Remote-Logins für root

Die siebte Aufgabe im Playbook deaktiviert den Remote-Login für den Benutzer root:

initial.yml
- name: Disable remote login for root
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    state: present
    regexp: '^PermitRootLogin yes'
    line: 'PermitRootLogin no'

Diese Aufgabe verwendet das ansible.builtin.lineinfile–Modul, um eine Zeile im SSHD-Konfigurationsfile /etc/ssh/sshd_config zu suchen und zu ändern. Diese Zeile wird durch die neue Einstellung PermitRootLogin no ersetzt. Damit wird sichergestellt, dass sich der Benutzer root nicht mehr remote anmelden kann. Die Anmeldung ist nur noch mit dem Benutzerkonto aus Aufgabe 6 möglich. Administratorrechte können dann über sudo erlangt werden.

Aufgabe 8: Ändern des SSH-Ports

Die achte Aufgabe im Playbook ändert den Port, über den der SSH-Dienst erreichbar ist:

initial.yml
- name: Change the SSH port
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    state: present
    regexp: '^#Port 22'
    line: 'Port "{{ ssh_port }}"'

Da Port 22 ein bekannter Standardport ist, wird er oft Ziel von automatisierten Angriffen. Durch das Ändern des SSH-Ports ist die Sicherheit der Hosts erhöht. Diese Aufgabe verwendet das ansible.builtin.lineinfile-Modul, um den Standardport 22 auf einen benutzerdefinierten Port zu ändern, der in der Datei vars/default.yml definiert ist.

Aufgabe 9: UFW – SSH-Verbindungen erlauben

Die neunte Aufgabe im Playbook erlaubt den SSH-Zugriff über die Firewall:

initial.yml
- name: UFW - Allow SSH connections
  community.general.ufw:
    rule: allow
    port: "{{ ssh_port }}"

Diese Aufgabe verwendet das community.general.ufw–Modul, um den SSH-Datenverkehr durch die Firewall zuzulassen. Beachten Sie, dass der SSH-Port nicht mehr 22 ist, sondern der davor benutzerdefinierte Port. Diese Aufgabe entspricht dem manuellen Ausführen des Befehls ufw allow 5995/tcp (wobei 5995 ein Beispiel für den benutzerdefinierten SSH-Port ist).

Aufgabe 10: Schutz vor Brute-Force-Angriffen auf SSH

Die zehnte Aufgabe schützt den SSH-Zugang vor Brute-Force-Angriffen:

initial.yml
- name: Brute-force attempt protection for SSH
  community.general.ufw:
    rule: limit
    port: "{{ ssh_port }}"
    proto: tcp

Diese Aufgabe verwendet das community.general.ufw-Modul mit einer Rate-Limit-Regel, die den Zugriff auf IP-Adressen verweigert, die sechsmal oder öfter innerhalb von 30 Sekunden eine Verbindung zum SSH-Port nicht erfolgreich herstellen konnten. Der Parameter proto gibt das verwendete Protokoll an, in diesem Fall TCP.

Aufgabe 11: UFW – Anderen eingehenden Datenverkehr ablehnen und aktivieren

Die elfte Aufgabe im Playbook aktiviert die Firewall und lehnt anderen eingehenden Datenverkehr ab:

initial.yml
- name: UFW - Deny other incoming traffic and enable UFW
  community.general.ufw:
    state: enabled
    policy: deny
    direction: incoming

Diese Aufgabe verwendet das community.general.ufw-Modul, um die Firewall zu aktivieren (state: enabled) und eine Standardrichtlinie festzulegen, die jeglichen eingehenden Datenverkehr ablehnt (policy: deny), es sei denn, er wurde explizit erlaubt (wie in Aufgabe 9 für SSH-Datenverkehr).

Aufgabe 12: Entfernen nicht mehr benötigter Abhängigkeiten

Die zwölfte Aufgabe im Playbook bereinigt die Paketabhängigkeiten:

initial.yml
- name: Remove dependencies that are no longer required
  ansible.builtin.apt:
    autoremove: yes

Diese Aufgabe entfernt nicht mehr benötigte Paketabhängigkeiten von den Servern, indem das ansible.builtin.apt-Modul verwendet wird. Es entspricht dem manuellen Ausführen des Befehls sudo apt autoremove.

Aufgabe 13: Neustarten des SSH-Dienstes

Die dreizehnte Aufgabe startet den SSH-Dienst neu:

initial.yml
- name: Restart the SSH daemon
  ansible.builtin.systemd:
    state: restarted
    name: ssh

Diese Aufgabe verwendet das ansible.builtin.systemd-Modul, um den SSH-Dienst neu zu starten. Durch den Neustart des SSH-Dienstes werden die zuvor vorgenommenen Konfigurationsänderungen, wie das Ändern des SSH-Ports und das Deaktivieren des Remote-Logins für root, wirksam.

Play 2: Neustarten der Hosts nach der Initialkonfiguration

Dieses Play beginnt, nachdem alle Aufgaben in Play 1 erfolgreich abgeschlossen wurden. Die Konfiguration des Plays ist durch die folgenden Schlüsselwörter definiert:

initial.yml
- name: Rebooting hosts after initial setup
  hosts: initial
  port: "{{ ssh_port }}"
  remote_user: "{{ create_user }}"
  become: true
  vars_files:
    - vars/default.yml
    - secret
  vars:
    ansible_become_pass: "{{ password }}"

Der Schlüssel hosts gibt die Gruppe von Hosts an, die von diesem Play angesprochen werden, in diesem Fall die Gruppe initial aus der in Schritt 2 erstellten Inventardatei. Der Schlüssel port zeigt auf den benutzerdefinierten SSH-Port, der in Schritt 4 konfiguriert wurde, da der Standardport 22 nicht mehr zugänglich ist.

Im ersten Play hat sich der Ansible Controller als Benutzer root angemeldet. Da der Remote-Login für root jetzt deaktiviert ist, gibt der Schlüssel remote_user den sudo-Benutzer an, der in Aufgabe 5 von Play 1 erstellt wurde. Der Schlüssel become ermöglicht die Privilegien-Eskalation, sodass der Ansible Controller Aufgaben ausführen kann, die Root-Rechte erfordern, indem er den sudo-Mechanismus verwendet.

Aufgabe 14: Alle Hosts neu starten

Diese Aufgabe startet alle Hosts, die in der Gruppe initial konfiguriert sind, neu:

initial.yml
- name: Reboot all hosts
  ansible.builtin.reboot:

Durch den Neustart ist sichergestellt, dass alle Updates für den Kernel oder die Systembibliotheken wirksam sind, vor Installation zusätzlicher Konfigurationen oder Anwendungen. Diese Aufgabe ruft das Modul ansible.builtin.reboot auf, um alle Hosts neu zu starten, die im Play definiert sind.

Komplette Playbook-Datei

Das vollständige Playbook für die Initialkonfiguration des Servers, einschließlich beider Plays, sieht wie folgt aus:

initial.yml
- name: Initial server setup tasks
  hosts: initial
  remote_user: root
  vars_files:
    - vars/default.yml
    - secret

  tasks:
    - name: update cache
      ansible.builtin.apt:
        update_cache: yes

    - name: Update all installed packages
      ansible.builtin.apt:
        name: "*"
        state: latest

    - name: Make sure NTP service is running
      ansible.builtin.systemd:
        state: started
        name: systemd-timesyncd

    - name: Make sure we have a 'sudo' group
      ansible.builtin.group:
        name: sudo
        state: present

    - name: Create a user with sudo privileges
      ansible.builtin.user:
        name: "{{ create_user }}"
        state: present
        groups: sudo
        append: true
        create_home: true
        shell: /bin/bash
        password: "{{ password | password_hash('sha512', password_salt) }}"
        update_password: on_create

    - name: Set authorized key for remote user
      ansible.builtin.authorized_key:
        user: "{{ create_user }}"
        state: present
        key: "{{ copy_local_key }}"

    - name: Disable remote login for root
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        state: present
        regexp: '^PermitRootLogin yes'
        line: 'PermitRootLogin no'

    - name: Change the SSH port
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        state: present
        regexp: '^#Port 22'
        line: 'Port "{{ ssh_port }}"'

    - name: UFW - Allow SSH connections
      community.general.ufw:
        rule: allow
        port: "{{ ssh_port }}"

    - name: Brute-force attempt protection for SSH
      community.general.ufw:
        rule: limit
        port: "{{ ssh_port }}"
        proto: tcp

    - name: UFW - Deny other incoming traffic and enable UFW
      community.general.ufw:
        state: enabled
        policy: deny
        direction: incoming

    - name: Remove dependencies that are no longer required
      ansible.builtin.apt:
        autoremove: yes

    - name: Restart the SSH daemon
      ansible.builtin.systemd:
        state: restarted
        name: ssh

- name: Rebooting hosts after initial setup
  hosts: initial
  port: "{{ ssh_port }}"
  remote_user: "{{ create_user }}"
  become: true
  vars_files:
    - vars/default.yml
    - secret
  vars:
    ansible_become_pass: "{{ password }}"

  tasks:
    - name: Reboot all hosts
      ansible.builtin.reboot:

Playbook ausführen

Nun können Sie das Playbook ausführen. Überprüfen Sie zuerst die Syntax der Playbook-Datei mit folgendem Befehl:

ansible-playbook --syntax-check --ask-vault-pass initial.yml

Das in Schritt 5 erstellte Vault-Passwort müssen Sie nun eingeben. Wenn keine YAML-Syntaxfehler vorliegen, erhalten Sie folgende Ausgabe:

Output
playbook: initial.yml

Nach erfolgreicher Syntaxprüfung können Sie das Playbook mit folgendem Befehl ausführen:

ansible-playbook --ask-vault-pass initial.yml

Eine erneute Abfrage des Vault-Passwort folgt. Nach erfolgreicher Authentifizierung loggt sich der Ansible-Controller auf jedem Host als root-Benutzer ein und führt alle im Playbook definierten Aufgaben aus. Anstatt den Befehl ssh root@node-ip-address manuell für jeden Server auszuführen, verbindet sich Ansible mit allen Knoten, die in der Datei /etc/ansible/hosts definiert sind, und führt die Aufgaben automatisch aus.

Beispielausgabe

Für die Beispiel-Hosts in diesem Tutorial benötigte Ansible etwa drei Minuten, um die Aufgaben auf drei Hosts abzuschließen. Nach Abschluss erhalten Sie eine Ausgabe wie diese:

Output
PLAY RECAP *****************************************************************************************************
host1   : ok=16   changed=11    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
host2   : ok=16   changed=11    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
host3   : ok=16   changed=11    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Jeder erfolgreich ausgeführte Abschnitt der Aufgaben und Play-Keywords wird in der Spalte ok gezählt. In diesem Fall gibt es 14 erfolgreich ausgewertete Aufgaben in zwei Plays was zu einer Zählung von 16 führt. Die Spalte changed zeigt Aufgaben an, die Änderungen an den Hosts vorgenommen haben, wobei 11 Aufgaben Änderungen führten.

Die Spalte unreachable zeigt die Anzahl der Hosts, zu denen der Ansible-Controller keine Verbindung herstellen konnte. In diesem Fall ist der Wert 0. Ebenso ist die Spalte failed 0, da keine Aufgaben fehlgeschlagen sind.

Eine Aufgabe wird als skipped markiert, wenn ihre Bedingungen (normalerweise mit dem Parameter when definiert) nicht erfüllt sind. Das Playbook überspringt keine Aufgaben. Die letzten beiden Spalten, rescued und ignored, beziehen sich auf Fehlerbehandlungsmechanismen und wurden in diesem Durchlauf nicht ausgelöst.

Überprüfung

Sie haben jetzt erfolgreich die Initialkonfiguration mehrerer Ubuntu 22.04-Server mit Ansible automatisiert. Um sicherzustellen, dass die Einrichtung erfolgreich war, loggen Sie sich in einen der Hosts ein und prüfen Sie manuell, ob alle erwarteten Konfigurationen und Updates vorhanden sind. Die Erläuterung erfolgt im nächsten Abschnitt.

Schritt 7 — Manuelle Überprüfung der Serverkonfiguration (Optional)

Um die Ausgabe des Play-Rekaps am Ende des vorherigen Schritts zu bestätigen, können Sie sich in einen der Hosts einloggen, um die Einrichtung manuell zu überprüfen. Diese Aktionen sind optional und dienen zu Lernzwecken, da der Ansible-Rekapitulationsbericht eine genaue Zusammenfassung bietet.

Starten Sie, indem Sie sich mit folgendem Befehl in einen der Hosts einloggen:

ssh -p 5995 sammy@host1-public-ip-address

Hierbei gibt die Option -p den benutzerdefinierten SSH-Port an, der in Aufgabe 8 konfiguriert wurde (z. B. 5995), und sammy ist der Benutzer, der in Aufgabe 5 erstellt wurde. Wenn Sie sich als dieser Benutzer über den benutzerdefinierten Port erfolgreich einloggen können, wissen Sie, dass Ansible diese Aufgaben erfolgreich abgeschlossen hat.

Sobald Sie eingeloggt sind, prüfen Sie, ob Sie die Paketdatenbank aktualisieren können:

sudo apt update

Bei einer Passwortabfrage mit der in Aufgabe 5 Sie das konfigurierte Passwort authentifizieren können, bestätigt dies, dass Ansible den Benutzer erfolgreich erstellt und dessen Passwort gesetzt hat.

Schritt 8 — Verwendung von Ansible für die laufende Wartung der Hosts (Optional)

Während das in Schritt 6 ausgeführte Playbook für die Initialkonfiguration der Server ausgelegt ist, ist es nicht für die laufende Verwaltung der Hosts vorgesehen. Für die fortlaufende Wartung können Sie das Playbook ongoing.yml ausführen, das im Repository aus Schritt 3 enthalten ist. Dieser Abschnitt erklärt, wie Sie dieses Playbook für die regelmäßige Serverwartung verwenden.

Bevor Sie das Playbook ausführen, öffnen Sie es mit nano oder Ihrem bevorzugten Texteditor, um dessen Inhalt zu überprüfen:

nano ongoing.yml

Play 1: Laufende Wartung

Das Playbook enthält ein einzelnes Play mit Aufgaben, die für die Serverwartung ausgelegt sind. Die folgenden Keywords definieren das Verhalten des Plays:

ongoing.yml
- hosts: ongoing
  port: "{{ ssh_port }}"
  remote_user: "{{ create_user }}"
  become: true
  vars_files:
    - vars/default.yml
    - secret
  vars:
    ansible_become_pass: "{{ password }}"

Abgesehen von der Gruppe, die an das hosts-Keyword übergeben wird, sind dies dieselben Keywords, die im zweiten Play des Setup-Playbooks verwendet wurden.

Nach den Keywords folgt eine Liste von Aufgaben, die nacheinander ausgeführt werden. Wie im Setup-Playbook beginnt jede Aufgabe im Wartungs-Playbook mit einem Namen, der eine kurze Beschreibung dessen liefert, was die Aufgabe erreichen soll.

Aufgabe 1: Cache aktualisieren

Die erste Aufgabe aktualisiert die Paketdatenbank:

ongoing.yml
- name: update cache
  ansible.builtin.apt:
    update_cache: yes

Diese Aufgabe aktualisiert die Paketdatenbank mithilfe des Moduls ansible.builtin.apt, weshalb sie mit update_cache: yes definiert ist. Diese Aufgabe erfüllt denselben Zweck wie der Befehl sudo apt update, der häufig der Installation eines Pakets oder der Aktualisierung aller installierten Pakete vorausgeht.

Aufgabe 2: Alle installierten Pakete aktualisieren

Die zweite Aufgabe aktualisiert die installierten Pakete:

ongoing.yml
- name: Update all installed packages
  ansible.builtin.apt:
    name: "*"
    state: latest

Wie die erste Aufgabe verwendet auch diese Aufgabe das Modul ansible.builtin.apt. Hier stellen Sie sicher, dass alle installierten Pakete auf dem neuesten Stand sind, indem Sie einen Platzhalter verwenden, um die Pakete anzugeben (name: "*") und state: latest, was dem manuellen Ausführen des Befehls sudo apt upgrade -y auf den Servern entspricht.

Aufgabe 3: Sicherstellen, dass der NTP-Dienst läuft

Die dritte Aufgabe stellt sicher, dass der NTP-Daemon aktiv ist:

ongoing.yml
- name: Make sure NTP service is running
  ansible.builtin.systemd:
    state: started
    name: systemd-timesyncd

Aktive Dienste auf einem Server können aus verschiedenen Gründen fehlschlagen. Daher möchten Sie sicherstellen, dass solche Dienste weiterhin aktiv bleiben. Diese Aufgabe ruft das Modul ansible.builtin.systemd auf, um sicherzustellen, dass systemd-timesyncd, der NTP-Daemon, aktiv bleibt (state: started).

Aufgabe 4: UFW – Läuft die Firewall?

Die vierte Aufgabe überprüft den Status der UFW-Firewall:

ongoing.yml
- name: UFW - Is it running?
  ansible.builtin.command: ufw status
    register: ufw_status

Sie können den Status der UFW-Firewall auf Ubuntu mit dem Befehl sudo ufw status überprüfen. Die erste Zeile der Ausgabe lautet entweder Status: active oder Status: inactive. Diese Aufgabe verwendet das Modul ansible.builtin.command, um denselben Befehl auszuführen, und speichert (register) die Ausgabe in der Variable ufw_status. In der nächsten Aufgabe kommt es zur Abfrage des Variablenwerts.

Aufgabe 5: UFW – Aktivieren und eingehenden Verkehr blockieren

Die fünfte Aufgabe aktiviert die UFW-Firewall, falls es zu einem Stop kam:

ongoing.yml
- name: UFW - Enable UFW and deny incoming traffic
  community.general.ufw:
    state: enabled
  when: "'inactive' in ufw_status.stdout"

Diese Aufgabe ruft das Modul community.general.ufw auf, um die Firewall nur dann zu aktivieren, wenn der Begriff inactive in der Ausgabe der Variablen ufw_status erscheint. Wenn die Firewall aktiv ist, wird die Bedingung when nicht erfüllt, und die Aufgabe wird als übersprungen markiert.

Aufgabe 6: Entfernen von nicht mehr benötigten Abhängigkeiten

Die sechste Aufgabe in diesem Playbook bereinigt Paketabhängigkeiten:

ongoing.yml
- name: Remove dependencies that are no longer required
  ansible.builtin.apt:
    autoremove: yes

Diese Aufgabe entfernt Paketabhängigkeiten, die auf dem Server nicht mehr benötigt werden, indem das Modul ansible.builtin.apt aufgerufen wird. Dies entspricht dem manuellen Ausführen des Befehls sudo apt autoremove.

Aufgabe 7: Überprüfen, ob ein Neustart erforderlich ist

Die siebte Aufgabe prüft, ob ein Neustart erforderlich ist:

ongoing.yml
- name: Check if reboot required
  ansible.builtin.stat:
    path: /var/run/reboot-required
  register: reboot_required

Auf Ubuntu signalisiert ein neu installiertes oder aktualisiertes Paket, dass ein Neustart erforderlich ist, indem die Datei /var/run/reboot-required erstellt wird. Diese Aufgabe ruft das Modul ansible.builtin.stat auf, um das Vorhandensein dieser Datei zu überprüfen, und speichert (register) die Ausgabe in der Variablen reboot_required.

Aufgabe 8: Neustart, falls erforderlich

Die achte Aufgabe startet den Server bei Bedarf neu:

ongoing.yml
- name: Reboot if required
  ansible.builtin.reboot:
  when: reboot_required.stat.exists == true

Durch Abfragen der Variablen reboot_required aus Aufgabe 7 ruft diese Aufgabe das Modul ansible.builtin.reboot auf, um die Hosts nur dann neu zu starten, wenn die Datei /var/run/reboot-required vorhanden ist. Wenn ein Neustart erforderlich ist, ist die Aufgabe als geändert markiert; andernfalls ist sie als übersprungen markiert.

Vollständiges Playbook für die laufende Wartung

Das vollständige Playbook für die laufende Wartung sieht wie folgt aus:

ongoing.yml
- hosts: ongoing
  port: "{{ ssh_port }}"
  remote_user: "{{ create_user }}"
  become: true
  vars_files:
    - vars/default.yml
    - secret
  vars:
    ansible_become_pass: "{{ password }}"

  tasks:
    - name: update cache
      ansible.builtin.apt:
        update_cache: yes

    - name: Update all installed packages
      ansible.builtin.apt:
        name: "*"
        state: latest

    - name: Make sure NTP service is running
      ansible.builtin.systemd:
        state: started
        name: systemd-timesyncd

    - name: UFW - Is it running?
      ansible.builtin.command: ufw status
      register: ufw_status
      
    - name: UFW - Enable UFW and deny incoming traffic
      community.general.ufw:
        state: enabled
      when: "'inactive' in ufw_status.stdout"

    - name: Remove dependencies that are no longer required
      ansible.builtin.apt:
        autoremove: yes

    - name: Check if reboot required
      ansible.builtin.stat:
        path: /var/run/reboot-required
      register: reboot_required

    - name: Reboot if required
      ansible.builtin.reboot:
      when: reboot_required.stat.exists == true

Nach Überprüfung des Wartungs-Playbooks können Sie es nun ausführen. Beginnen Sie mit der Syntaxprüfung der Playbook-Datei mit folgendem Befehl:

ansible-playbook --syntax-check --ask-vault-pass ongoing.yml

Bei Aufforderung geben Sie das Vault-Passwort ein, das Sie in Schritt 5 erstellt haben. Falls keine Fehler in der YAML-Syntax vorliegen, wird die Ausgabe wie folgt aussehen:

Output
playbook: ongoing.yml

Sobald die Syntaxprüfung erfolgreich war, können Sie das Playbook mit folgendem Befehl ausführen:

ansible-playbook --ask-vault-pass ongoing.yml

EIne erneute Vault-Passwort Abfrage folgt. Nach erfolgreicher Authentifizierung meldet sich der Ansible-Controller bei jedem Host mit dem im Playbook angegebenen Benutzer an (z. B. sammy) und führt die Aufgaben aus. Anstatt den Befehl ssh -p 5995 sammy@host_ip_address manuell auf jedem Server auszuführen, verbindet sich Ansible mit den im Inventory-File angegebenen Knoten der Gruppe ongoing und führt die Aufgaben automatisch aus.

Beispielausgabe

Wenn das Playbook erfolgreich abgeschlossen wird, sieht die Ausgabe in etwa wie folgt aus:

Output
PLAY RECAP *****************************************************************************************************
host1   : ok=7   changed=2    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0   
host2   : ok=7   changed=2    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0   
host3   : ok=7   changed=2    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0

Die Play-Rekapitulation zeigt die Ergebnisse des Playbook-Laufs:

• Die Spalte ok gibt die Gesamtzahl der erfolgreich bewerteten Aufgaben an. In diesem Fall sind es Bewertungen von 7 Aufgaben für jeden Host.
• Die Spalte changed zeigt Aufgaben, die Änderungen an den Hosts vorgenommen haben. Hier führten 2 Aufgaben zu Änderungen.
• Die Spalte unreachable zeigt die Anzahl der Hosts, zu denen der Controller keine Verbindung herstellen konnte. Dieser Wert beträgt 0, was auf keine Verbindungsprobleme hinweist.
• Die Spalte failed zeigt fehlgeschlagene Aufgaben an. Dieser Wert beträgt ebenfalls 0.
• Die Spalte skipped zeigt Aufgaben, die übersprungen wurden, weil ihre Bedingungen (mit dem Parameter when festgelegt) nicht erfüllt waren. In diesem Fall sind es 2 übersprungene Aufgaben.
• Die Spalten rescued und ignored beziehen sich auf Fehlerbehandlungen und wurden in diesem Playbook-Lauf nicht ausgelöst.

Schlussfolgerung

In diesem Tutorial haben Sie Ansible verwendet, um die initiale Einrichtung und laufende Wartung mehrerer Ubuntu 22.04-Server zu automatisieren. Das Playbook für die initiale Serverkonfiguration ermöglichte es Ihnen, grundlegende Sicherheitseinstellungen zu konfigurieren, Benutzer zu erstellen und Softwarepakete mit einem einzigen Befehl zu aktualisieren. Dadurch sparen Sie Zeit und reduzieren manuelle Arbeitsaufwände. Das Wartungs-Playbook erlaubte es Ihnen, regelmäßige Updates durchzuführen, sicherzustellen, dass kritische Dienste laufen, und Serververwaltungsaufgaben zu optimieren.

Die Fähigkeit von Ansible, Automatisierungen über mehrere Server zu skalieren, macht es zu einem unverzichtbaren Werkzeug für die Verwaltung verteilter Anwendungen, Cluster oder jeder Umgebung, die häufige Konfigurationsupdates erfordert. Durch die Verwendung von Variablen, verschlüsselten Vaults und modularen Playbooks können Sie sicherstellen, dass sensible Informationen geschützt sind und Konfigurationen in Ihrer Infrastruktur konsistent bleiben.

Weitere Informationen zur Erweiterung Ihrer Automatisierungs-Workflows finden Sie in der offiziellen Ansible-Dokumentation und den Community-Ressourcen. Egal, ob Sie Anwendungen bereitstellen, Konfigurationen verwalten oder Sicherheitsrichtlinien durchsetzen – Ansible bietet eine robuste und flexible Plattform, um Ihre Anforderungen zu erfüllen.

Wenn Sie zusätzliche Schritte oder Aufgaben automatisieren möchten, können Sie Ihre Playbooks erweitern oder neue erstellen, um spezifische Anforderungen zu erfüllen. Automatisierung verbessert nicht nur die Effizienz, sondern reduziert auch Fehler und bildet so einen Grundpfeiler der modernen Systemadministration.