centos:ansible:start

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
centos:ansible:start [14.01.2020 21:46. ]
django [Facts]
centos:ansible:start [28.06.2020 14:07. ] (aktuell)
django [Ansible]
Zeile 1: Zeile 1:
-====== Ansible ====== +{{:​centos:​ansible:​ansible_logo_only.png?​nolink&​28 |Bild: Ansible Logo}} 
-{{:​centos:​ansible:​ansible_logo.png?​nolink&​125 |Bild: Ansible Logo}} ​ +===== Ansible =====
-Einzelne Serversysteme mag man durchaus noch manuell einzeln installieren,​ konfigurieren und pflegen mögen und auch durchaus können. Komplexere Installationen,​ oder gleichartige Installationen lassen sich so aber nicht mehr ressourcenschonend und transparent nachvollziehbar betreiben. In solchen Umgebungen bedient man sich der Automatisierung bzw. Orchestrierung.  +
- +
-Doch was versteht man nun unter diesem Begriff Orchestrierung?​ Orchestrierung beschreibt das flexible Kombinieren mehrerer Services bzw. Dienste wie auch unterschiedlicher Serverinstanzen zu einer sinnvollen (Gesamt-)Konzeption oder auch Komposition. So wird man den Webserver erst starten, wenn zuvor der Datenbank und z.B. das NAS zur Verfügung steht und nicht umgekehrt.  +
-Die Anlehnung an Begrifflichkeiten aus der Musik ist hier ganz bewusst und nicht zufällig gewählt.  +
-Die Sicht auf einzelne Service-/​Daemon entspricht in etwa die eines Notenblattes einer Einzelstimme in einem Orchester. Einzelne Stimmen bzw. Instrumente machen aber noch lange kein stimmiges Gesamtensemble,​ erst der Dirigent (Orchestrator) sorgt für ein sinnvolles und optimales Zusammenspiel aller Einzelspieler/​-stimmen.  +
- +
-Bekannte Anwendungen rund um das Thema Automatisierung und Orchestrierung von Serversystemen-/​Rechenzentren sind **[[https://​www.ansible.com/​|Ansible]]**,​ **[[https://​puppet.com|Puppet]]** oder **[[https://​www.chef.io/​products/​chef-infra/​|Chef]]**. Im nachfolgender Anwendungsbeschreibung werden wir uns nun detailliert mit Ansible beschäftigen,​ da es sich bei diesem Projekt unter anderem folgende schlagkräftigen Vorteile/​Argumente klar herausstellen:​ +
- +
-  - Ansible kann in der Community Edition kostenlos genutzt werden. Darüber hinaus bietet aber Red Hat aber auch kostenpflichtige Editionen mit grafischer Oberfläche und Support an. +
-  - Eine der größten Vorteile von Ansible, sind die vorgefertigten "​Playbooks",​ die z.B. auf GitHub von vielen fleißigen Helfern der Community zur Verfügung gestellt werden. Bei diesen Playbooks handelt es sich um vorgefertigte Scripte, mit denen Server automatisiert bereitgestellt und konfiguriert werden können. Somit muss nicht für jede Anwendung erneut eine neue Konfigurationsvorgehensweise geschrieben werden um eine Anwendung zu orchestrieren. Dank dieser vorgefertigten Playbooks ist die Automatisierung also wesentlich einfacher. Alle Konfigurationsinformationen werden in diesen Ansible Playbooks gesammelt und auf die im Host Inventory gespeicherten Hosts ausgerollt. +
-  - Ein weiterer Vorteil von Ansible, ist der Umstand dass kein separater eigener Server aufgesetzt werden muss, um Ansible und seine Paybooks zu nutzen. Der (Client-)Rechner,​ auf dem die Playbooks zur Verfügung stehen, müssen nur die Server, die automatisiert verwaltet und konfiguriert werden sollen, mit Hilfe der SSH erreichen werden können. \\ Ansible arbeitet im Push-Verfahren und benötigt neben SSH und Python keine weitere Installation auf den einzelnen Systemen.  +
-  - Gegenüber Chef und Puppet ist die einfachere Verwaltung und Verwendung von Ansible, da z.B. keine zusätzliche Software auf dem zu verwaltenden System benötigt wird. Die Definitionen erfolgen im JSON-Format. Zusätzliche optionale Module können aber auch in jeder beliebigen Programmiersprache geschrieben sein. Hauptsächlich werden [[https://​yaml.org/​|YAML]]-basierten Skripte, die als "​Playbooks"​ bezeichnet werden, zur Orchestrierung der Systeme verwendet. ​ +
-===== Grundlagen ===== +
-==== Dokumentation ==== +
-=== O’REILLY Fachbuch - Ansible: Up & Running ​=== +
-Ein wertvoller und verlässlicher Begleiter beim eingehenden Studium von Ansible und dessen Fähigkeiten kann sicher das Buch **Ansible: Up & Running** (ISBN: 978-1-491-97980-8) von **[[https://​www.oreilly.com/​|O’REILLY]]** herangezogen und empfohlen werden. +
-{{ :​centos:​ansible:​ansible_book.png?​nolink&​250 |Bild: Photo des Buchs Ansible: Up & Running von O`REILLY}} +
- +
-=== online-Dokumentation === +
-Eine stets aktuelle Programm- und Projektdokumentation ist in der in der **Onlinebibliothek** unter : https://​docs.ansible.com/​ansible/​latest/​index.html zu finden! +
- +
-=== Dokumentation (RPM) === +
-Vom Maintainer des Paketes **ansible** wird auch die zugehörige sehr umfangreiche Dokumentation in Form eines eigenen Paketes **//​ansible-doc//​** zur Verfügung gestellt. +
-Wir installieren uns also das zugehörige Paket. +
-   # dnf install ansible-doc -y +
-  +
-Nach erfolgter Installation finden wir auf der Festplatte unserer Admin-Workstation umfangreiche Dokumentationen. Mit Hilfe des Befehls **''​rpm -qil''​** erhalten wir einen Überblick über das betreffende Paket. +
-   # rpm -qi ansible-doc +
- +
-<​code>​Name ​       : ansible-doc +
-Version ​    : 2.9.2 +
-Release ​    : 1.fc31 +
-Architecture:​ noarch +
-Install Date: Sa 21 Dez 2019 20:38:39 CET +
-Group       : Unspecified +
-Size        : 311719083 +
-License ​    : GPLv3+ +
-Signature ​  : RSA/SHA256, Mo 09 Dez 2019 18:59:12 CET, Key ID 50cb390b3c3359c4 +
-Source RPM  : ansible-2.9.2-1.fc31.src.rpm +
-Build Date  : So 08 Dez 2019 21:42:23 CET +
-Build Host  : buildvm-aarch64-24.arm.fedoraproject.org +
-Packager ​   : Fedora Project +
-Vendor ​     : Fedora Project +
-URL         : http://​ansible.com +
-Bug URL     : https://​bugz.fedoraproject.org/​ansible +
-Summary ​    : Documentation for Ansible +
-Description : +
- +
-Ansible is a radically simple model-driven configuration management,​ +
-multi-node deployment, and remote task execution system. Ansible works +
-over SSH and does not require any software or daemons to be installed +
-on remote nodes. Extension modules can be written in any language and +
-are transferred to managed machines automatically. +
- +
-This package installs extensive documentation for ansible</​code>​ +
- +
-Eine Auflistung sämtlicher mitgelieferter Dateien erhält man durch Ergänzung der Option **''​l''​**. +
-   # rpm -qi ansible-doc +
- +
-==== Ansible Funktionsbeschreibung ==== +
-Das folgende Übersichtsskizze zeit die grundlegende Module und die  die Funktionsweise von Ansible. +
- +
-<​uml>​ +
-package "​Ansible Management Node" as AMN { +
- +
-  database "/​etc/​ansible/"​ { +
-  frame "​playbook"​ { +
- ​ [Commands] +
-  } +
-  frame "​inventory"​ { +
-   ​database "Group B" { +
-        [Host n] +
-   } +
-   ​database "Group A" { +
-        [Host 1] +
-        [Host 2] +
-        [Host 3] +
-   }  +
-  } +
-+
- +
-   +
- +
-+
-  +
-cloud { +
-  [Host "​1"​] +
-  [Host "​2"​] +
-  [Host "​3"​] +
-+
- +
-cloud { +
-  [Host "​n"​] +
-+
- +
-AMN -right-> [Host "​n"​] : SSH +
-AMN -down-> [Host "​3"​] : SSH +
-AMN -down-> [Host "​1"​] : SSH +
-AMN -down-> [Host "​2"​] : SSH +
-</​uml>​ +
- +
-Der Managementknoten im obigen Bild ist der Steuerknoten (Managing Node), der die gesamte Ausführung des Playbooks steuert. Es ist der Knoten, von dem aus die Installation ausgeführt wird, also z.B. unser zentraler Admin-Node. Die Inventarisierungsdatei enthält die Liste der Hosts, auf denen die Ansible Module ausgeführt werden müssen. Der Verwaltungsknoten stellt eine SSH-Verbindung her und führt die kleinen Module auf dem Host-Computer aus, installiert,​ konfiguriert und aktualisiert ggf. das entsprechende Softwarepaket. +
- +
-Das Schöne an Ansible ist dabei:  +
-  * dass es automatisch die Module entfernt, sobald diese installiert wurden,  +
-  * dass es eine Verbindung mit dem Host-Computer herstellt,  +
-  * die Anweisungen ausführt und bei erfolgreicher Installation den Code entfernt, der auf dem Host-Computer kopiert und ausgeführt wurde. +
- +
-==== YAML - was ist das? ==== +
-Wie Eingangs schon beschrieben verwendet Ansible Playbooks zur Beschreibung der Orchestrierungs- und  Automatisierungsaufgaben. Diese Playbooks sind meinst in **YAML** geschrieben und somit für den Admin eher sehr leicht zu verstehen, zu lesen und zu schreiben sind. Diese Playbooks beinhalten dabei detaillierte Informationen,​ die die Hard- und Software beschreibt. Somit kann z.B. von zentraler Stelle aus gleichnamige Dienste aufgesetzt und auch aktualisiert werden. +
- +
-Wir wollen uns daher kurz die grundlegende Syntax dazu ansehen. YAML selbst ist relativ einfach und intuitiv und daher in aller Regel einfacher und schneller zu verstehen als z.B. XML und JSON. Eine detaillierte Beschreibung dazu findet sich auch in der **[[https://​docs.ansible.com/​ansible/​latest/​reference_appendices/​YAMLSyntax.html|Ansible Referens zu YAML]]**. +
- +
-  * **START/​ENDE** Notation: \\ Jede YAML-Datei beginnt optional mit ''​%%---%%''​ und endet mit ''​%%...%%''​. +
-  * **Bemerkungen**:​ \\ Bemerkungen werden mit einem **''#''​** gekennzeichnet. +
-  * **key-value** Wertepaare: \\  YAML verwendet ein einfaches Schlüssel-Wertepaar zur Darstellung der Daten. Zur Trennung zwischen Schlüssel und Wert wird ein **'':''​**(Doppelpunkt verwendet. \\ Beispiel: <​code>​--- #YAML start syntax (optional)  +
-db_host:  +
-   ​vendor:​ Supermicro  +
-   ​serial:​ 9000140867 +
-   cpu: Intel Xeon E-2176G 6-Core 3,7GHz 12MB 8GT/s +
-   ram: 96 GB  +
-   HD: 2048 TB  +
-   nic: 4x 1Gbit/s LAN onBoard (Intel I210AT) +
-   rack: g33k +
-   he: 12/13  +
-... #YAML end syntax (optional)</​code>​ Alternativ dazu kann auch die abgekürzte Schreibweise verwendet werden, bei der aber die Lesbarkeit unter Umständen etwas leidet. <​code>​db_host:​ {vendor: Supermicro, serial: 9000140867, cpu: Intel Xeon E-2176G 6-Core 3,7GHz 12MB 8GT/s, ram: 96 GB, HD: 2048 TB, nic: 4x 1Gbit/s LAN onBoard (Intel I210AT), rack: g33k, he: 12/​13}</​code>​ +
-  * **Listen**: \\ Zur Verwendung von Listen wird jeder Eintrag dieser Liste in einer eigenen Zeile, eingerückt um ein Leerzeichen beginnend mit einem **''​-''​**,​ aufgeführt. \\ Bsp.: <​code>​--- #YAML start syntax (optional)  +
-kunden:  +
-   - 2017-DEAD-BEEF-0815 +
-   - 2017-BAAD-C0DE-4221 +
-   - 2018-900D-F00D-1967 +
-... #YAML end syntax (optional)</​code>​ Auch hier kann natürlich die gekürzte Schreibweise verwendet werden: <​code>​kunden:​ ['​2017-DEAD-BEEF-0815',​ '​2017-BAAD-C0DE-4221',​ '​2018-900D-F00D-0007'​]</​code>​ +
-  * kombinierte **key-value** Wertepaare und **Listen**: \\ Natürlich können auch Kombinationen von Wertepaaren und Listen verwendet werden. \\ Bsp.: <​code>​db_host:​  +
-   ​vendor:​ Supermicro  +
-   ​serial:​ 9000140867 +
-   cpu: Intel Xeon E-2176G 6-Core 3,7GHz 12MB 8GT/s +
-   ram: 96 GB  +
-   HD: 2048 TB  +
-   nic: 4x 1Gbit/s LAN onBoard (Intel I210AT) +
-   rack: g33k +
-   he: 12/13  +
-   nic:  +
-     - 4c:​52:​62:​09:​bd:​29 +
-     - 4c:​52:​62:​09:​bd:​28 +
-     - 4c:​52:​62:​09:​bd:​27 +
-     - 4c:​52:​62:​09:​bd:​26 +
-... #YAML end syntax (optional)</​code>​ Auch eine Kombination von Listen und zugehörigen Wertepaaren ist möglich. <​code> ​ - db_host:  +
-     ​vendor:​ Supermicro  +
-     ​serial:​ 9000140867 +
-        cpu: Intel Xeon E-2176G 6-Core 3,7GHz 12MB 8GT/s +
-        ram: 96 GB  +
-         HD: 2048 TB  +
-        nic: 4x 1Gbit/s LAN onBoard (Intel I210AT) +
-       rack: g33k +
-         he: 12/13  +
-        nic:  +
-          - 4c:​52:​62:​09:​bd:​29 +
-          - 4c:​52:​62:​09:​bd:​28 +
-          - 4c:​52:​62:​09:​bd:​27 +
-          - 4c:​52:​62:​09:​bd:​26 +
- +
- - mx_host:  +
-     ​vendor:​ Supermicro  +
-     ​serial:​ 9000141271 +
-        cpu: Intel Xeon E-2176G 6-Core 3,7GHz 12MB 8GT/s +
-        ram: 64 GB  +
-         HD: 1024 TB  +
-        nic: 4x 1Gbit/s LAN onBoard (Intel I210AT) +
-       rack: g33k +
-         he: 10/11  +
-        nic:  +
-          - 4c:​52:​62:​0a:​ce:​0f +
-          - 4c:​52:​62:​0a:​ce:​1f +
-          - 4c:​52:​62:​0c:​f0:​22 +
-          - 4c:​52:​62:​0c:​f0:​23 +
-... #YAML end syntax (optional)</​code>​ +
-  * **YAML-Formatierungen**:​ \\ YAML verwendet **''​|''​** zum Einfügen von Zeilenumbrüchen bei der Anzeige mehrerer Zeilen und **''>''​** zum Unterdrückung von Zeilenumbrüchen bei der Anzeige von mehreren Zeilen. Dadurch können wir große Zeilen besser strukturieren und für den Admin lesbarer gestalten. In beiden Fällen wird die Einrückung und Verwendung von Leerzeichen ignoriert. \\ Bsp: <​code>​include_newlines:​ | +
-         hier haben wir +
-         drei separate Textzeilen +
-         ​jeweils in einer neuen Zeile +
- +
-fold_newlines:​ > +
-         ​obwohl hier optisch der Text +
-         in drei Zeilen getrennt formatiert wurde +
-         wird diese als eine Zeile interprätiert</​code>​ +
- +
-<WRAP center round tip 80%> +
-**YAML** spezifische Ausdrücke: \\ +
- +
-Rund um YAML werden wir des öfteren über folgende Ausdrücke stolpern: +
-  * **Service/​Server** : Ein Prozess auf der Maschine, der den Dienst zur Verfügung stellt. +
-  * **Machine** : Ein physischer Server, vm(virtuelle Maschine) oder ein Container. +
-  * **Target machine** :  Eine Maschine die wir mit Ansible konfigurieren werden. +
-  * **Task** : Eine Aktion (ausführen,​ löschen, aktualisieren) usw., die von Ansible verwaltet wird. +
-  * **Playbook** : Dies ist eine **//​yml//​**-Datei,​ in der Ansible Befehle aufgelistet werden und dann auf dem Zielsystem ​ ausgeführt wird. +
-</​WRAP>​ +
- +
-Viele hilfreiche Informationen zur YAML-Notation sind in der **[[https://​docs.ansible.com/​ansible/​latest/​reference_appendices/​YAMLSyntax.html|Ansible-Dokumentation]]** zu finden. +
- +
-==== Playbooks ==== +
-In diesem Abschnitt werden wir uns nun die **Playbooks**,​ die Ansbilbe verwendet, etwas genauer ansehen. +
- +
-Playbooks sind die Dateien, in denen Ansible-Code im **[[#​yaml|YAML]]**((**Y**et **A**nother **M**arkup **L**anguage))-Format geschrieben. Playbooks sind eines der Kernmerkmale von Ansible und teilen Ansible mit, was genau ausgeführt und konfiguriert werden soll. Sie sind sozusgane eine Art ToDo-Liste für Ansible, die eine Liste von Aufgaben enthält. +
- +
-Ein Playbook enthält din oder mehrere Aufgaben/ Schritte (**tasks**) zur Installation und Konfiguration,​ die der Admin auf einem Zielsystem (**target machine**) ausführen möchte und sind sozusagen die elemantren Bausteine für alle Anwendungsfälle von Ansible. Playbooks werden sequentiell ausgeführt. Jedes Playbook wird entsprechend seiner Aufgabe strukturiert. +
- +
-Die Aufgabe eines Playbooks ist es, eine Reihe von Anweisungen abzubilden, mit deren ein bestimmtes Zielsystem (**machine**) bzw. ein Service/​Daemon (**service/​server**) auf diesem Zielsystem installiert und konfiguriert wird. +
- +
-Da es sich bei YAML um eine sogenannte **[[https://​en.wikipedia.org/​wiki/​Strict_programming_language|Strict programming language]]** handelt, ist beim Schreiben der YAML-Dateien besondere Sorgfalt geboten. Es gibt zwar verschiedene YAML-Editoren,​ aber in aller Regel reicht dazu auch ein ganz normaler Editor wie z.B. **vim**, **nano** oder **emacs**. +
- +
-In nachfolgendem Beispiel wollen wir einen Mailserver "​installieren"​ und definieren hierzu folegnde Werte/​Abschnitte:​ +
-  - **name** : Dieser Tag gibt den Namen des Ansible-Playbooks an; dieser Wert ist frei wähllbar und muss nur eindeutig sein. In unserem Fall beschreiben wir einfach, was das Script später erledigen soll, nämlich einen Mailserver installieren. +
-  - **hosts** : Dieses Tag gibt die Listen der Hosts oder der Hostgruppe an, gegen die wir dann später die Task ausführen wollen. Das Host-Feld/​Tag ist obligatorisch. Es teilt Ansible mit, auf welchen Hosts die aufgelisteten Tasks ausgeführt werden sollen. Die Aufgaben können auf demselben Rechner oder auf einem entfernten Rechner ausgeführt werden. Man kann die Tasks auf einem oder auch mehreren Rechnern ausführen und daher kann das hosts-Tag auch einen Eintrag für eine Gruppe von Hosts haben. +
-  - **vars** : Mit dem Vars-Tag können Sie die Variablen definieren, die wie in unserem Playbook verwenden können.  +
-  - **tasks** : Alle Playbooks enthalten entweder Aufgaben oder eine Liste von auszuführenden Aufgaben. Aufgaben sind eine Liste von Aktionen, die wir später auf dem oder den Zielsystem ausführen wollen. Ein Aufgabenfeld enthält einen optionalen Namen der Aufgabe und fungiert als Hilfetext für den Admin. \\ Jeder Task verweist intern auf ein Stück Code, das auch als Modul bezeichnet wird. Ein Modul definiert dabei, was später ausgeführt werden soll, und beinhaltet die zugehörigen Argumente, die für das auszuführende Modul erforderlich sind. +
- +
-   # vim /​etc/​ansible/​beispiel.yml +
-<file yaml /​etc/​ansible/​beispiel.yml>​--- #YAML start Beispielsscript zur Installation und Konfiguration eines Mailservers +
-    name: install and configure MX +
-    hosts: mxtest.dmz.mailserver.guru +
-    become: yes +
- +
-    vars:  +
-       ​mx_port_value : 25 +
-    +
-    tasks: +
-    -name: Install Postfix +
-       yum: <code to install the MX> +
-     +
-    -name: Ensure the installed service is enabled and running +
-    service: +
-      name: <your service name> +
- +
-… #YAML end syntax +
-</​file>​ +
- +
-==== Facts ==== +
-Ansible ermittelt bei jedem Aufruf Systeminformationen des jeweiligen Zielsystems. Im Bezug auf Ansible werden diese Systeminformationen auch als **facts** bezeichnet. In unseren **[[#​playbooks|Playbooks]]** auf die wir nun gleich noch eingehender eingehen werden, können wir dann später noch gezielt zugreifen. In unseren Playbooks können wir dann gezielt auf diesen Daten zugreifen, um z.B. maßgeschneiderte Konfigurationen,​ basierend auf genau diese facts (Hosteinstellungen) erzeugen lassen.  +
- +
-Wir können uns die facts eines Zielhost z.B. mit folgendem Befehl anzeigen lassen. Wir haben die Option ''​%%--%%ask-become-pass''​ angegeben, da unser Zielsystem einige Daten nur preisgibt, sofern der User auch entsprechende root-Rechte besitzt. Die Ausgabe hier wurde entsprechend gekürzt +
-   $ ansible centos8 --ask-become-pass -m setup +
- +
-<​html><​pre class="​code">​ +
-<font style="​color:​ rgb(0, 0, o)"><​b>​BECOME password:</​font>​ +
-<font style="​color:​ rgb(25, 100, 5)">​www8.dmz.nausch.org | SUCCESS => { +
-    "​ansible_facts":​ { +
-        "​ansible_all_ipv4_addresses":​ [ +
-            "​10.10.10.90",​ +
-            "​10.0.0.90"​ +
-        ], +
-        "​ansible_all_ipv6_addresses":​ [ +
-            "​fe80::​d4bb:​cb5:​9a09:​a808",​ +
-            "​fe80::​6d8:​6bbc:​a9e9:​449e"​ +
-        ], +
-        "​ansible_apparmor":​ { +
-            "​status":​ "​disabled"​ +
-        }, +
-        "​ansible_architecture":​ "​x86_64",​ +
-        "​ansible_bios_date":​ "​01/​01/​2011",​ +
-        "​ansible_bios_version":​ "​0.5.1",​ +
- +
-... +
- +
-... +
-        "​ansible_system_capabilities_enforced":​ "​True",​ +
-        "​ansible_system_vendor":​ "Red Hat",​ +
-        "​ansible_uptime_seconds":​ 410582, +
-        "​ansible_user_dir":​ "/​root",​ +
-        "​ansible_user_gecos":​ "​root",​ +
-        "​ansible_user_gid":​ 0, +
-        "​ansible_user_id":​ "​root",​ +
-        "​ansible_user_shell":​ "/​bin/​bash",​ +
-        "​ansible_user_uid":​ 0, +
-        "​ansible_userspace_architecture":​ "​x86_64",​ +
-        "​ansible_userspace_bits":​ "​64",​ +
-        "​ansible_virtualization_role":​ "​guest",​ +
-        "​ansible_virtualization_type":​ "​kvm",​ +
-        "​discovered_interpreter_python":​ "/​usr/​libexec/​platform-python",​ +
-        "​gather_subset":​ [ +
-            "​all"​ +
-        ], +
-        "​module_setup":​ true +
-    }, +
-    "​changed":​ false +
-}</​font></​b></​pre>​ +
-</​html>​ +
- +
- +
-Da die Abfrage/​Ausgabe aller facts auf Grund der vielen Daten schnell unübersichtlich werden kann, ist es auch möglich sich nur einen bestimmten Teilbereich anzeigen zu lassen. Im nachfolgenden Beispiel lassen wir uns z.B. nur Speicherrelevante facts anzeigen: +
-   # ansible centos8 --ask-become-pass -m setup -a '​filter=ansible_mem*'​ +
- +
-<​html><​pre class="​code">​ +
-<font style="​color:​ rgb(0, 0, o)"><​b>​BECOME password:</​font>​ +
-<font style="​color:​ rgb(25, 100, 5)">​www8.dmz.nausch.org | SUCCESS => { +
-    "​ansible_facts":​ { +
-        "​ansible_memfree_mb":​ 7203, +
-        "​ansible_memory_mb":​ { +
-            "​nocache":​ { +
-                "​free":​ 7517, +
-                "​used":​ 294 +
-            }, +
-            "​real":​ { +
-                "​free":​ 7203, +
-                "​total":​ 7811, +
-                "​used":​ 608 +
-            }, +
-            "​swap":​ { +
-                "​cached":​ 0, +
-                "​free":​ 4095, +
-                "​total":​ 4095, +
-                "​used":​ 0 +
-            } +
-        }, +
-        "​ansible_memtotal_mb":​ 7811, +
-        "​discovered_interpreter_python":​ "/​usr/​libexec/​platform-python"​ +
-    }, +
-    "​changed":​ false +
-}</​font></​b></​pre>​ +
-</​html>​ +
- +
-==== Variablen ==== +
-Variablen in Playbooks sind der Verwendung von Variablen in jeder anderen Programmiersprache sehr ähnlich. Mit Hilfe von Variablen können wir einfach wiederkehrende Werteangaben einmal definieren und später reicht es dann jeweils auf diese Definition zu referenzieren. Ferner ist es auch möglich Variablen auf Grund einer Bedingung zu setzen. +
- +
-So können wir zum Beispiel die Variable **''​DNS_port''​** definieren und dieser dem Wert **53** zuweisen. Diese Variable und natürlich auch den zugehörigen Wert können wir dann in unserem Playbook überall dort Verwenden, wo wir später die VAriable **''​{{dns_port}}''​** verwenden. ​  +
-Die zugehörige Definition in einem unserer Playbooks würde dann wie folgt aussehen. +
-<code yaml>​--- +
-  - hosts : dns.dmz.mailserver.guru  +
-  vars: +
-    dns_port : 53  +
-</​code>​  +
- +
-Im nachfolgednen Beispiel wollen wir eine Variable fallbezogen setzen. +
-<code yaml>​--- +
-block:  +
-   - name: Install bind Nameserver-Daemon  +
-      action: >  +
-      yum name = "​demo-nds1"​ state = present  +
-      register: Output  +
-           +
-   ​always:​  +
-      - debug:  +
-         msg:  +
-            - "​Install bind task ended with message: {{Output}}"​  +
-            - "​Installed bind  - {{Output.changed}}"​  +
- +
-</​code>​ +
-In diesem Beispiel haben wir die Variable ''​**output**''​ verwendet. Sehen wir uns nun dazu die einzelnen Definitionen (**keywords**) etwas genauer an: +
-  - **block** : Ansible syntax zur Ausführung des nachfolgenden Code-Blocks. +
-  - **name** :  Relevanter Name des Blocks - Dieser wird bei der Protokollierung verwendet und hilft bei der Fehlersuche,​ wenn alle Blöcke erfolgreich ausgeführt wurden. +
-  - **action** : Der Code neben dem Action-Tag ist die auszuführende Aufgabe. Die action wiederum ist ein Ansible-Schlüsselwort,​ das in yaml verwendet wird. +
-  - **register** : Die Ausgabe der Aktion wird mit dem Register-Schlüsselwort registriert und Output ist der Variablenname,​ der die Aktionsausgabe enthält. +
-  - **always** : Dies ist ein Ansible-Schlüsselwort,​ das angibt, dass die Aktion immer ausgeführt werden soll. +
-  - **msg** :  Zeigt die definierte Meldung an. +
- +
-**__Verwendung der Variable %%{{%%Output%%}}%%__**:​ \\ +
-Zunächst wird der wert der Variable **Output** ermittelt. Außerdem wird der Wert der Ausgabevariablen ausgegeben, so wie er im Abschnitt **''​msg''​** verwendet wird.  +
- +
-Zusätzlich kann man einer Variable noch eine sog. Sub-Eigenschaft zuweisen; so wird in dem gezeigten Fall erfolgt die Ausgabe nur, wenn sich die Ausgabe auch wirklich geändert hat, die Bedingung also erfüllt worden ist. +
- +
-==== Blöcke ==== +
-Ein Playbook wird meist in einzelen Abschnitte und Code-Blöcken unterteilt. Somit ist ein Playbook zum einen leichter für den Admin les- und handelbar. Ferner hilft das Schreiben der spezifischen Anweisung in Blöcken, Funktionalitäten zu trennen, sie bei Bedarf mit Ausnahmeregeln zu behandeln oder in den nachfolgend gezeihgten Schleifenbedingungen abzuarbeiten. +
- +
-==== Ausnahmeregelung und -behandlung ==== +
-Die Ausnahmebehandlung in Ansible ist ähnlich der Ausnahmebehandlung in jeder Programmiersprache. Nachfolgendes Beispiel soll dies entsprechend illustrieren:​ +
- +
-<code yaml>​--- +
-tasks:  +
-   - name: Name des auszuführenden tasks +
-      always:  +
-         - debug: msg = "​Debugmeldung,​ welche immer ausgegben und immer geloggt werden soll."  +
- +
-      block:  +
-         - debug: msg = '​Debugmeldung die ausgegeben und geloggt werden soll '  +
-         - command: <Befehl der ausgeführt werden soll>  +
-       +
-      rescue:  +
-         - debug: msg = '​Folgender Ausnahmezustand wurde festgestellt und wird auch ausgegeben '  +
-         - command: <Rescue Befehle die ausgeführt werden, sofern obige Ausnahme auftrat.  +
- +
-</​code>​ +
-Auch hier werfen wir nun einen Blick auf die einzelnen Definitionen:​ +
-  - **always** und **rescue** sind spezifische Schlüsselwörter für Ausnahmebedingungen und -regelungen. +
-  - **always** Wird immer vorbehaltlos ausgeführt. +
-  - **block** definiert die shell Befehel die auf dem Zielsystem ausdgeführt werden sollen. \\ Wenn der Befehl, der innerhalb des block-Abschnittes definiert wurde, fehlschlägt,​ dann erreicht die Ausführung den Rescue-Block und er wird ausgeführt. Sofern es keinen Fehler m Befehl unter Block-Definition gab, dann wird der Rescue-Block __nicht__ ausgeführt! +
- +
-==== Schleifen ==== +
-Das nachfolgende Konfigurationsbeispiel,​ bzw. ein Auszug aus einem Playbook, zeigt, wie **[[https://​docs.ansible.com/​ansible/​latest/​user_guide/​playbooks_loops.html|Schleifenbedingungen in Ansible]]** gesetzt und verarbeitet werden. In diesem Beispiel wollen wir alle **html**-Dateien eines Verzeichnisses auf einem Webserver, bzw. genauer gesagt aus dessen DOCUMENT_ROOT kopieren. +
- +
-Die meisten der Befehle, die im folgenden Beispiel verwendet werden, haben wir uns zuvor schon genauer angesehen, so dass wir uns hier auf die Verwendung von Schleifen konzentrieren. +
- +
-<code yaml>--- #Ansible Schleifenoperation  +
-- hosts: www-n.dmz.nausch.org  +
-   ​tasks:​  +
-      - name: Install Apache  +
-      shell: "ls *.html"​  +
-      register: output  +
-      args:  +
-         ​chdir:​ /​var/​www/​html/​demo/​webseite  +
-       +
-      - file:  +
-         src: '/​tmp/​{{ item }}'  +
-         dest: ''/​var/​www/​html/​demo/​webseite/​{{ item }}'  +
-         ​state:​ link  +
-      loop: " {{ output.stdout_lines }} " +
-</​code>​ +
- +
-  * Zunächst wird also der **'​shell'​-Befehl** ''​**ls *.html**''​ aufgerufen. Er listet also alle HTML-Dateien im entsprechenden Verzeichnis auf. +
-  * Die Ausgabe dieses Befehls wird der Variablen mit dem Namen **''​output''​** übergeben. +
-  * Mit Hilfe der Syntax **''​loop''​** wird eine Schleifenbedingung definiert. +
-  * Mit der Codezeile **''​loop:​ %%"​%% ​ %%{{%% output.stdout_lines %%}}%% %%"​%%''​** wird der Inhalt von ''​output.stdout_lines''​ Zeilenweise eingelesen und verarbeitet bzw. genauer gesagt zeilenweise an Ansible übergeben. +
- +
-==== Bedingungen ==== +
-Bedingungen verwendet man immer dann, wenn man einen bestimmten Schritt nur dann ausführen möchte, wenn zuvor eine definierte Bedingung erfüllt worden ist. +
- +
-Im nachfolgenden Beispiel wird die Nachricht ''​gewünschte OS vorhanden''​ nur ausgegeben wenn die Variable **''​os''​** den Wert ''​RedHat''​ beinhaltet. Das Keyword **when** kann dabei mit den bekannten logischen Verknüpfungen **logisch und** bzw. **logisch oder** verwendet werden. +
- +
-<code yaml>--- #Beispiel für eine Bedingung +
-- hosts: all  +
-   vars:  +
-      os: "​RedHat"​  +
-   ​tasks:​  +
-      - name: Testing Ansible Variable  +
-      debug:  +
-         msg: "​gewünschte OS vorhanden"​  +
-         when: os == "​RedHat"​  +
-</​code>​ +
- +
-==== adhoc - Befehle ==== +
-Ad-hoc-Befehle sind Befehle, die einzeln auf der Konsole ausgeführt werden, unabhängig davon, ob ein entsprechende Playbook definiert wurde. +
- +
-So könnte man zum Beispiel einen reboot aller definierten Server anstoßen, in dem man den passendden adhoc-Befehl mit HIlfe des Programms ''​**/​usr/​bin/​ansible**''​ ausführt. Hierzu werden wir uns nachfolgend gleich einmal ein entsprechendes Beispiel etwas genauer ansehen. +
- +
-Der Befehl **''​ansible-playbook''​** wird für das Konfigurationsmanagement und das Deployment verwendet. Wird beim Aufruf vin **''​ansible''​** keine zusätzlichen Befehle und Optionen angebgeben bzw. beim Aufruf von **''​ansible-playbook''​** **__kein__** Playbook verwendet gibt der Befehl alle zur Verfügung stehenden Optionen aus.  +
- +
-Bsp.: +
-   # ​ ansible-playbook +
- +
-<​code>​Usage:​ ansible-playbook [options] playbook.yml [playbook2 ...] +
- +
-Runs Ansible playbooks, executing the defined tasks on the targeted hosts. +
- +
-Options: +
-  --ask-vault-pass ​     ask for vault password +
-  -C, --check ​          ​don'​t make any changes; instead, try to predict some +
-                        of the changes that may occur +
-  -D, --diff ​           when changing (small) files and templates, show the +
-                        differences in those files; works great with --check +
-  -e EXTRA_VARS, --extra-vars=EXTRA_VARS +
-                        set additional variables as key=value or YAML/JSON, if +
-                        filename prepend with @ +
-  --flush-cache ​        clear the fact cache +
-  --force-handlers ​     run handlers even if a task fails +
-  -f FORKS, --forks=FORKS +
-                        specify number of parallel processes to use +
-                        (default=5) +
-  -h, --help ​           show this help message and exit +
-  -i INVENTORY, --inventory=INVENTORY,​ --inventory-file=INVENTORY +
-                        specify inventory host path or comma separated host +
-                        list. --inventory-file is deprecated +
-  -l SUBSET, --limit=SUBSET +
-                        further limit selected hosts to an additional pattern +
-  --list-hosts ​         outputs a list of matching hosts; does not execute +
-                        anything else +
-  --list-tags ​          list all available tags +
-  --list-tasks ​         list all tasks that would be executed +
-  -M MODULE_PATH,​ --module-path=MODULE_PATH +
-                        prepend colon-separated path(s) to module library +
-                        (default=[u'/​root/​.ansible/​plugins/​modules',​ +
-                        u'/​usr/​share/​ansible/​plugins/​modules'​]) +
-  --new-vault-id=NEW_VAULT_ID +
-                        the new vault identity to use for rekey +
-  --new-vault-password-file=NEW_VAULT_PASSWORD_FILES +
-                        new vault password file for rekey +
-  --skip-tags=SKIP_TAGS +
-                        only run plays and tasks whose tags do not match these +
-                        values +
-  --start-at-task=START_AT_TASK +
-                        start the playbook at the task matching this name +
-  --step ​               one-step-at-a-time:​ confirm each task before running +
-  --syntax-check ​       perform a syntax check on the playbook, but do not +
-                        execute it +
-  -t TAGS, --tags=TAGS ​ only run plays and tasks tagged with these values +
-  --vault-id=VAULT_IDS ​ the vault identity to use +
-  --vault-password-file=VAULT_PASSWORD_FILES +
-                        vault password file +
-  -v, --verbose ​        ​verbose mode (-vvv for more, -vvvv to enable +
-                        connection debugging) +
-  --version ​            show program'​s version number and exit +
- +
-  Connection Options: +
-    control as whom and how to connect to hosts +
- +
-    -k, --ask-pass ​     ask for connection password +
-    --private-key=PRIVATE_KEY_FILE,​ --key-file=PRIVATE_KEY_FILE +
-                        use this file to authenticate the connection +
-    -u REMOTE_USER,​ --user=REMOTE_USER +
-                        connect as this user (default=None) +
-    -c CONNECTION, --connection=CONNECTION +
-                        connection type to use (default=smart) +
-    -T TIMEOUT, --timeout=TIMEOUT +
-                        override the connection timeout in seconds +
-                        (default=10) +
-    --ssh-common-args=SSH_COMMON_ARGS +
-                        specify common arguments to pass to sftp/​scp/​ssh (e.g. +
-                        ProxyCommand) +
-    --sftp-extra-args=SFTP_EXTRA_ARGS +
-                        specify extra arguments to pass to sftp only (e.g. -f, +
-                        -l) +
-    --scp-extra-args=SCP_EXTRA_ARGS +
-                        specify extra arguments to pass to scp only (e.g. -l) +
-    --ssh-extra-args=SSH_EXTRA_ARGS +
-                        specify extra arguments to pass to ssh only (e.g. -R) +
- +
-  Privilege Escalation Options: +
-    control how and which user you become as on target hosts +
- +
-    -s, --sudo ​         run operations with sudo (nopasswd) (deprecated,​ use +
-                        become) +
-    -U SUDO_USER, --sudo-user=SUDO_USER +
-                        desired sudo user (default=root) (deprecated,​ use +
-                        become) +
-    -S, --su            run operations with su (deprecated,​ use become) +
-    -R SU_USER, --su-user=SU_USER +
-                        run operations with su as this user (default=None) +
-                        (deprecated,​ use become) +
-    -b, --become ​       run operations with become (does not imply password +
-                        prompting) +
-    --become-method=BECOME_METHOD +
-                        privilege escalation method to use (default=sudo),​ +
-                        valid choices: [ sudo | su | pbrun | pfexec | doas | +
-                        dzdo | ksu | runas | pmrun ] +
-    --become-user=BECOME_USER +
-                        run operations as this user (default=root) +
-    --ask-sudo-pass ​    ask for sudo password (deprecated,​ use become) +
-    --ask-su-pass ​      ask for su password (deprecated,​ use become) +
-    -K, --ask-become-pass +
-                        ask for privilege escalation password</​code>​ +
- +
-Zusätzliche Hinweise zum Befehl **''​ansible-playbook''​** finden sich in der zugehörigen manpage. +
-<​code>​ANSIBLE-PLAYBOOK(1) ​                        ​System administration commands ​                       ANSIBLE-PLAYBOOK(1) +
- +
-NAME +
-       ​ansible-playbook - Runs Ansible playbooks, executing the defined tasks on the targeted hosts. +
- +
-SYNOPSIS +
-       ​ansible-playbook [options] playbook.yml [playbook2 ...] +
- +
-DESCRIPTION +
-       the tool to run Ansible playbooks, which are a configuration and multinode deployment system. See the project +
-       home page (https://​docs.ansible.com) for more information. +
- +
-COMMON OPTIONS +
-       ​--ask-su-pass +
-           ask for su password (deprecated,​ use become) +
- +
-       ​--ask-sudo-pass +
-           ask for sudo password (deprecated,​ use become) +
- +
-       ​--ask-vault-pass +
-           ask for vault password +
- +
-       ​--become-method BECOME_METHOD +
-           ​privilege escalation method to use (default=sudo),​ valid choices: [ sudo | su | pbrun | pfexec | doas | +
-           dzdo | ksu | runas | pmrun ] +
- +
-       ​--become-user BECOME_USER +
-           run operations as this user (default=root) +
- +
-       ​--flush-cache +
-           clear the fact cache +
- +
-       ​--force-handlers +
-           run handlers even if a task fails +
- +
-       ​--list-hosts +
-           ​outputs a list of matching hosts; does not execute anything else +
- +
-       ​--list-tags +
-           list all available tags +
- +
-       ​--list-tasks +
-           list all tasks that would be executed +
- +
-       ​--new-vault-id NEW_VAULT_ID +
-           the new vault identity to use for rekey +
- +
-       ​--new-vault-password-file +
-           new vault password file for rekey +
- +
-       ​--private-key,​ --key-file +
-           use this file to authenticate the connection +
- +
-       ​--scp-extra-args SCP_EXTRA_ARGS +
-           ​specify extra arguments to pass to scp only (e.g. -l) +
- +
-       ​--sftp-extra-args SFTP_EXTRA_ARGS +
-           ​specify extra arguments to pass to sftp only (e.g. -f, -l) +
- +
-       ​--skip-tags +
-           only run plays and tasks whose tags do not match these values +
-           ​specify common arguments to pass to sftp/​scp/​ssh (e.g. ProxyCommand) +
- +
-       ​--ssh-extra-args SSH_EXTRA_ARGS +
-           ​specify extra arguments to pass to ssh only (e.g. -R) +
- +
-       ​--start-at-task START_AT_TASK +
-           start the playbook at the task matching this name +
- +
-       ​--step +
-           ​one-step-at-a-time:​ confirm each task before running +
- +
-       ​--syntax-check +
-           ​perform a syntax check on the playbook, but do not execute it +
- +
-       ​--vault-id +
-           the vault identity to use +
- +
-       ​--vault-password-file +
-           vault password file +
- +
-       ​--version +
-           show program’s version number and exit +
- +
-       -C, --check +
-           ​don’t make any changes; instead, try to predict some of the changes that may occur +
- +
-       -D, --diff +
-           when changing (small) files and templates, show the differences in those files; works great with --check +
- +
-       -K, --ask-become-pass +
-           ask for privilege escalation password +
- +
-       -M, --module-path +
-           ​prepend colon-separated path(s) to module library (default=[u'/​home/​jenkins/​.ansible/​plugins/​modules',​ +
-           ​u'/​usr/​share/​ansible/​plugins/​modules'​]) +
- +
-       -R SU_USER, --su-user SU_USER +
-           run operations with su as this user (default=None) (deprecated,​ use become) +
- +
-       -S, --su +
-           run operations with su (deprecated,​ use become) +
- +
-       -T TIMEOUT, --timeout TIMEOUT +
-           ​override the connection timeout in seconds (default=10) +
- +
-       -U SUDO_USER, --sudo-user SUDO_USER +
-           ​desired sudo user (default=root) (deprecated,​ use become) +
- +
-       -b, --become +
-           run operations with become (does not imply password prompting) +
- +
-       -c CONNECTION, --connection CONNECTION +
-           ​connection type to use (default=smart) +
- +
-       -e, --extra-vars +
-           set additional variables as key=value or YAML/JSON, if filename prepend with @ +
- +
-       -f FORKS, --forks FORKS +
-           ​specify number of parallel processes to use (default=5) +
- +
-       -h, --help +
-           show this help message and exit +
- +
- +
-       -b, --become +
-           run operations with become (does not imply password prompting) +
- +
-       -c CONNECTION, --connection CONNECTION +
-           ​connection type to use (default=smart) +
- +
-       -e, --extra-vars +
-           set additional variables as key=value or YAML/JSON, if filename prepend with @ +
- +
-       -f FORKS, --forks FORKS +
-           ​specify number of parallel processes to use (default=5) +
- +
-       -h, --help +
-           show this help message and exit +
- +
-       -i, --inventory,​ --inventory-file +
-           ​specify inventory host path or comma separated host list. --inventory-file is deprecated +
- +
-       -k, --ask-pass +
-           ask for connection password +
- +
-       -l SUBSET, --limit SUBSET +
-           ​further limit selected hosts to an additional pattern +
- +
-       -s, --sudo +
-           run operations with sudo (nopasswd) (deprecated,​ use become) +
- +
-       -t, --tags +
-           only run plays and tasks tagged with these values +
- +
-       -u REMOTE_USER,​ --user REMOTE_USER +
-           ​connect as this user (default=None) +
- +
-       -v, --verbose +
-           ​verbose mode (-vvv for more, -vvvv to enable connection debugging) +
- +
-ENVIRONMENT +
-       The following environment variables may be specified. +
- +
-       ​ANSIBLE_CONFIG — Override the default ansible config file +
- +
-       Many more are available for most options in ansible.cfg +
- +
-FILES +
-       /​etc/​ansible/​ansible.cfg — Config file, used if present +
- +
-       ​~/​.ansible.cfg — User config file, overrides the default config if present +
- +
-AUTHOR +
-       ​Ansible was originally written by Michael DeHaan. See the AUTHORS file for a complete list of contributors. +
- +
-COPYRIGHT +
-       ​Copyright © 2017 Red Hat, Inc | Ansible. Ansible is released under the terms of the GPLv3 License. +
- +
-SEE ALSO +
-       ​ansible(1),​ ansible-config(1),​ ansible-console(1),​ ansible-doc(1),​ ansible-galaxy(1),​ ansible-inventory(1),​ +
-       ​ansible-pull(1),​ ansible-vault(1) +
- +
-       ​Extensive documentation is available in the documentation site: http://​docs.ansible.com. IRC and mailing list +
-       info can be found in file CONTRIBUTING.md,​ available in: https://​github.com/​ansible/​ansible +
- +
-Ansible 2.4.2.0 ​                                      ​11/​29/​2017 ​                                 ANSIBLE-PLAYBOOK(1) +
-</​code>​ +
- +
-Will man z.B. die installierte und Verwendete Version von Ansible abfragen gibt man die Opion **%%--%%version** beim Aufruf des Befehls **''​ansible''​** an. +
-   # ansible --version +
- +
-<​code>​ansible 2.9.2 +
-  config file = /​etc/​ansible/​ansible.cfg +
-  configured module search path = ['/​root/​.ansible/​plugins/​modules',​ '/​usr/​share/​ansible/​plugins/​modules'​] +
-  ansible python module location = /​usr/​lib/​python3.7/​site-packages/​ansible +
-  executable location = /​usr/​bin/​ansible +
-  python version = 3.7.5 (default, Dec 15 2019, 17:54:26) [GCC 9.2.1 20190827 (Red Hat 9.2.1-1)]</​code>​ +
- +
-Sehen wir uns nun an, wie wir die zuvor gestelle Aufgabe des gleichzeitigen Neustarts von einer Gruppe Server parallelisiert anstoßen können. Im folgenden Beispiel wollen wir in der **Gruppe** **''​intranet''​** alle Server neu starten und dabei statt der default-mäßigen parallelen Abarbeitung von **5** parallelen Prozessen **15** verwenden. +
-   $ ansible intranet -a "/​usr/​sbin/​reboot"​ -f 15 +
- +
-Genau so ist es natürlich möglich parallel auf mehreren Maschinen eine Date (um)zukopieren. Im nachfolgenden Beispiel kopieren wir auf allen DMZ-Maschinen die Datei **''/​etc/​yum.repos.d/​mailserver.guru.repo''​** in das Zielverzeichnis **''/​tmp''​** und geben dabei einen neuen Dateinamen an. +
-   $ ansible dmz -m copy -a "src = /​etc/​yum.repos.d/​mailserver.guru.repo dest = /​tmp/​mailserver.guru.repo.backup"​ +
- +
-Ebenso kann man natürlich auch auf allen Webservern (Gruppe **www**) z.B. ein spezifisches Verzeichnis anlegen lassen. +
-   $ ansible www -m file -a "dest = /​var/​www/​html/​new_website mode = 755 owner = apache group = apache state = directory"​ +
- +
-Natürlich kann man auf diesem Wege auch ganze Ordnerstrukturen und Dateien auf mehreren Maschinen der Gruppe **intranet** löschen. +
-   $ ansible intranet -m file -a "dest = /​home/​admin1/​.ssh/​authorized_keys state = absent"​ +
- +
-Aber nicht nur für die Ausführung von Dateibefehlen kann über adhoc-Kommandos erfolgen, sondern z.B. auch Befehle des Paketmanagers **dnf** bzw. auf älteren Systemen **yum**. +
- +
-Der folgende Befehl prüft z.B. ob das Paket **''​bash-completion''​** auf allen Servern der Gruppe **all** __**nicht**__ installiert wurde: +
-   $ ansible all -m yum -a "name = bash-completion state = absent"​  +
- +
-Im folgenden Beispiel wollen wir wissen, ob auf allen Systemen im Intranet der Timeserver-Daemon **[[centos:​ntp_c7|chrony]]** installiert wurde. +
-   $ ansible intranet -m yum -a "name = chrony state = present"​ +
- +
-Wollen wir zusätzlich noich wissen, ob auch die letzte Version installiert wurde, benutzen wir folgenden Aufruf: +
-   $ ansible intranet -m yum -a "name = chrony state = latest"​  +
- +
- +
- +
- +
- +
- +
-===== Installation ===== +
-Nachdem wir uns nun eigehend mit den Grundlagen zu Ansible beschäftigt haben, wollen wir nun noch das eigentliche Paket **ansible** installieren. +
- +
-Die Installation von Ansible auf unserer Admin-Workstation,​ von der wir unsere Zielsysteme aus orchestrieren wollen, gestaltet sich dank unseres Paket-Managers **dnf** bzw. **yum** entsprechend einfach. Im Grunde reicht dabei die Installation des Paketes **//​ansible//​**.  +
-   # dnf install ansible ​ -y +
- +
- +
-==== RPM-Paket ansible ==== +
-Einen Überblick über das Paket kann man mit Hilfe des Befehls **''​rpm -qi''​** sich anzeigen lassen. +
-   # rpm -ai ansible +
-<​code>​Name ​       : ansible +
-Version ​    : 2.9.2 +
-Release ​    : 1.fc31 +
-Architecture:​ noarch +
-Install Date: Sa 21 Dez 2019 20:38:05 CET +
-Group       : Unspecified +
-Size        : 102078689 +
-License ​    : GPLv3+ +
-Signature ​  : RSA/SHA256, Mo 09 Dez 2019 18:59:12 CET, Key ID 50cb390b3c3359c4 +
-Source RPM  : ansible-2.9.2-1.fc31.src.rpm +
-Build Date  : So 08 Dez 2019 21:42:23 CET +
-Build Host  : buildvm-aarch64-24.arm.fedoraproject.org +
-Packager ​   : Fedora Project +
-Vendor ​     : Fedora Project +
-URL         : http://​ansible.com +
-Bug URL     : https://​bugz.fedoraproject.org/​ansible +
-Summary ​    : SSH-based configuration management, deployment, and task execution system +
-Description : +
-Ansible is a radically simple model-driven configuration management,​ +
-multi-node deployment, and remote task execution system. Ansible works +
-over SSH and does not require any software or daemons to be installed +
-on remote nodes. Extension modules can be written in any language and +
-are transferred to managed machines automatically.</​code>​ +
- +
-Interessieren wir uns für eine Datei- und Ordnerliste,​ werden wir wie immer mit folgendem Aufruf fündig: +
-   # rpm -qil ansible +
- +
-===== weitere Schritte zur Installation und Konfiguration ===== +
-Nachdem wir uns nun eingehend mit den **[[#​grundlagen|Grundlagen]]** und auch schon das benötigte Programmpaket auf unserer Admin-Workstation zur orchestrierung **[[#​installation|installiert haben]]**, machen wir uns nun an die Konfguration von Ansible und wagen uns an die ersten Playbooks im Kapitel **[[centos:​ansible:​first| Erste Schritte Rund um Ansible]]** heran.  +
- +
-====== Links ====== +
-  * **⇒ [[centos:​ansible:​first|Weiter zum Kapitel "Erste Schritte Rund um Ansible"​]]** +
-  * **[[wiki:​start|Zurück zu >>​Projekte und Themenkapitel<<​]]** +
-  * **[[http://​dokuwiki.nausch.org/​doku.php/​|Zurück zur Startseite]]** +
  
 +  * [[centos:​ansible:​basics|Ansible - Grundlagen]]
 +  * [[centos:​ansible:​first|Erste Schritte Rund um Ansible]]
 +  * [[centos:​ansible:​playbooks1|Ansible - Playbookbeispiele]]
 +  * [[centos:​ansible:​detail|Ansible - Erweiterte Konfigurationsbeispiele]]
 +  * [[centos:​ansible:​pxe|Installation eines Ansible-Orchestrator-Management-Hosts mit Hilfe eines Kickstartfiles für CentOS 8.x (PXE-Server)]]
 +  * [[centos:​ansible:​ffmuc-rpb4-ol|Bau eines Freifunk-Offloaders auf Basis eines Raspberry 4B]]
  
  
  • centos/ansible/start.1579038413.txt.gz
  • Zuletzt geändert: 14.01.2020 21:46.
  • von django