Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| centos:ansible:basics [28.06.2020 13:53. ] – [adhoc - Befehle] django | centos:ansible:basics [14.09.2022 11:31. ] (aktuell) – Seite in neuen Namespace verschoben django | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | ====== Ansible ====== | ||
| - | {{: | ||
| - | Einzelne Serversysteme mag man durchaus noch manuell einzeln installieren, | ||
| - | |||
| - | Doch was versteht man nun unter diesem Begriff Orchestrierung? | ||
| - | Die Anlehnung an Begrifflichkeiten aus der Musik ist hier ganz bewusst und nicht zufällig gewählt. | ||
| - | Die Sicht auf einzelne Service-/ | ||
| - | |||
| - | Bekannte Anwendungen rund um das Thema Automatisierung und Orchestrierung von Serversystemen-/ | ||
| - | |||
| - | - 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össten Vorteile von Ansible, sind die vorgefertigten " | ||
| - | - 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, | ||
| - | - 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:// | ||
| - | ===== 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:// | ||
| - | {{ : | ||
| - | |||
| - | === Gourav Shah - Ansible Playbook Essentials === | ||
| - | Ein weiteres sehr gutes Fachbuch zu Ansible in englischer Sprache ist das Buch **Ansible Playbook Essentials** von **//Gourav Shah//**, erhältlich als **[[https:// | ||
| - | {{ : | ||
| - | |||
| - | === online-Dokumentation === | ||
| - | Eine stets aktuelle Programm- und Projektdokumentation ist in der in der **Onlinebibliothek** unter : https:// | ||
| - | |||
| - | Folgende links sind immer eine gute Quelle, sich zu den Möglichkeiten Rund um Ansible zu informieren: | ||
| - | * **[[https:// | ||
| - | * **[[https:// | ||
| - | * **[[https:// | ||
| - | * **[[https:// | ||
| - | * **[[https:// | ||
| - | * **[[https:// | ||
| - | |||
| - | |||
| - | === Dokumentation (RPM) === | ||
| - | Vom Maintainer des Paketes **ansible** wird auch die zugehörige sehr umfangreiche Dokumentation in Form eines eigenen Paketes **// | ||
| - | 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 -qi ansible-doc | ||
| - | |||
| - | < | ||
| - | Version | ||
| - | Release | ||
| - | Architecture: | ||
| - | Install Date: Sa 21 Dez 2019 20:38:39 CET | ||
| - | Group : Unspecified | ||
| - | Size : 311719083 | ||
| - | License | ||
| - | Signature | ||
| - | 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 | ||
| - | Vendor | ||
| - | URL : http:// | ||
| - | Bug URL : https:// | ||
| - | Summary | ||
| - | 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</ | ||
| - | |||
| - | Eine Auflistung sämtlicher mitgelieferter Dateien erhält man durch Ergänzung der Option **'' | ||
| - | # rpm -qi ansible-doc | ||
| - | |||
| - | ==== Ansible Funktionsbeschreibung ==== | ||
| - | Das folgende Übersichtsskizze zeit die grundlegende Module und die die Funktionsweise von Ansible. | ||
| - | |||
| - | {{ : | ||
| - | |||
| - | /* | ||
| - | <uml> | ||
| - | package " | ||
| - | |||
| - | database "/ | ||
| - | frame " | ||
| - | | ||
| - | } | ||
| - | frame " | ||
| - | | ||
| - | [Host n] | ||
| - | } | ||
| - | | ||
| - | [Host 1] | ||
| - | [Host 2] | ||
| - | [Host 3] | ||
| - | | ||
| - | } | ||
| - | } | ||
| - | |||
| - | | ||
| - | |||
| - | } | ||
| - | |||
| - | cloud { | ||
| - | [Host " | ||
| - | [Host " | ||
| - | [Host " | ||
| - | } | ||
| - | |||
| - | cloud { | ||
| - | [Host " | ||
| - | } | ||
| - | |||
| - | AMN -right-> [Host " | ||
| - | AMN -down-> [Host " | ||
| - | AMN -down-> [Host " | ||
| - | AMN -down-> [Host " | ||
| - | </ | ||
| - | */ | ||
| - | |||
| - | |||
| - | 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, | ||
| - | |||
| - | 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, | ||
| - | |||
| - | 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:// | ||
| - | |||
| - | * **START/ | ||
| - | * **Bemerkungen**: | ||
| - | * **key-value** Wertepaare: \\ YAML verwendet ein einfaches Schlüssel-Wertepaar zur Darstellung der Daten. Zur Trennung zwischen Schlüssel und Wert wird ein **'':'' | ||
| - | db_host: | ||
| - | | ||
| - | | ||
| - | 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)</ | ||
| - | * **Listen**: \\ Zur Verwendung von Listen wird jeder Eintrag dieser Liste in einer eigenen Zeile, eingerückt um ein Leerzeichen beginnend mit einem **'' | ||
| - | kunden: | ||
| - | - 2017-DEAD-BEEF-0815 | ||
| - | - 2017-BAAD-C0DE-4221 | ||
| - | - 2018-900D-F00D-1967 | ||
| - | ... #YAML end syntax (optional)</ | ||
| - | * kombinierte **key-value** Wertepaare und **Listen**: \\ Natürlich können auch Kombinationen von Wertepaaren und Listen verwendet werden. \\ Bsp.: < | ||
| - | | ||
| - | | ||
| - | 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 | ||
| - | | ||
| - | - 4c: | ||
| - | - 4c: | ||
| - | - 4c: | ||
| - | - 4c: | ||
| - | ... #YAML end syntax (optional)</ | ||
| - | | ||
| - | | ||
| - | 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: | ||
| - | - 4c: | ||
| - | - 4c: | ||
| - | - 4c: | ||
| - | |||
| - | - mx_host: | ||
| - | | ||
| - | | ||
| - | 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: | ||
| - | - 4c: | ||
| - | - 4c: | ||
| - | - 4c: | ||
| - | ... #YAML end syntax (optional)</ | ||
| - | * **YAML-Formatierungen**: | ||
| - | hier haben wir | ||
| - | drei separate Textzeilen | ||
| - | | ||
| - | |||
| - | fold_newlines: | ||
| - | | ||
| - | in drei Zeilen getrennt formatiert wurde | ||
| - | wird diese als eine Zeile interprätiert</ | ||
| - | |||
| - | <WRAP center round tip 80%> | ||
| - | **YAML** spezifische Ausdrücke: \\ | ||
| - | |||
| - | Rund um YAML werden wir des öfteren über folgende Ausdrücke stolpern: | ||
| - | * **Service/ | ||
| - | * **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, | ||
| - | * **Playbook** : Dies ist eine **// | ||
| - | </ | ||
| - | |||
| - | Viele hilfreiche Informationen zur YAML-Notation sind in der **[[https:// | ||
| - | |||
| - | ==== Playbooks ==== | ||
| - | In diesem Abschnitt werden wir uns nun die **Playbooks**, | ||
| - | |||
| - | Playbooks sind die Dateien, in denen Ansible-Code im **[[# | ||
| - | |||
| - | Ein Playbook enthält ein oder mehrere Aufgaben/ Schritte (**tasks**) zur Installation und Konfiguration, | ||
| - | |||
| - | Die Aufgabe eines Playbooks ist es, eine Reihe von Anweisungen abzubilden, mit deren ein bestimmtes Zielsystem (**machine**) bzw. ein Service/ | ||
| - | |||
| - | Da es sich bei YAML um eine sogenannte **[[https:// | ||
| - | |||
| - | In nachfolgendem Beispiel wollen wir einen Mailserver " | ||
| - | - **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/ | ||
| - | - **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 / | ||
| - | <file yaml / | ||
| - | name: install and configure MX | ||
| - | hosts: mxtest.dmz.mailserver.guru | ||
| - | become: yes | ||
| - | |||
| - | vars: | ||
| - | | ||
| - | |||
| - | 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 | ||
| - | </ | ||
| - | |||
| - | ==== Facts ==== | ||
| - | Ansible ermittelt bei jedem Aufruf Systeminformationen des jeweiligen Zielsystems. Im Bezug auf Ansible werden diese Systeminformationen auch als **facts** bezeichnet. In unseren **[[# | ||
| - | |||
| - | Wir können uns die facts eines Zielhost z.B. mit folgendem Befehl anzeigen lassen. Wir haben die Option '' | ||
| - | $ ansible centos8 --ask-become-pass -m setup | ||
| - | |||
| - | < | ||
| - | <font style=" | ||
| - | <font style=" | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | ], | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | ], | ||
| - | " | ||
| - | " | ||
| - | }, | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | |||
| - | ... | ||
| - | |||
| - | ... | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | ], | ||
| - | " | ||
| - | }, | ||
| - | " | ||
| - | }</ | ||
| - | </ | ||
| - | |||
| - | |||
| - | Da die Abfrage/ | ||
| - | # ansible centos8 --ask-become-pass -m setup -a ' | ||
| - | |||
| - | < | ||
| - | <font style=" | ||
| - | <font style=" | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | }, | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | }, | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | } | ||
| - | }, | ||
| - | " | ||
| - | " | ||
| - | }, | ||
| - | " | ||
| - | }</ | ||
| - | </ | ||
| - | |||
| - | ==== 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. | ||
| - | |||
| - | Bei der Definition bzw.genauer gesagt bei der Wertezuweisung zu Variablen, stehen uns altbekannte Möglichkeiten aus diversen Programmiersprachen zur Verfügung. so können wir z.B. bei der Definition der Nodes **'' | ||
| - | * **catch all** : Auswahl aller Hosts durch **'' | ||
| - | * **Hostgruppe** : Wählt die im **inventory** definierte Hostgruppe: **'' | ||
| - | * **Teilmenge einer Hostgruppe**: | ||
| - | * **Ausschlussverfahren** : Einzelne Hosts aus einer Gruppe auszunehmen (exclude) ist natürlich auch einfach machbar. **'' | ||
| - | * **kombinierte Bereiche** : Natürlich ist es auch möglich, Kombinationen der obigen Definitionen anzuwenden, wie z.B.: **'' | ||
| - | |||
| - | Neben der Variablenzuweiseung ist es auch ferner möglich Variablen auf Grund einer Bedingung zu setzen. | ||
| - | |||
| - | So können wir zum Beispiel die Variable **'' | ||
| - | 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 | ||
| - | </ | ||
| - | |||
| - | Im nachfolgednen Beispiel wollen wir eine Variable fallbezogen setzen. | ||
| - | <code yaml>--- | ||
| - | block: | ||
| - | - name: Install bind Nameserver-Daemon | ||
| - | action: > | ||
| - | yum name = " | ||
| - | register: Output | ||
| - | | ||
| - | | ||
| - | - debug: | ||
| - | | ||
| - | - " | ||
| - | - " | ||
| - | |||
| - | </ | ||
| - | In diesem Beispiel haben wir die Variable '' | ||
| - | - **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, | ||
| - | - **action** : Der Code neben dem Action-Tag ist die auszuführende Aufgabe. Die action wiederum ist ein Ansible-Schlüsselwort, | ||
| - | - **register** : Die Ausgabe der Aktion wird mit dem Register-Schlüsselwort registriert und Output ist der Variablenname, | ||
| - | - **always** : Dies ist ein Ansible-Schlüsselwort, | ||
| - | - **msg** : Zeigt die definierte Meldung an. | ||
| - | |||
| - | **__Verwendung der Variable %%{{%%Output%%}}%%__**: | ||
| - | Zunächst wird der wert der Variable **Output** ermittelt. Ausserdem wird der Wert der Ausgabevariablen ausgegeben, so wie er im Abschnitt **'' | ||
| - | |||
| - | 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 = " | ||
| - | |||
| - | block: | ||
| - | - debug: msg = ' | ||
| - | - command: <Befehl der ausgeführt werden soll> | ||
| - | | ||
| - | rescue: | ||
| - | - debug: msg = ' | ||
| - | - command: <Rescue Befehle die ausgeführt werden, sofern obige Ausnahme auftrat. | ||
| - | |||
| - | </ | ||
| - | 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 Befehle die auf dem Zielsystem ausgeführt werden sollen. \\ Wenn der Befehl, der innerhalb des block-Abschnittes definiert wurde, fehlschlägt, | ||
| - | |||
| - | ==== Schleifen ==== | ||
| - | Das nachfolgende Konfigurationsbeispiel, | ||
| - | |||
| - | 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 | ||
| - | | ||
| - | - name: Install Apache | ||
| - | shell: "ls *.html" | ||
| - | register: output | ||
| - | args: | ||
| - | | ||
| - | | ||
| - | - file: | ||
| - | src: '/ | ||
| - | dest: ''/ | ||
| - | | ||
| - | loop: " {{ output.stdout_lines }} " | ||
| - | </ | ||
| - | |||
| - | * Zunächst wird also der **' | ||
| - | * Die Ausgabe dieses Befehls wird der Variablen mit dem Namen **'' | ||
| - | * Mit Hilfe der Syntax **'' | ||
| - | * Mit der Codezeile **'' | ||
| - | |||
| - | ==== 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 '' | ||
| - | |||
| - | <code yaml>--- #Beispiel für eine Bedingung | ||
| - | - hosts: all | ||
| - | | ||
| - | os: " | ||
| - | | ||
| - | - name: Testing Ansible Variable | ||
| - | debug: | ||
| - | msg: " | ||
| - | when: os == " | ||
| - | </ | ||
| - | |||
| - | ==== 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 passenden adhoc-Befehl mit Hilfe des Programms '' | ||
| - | |||
| - | Der Befehl **'' | ||
| - | |||
| - | Bsp.: | ||
| - | # | ||
| - | |||
| - | < | ||
| - | |||
| - | Runs Ansible playbooks, executing the defined tasks on the targeted hosts. | ||
| - | |||
| - | Options: | ||
| - | --ask-vault-pass | ||
| - | -C, --check | ||
| - | of the changes that may occur | ||
| - | -D, --diff | ||
| - | 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 | ||
| - | --force-handlers | ||
| - | -f FORKS, --forks=FORKS | ||
| - | specify number of parallel processes to use | ||
| - | (default=5) | ||
| - | -h, --help | ||
| - | -i INVENTORY, --inventory=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 | ||
| - | anything else | ||
| - | --list-tags | ||
| - | --list-tasks | ||
| - | -M MODULE_PATH, | ||
| - | prepend colon-separated path(s) to module library | ||
| - | (default=[u'/ | ||
| - | u'/ | ||
| - | --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 | ||
| - | --syntax-check | ||
| - | execute it | ||
| - | -t TAGS, --tags=TAGS | ||
| - | --vault-id=VAULT_IDS | ||
| - | --vault-password-file=VAULT_PASSWORD_FILES | ||
| - | vault password file | ||
| - | -v, --verbose | ||
| - | connection debugging) | ||
| - | --version | ||
| - | |||
| - | Connection Options: | ||
| - | control as whom and how to connect to hosts | ||
| - | |||
| - | -k, --ask-pass | ||
| - | --private-key=PRIVATE_KEY_FILE, | ||
| - | use this file to authenticate the connection | ||
| - | -u 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/ | ||
| - | 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 | ||
| - | become) | ||
| - | -U SUDO_USER, --sudo-user=SUDO_USER | ||
| - | desired sudo user (default=root) (deprecated, | ||
| - | become) | ||
| - | -S, --su run operations with su (deprecated, | ||
| - | -R SU_USER, --su-user=SU_USER | ||
| - | run operations with su as this user (default=None) | ||
| - | (deprecated, | ||
| - | -b, --become | ||
| - | 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-su-pass | ||
| - | -K, --ask-become-pass | ||
| - | ask for privilege escalation password</ | ||
| - | |||
| - | Zusätzliche Hinweise zum Befehl **'' | ||
| - | < | ||
| - | |||
| - | NAME | ||
| - | | ||
| - | |||
| - | SYNOPSIS | ||
| - | | ||
| - | |||
| - | DESCRIPTION | ||
| - | the tool to run Ansible playbooks, which are a configuration and multinode deployment system. See the project | ||
| - | home page (https:// | ||
| - | |||
| - | COMMON OPTIONS | ||
| - | | ||
| - | ask for su password (deprecated, | ||
| - | |||
| - | | ||
| - | ask for sudo password (deprecated, | ||
| - | |||
| - | | ||
| - | ask for vault password | ||
| - | |||
| - | | ||
| - | | ||
| - | dzdo | ksu | runas | pmrun ] | ||
| - | |||
| - | | ||
| - | run operations as this user (default=root) | ||
| - | |||
| - | | ||
| - | clear the fact cache | ||
| - | |||
| - | | ||
| - | run handlers even if a task fails | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | list all available tags | ||
| - | |||
| - | | ||
| - | list all tasks that would be executed | ||
| - | |||
| - | | ||
| - | the new vault identity to use for rekey | ||
| - | |||
| - | | ||
| - | new vault password file for rekey | ||
| - | |||
| - | | ||
| - | use this file to authenticate the connection | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | only run plays and tasks whose tags do not match these values | ||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | start the playbook at the task matching this name | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | the vault identity to use | ||
| - | |||
| - | | ||
| - | vault password file | ||
| - | |||
| - | | ||
| - | show program’s version number and exit | ||
| - | |||
| - | -C, --check | ||
| - | | ||
| - | |||
| - | -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 | ||
| - | | ||
| - | | ||
| - | |||
| - | -R SU_USER, --su-user SU_USER | ||
| - | run operations with su as this user (default=None) (deprecated, | ||
| - | |||
| - | -S, --su | ||
| - | run operations with su (deprecated, | ||
| - | |||
| - | -T TIMEOUT, --timeout TIMEOUT | ||
| - | | ||
| - | |||
| - | -U SUDO_USER, --sudo-user SUDO_USER | ||
| - | | ||
| - | |||
| - | -b, --become | ||
| - | run operations with become (does not imply password prompting) | ||
| - | |||
| - | -c CONNECTION, --connection CONNECTION | ||
| - | | ||
| - | |||
| - | -e, --extra-vars | ||
| - | set additional variables as key=value or YAML/JSON, if filename prepend with @ | ||
| - | |||
| - | -f FORKS, --forks FORKS | ||
| - | | ||
| - | |||
| - | -h, --help | ||
| - | show this help message and exit | ||
| - | |||
| - | |||
| - | -b, --become | ||
| - | run operations with become (does not imply password prompting) | ||
| - | |||
| - | -c CONNECTION, --connection CONNECTION | ||
| - | | ||
| - | |||
| - | -e, --extra-vars | ||
| - | set additional variables as key=value or YAML/JSON, if filename prepend with @ | ||
| - | |||
| - | -f FORKS, --forks FORKS | ||
| - | | ||
| - | |||
| - | -h, --help | ||
| - | show this help message and exit | ||
| - | |||
| - | -i, --inventory, | ||
| - | | ||
| - | |||
| - | -k, --ask-pass | ||
| - | ask for connection password | ||
| - | |||
| - | -l SUBSET, --limit SUBSET | ||
| - | | ||
| - | |||
| - | -s, --sudo | ||
| - | run operations with sudo (nopasswd) (deprecated, | ||
| - | |||
| - | -t, --tags | ||
| - | only run plays and tasks tagged with these values | ||
| - | |||
| - | -u REMOTE_USER, | ||
| - | | ||
| - | |||
| - | -v, --verbose | ||
| - | | ||
| - | |||
| - | ENVIRONMENT | ||
| - | The following environment variables may be specified. | ||
| - | |||
| - | | ||
| - | |||
| - | Many more are available for most options in ansible.cfg | ||
| - | |||
| - | FILES | ||
| - | / | ||
| - | |||
| - | | ||
| - | |||
| - | AUTHOR | ||
| - | | ||
| - | |||
| - | COPYRIGHT | ||
| - | | ||
| - | |||
| - | SEE ALSO | ||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | info can be found in file CONTRIBUTING.md, | ||
| - | |||
| - | Ansible 2.4.2.0 | ||
| - | </ | ||
| - | |||
| - | Will man z.B. die installierte und Verwendete Version von Ansible abfragen gibt man die Opion **%%--%%version** beim Aufruf des Befehls **'' | ||
| - | # ansible --version | ||
| - | |||
| - | < | ||
| - | config file = / | ||
| - | configured module search path = ['/ | ||
| - | ansible python module location = / | ||
| - | executable location = / | ||
| - | python version = 3.7.5 (default, Dec 15 2019, 17:54:26) [GCC 9.2.1 20190827 (Red Hat 9.2.1-1)]</ | ||
| - | |||
| - | 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** **'' | ||
| - | $ ansible intranet -a "/ | ||
| - | |||
| - | 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 **''/ | ||
| - | $ ansible dmz -m copy -a "src = / | ||
| - | |||
| - | Ebenso kann man natürlich auch auf allen Webservern (Gruppe **www**) z.B. ein spezifisches Verzeichnis anlegen lassen. | ||
| - | $ ansible www -m file -a "dest = / | ||
| - | |||
| - | 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 = / | ||
| - | |||
| - | 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 **'' | ||
| - | $ 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: | ||
| - | $ 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" | ||
| - | |||
| - | ==== Module - Dokumentation ==== | ||
| - | Ansible bringt bei der Installation eine Vielzahl von Modulen, die sich im Verzeichnis **'' | ||
| - | |||
| - | Wie diese **[[https:// | ||
| - | |||
| - | Also entweder im Falle des Modules**dnf** die Webseite https:// | ||
| - | $ ansible-doc dnf | ||
| - | < | ||
| - | |||
| - | Installs, upgrade, removes, and lists packages and groups with the `dnf' package | ||
| - | manager. | ||
| - | |||
| - | * This module is maintained by The Ansible Core Team | ||
| - | OPTIONS (= is mandatory): | ||
| - | |||
| - | - allow_downgrade | ||
| - | Specify if the named package and version is allowed to downgrade a maybe already | ||
| - | installed higher version of that package. Note that setting allow_downgrade=True can | ||
| - | make this module behave in a non-idempotent way. The task could end up with a set of | ||
| - | packages that does not match the complete list of specified packages to install | ||
| - | (because dependencies between the downgraded package and others can cause changes to | ||
| - | the packages which were in the earlier transaction). | ||
| - | [Default: no] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - autoremove | ||
| - | If `yes', removes all " | ||
| - | dependencies of user-installed packages but which are no longer required by any such | ||
| - | package. Should be used alone or when state is `absent' | ||
| - | [Default: no] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - bugfix | ||
| - | If set to `yes', and `state=latest' | ||
| - | bugfix related. | ||
| - | [Default: no] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - conf_file | ||
| - | The remote dnf configuration file to use for the transaction. | ||
| - | [Default: (null)] | ||
| - | |||
| - | - disable_excludes | ||
| - | Disable the excludes defined in DNF config files. | ||
| - | If set to `all', disables all excludes. | ||
| - | If set to `main', | ||
| - | If set to `repoid', | ||
| - | [Default: (null)] | ||
| - | version_added: | ||
| - | |||
| - | - disable_gpg_check | ||
| - | Whether to disable the GPG checking of signatures of packages being installed. Has an | ||
| - | effect only if state is `present' | ||
| - | [Default: no] | ||
| - | type: bool | ||
| - | |||
| - | - disable_plugin | ||
| - | `Plugin' | ||
| - | not persist beyond the transaction. | ||
| - | [Default: (null)] | ||
| - | version_added: | ||
| - | |||
| - | - disablerepo | ||
| - | `Repoid' | ||
| - | not persist beyond the transaction. When specifying multiple repos, separate them with | ||
| - | a "," | ||
| - | [Default: (null)] | ||
| - | |||
| - | - download_dir | ||
| - | Specifies an alternate directory to store packages. | ||
| - | Has an effect only if `download_only' | ||
| - | [Default: (null)] | ||
| - | type: str | ||
| - | version_added: | ||
| - | |||
| - | - download_only | ||
| - | Only download the packages, do not install them. | ||
| - | [Default: no] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - enable_plugin | ||
| - | `Plugin' | ||
| - | persist beyond the transaction. | ||
| - | [Default: (null)] | ||
| - | version_added: | ||
| - | |||
| - | - enablerepo | ||
| - | `Repoid' | ||
| - | not persist beyond the transaction. When specifying multiple repos, separate them with | ||
| - | a "," | ||
| - | [Default: (null)] | ||
| - | |||
| - | - exclude | ||
| - | Package name(s) to exclude when state=present, | ||
| - | separated string. | ||
| - | [Default: (null)] | ||
| - | version_added: | ||
| - | |||
| - | - install_repoquery | ||
| - | This is effectively a no-op in DNF as it is not needed with DNF, but is an accepted | ||
| - | parameter for feature parity/ | ||
| - | [Default: yes] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - install_weak_deps | ||
| - | Will also install all packages linked by a weak dependency relation. | ||
| - | [Default: yes] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - installroot | ||
| - | Specifies an alternative installroot, | ||
| - | [Default: /] | ||
| - | version_added: | ||
| - | |||
| - | - list | ||
| - | Various (non-idempotent) commands for usage with `/ | ||
| - | playbooks. See examples. | ||
| - | [Default: (null)] | ||
| - | |||
| - | - lock_timeout | ||
| - | Amount of time to wait for the dnf lockfile to be freed. | ||
| - | [Default: 30] | ||
| - | type: int | ||
| - | version_added: | ||
| - | |||
| - | = name | ||
| - | A package name or package specifier with version, like `name-1.0' | ||
| - | state=latest, | ||
| - | or a local path to a rpm file. To operate on several packages this can accept a comma | ||
| - | separated string of packages or a list of packages. | ||
| - | (Aliases: pkg) | ||
| - | elements: str | ||
| - | type: list | ||
| - | |||
| - | - releasever | ||
| - | Specifies an alternative release from which all packages will be installed. | ||
| - | [Default: (null)] | ||
| - | version_added: | ||
| - | |||
| - | - security | ||
| - | If set to `yes', and `state=latest' | ||
| - | security related. | ||
| - | [Default: no] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - skip_broken | ||
| - | Skip packages with broken dependencies(devsolve) and are causing problems. | ||
| - | [Default: no] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - state | ||
| - | Whether to install (`present', | ||
| - | Default is `None', | ||
| - | `autoremove' | ||
| - | (Choices: absent, present, installed, removed, latest)[Default: | ||
| - | |||
| - | - update_cache | ||
| - | Force dnf to check if cache is out of date and redownload if needed. Has an effect only | ||
| - | if state is `present' | ||
| - | (Aliases: expire-cache)[Default: | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - update_only | ||
| - | When using latest, only update installed packages. Do not install packages. | ||
| - | Has an effect only if state is `latest' | ||
| - | [Default: no] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | - validate_certs | ||
| - | This only applies if using a https url as the source of the rpm. e.g. for localinstall. | ||
| - | If set to `no', the SSL certificates will not be validated. | ||
| - | This should only set to `no' used on personally controlled sites using self-signed | ||
| - | certificates as it avoids verifying the source site. | ||
| - | [Default: yes] | ||
| - | type: bool | ||
| - | version_added: | ||
| - | |||
| - | |||
| - | NOTES: | ||
| - | * When used with a `loop:` each package will be processed individually, | ||
| - | more efficient to pass the list directly to the `name` option. | ||
| - | * Group removal doesn' | ||
| - | upstream dnf's API doesn' | ||
| - | removal the module is unable to detect that the group is installed | ||
| - | (https:// | ||
| - | |||
| - | |||
| - | REQUIREMENTS: | ||
| - | |||
| - | AUTHOR: Igor Gnatenko (@ignatenkobrain) < | ||
| - | METADATA: | ||
| - | status: | ||
| - | - stableinterface | ||
| - | supported_by: | ||
| - | | ||
| - | |||
| - | EXAMPLES: | ||
| - | |||
| - | - name: install the latest version of Apache | ||
| - | dnf: | ||
| - | name: httpd | ||
| - | state: latest | ||
| - | |||
| - | - name: install the latest version of Apache and MariaDB | ||
| - | dnf: | ||
| - | name: | ||
| - | - httpd | ||
| - | - mariadb-server | ||
| - | state: latest | ||
| - | |||
| - | - name: remove the Apache package | ||
| - | dnf: | ||
| - | name: httpd | ||
| - | state: absent | ||
| - | |||
| - | - name: install the latest version of Apache from the testing repo | ||
| - | dnf: | ||
| - | name: httpd | ||
| - | enablerepo: testing | ||
| - | state: present | ||
| - | |||
| - | - name: upgrade all packages | ||
| - | dnf: | ||
| - | name: " | ||
| - | state: latest | ||
| - | |||
| - | - name: install the nginx rpm from a remote repo | ||
| - | dnf: | ||
| - | name: ' | ||
| - | state: present | ||
| - | |||
| - | - name: install nginx rpm from a local file | ||
| - | dnf: | ||
| - | name: / | ||
| - | state: present | ||
| - | |||
| - | - name: install the ' | ||
| - | dnf: | ||
| - | name: ' | ||
| - | state: present | ||
| - | |||
| - | - name: Autoremove unneeded packages installed as dependencies | ||
| - | dnf: | ||
| - | autoremove: yes | ||
| - | |||
| - | - name: Uninstall httpd but keep its dependencies | ||
| - | dnf: | ||
| - | name: httpd | ||
| - | state: absent | ||
| - | autoremove: no | ||
| - | |||
| - | - name: install a modularity appstream with defined stream and profile | ||
| - | dnf: | ||
| - | name: ' | ||
| - | state: present | ||
| - | |||
| - | - name: install a modularity appstream with defined stream | ||
| - | dnf: | ||
| - | name: ' | ||
| - | state: present | ||
| - | |||
| - | - name: install a modularity appstream with defined profile | ||
| - | dnf: | ||
| - | name: ' | ||
| - | state: present | ||
| - | |||
| - | </ | ||
| - | |||
| - | ===== 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, | ||
| - | # dnf install ansible | ||
| - | |||
| - | |||
| - | ==== RPM-Paket ansible ==== | ||
| - | Einen Überblick über das Paket kann man mit Hilfe des Befehls **'' | ||
| - | # rpm -ai ansible | ||
| - | < | ||
| - | Version | ||
| - | Release | ||
| - | Architecture: | ||
| - | Install Date: Sa 21 Dez 2019 20:38:05 CET | ||
| - | Group : Unspecified | ||
| - | Size : 102078689 | ||
| - | License | ||
| - | Signature | ||
| - | 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 | ||
| - | Vendor | ||
| - | URL : http:// | ||
| - | Bug URL : https:// | ||
| - | Summary | ||
| - | 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.</ | ||
| - | |||
| - | Interessieren wir uns für eine Datei- und Ordnerliste, | ||
| - | # rpm -qil ansible | ||
| - | |||
| - | ===== weitere Schritte zur Installation und Konfiguration ===== | ||
| - | Nachdem wir uns nun eingehend mit den **[[# | ||
| - | |||
| - | ====== Links ====== | ||
| - | * **⇒ [[centos: | ||
| - | * ** [[centos: | ||
| - | * **[[wiki: | ||
| - | * **[[http:// | ||
django