1 Grundlagen von Ansible
1.1 Was ist Ansible?
Ansible ist ein modernes und quelloffenes IT-Automatisierungs-, Orchestrierungs- und Provisionierungstool, das Ihnen die Arbeit erleichtert. Es verwaltet Server dienstfrei. Sie müssen nur eine Liste aller Anweisungen definieren, an denen Sie interessiert sind, und Ansible wird sie für Sie erledigen. Ansible ist immer bereit, Ihre Server zu verwalten, egal ob es darum geht, ein Paket zu installieren, eine Konfiguration zu aktualisieren oder sogar einen Dienst neu zu starten. Ansible verwendet Playbook-Dateien, um Automatisierungsaufgaben zu beschreiben, und Playbooks werden in einer sehr einfachen Sprache namens YAML geschrieben. YAML ist eine für Menschen lesbare Sprache zur Serialisierung von Daten und wird üblicherweise für Konfigurationsdateien verwendet, kann aber in vielen Anwendungen eingesetzt werden, in denen Daten gespeichert werden. Sie ist für den Menschen sehr einfach zu verstehen, zu lesen und zu schreiben. Dies hat den Vorteil, dass auch Nicht-IT-Supportmitarbeiter das Playbook lesen und verstehen und bei Bedarf Fehler beheben können.
Nachdem eine Verbindung zu Ihren Servern hergestellt wurde, schiebt Ansible kleine Programme namens "Ansible-Module" nach. Ansible führt diese Module auf Ihren Servern aus und entfernt sie, wenn sie fertig sind. Informationen zu allen Servern, wie z. B. IP, SSH-Anmeldeinformationen usw., werden im Inventar gespeichert. Dabei handelt es sich um eine oder mehrere Textdateien. Der Inhalt kann im Ini- oder YAML-Format geschrieben werden. Ansible verwendet die Host-Datei, in der Sie die Hosts gruppieren und die Aktionen einer bestimmten Gruppe in den Playbooks steuern können.
1.2 Warum brauchen wir Ansible?
Die Verwaltung eines Servers ist einfach. Die Verwaltung von 10 ist möglich. Die Verwaltung von Hunderten oder mehr ist ohne Automatisierung eine mühsame Aufgabe. Ansible ist so konzipiert, dass es einfach und effektiv ist. Sie können identische, replizierbare Server und Servercluster erstellen. Ansible ist für die Bereitstellung auf mehreren Ebenen ausgelegt. Ansible verwaltet nicht ein System nach dem anderen, sondern modelliert die IT-Infrastruktur, indem es beschreibt, dass alle Ihre Systeme miteinander verbunden sind, und wird auf mehreren Hosts gleichzeitig ausgeführt. Ansible ist völlig agentenlos, was bedeutet, dass es durch die Verbindung Ihrer Server über ssh (standardmäßig) funktionieren könnte. Es gibt aber auch andere Methoden für die Verbindung wie Kerberos
1.3 Was sind die Vorteile von Ansible?
Ansible verwaltet Maschinen agentenlos. Auf der Client-Seite muss nichts installiert sein. Es werden jedoch sowohl Push- als auch Pull-Modi unterstützt. Ansible ist ein sicherheitsorientiertes Werkzeug. Es verwendet OpenSSH als Transportprotokoll. Die Ansible-Playbooks sind in YAML geschrieben und leicht zu lesen. Bei Bedarf kann Ansible problemlos mit Kerberos, LDAP und anderen zentralisierten Authentifizierungsmanagementsystemen verbunden werden.
1.4 Wie installiert man Ansible?
Paketmanager wie dnf, yum, zypper oder apt können verwendet werden.
- Auf Fedora-Rechnern:
dnf install ansible
- Auf CentOS-Maschinen
yum install epel-release
yum install ansible
- Auf openSuse-Maschinen
zypper install ansible
2 Inventarisierung
Die Bestandsaufnahme definiert die Gruppen von Hosts, die sich in irgendeiner Weise ähneln. Wenn wir zum Beispiel unsere Webserver in einer Gruppe und Backend-Server in einer anderen gruppieren wollen. Eine Gruppe kann mehrere Server enthalten und ein Server kann Teil mehrerer Gruppen sein. Der Name der Gruppe wird in eckige Klammern "[]" eingeschlossen. Die Servernamen können ihre DNS-Namen oder IP-Adressen sein.
Beispiel 2.0.1:
[localhost]
localhost
[Backend]
192.168.1.10
192.168.1.11
Standardmäßig sucht Ansible nach der Inventarisierungsdatei unter /etc/ansible/hosts, aber das kann geändert werden, indem ein "-i" {{path_to_inventory}} an die Ansible-Befehlszeile übergeben wird. Wir können die Art und Weise, wie Ansible sich mit unseren Hosts verbindet, ändern, indem wir zusätzliche Informationen in der Inventardatei angeben.
Beispiel 2.0.2:
[localhost]
LC1 ansible_ssh_host=localhost ansible_ssh_host=8022
[Backend]
BK1 ansible_ssh_host=192.168.1.10
BK2 ansible_ssh_host=192.168.1.11
[loadbalancers]
LB1 ansible_ssh_host=192.168.1.2
LB2 ansible_ssh_host=192.168.1.3
2.1 Hinzufügen von Bereichen von Hosts
Wir können ein paar Einträge überspringen, indem wir einen Bereich hinzufügen. Hier fügen wir 5 Hosts mit nur einem Eintrag hinzu.
Beispiel 2.1.1
[Backend]
192.168.1.[06:10]
2.2 Hinzufügen von Variablen zum Bestand
Grundsätzlich stellt eine Variable einen Wert dar. Eine Variable kann Buchstaben, Ziffern und Unterstriche enthalten und beginnt immer mit einem Buchstaben. Variablen werden verwendet, wenn Anweisungen von einem Server zum anderen variieren.
Es gibt eine Reihe von Variablenarten:
- Spielbuch-Variablen. Werden im aktuellen Spielbuch definiert. Sie können global oder lokal sein, je nachdem, wo sie definiert sind. Globale Variablen sind für das gesamte Spielbuch definiert und können von jeder Aufgabe aus aufgerufen werden. Lokale Variablen sind nur für den Bereich der aktuell laufenden Aufgabe verfügbar.
- Inventarisierungsvariablen. Nur in der Inventardatei definiert.
Beispiel 2.2.1
[Backend]
192.168.1.10:8022 http_port=80 maxConnections=200
192.168.1.10:8022 http_port=443 maxConnections=400
- Spezielle Variablen. Dies sind spezielle Variablen, die von Ansible verwendet werden und nicht direkt vom Benutzer gesetzt werden können. Sie werden immer überschrieben, um den internen Zustand widerzuspiegeln.
- Fakten. Dies sind Variablen, die Informationen über den aktuellen Host (inventory_hostname) enthalten. Sie sind nur verfügbar, wenn sie zuerst erfasst werden.
- Verbindungsvariablen. Verbindungsvariablen werden normalerweise verwendet, um festzulegen, wie die Aktionen auf einem Ziel ausgeführt werden sollen. Die meisten von ihnen entsprechen den Verbindungs-Plugins, aber nicht alle sind spezifisch für diese. Andere Plugins wie Shell, Terminal und become sind normalerweise beteiligt.
- Gruppenvariablen. Definiert für eine bestimmte Inventarisierungsgruppe. Der Zugriff ist nur für Hosts möglich, die Teil dieser Gruppen sind.
2.3 Alias
Wir können auch Aliasnamen in Ihrem Bestand definieren:
Beispiel 2.3.1:
[localhost]
LC1 ansible_ssh_host=localhost
[Backend]
BK1 ansible_ssh_host=192.168.1.10
BK2 ansible_ssh_host=192.168.1.11
[loadbalancers]
LB1 ansible_ssh_host=192.168.1.2
LB2 ansible_ssh_host=192.168.1.3
Im obigen Beispiel stellt Ansible mit dem Host-Alias "BK2" eine Verbindung zu 192.168.1.11 an Port 22 her.
2.4 Eine Variable mehreren Maschinen zuordnen: Gruppenvariablen
Gruppenvariablen sind eine praktische Möglichkeit, Variablen auf mehrere Hosts gleichzeitig anzuwenden. Vor der Ausführung reduziert Ansible jedoch Variablen, einschließlich Inventarvariablen, immer auf die Host-Ebene. Wenn ein Host Mitglied mehrerer Gruppen ist, liest Ansible die Variablenwerte aus allen diesen Gruppen. Wenn Sie derselben Variable in verschiedenen Gruppen unterschiedliche Werte zuweisen, wählt Ansible den zu verwendenden Wert auf der Grundlage interner Regeln für die Zusammenführung aus.
Beispiel 2.4.1:
[localhost]
LC1 ansible_ssh_host=localhost
[Backend]
BK1 ansible_ssh_host=192.168.1.10
BK2 ansible_ssh_host=192.168.1.11
[loadbalancers]
LB1 ansible_ssh_host=192.168.1.2
LB2 ansible_ssh_host=192.168.1.3
[Backend:vars]
services_folder=/opt/apps
logs_folder=/var/log
2.5 Vererbung von Variablenwerten: Gruppenvariablen für Gruppen von Gruppen
Mit dem Suffix :children in der INI oder dem Eintrag children: in Dateien im YAML-Format können Gruppen von Gruppen gebildet werden. Mit :vars oder vars können wir Variablen auf diese Gruppen von Gruppen anwenden:
Beispiel 2.4.1:
[localhost]
LC1 ansible_ssh_host=localhost
[Backend]
BK1 ansible_ssh_host=192.168.1.10
BK2 ansible_ssh_host=192.168.1.11
[loadbalancers]
LB1 ansible_ssh_host=192.168.1.2
LB2 ansible_ssh_host=192.168.1.3
[nfs:children]
Backend
[nfs:vars]
src=/usr/local/fileshare
dest=fileshare
user=test
Für Kindergruppen gibt es eine Reihe von Eigenschaften zu beachten:
- Jeder Host, der Mitglied einer untergeordneten Gruppe ist, ist automatisch auch Mitglied der übergeordneten Gruppe.
- Die Variablen einer untergeordneten Gruppe haben Vorrang vor den Variablen einer übergeordneten Gruppe.
- Gruppen können mehrere Eltern und Kinder haben, aber keine zirkulären Beziehungen.
- Hosts können auch in mehreren Gruppen sein, aber es gibt nur eine Instanz eines Hosts, der die Daten aus den mehreren Gruppen zusammenführt.
2.6 Verwendung mehrerer Bestandsquellen
Wir können mehrere Inventarisierungsquellen (Verzeichnisse, dynamische Inventarisierungsskripte oder Dateien, die von Inventarisierungsplugins unterstützt werden) gleichzeitig ansteuern, indem wir mehrere Inventarisierungsparameter über die Befehlszeile eingeben oder Ansible Inventory-Dateien konfigurieren. Dies kann nützlich sein, wenn wir normalerweise getrennte Umgebungen, wie QA und Produktion, gleichzeitig für eine bestimmte Aktion anvisieren wollen.
Wir können zwei Quellen über die Befehlszeile ansteuern:
Beispiel 2.4.1:
ansible-playbook test.yml -i backend -i localhost
Beachten Sie, dass bei variablen Konflikten in den Beständen diese nach den Regeln aufgelöst werden. Die sich ergebende Reihenfolge wird durch die Reihenfolge der Parameter der Inventarquelle bestimmt. Wenn [all:vars] im Staging-Inventar myvar = 1 definiert, das Produktionsinventar jedoch myvar = 2 definiert, wird das Spielbuch mit myvar = 2 ausgeführt. Das Ergebnis würde sich umkehren, wenn das Spielbuch mit -i production -i qa ausgeführt würde.
[localhost]
LC1 ansible_ssh_host=localhost
[Backend]
BK1 ansible_ssh_host=192.168.1.10
BK2 ansible_ssh_host=192.168.1.11
[all:vars]
myvar=1
[Backend:vars]
myvar=2
2.7 Verbindung zu Hosts: Parameter des Verhaltensinventars
Wie oben beschrieben, steuern die folgenden Variablen, wie Ansible mit entfernten Hosts interagiert.
Host-Verbindung:
Ansible stellt keinen Kanal zur Verfügung, der die Kommunikation zwischen dem Benutzer und dem ssh-Prozess ermöglicht, um ein Passwort manuell zu akzeptieren und einen ssh-Schlüssel zu entschlüsseln, wenn das ssh-Verbindungs-Plugin verwendet wird. Die Verwendung von ssh-agent wird dringend empfohlen. Wir müssen also Passwörter und Passphrasen vor der Ausführung von Ansible bereitstellen.
- ansible_connection: Verbindungstyp zum Host. Dies kann der Name eines beliebigen Verbindungs-Plugins von ansible sein. SSH-Protokolltypen sind:
- smart
- ssh
- paramiko
Der Standard ist intelligent. Es gibt auch eine Möglichkeit für nicht-SSH-basierte Typen.
Allgemein für alle Verbindungen:
- ansible_host: Der Name des Hosts, mit dem eine Verbindung hergestellt werden soll, sofern er sich von dem Alias unterscheidet, den Sie ihm geben möchten.
- ansible_password: Das Passwort, das für die Authentifizierung beim Host verwendet werden soll (speichern Sie diese Variable niemals im Klartext; verwenden Sie immer einen Tresor. Siehe Variablen und Tresore)
- ansible_port: Die Nummer des Verbindungsports, wenn nicht der Standard (22 für ssh)
- ansible_user: Der Benutzername, der bei der Verbindung mit dem Host verwendet werden soll
Speziell für die SSH-Verbindung:
- ansible_ssh_private_key_file: Private Schlüsseldatei, die von ssh verwendet wird. Nützlich, wenn Sie mehrere Schlüssel verwenden und den SSH-Agenten nicht einsetzen wollen.
- ansible_ssh_common_args: Diese Einstellung wird immer an die Standardbefehlszeile für sftp, scp und ssh angehängt. Nützlich, um einen ProxyCommand für einen bestimmten Host (oder eine Gruppe) zu konfigurieren.
- ansible_sftp_extra_args: Diese Einstellung wird immer an die Standard-Sftp-Befehlszeile angehängt.
- ansible_scp_extra_args: Diese Einstellung wird immer an die Standard-SCP-Befehlszeile angehängt.
- ansible_ssh_extra_args: Diese Einstellung wird immer an die standardmäßige ssh-Befehlszeile angehängt.
- ansible_ssh_pipelining: Legt fest, ob SSH-Pipelining verwendet werden soll oder nicht. Dies kann die Pipelining-Einstellung in ansible.cfg außer Kraft setzen.
- ansible_ssh_executable (hinzugefügt in Version 2.2): Diese Einstellung setzt das Standardverhalten außer Kraft, um das System ssh zu verwenden. Damit kann die Einstellung ssh_executable in ansible.cfg außer Kraft gesetzt werden.
Privilegieneskalation (siehe Ansible Privilegieneskalation für weitere Details):
- ansible_become: Äquivalent zu ansible_sudo oder ansible_su, ermöglicht es, eine Privilegienerweiterung zu erzwingen
- ansible_become_method: Ermöglicht das Festlegen einer Methode zur Privilegienerweiterung
- ansible_become_user: Äquivalent zu ansible_sudo_user oder ansible_su_user, ermöglicht es, den Benutzer festzulegen, zu dem man durch Privilegieneskalation wird
- ansible_become_password: Äquivalent zu ansible_sudo_password oder ansible_su_password, ermöglicht es Ihnen, das Passwort für die Privilegienerweiterung festzulegen (speichern Sie diese Variable niemals im Klartext; verwenden Sie immer einen Tresor. Siehe Variablen und Tresore)
- ansible_become_exe: Äquivalent zu ansible_sudo_exe oder ansible_su_exe, ermöglicht es Ihnen, die ausführbare Datei für die gewählte Eskalationsmethode festzulegen
- ansible_become_flags: Äquivalent zu ansible_sudo_flags oder ansible_su_flags, ermöglicht es Ihnen, die Flags zu setzen, die an die ausgewählte Eskalationsmethode übergeben werden. Dies kann auch global in ansible.cfg in der Option sudo_flags gesetzt werden
Parameter der Remote-Host-Umgebung:
- - ansible_shell_type: Der Shell-Typ des Zielsystems. Sie sollten diese Einstellung nur verwenden, wenn Sie ansible_shell_executable auf eine nicht Bourne-kompatible (sh) Shell eingestellt haben. Standardmäßig werden Befehle in der sh-Syntax formatiert. Wenn Sie diese Einstellung auf csh oder fish setzen, werden die Befehle auf dem Zielsystem stattdessen in der Syntax dieser Shells ausgeführt.
- - ansible_python_interpreter: Der Python-Pfad des Zielhosts. Dies ist nützlich für Systeme mit mehr als einem Python oder nicht unter /usr/bin/python, wie z.B. *BSD, oder wo /usr/bin/python kein Python der Serie 2.X ist. Wir verwenden nicht den /usr/bin/env-Mechanismus, da dies voraussetzt, dass der Pfad des entfernten Benutzers richtig eingestellt ist und außerdem davon ausgegangen wird, dass die ausführbare Python-Datei python heißt, während die ausführbare Datei z.B. python2.6 heißen könnte.
- ansible_*_interpreter: Funktioniert für alles wie Ruby oder Perl und funktioniert genauso wie ansible_python_interpreter. Dies ersetzt den Shebang von Modulen, die auf diesem Host ausgeführt werden.
Neu in Version 2.1.
- - ansible_shell_executable: Legt die Shell fest, die der Ansible-Controller auf dem Zielrechner verwendet, und setzt den Wert in ansible.cfgaußer Kraft . Die Standardeinstellungist /bin/sh. Sie sollten diesen Wert nur ändern, wenn es nicht möglich ist, /bin/sh zu verwenden. Nicht installiert oder keine Schreibrechte für die Ausführung.
Beispiele aus einer Ansible-INI-Hostdatei:
[localhost]
LC1 ansible_ssh_host=localhost
[Backend]
BK1 ansible_ssh_host=192.168.1.10 ansible_port=2222 ansible_user=manager ansible_python_interpreter=/usr/local/bin/python
BK2 ansible_ssh_host=192.168.1.11 ansible_ssh_private_key_file=/home/example/.ssh/aws.pem
2.8 Inventar einrichten
Wenn Sie mehrere Umgebungen verwalten müssen, ist es sicherer, wenn Sie nur Hosts einer einzigen Umgebung pro Inventardatei definieren. Auf diese Weise ist es schwieriger, versehentlich den Status von Knoten in einer QA-Umgebung zu ändern, wenn Sie eigentlich einige Server "in der Produktion" aktualisieren wollten.
Für das oben erwähnte Beispiel könnten Sie eine Produktionsinventardatei haben:
Um ein Playbook namens deploy.yml auf alle Backend-Server in der Produktionsumgebung anzuwenden, verwenden Sie den folgenden Befehl:
ansible-playbook deploy.yml -i inventory/AFD_hosts_2.8.1_production -l backend
Mehr zu diesem Thema demnächst!
3. Ad-hoc-Befehle 4. YAML-Grundlagen 5. Playbooks 6. Variablen 7. Rollen