Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
centos:ansible:start [14.01.2020 21:46. ] – [Facts] django | centos:ansible:start [24.09.2022 14:26. ] – django | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== Ansible ====== | + | {{: |
- | {{: | + | ===== Ansible (Artikel gerade |
- | 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ößten 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** | + | |
- | {{ : | + | |
- | + | ||
- | === online-Dokumentation === | + | |
- | Eine stets aktuelle Programm- und Projektdokumentation ist in der in der **Onlinebibliothek** unter : 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. | + | |
- | + | ||
- | < | + | |
- | 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 | + | |
- | nic: | + | |
- | - 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 din 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. Ferner ist es auch 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: | + | |
- | msg: | + | |
- | - " | + | |
- | - " | + | |
- | + | ||
- | </ | + | |
- | 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. Außerdem 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 Befehel die auf dem Zielsystem ausdgefü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 | + | |
- | vars: | + | |
- | 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 passendden 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" | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | ===== 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: | + | |
- | * **[[wiki: | + | |
- | * **[[http:// | + | |
+ | * < | ||
+ | * < | ||
+ | * < | ||
+ | * < | ||
+ | * < | ||
+ | * < | ||