Ansible-Tutorial für Anfänger: Playbook & Befehle

⚡ Intelligente Zusammenfassung

Ansible ist eine Open-Source-Automatisierungs-Engine ohne Agenten, die Server über SSH konfiguriert, Ad-hoc-Befehle ausführt und komplexe Bereitstellungen mithilfe von YAML-Playbooks, Rollen und wiederverwendbaren Vorlagen unter Linux und macOS orchestriert. Windows Infrastruktur.

  • 🧩 Kein Agent ArchiStruktur: Ansible stellt über SSH eine Verbindung zu den Clients her und überträgt Module, sodass keine Agentensoftware auf den verwalteten Knoten installiert werden muss.
  • 📥 Installation: Richten Sie Ansible auf dem Kontrollknoten mit yum und EPEL unter CentOS oder RHEL ein, oder mit apt und dem PPA unter Ubuntu oder Debian.
  • Ad-hoc-Befehle: Führen Sie einmalige Aufgaben aus, wie zum Beispiel ping, copy, or yum across an inventory using the ansible -m module syntax.
  • 📜 Spielbücher: Beschreiben Sie den gewünschten Zustand in YAML-Playbooks, die Plays, Tasks und Module gruppieren, um viele Server konsistent zu konfigurieren.
  • 🧱 Rollen und Vorlagen: Große Playbooks lassen sich in wiederverwendbare Rollen aufteilen, die mit ansible-galaxy erstellt werden, und Konfigurationsdateien können mit Jinja2-Vorlagen gerendert werden.
  • 🔁 Handler und Fakten: Trigger-Handler werden über Benachrichtigungen bei Änderungen ausgelöst, und gather_facts-Variablen werden für bedingte, wiederholbare Automatisierung verwendet.
  • 🎯 Fallstudie: Ein einzelnes p4.yml-Playbook kann die Rollen SELinux, httpd und Resolver auf allen Hosts ausführen, wobei jede Rolle durch ein Tag gesteuert wird.

Ansible-Tutorial für Anfänger: Installation, Ad-hoc-Befehle, Playbooks, Rollen und Vorlagen

Ansible ist eines der am weitesten verbreiteten Open-Source-Automatisierungstools in der modernen IT. DevOpsAnsible wird für sein agentenloses Design und seine einfachen, übersichtlichen Konfigurationsdateien geschätzt. Dieses Ansible-Tutorial für Anfänger erklärt anhand praktischer Beispiele, was Ansible ist, wie man es installiert und wie man Ad-hoc-Befehle, Playbooks, Rollen und Vorlagen verwendet.

Was ist Ansible?

Ansible ist ein Open-Source-Automatisierungs- und Orchestrierungstool für Softwarebereitstellung, Konfigurationsmanagement und Softwareverteilung. Es konfiguriert Unix-ähnliche Systeme und Windows Ansible ähnelt anderen Systemen und bietet Infrastruktur als Code durch seine eigene deklarative Sprache. Ansible wird oft mit agentenbasierten Tools wie beispielsweise verglichen. Marionette.

Ansible ist aufgrund seiner einfachen Installation, der unkomplizierten Client-Anbindung und des agentenlosen Designs beliebt. Es verbindet sich mit Clients über SSHDaher ist kein spezieller Agent auf Clientseite erforderlich. Ansible überträgt Module an jeden Client, die Module werden lokal ausgeführt und ihre Ausgabe wird an den Ansible-Server zurückgesendet.

Da Ansible auf SSH basiert, kann es sich mithilfe von SSH-Schlüsseln einfach mit Clients verbinden, was den gesamten Prozess vereinfacht. Clientdetails wie Hostnamen oder IP-Adressen und SSH-Ports werden in sogenannten Inventardateien gespeichert. Sobald Sie eine Inventardatei erstellt und befüllt haben, kann Ansible sie verwenden.

Warum Ansible verwenden?

Hier einige wichtige Vorteile der Verwendung von Ansible:

  • Einer der größten Vorteile von Ansible ist, dass es für jedermann kostenlos nutzbar ist.
  • Für die Installation und Nutzung sind keine besonderen Systemadministratorkenntnisse erforderlich, und die offizielle Dokumentation ist sehr umfangreich.
  • Dank seiner Modularität bei Plugins, Modulen, Inventaren und Playbooks ist Ansible ein hervorragender Begleiter für die Orchestrierung großer Umgebungen.
  • Ansible ist leichtgewichtig und konsistent und unterliegt keinen Einschränkungen hinsichtlich des Betriebssystems oder der zugrunde liegenden Hardware.
  • Dank seines agentenlosen Designs und der Verwendung von OpenSSH-Sicherheitsfunktionen ist es sehr sicher.
  • Ansible zeichnet sich durch eine sanfte Lernkurve aus, unterstützt durch eine umfassende Dokumentation sowie eine leicht zu erlernende Struktur und Konfiguration.

Diese Stärken, insbesondere im Vergleich zu anderen Alternativen zu AnsibleDies trägt dazu bei, die rasche Verbreitung zu erklären. Vor der Installation ist es hilfreich zu verstehen, wie das Projekt entstanden ist.

Geschichte von Ansible

Hier sind die wichtigsten Meilensteine ​​in der Geschichte von Ansible:

  • Das Ansible-Projekt begann im Februar 2012. Es wurde ursprünglich von Michael DeHaan entwickelt, dem Schöpfer von Cobbler und Func (Fedora Unified Network Controller).
  • Das Unternehmen, das Ansible finanzierte und ursprünglich AnsibleWorks Inc. hieß, wurde 2015 von Red Hat übernommen und später zusammen mit Red Hat unter die Marke AnsibleWorks Inc. gestellt. IBM Regenschirm.
  • Heute ist Ansible in Distributionen wie Fedora Linux, RHEL, CentOS und Oracle Linux.

Wichtige Begriffe, die in Ansible verwendet werden

Die folgenden Begriffe tauchen im Verlauf dieses Ansible-Tutorials auf und es lohnt sich, sie vor Beginn zu kennen:

Ansible-Server

Die Maschine, auf der Ansible installiert ist und von der aus alle Aufgaben und Playbooks ausgeführt werden.

Modul

Ein Modul ist ein Befehl oder eine Gruppe ähnlicher Ansible-Befehle, die auf der Clientseite ausgeführt werden sollen.

Aufgabe

Eine Aufgabe ist ein Abschnitt, der aus einer einzigen, abzuschließenden Prozedur besteht.

Funktion / Rolle (Role) *

Eine Methode, um Aufgaben und zugehörige Dateien so zu organisieren, dass sie später in einem Playbook aufgerufen werden können.

Tatsache

Informationen, die über die Operation gather_facts aus den globalen Systemvariablen des Clients abgerufen werden.

Inventar

Eine Datei, die Daten über die Ansible-Clientserver enthält. Sie wird in späteren Beispielen als Hosts-Datei bezeichnet.

Spielen

Die Umsetzung eines Spielplans.

Handler

Eine Aufgabe, die nur aufgerufen wird, wenn ein Benachrichtigungssignal vorhanden ist.

Notifier

Ein Abschnitt, der einer Aufgabe zugeordnet ist und einen Handler aufruft, wenn sich die Ausgabe ändert.

Etikett

Ein Name, der einer Aufgabe zugewiesen wird und später verwendet werden kann, um genau diese Aufgabe oder eine Gruppe von Aufgaben auszuführen.

Ansible-Installation unter Linux

Nachdem Sie Ihre Optionen abgewogen und sich für Ansible entschieden haben, besteht der nächste Schritt in der Installation auf Ihrem System. Die folgende kurze Anleitung beschreibt die Installation auf den gängigsten Systemen. Linux Verteilungen.

Installieren Sie Ansible auf Centos/RedHat-Systemen

Schritt 1) Installieren Sie das EPEL-Repository.

[root@ansible-server ~]# sudo yum install epel-release

Schritt 2) Installieren Sie das Ansible-Paket.

[root@ansible-server ~]# sudo  yum install -y ansible

Installieren Sie Ansible auf Centos/RedHat-Systemen

Installieren Sie ansible auf Ubuntu/Debian-Systeme

Schritt 1) Führen Sie ein Update der Pakete durch.

$ sudo apt update

Schritt 2) Installieren Sie das Software-Eigenschaften-Gemeinschaftspaket.

$ sudo apt install software-properties-common

Schritt 3) Installieren Sie das Ansible Personal Package Archive.

$ sudo apt-add-repository ppa:ansible/ansible

Schritt 4) Installieren Sie Ansible.

$ sudo apt update
$ sudo apt install ansible

Ansible-Ad-hoc-Befehle

Eine der einfachsten Möglichkeiten, Ansible zu nutzen, sind Ad-hoc-Befehle. Diese sind nützlich, wenn Sie einen Befehl auf einem einzelnen Server oder einer Servergruppe ausführen möchten. Ad-hoc-Befehle werden nicht für die spätere Verwendung gespeichert, ermöglichen aber eine schnelle Interaktion mit den gewünschten Servern.

In diesem Ansible-Tutorial wird eine einfache Hosts-Datei für zwei Server konfiguriert, die host1 und host2 enthält.

Sie können die Erreichbarkeit der Hosts vom Ansible-Server aus überprüfen, indem Sie einen Befehl ausführen. ping Befehl auf allen Hosts.

[root@ansible-server test_ansible]# ansible -i hosts all -m ping
host1 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
host2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Ansible Ad-hoc-Befehle

Erläuterung:

  1. Status des Befehls, in diesem Fall ERFOLGREICH
  2. Host, auf dem der Befehl ausgeführt wurde
  3. Der Befehl, der über den Parameter -m ausgegeben wird, in diesem Fall ping
  4. Mit dem Parameter -i können Sie auf die Hosts-Datei verweisen.

Sie können denselben Befehl bei Bedarf auch auf einem einzelnen Host ausführen.

[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2
host2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Ansible Ad-hoc-Befehle

Erläuterung:

  1. Der Limit-Parameter kann verwendet werden, um Befehle nur auf bestimmten Hosts in der Hostdatei auszugeben
  2. Name des Hosts, wie in der Inventardatei definiert

Wenn Sie eine Datei schnell an mehrere Ziele kopieren müssen, verwenden Sie das Modul „copy“, das auf SCP basiert. Der Befehl und seine Ausgabe sehen wie folgt aus:

[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"
host1 | SUCCESS => {
    "changed": true,
    "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709",
    "dest": "/tmp/testfile",
    "gid": 0,
    "group": "root",
    "md5sum": "d41d8cd98f00b204e9800998ecf8427e",
    "mode": "0644",
    "owner": "root",
    "size": 0,
    "src": "/root/.ansible/tmp/ansible-tmp-1562216392.43-256741011164877/source",
    "state": "file",
    "uid": 0
}
host2 | SUCCESS => {
    "changed": true,
    "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709",
    "dest": "/tmp/testfile",
    "gid": 0,
    "group": "root",
    "md5sum": "d41d8cd98f00b204e9800998ecf8427e",
    "mode": "0644",
    "owner": "root",
    "size": 0,
    "src": "/root/.ansible/tmp/ansible-tmp-1562216392.6-280302911361278/source",
    "state": "file",
    "uid": 0
}

Ansible Ad-hoc-Befehle

Erläuterung:

  1. Kopiermodul definiert
  2. Modulargumente sind in diesem Fall der absolute Quellpfad und der absolute Zielpfad.
  3. Ansible-Befehlsausgabe, die den Erfolg des Kopierbefehls und andere Details wie die SHA1- oder MD5-Prüfsummen zur Dateiintegritätsprüfung und Metadaten wie Eigentümer, Größe oder Berechtigungen widerspiegelt. Es ist mühelos, ein Paket auf mehreren Servern zu installieren. Ansible verfügt über mehrere Module, die mit verwendeten Installationsprogrammen wie Yum, Apt, DNF usw. interagieren.

Im nächsten Beispiel installieren Sie ein Paket mit dem yum-Modul auf zwei CentOS-Hosts.

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=present'
host1 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [


"Loaded plugins: fastestmirror\nLoading mirror speeds from cached hostfile\n * base: mirror.netsite.dk\n * elrepo: mirrors.xservers.ro\n * epel: fedora.mirrors.telekom.ro\n * extras: centos.mirrors.telekom.ro\n * remi-php70: remi.schlundtech.de\n * remi-safe: remi.schlundtech.de\n * updates: centos.mirror.iphh.net\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n========================================================================\n Package         Arch              Version                Repository       Size\n========================================================================\nInstalling:\n ncdu            x86_64            1.14-1.el7             epel             51 k\n\nTransaction Summary\n========================================================================\nInstall  1 Package\n\nTotal download size: 51 k\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nInstalled:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}
host2 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nLoading mirror speeds from cached hostfile\n * base: mirror.netsite.dk\n * elrepo: mirrors.leadhosts.com\n * epel: mirrors.nav.ro\n * extras: centos.mirrors.telekom.ro\n * remi-php70: mirrors.uni-ruse.bg\n * remi-safe: mirrors.uni-ruse.bg\n * updates: centos.mirror.iphh.net\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n========================================================================\n Package         Arch              Version                Repository       Size\n========================================================================\nInstalling:\n ncdu            x86_64            1.14-1.el7             epel             51 k\n\nTransaction Summary\n========================================================================\nInstall  1 Package\n\nTotal download size: 51 k\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nInstalled:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}

Ansible Ad-hoc-Befehle

Erläuterung:

  1. In diesem Beispiel wird das Yum-Modul verwendet
  2. Es definiert die Modulargumente und in diesem Fall wählen Sie den Namen des Pakets und seinen Status. Fehlt beispielsweise der Status, wird das Paket durchsucht und, falls gefunden, entfernt
  3. Bei gelber Farbe sehen Sie die Ausgabe des Ansible-Befehls mit geändertem Status, was in diesem Fall bedeutet, dass das Paket gefunden und installiert wurde.
  4. Status des über Ansible ausgegebenen Yum-Installationsbefehls. In diesem Fall wurde das Paket ncdu.x86_64 0:1.14-1.el7 installiert.

Selbstverständlich können alle Optionen des yum-Installationsprogramms über Ansible genutzt werden, einschließlich update, install, latest version und remove.

Im folgenden Beispiel wird derselbe Befehl ausgeführt, um das zuvor installierte ncdu-Paket zu entfernen.

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'
host1 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be erased\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n========================================================================\n Package         Arch              Version               Repository        Size\n========================================================================\nRemoving:\n ncdu            x86_64            1.14-1.el7            @epel             87 k\n\nTransaction Summary\n========================================================================\nRemove  1 Package\n\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Erasing    : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nRemoved:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}
host2 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be erased\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n========================================================================\n Package         Arch              Version               Repository        Size\n========================================================================\nRemoving:\n ncdu            x86_64            1.14-1.el7            @epel             87 k\n\nTransaction Summary\n========================================================================\nRemove  1 Package\n\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Erasing    : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nRemoved:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}

Ansible Ad-hoc-Befehle

Erläuterung:

  1. Die Ausgabe des Befehls yum zeigt, dass das Paket entfernt wurde.

Ein weiteres wesentliches Merkmal von Ansible ist die Fähigkeit, Informationen über ein System zu sammeln. Es erfasst Hardware-, Software- und Versionsinformationen und speichert jeden Wert in einer Variablen, die später wiederverwendet werden kann.

Wenn Sie detaillierte Informationen über die Systeme benötigen, die Ansible modifizieren soll, sammelt das Setup-Modul diese Informationen aus den Systemvariablen.

Ansible Ad-hoc-Befehle

Ansible-Playbooks

Ansible-Playbooks Playbooks ermöglichen es, Befehle über Skripte an entfernte Systeme zu senden. Sie konfigurieren komplexe Systemumgebungen und erhöhen die Flexibilität, indem sie ein einzelnes Skript auf einem oder mehreren Systemen ausführen. Sie verhalten sich eher wie eine Konfigurationssprache als wie eine Programmiersprache.

Playbook-Befehle verwenden das YAML-Format, daher ist nur wenig Syntax erforderlich, die Einrückung muss jedoch beachtet werden. Wie der Name schon sagt, ist ein Playbook eine Sammlung von Plays. Mithilfe eines Playbooks können Sie bestimmten Hosts spezifische Rollen und anderen unterschiedliche Rollen zuweisen und so viele Server in einer einzigen Datei orchestrieren.

Bevor wir mit den Playbook-Beispielen fortfahren, ist es hilfreich, eine Aufgabe zu definieren. Aufgaben sind die Schnittstelle zu Ansible-Modulen für Rollen und Playbooks.

Betrachten wir nun ein Ansible-Playbook mit einem einzigen Play, das mehrere Tasks enthält, wie unten dargestellt:

---

- hosts: group1
  tasks:
  - name: Install lldpad package
    yum:
      name: lldpad
      state: latest
  - name: check lldpad service status
    service:
      name: lldpad
      state: started

Ansible-Playbooks

Im obigen Playbook werden die Hosts der Gruppe 1 in der Hosts-Datei mithilfe des Yum-Moduls für die Installation des lldpad-Pakets ausgewählt. Der nach der Installation erstellte lldpad-Dienst wird anschließend mit dem Service-Modul gestartet, das hauptsächlich mit dem Systemd-Ensemble interagiert.

Erläuterung:

  1. Gruppe von Hosts, auf denen das Playbook ausgeführt wird
  2. Das Yum-Modul wird in dieser Aufgabe für die lldpad-Installation verwendet
  3. Mit dem Servicemodul wird überprüft, ob der Dienst nach der Installation betriebsbereit ist

Jedes Ansible-Playbook arbeitet mit einer Inventardatei. Diese Inventardatei enthält eine Liste von Servern, die in Gruppen unterteilt sind, wodurch eine bessere Kontrolle über Details wie die IP-Adresse und den SSH-Port für jeden Host ermöglicht wird.

Die Inventardatei für dieses Playbook-Beispiel sieht wie folgt aus. Es gibt zwei Gruppen, Gruppe1 und Gruppe2, die jeweils Host1 und Host2 enthalten.

[group1]
host1 ansible_host=192.168.100.2 ansible_ssh_port=22
[group2]
host2 ansible_host=192.168.100.3 ansible_ssh_port=22

Ansible-Playbooks

Erläuterung:

  1. Gruppenname
  2. Hostname mit IP-Adresse und SSH-Port, in diesem Fall der Standardport 22.

Das nächste Ansible-Playbook-Beispiel enthält zwei Plays für zwei Hostgruppen. Für die erste Gruppe, Gruppe1, ist SELinux aktiviert, und wenn es aktiviert ist, erscheint eine Meldung auf dem Hostbildschirm.

Bei der zweiten Gruppe wird das httpd-Paket nur dann installiert, wenn ansible_os_family RedHat und ansible_system_vendor HP ist.

ansible_os_family und ansible_system_vendor sind Variablen, die mit der Option gather_facts erfasst werden und wie in diesem bedingten Beispiel verwendet werden können.

---

- hosts: group1
  tasks:
  - name: Enable SELinux
    selinux:
      state: enabled
    when: ansible_os_family == 'Debian'
    register: enable_selinux

  - debug:
      Imsg: "Selinux Enabled. Please restart the server to apply changes."
    when: enable_selinux.changed == true

- hosts: group2
  tasks:
  - name: Install apache
    yum:
      name: httpd
      state: present
    when: ansible_system_vendor == 'HP' and ansible_os_family == 'RedHat'

Ansible-Playbooks

Erläuterung:

  1. Beispiel für die when-Klausel. In diesem Fall ist der Betriebssystemtyp Debian. Die Variable „ansible_os_family“ wird über die Funktion „gather_facts“ erfasst.
  2. Die Aufgabenausgabe wird für die zukünftige Verwendung unter dem Namen „enable_selinux“ registriert
  3. Ein weiteres Beispiel für die „when“-Klausel. In diesem Fall wird dem Host-Benutzer eine Meldung angezeigt, ob SELinux zuvor tatsächlich aktiviert wurde.
  4. Ein weiteres Beispiel für die when-Klausel, die aus zwei Regeln besteht

Neben Aufgaben gibt es auch spezielle Aufgaben, sogenannte Handler. Ein Handler muss im gesamten Playbook einen eindeutigen Namen haben. Handler funktionieren wie reguläre Aufgaben, können aber über einen Notifier benachrichtigt werden.

Wird ein Handler während der Ausführung eines Playbooks nicht benachrichtigt, wird er nicht ausgeführt. Wird ein Handler jedoch von mehreren Aufgaben benachrichtigt, wird er nur einmal ausgeführt, nachdem alle Aufgaben abgeschlossen sind.

Im folgenden Beispiel enthält eine bestimmte Aufgabe einen Benachrichtigungsabschnitt, der eine weitere Aufgabe aufruft. Ändert sich die Ausgabe der ersten Aufgabe, wird eine Handler-Aufgabe aufgerufen. Ein typisches Beispiel hierfür ist das Ändern einer Konfigurationsdatei und der anschließende Neustart des betroffenen Dienstes.

---

- hosts: group2
  tasks:
  - name: sshd config file modify port
    lineinfile:
     path: /etc/ssh/sshd_config
     regexp: 'Port 28675'
     line: '#Port 22'
    notify:
       - restart sshd
handlers
    - name: restart sshd
      service: sshd
        name: sshd
        state: restarted

Wenn sich in diesem Fall die erste Aufgabe, „sshd config file modify port“, ändert, d. h. der Port nicht bereits 28675 ist, wird der Port geändert und die Aufgabe benachrichtigt den gleichnamigen Handler, der den sshd-Dienst neu startet.

Ansible-Playbooks

Erläuterung:

  1. Beispiel für einen Melder
  2. Beispiel für einen Handler

Ansible-Rollen

Bei der Arbeit mit großen Playbooks ist es einfacher, die Aufgaben in Rollen aufzuteilen. Rollen erleichtern auch die spätere Wiederverwendung von Arbeitsschritten. Eine Rolle ist eine Sammlung von Aufgaben, die von einem Playbook in ein anderes verschoben und unabhängig voneinander ausgeführt werden können, jedoch nur innerhalb einer Playbook-Datei.

Die Rollen werden in separaten Verzeichnissen gespeichert und folgen einer bestimmten Verzeichnisstruktur.

[root@ansible-server test2]# tree
.
`-- role1
    |-- defaults
    |   `-- main.yml
    |-- handlers
    |   `-- main.yml
    |-- meta
    |   `-- main.yml
    |-- README.md
    |-- tasks
    |   `-- main.yml
    |-- tests
    |   |-- inventory
    |   `-- test.yml
    `-- vars
        `-- main.yml

7 directories, 8 files

Die YAML-Datei im Verzeichnis „defaults“ enthält die Standardvariablen des Playbooks. Im Verzeichnis „handlers“ werden die Handler gespeichert, und das Verzeichnis „meta“ enthält Informationen zum Autor und zu Rollenabhängigkeiten. Das Verzeichnis „tasks“ enthält die Haupt-YAML-Datei für die Rolle.

Das Verzeichnis „tests“ enthält ein Beispiel-YAML-Playbook und eine Beispiel-Inventardatei und wird hauptsächlich zum Testen verwendet, bevor die eigentliche Rolle erstellt wird.

Das Verzeichnis „vars“ enthält die YAML-Datei, in der alle von der Rolle verwendeten Variablen definiert sind. Die Verzeichnisse „templates“ und „files“ enthalten die Vorlagen und Dateien, die von den Aufgaben innerhalb der Rolle verwendet werden.

Um die Verzeichnisstruktur für eine Rolle zu erstellen, verwenden Sie den folgenden Befehl mit dem Rollennamen als letztem Parameter:

[root@ansible-server test2]# ansible-galaxy init role1

Ansible funktioniert auch gut mit Templates und verwendet Jinja2 als Template-Sprache.

Das nächste Beispiel zeigt, wie eine einfache Jinja2-Vorlage aussieht und wie man sie in einer Rolle verwendet.

Zur Laufzeit können Sie, abhängig beispielsweise davon, in welchem ​​Rechenzentrum sich Ihr Server befindet, mithilfe der Variablen resolver_ip_addresses aus mehreren Nameservern auswählen, die jeweils einem Rechenzentrum zugeordnet sind.

{% for resolver in resolver_ip_addresses %}
nameserver {{ resolver }}
{% endfor %}

options timeout:1
options attempts:5
options rotate

In diesem Beispiel definiert das Playbook-Verzeichnis mehrere Variablen, darunter resolver_ip_addresses, mit unterschiedlichen Werten je nach Rechenzentrum.

- name: Set resolver for server
  template:
    src: dns.j2
    dest: /etc/resolv.conf
    group: root
    owner: root
    mode: "0644"
    tag: resolver

Ansible-Rollen

Erläuterung:

  1. Name der zu verwendenden Vorlage. Die Vorlage befindet sich im Vorlagenverzeichnis im Rollenpfad
  2. Zielpfad des Dateinamens, der clientseitig durch die Vorlage ersetzt werden soll.
  3. Berechtigungen der Zieldatei

Rollenaufgaben können auch ein Tag-Feld mit einem zugewiesenen Namen haben. Mehrere Aufgaben können dasselbe Tag verwenden, und beim Ausführen eines Playbooks kann ein Tag angegeben werden, sodass nur die getaggten Aufgaben ausgeführt werden.

Ansible-Fallstudie

In diesem Abschnitt analysieren wir eine Fallstudie eines grundlegenden Ansible-Playbooks mit drei Rollen. Ziel ist es, die bisher behandelten Konzepte anhand eines praktischen Beispiels zu veranschaulichen. Einige frühere Beispiele aus diesem Tutorial wurden für dieses Playbook angepasst und wiederverwendet.

Nachfolgend ist die Verzeichnisstruktur des Playbooks dargestellt. Die verwendete YAML-Datei heißt p4.yml.

[root@ansible-server test_ansible]# ls -lrth
total 16K
-rw-r--r--. 1 root root   0 Jul  3 10:13 testfile
-rw-r--r--. 1 root root 203 Jul  3 13:30 p1.yml
-rw-r--r--. 1 root root 125 Jul  3 15:00 hosts
-rw-r--r--. 1 root root 488 Jul  3 16:40 p2.yml
-rw-r--r--. 1 root root 188 Jul  4 17:33 p4.yml
drwxr-xr-x. 5 root root  47 Jul  4 17:35 roles
[root@ansible-server test_ansible]# cd roles
[root@ansible-server roles]# ls -lrth
total 12K
drwxr-xr-x. 9 root root 4.0K Jul  4 12:52 httpd
drwxr-xr-x. 9 root root 4.0K Jul  4 13:55 selinux
drwxr-xr-x. 9 root root 4.0K Jul  4 16:54 resolver

Das Playbook umfasst drei Rollen. Die Resolver-Rolle konfiguriert einen bestimmten Nameserver auf den Servern, indem sie eine Datei in das Verzeichnis `/etc/resolv.conf` kopiert. Die httpd-Rolle installiert das httpd-Paket mithilfe des yum-Moduls. Die dritte Rolle aktiviert SELinux und fordert den angemeldeten Benutzer zum Neustart des Systems auf. Jede Rolle wurde mit dem Befehl `ansible-galaxy` erstellt.

Resolver-Rolle, main.yml-Aufgabe:

Ansible-Fallstudie

Httpd-Rolle, main.yml-Aufgabe:

Ansible-Fallstudie

Selinux-Rolle, main.yml-Aufgabe:

Ansible-Fallstudie

Nachfolgend finden Sie das Playbook p4.yml. Es wird auf allen Hosts ausgeführt, sofern in der Befehlszeile nichts anderes angegeben ist. Es läuft als Root-Benutzer auf Port 22 (SSH), sammelt vor dem Ausführen der Rollen Informationen und führt alle drei Rollen aus. Jede Rolle kann unabhängig ausgeführt werden, indem ihr Tag mit dem Parameter `-t` in der Befehlszeile von `ansible-playbook` angegeben wird.

---

- hosts: all
  user: root
  port: 22
  gather_facts: True
  roles:
    - { role: selinux, tags: selinux }
    - { role: httpd, tags: httpd }
    - { role: resolver, tags: resolver }

Anschließend können Sie das Playbook p4.yml auf den beiden Hosts ausführen und die Ausgabe auswerten. Derselbe Befehl kann mit dem Parameter `--check` für einen Testlauf und mit dem Parameter `-k` für die Passwortauthentifizierung ausgeführt werden.

Ansible-Fallstudie

Erläuterung:

  1. Ansible-playbook-Befehl, der p4.yml ausführt
  2. Playbook überspringt die SELinux-Rolle, da sie bereits aktiviert ist.
  3. Ansible hat festgestellt, dass das httpd-Paket bereits installiert ist, daher wird „OK“ zurückgegeben.
  4. Der Resolver wurde festgelegt und der Status des Rollenresolvers wurde geändert.

Spickzettel für Ansible-Befehle

Installieren Sie das EPEL-Repo auf Centos/RHEL-Systemen

[root@ansible-server ~]# sudo yum install epel-release

Installieren Sie das Ansible-Paket auf Centos/RHEL-Systemen

[root@ansible-server ~]# sudo  yum install -y ansible

Führen Sie ein Update der Pakete unter Debian/ durch.Ubuntu Systeme

$ sudo apt update

Installieren Sie das Software-Properties-Common-Paket unter Debian/Ubuntu Systeme

$ sudo apt install software-properties-common

Installieren Sie das persönliche Ansible-Paketarchiv auf Debian/Ubuntu Systeme

$ sudo apt-add-repository ppa:ansible/ansible

Ansible unter Debian/ installierenUbuntu Systeme

$ sudo apt update
$ sudo apt install ansible

Ausgabe a ping Befehl auf allen Servern, die in der Inventardatei namens hosts definiert sind

[root@ansible-server test_ansible]# ansible -i hosts all -m ping

Ausgabe a ping Befehl nur auf Host2

[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2

Kopieren Sie die Datei „testfile“ auf allen Hosts in die Inventardatei

[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"

Installieren Sie das ncdu-Paket auf allen Hosts

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=present'

Entfernen Sie das ncdu-Paket auf allen Hosts

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'

Erstellen Sie die Verzeichnisstruktur für die Rolle mit dem Namen „role1“.

[root@ansible-server test2]# ansible-galaxy init role1

Führen Sie das p4.yml-Playbook trocken aus

[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml --check

Führen Sie das p4.yml-Playbook mit Passwortauthentifizierung für alle Hosts aus

[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml -k

Häufig gestellte Fragen

Ja. Ansible ist agentenlos, daher läuft keine Software auf den verwalteten Knoten. Die Verbindung erfolgt über SSH oder WinRM. Windowsund überträgt kleine Module, die auf dem Zielsystem ausgeführt und anschließend entfernt werden. Nur der Kontrollknoten benötigt Ansible und Python installiert.

Ansible-Playbooks werden in YAML geschrieben, einer lesbaren Sprache, die Einrückungen anstelle von geschweiften Klammern verwendet. Templates nutzen die Jinja2-Templating-Sprache, während Fakten und Variablen es ermöglichen, ein Playbook an verschiedene Hosts anzupassen. Für den Einstieg sind keine allgemeinen Programmierkenntnisse erforderlich.

Ansible ist agentenlos und Push-basiert und sendet Änderungen über SSH, während Marionette und Chef sind üblicherweise agentenbasiert und pull-basiert. Ansible verwendet YAML, wohingegen… Chef Puppet verwendet Ruby und Puppet nutzt seine eigene domänenspezifische Sprache (DSL). Viele Teams entscheiden sich aufgrund der einfacheren Lernkurve für Ansible.

Ja. Ansible ist kostenlos und Open Source unter der GNU GPL und wird von Red Hat und einer großen Community weiterentwickelt. Die Kern-Engine und Tausende von Modulen sind kostenlos. Red Hat bietet außerdem die Ansible Automation Platform an, ein kostenpflichtiges Produkt mit grafischer Benutzeroberfläche, rollenbasierter Zugriffskontrolle und Support.

Ja. Neben Linux- und Unix-Hosts, die über SSH erreicht werden, verwaltet Ansible auch Windows Knoten über WinRM unter Verwendung dedizierter Knoten Windows Es kann Pakete installieren, die Registrierung bearbeiten, Dienste verwalten und PowerShell ausführen, also gemischtes Linux und Windows Flotten werden von einem zentralen Kontrollknoten aus automatisiert.

Ansible Galaxy ist eine öffentliche Plattform zum Teilen und Herunterladen von Community-Rollen und -Sammlungen. Der Befehl `ansible-galaxy` erstellt die Verzeichnisstruktur einer Rolle und installiert veröffentlichte Rollen, sodass Sie getestete Automatisierungen wiederverwenden können, anstatt jedes Playbook von Grund auf neu zu schreiben.

KI-Assistenten können YAML-Playbooks aus einer Anfrage in einfacher Sprache erstellen, unbekannte Module erklären und Lösungen für fehlgeschlagene Aufgaben oder Syntaxfehler vorschlagen. Sie können außerdem Shell-Skripte in idempotente Aufgaben umwandeln. Überprüfen Sie generierte Playbooks vor der Ausführung stets auf korrekte Modulnamen und Idempotenz.

Ja. GitHub-Copilot Vervollständigt Playbook-Aufgaben, Inventareinträge und Jinja2-Vorlagen anhand eines kurzen Kommentars oder Dateinamens. Verwenden Sie die Ausgabe als Ausgangspunkt und überprüfen Sie Einrückung, Modulparameter und Variablennamen, da generiertes YAML auf veraltete Syntax oder nicht vorhandene Module verweisen kann.

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: