Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
ansible [2018/09/27 13:01] root [Aufbau] |
ansible [2018/10/04 22:34] (aktuell) root [Inventory] |
||
---|---|---|---|
Zeile 6: | Zeile 6: | ||
|Tasks|Aufruf eines Moduls um eine bestimmte Aufgabe durchzuführen| | |Tasks|Aufruf eines Moduls um eine bestimmte Aufgabe durchzuführen| | ||
|Playbook|Sammlung von Tasks die als ein Satz ausgeführt werden| | |Playbook|Sammlung von Tasks die als ein Satz ausgeführt werden| | ||
+ | |Roles|Roles erlaubt es mehrere Playbooks zu einer Rolle zusammenzufassen. \\ \\ Dadurch lassen sich Playbooks thematisch aufteilen, gleichzeitig aber zusammenfassen.0\\ Die Roles können wiederum in anderen Playbooks genutz werden. \\ Sinnvoll zum Beispiel um Systeme aufzusetzen -> ein System kann dabei mehrere Rollen haben z.B. Basissystem + Webserver + Datenbankserver die jeweils in eigenen Rollen definiert werden können| | ||
====== Ad-Hoc-Kommandos ====== | ====== Ad-Hoc-Kommandos ====== | ||
Zeile 30: | Zeile 31: | ||
* Geschrieben in YAML | * Geschrieben in YAML | ||
- | * oberste Ebene besteht aus einem Dictionary mit mehreren Einträgen | + | * oberste Ebene besteht aus einer Liste von Plays |
+ | * darunter folgt ein Dictionary mit den Eigenschaften des Plays als Dictionary-Einträge: | ||
+ | * name des Plays | ||
+ | * hosts | ||
* tasks -> enthält die Tasks | * tasks -> enthält die Tasks | ||
* handlers -> die Handlers | * handlers -> die Handlers | ||
+ | < | ||
+ | - name: < | ||
+ | hosts: <Liste der Hosts für die das Play ausgeführt werden soll> | ||
+ | vars: | ||
+ | < | ||
+ | < | ||
+ | remote_user: | ||
+ | | ||
+ | tasks: | ||
+ | - name: < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | |||
+ | Einige Keywords auf dieser Ebene: | ||
+ | |||
+ | ^Keyword ^Bedeutung ^ | ||
+ | |remote-user|Als welcher Benutzer sich auf dem Remote-System eingeloggt wird| | ||
+ | |become|Werde root nach dem Login. \\ \\ Wert: yes| | ||
==== Tasks ==== | ==== Tasks ==== | ||
Zeile 63: | Zeile 87: | ||
Dienen dazu nach dem alle Tasks durch sind notwendige Dinge zu tun: wie Neustarts von Services usw. | Dienen dazu nach dem alle Tasks durch sind notwendige Dinge zu tun: wie Neustarts von Services usw. | ||
- | * Werden durch notify-Eintrag in tasks getriggered | + | * Werden durch notify-Eintrag in tasks getriggered |
* werden aber erst nach dem Abarbeiten aller Tasks ausgeführt | * werden aber erst nach dem Abarbeiten aller Tasks ausgeführt | ||
* werden nur einmal ausgeführt -> egal wieviele Tasks sie getriggered haben | * werden nur einmal ausgeführt -> egal wieviele Tasks sie getriggered haben | ||
Zeile 77: | Zeile 101: | ||
< | < | ||
< | < | ||
- | notify: <handler-Name der Benachrichtigt werden soll> | + | notify: <somename> |
handlers: | handlers: | ||
- | - name: | + | - name: < |
+ | < | ||
+ | < | ||
+ | < | ||
</ | </ | ||
+ | |||
+ | |||
+ | Der Handler wird oben im zweiten Task aufgerufen (die notify-Zeile). \\ In der Handler-Konfiguration existiert dann ein Handler mit dem entsprechenden Namen. \\ Die Handler-Konfiguration entspricht ansonstem der eines Tasks. | ||
====== Module ====== | ====== Module ====== | ||
Zeile 111: | Zeile 141: | ||
* Der Gruppenname kann " | * Der Gruppenname kann " | ||
+ | |||
+ | |||
+ | ====== Roles ====== | ||
+ | |||
+ | Roles erlaubt es mehrere Playbooks zu einer Rolle zusammenzufassen. \\ \\ Dadurch lassen sich Playbooks thematisch aufteilen, gleichzeitig aber zusammenfassen.0\\ Die Roles können wiederum in anderen Playbooks genutz werden. \\ Sinnvoll zum Beispiel um Systeme aufzusetzen -> ein System kann dabei mehrere Rollen haben z.B. Basissystem + Webserver + Datenbankserver die jeweils in eigenen Rollen definiert werden können. | ||
+ | |||
+ | * jede Rolle ist eine Verzeichnisstruktur | ||
+ | ====== Optionen der Werkzeuge ====== | ||
+ | |||
+ | * Die gelisteten Optionen können in verschiedenen ansible-Werkzeugen genutzt werden | ||
+ | |||
+ | ^Option ^Beschreibung ^ | ||
+ | | -k / --ask-pass|Normalerweise erwartet ansible das ssh-Login per Key funktioniert. \\ Die Option sorgt dafür das dass Passwort abgefragt wird | | ||
+ | |-b / --become|Nach dem Login via ssh, führe die Befehle mit sudo aus| | ||
+ | |-K / --ask-become-pass|Im Zusmmenhang mit sudo (Option -b) - Frage interaktiv nach dem sudo-Passwort | | ||
+ | |||
+ | |||
+ | ====== Dateien ====== | ||
+ | |||
+ | ===== ansible.cfg ===== | ||
+ | |||
+ | * Zentrale Konfigurationsdatei | ||
+ | * / | ||
+ | * ~/ | ||
+ | |||
+ | |||
+ | |||
+ |