Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- centos:ansible:basics [19.06.2020 19:30. ] – [Ansible Funktionsbeschreibung] django
+++ centos:ansible:basics [29.03.2022 18:17. ] – [Ansible] django
@@ Zeile 1: / Zeile 1: @@
 ====== Ansible ======
 {{:centos:ansible:ansible_logo.png?nolink&125 |Bild: Ansible Logo}}
-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.
+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. Daher wird man aus folgenden Gründen bestrebt sein, für diese Aufgaben ein Konfigurationsmanagement zu verwenden:
+  * Wiederkehrende und auch regelmässige Konfigurationsaufgaben und Tätigkeiten sollen automatisiert werden, um somit,
+  * Fehler bei manuellen Tätigkeiten bei copy & Paste, z.B. aus Dokumentationen wie z.B. aus diesem WIKI hier zu vermeiden, um auch dadurch
+  * wertvolle Ressourcen im speziellen hier die Arbeits- und Lebenszeit einzusparen. Darüber hinaus möchten wir auch sicherstellen, dass
+  * Aufgaben reproduzierbar nachvollzogen und auch bei Bedarf versioniert werden können. Zu guter Letzt wollen wir auch aus Sicherheitsaspekten \\ heraus die Administration und Konfiguration von einer zentralen Stelle aus bewerkstelligen und absichern.
+Genau in solchen Umgebungen bedient man sich daher 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.
@@ Zeile 11: / Zeile 17: @@
   - 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 "Playbooks", die z.B. auf GitHub von vielen fleissigen 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.
+  - 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 daher 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.
+  - 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. \\ Gegenüber anderen Konfigurationstools wird bei Ansible mit der Beschreibung des gewünschten Sollzustandes verfolgt und nicht die Abarbeitung granularer Einzelschritte z.B. in einem Script beschrieben. Darüber hinaus werden bei Ansible auch immer nur die Arbeitsschritte ab gearbeitet und erledigt, die aktuell nötig sind und nicht stur eine Abfolge von Einzeltätigkeiten perlenkettenmässig abgearbeitet. Aufgaben lassen sich so beliebig oft ausführen, ohne dass negative Seiteneffekte durch mehrmaliges unnötiges Abarbeiten von Aufgaben auftreten werden,
 ===== Grundlagen =====
 ==== Dokumentation ====
@@ Zeile 18: / Zeile 24: @@
 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}}
+=== 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://www.buecher.de/shop/ebooks/ansible-playbook-essentials-ebook-pdf/shah-gourav/products_products/detail/prod_id/56839184/|(eBook, PDF)]]** oder auch als gedruckte Version im einschlägigem Fachbuchhandel zu bestellen: (ISBN: 978-1-784-39829-3).
+{{ :centos:ansible:ansible-playbook-essentials.png?nolink&250 |Bild: Buchcover Ansible Playbook Essentials von Gourav Shah}}
+=== Axel Miesen - Ansible für Administratoren und DevOps-Teams ===
+Das dritte Buch (aktuelle Auflage von August 2020) im Bunde, welches sehr zu empfehlen ist, ist das Buch **Ansible - Das Praxisbuch für Administratoren und DevOps-Teams** von **//Axel Miesen//**, erschienen im Verlag [[https://www.rheinwerk-verlag.de/|Rheinwerk Computing]]. Erhältlich als **[[https://www.buecher.de/shop/server/ansible/miesen-axel/products_products/detail/prod_id/59485549/|(eBook, PDF)]]** oder als gedruckte Version im einschlägigen Fachbuchhandel zu bestellen: (ISBN: 978-3-8362-7660-3).
+{{ :centos:ansible:ansible-axel-miesen.png?nolink&250 |Bild: Buchcover Ansible für Administratoren und DevOps-Teams vom Axel Miesen}}
 === 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!
+Folgende links sind immer eine gute Quelle, sich zu den Möglichkeiten Rund um Ansible zu informieren:
+  * **[[https://docs.ansible.com/ansible/latest/playbooks_best_practices.html|Ansible - Best Practices]]**
+  * **[[https://docs.ansible.com/ansible/latest/playbooks_variables.html|Ansible - Using Variables]]**
+  * **[[https://docs.ansible.com/ansible/latest/playbooks_loops.html|Ansible - Loops]]**
+  * **[[https://docs.ansible.com/ansible/latest/playbooks_error_handling.html|Ansible - Error Handling In Playbooks]]**
+  * **[[https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse.html|Ansible - Creating Reusable Playbooks]]**
+  * **[[https://www.ansible.com/blog/ansible-best-practices-essentials|The Inside Playbook - Ansible Best Practices: The Essentials]]**
 === Dokumentation (RPM) ===
@@ Zeile 208: / Zeile 231: @@
 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.
+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 sozusagen 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.
+Ein Playbook enthält ein 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 elementaren 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.
@@ Zeile 327: / Zeile 350: @@
 ==== 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.
+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.
-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.
+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 **''hosts:''** folgende Wertedefinitionen verwenden:
+  * **catch all** : Auswahl aller Hosts durch **''- hosts: all''** bzw. auch **''- hosts: *''**
+  * **Hostgruppe** : Wählt die im **inventory** definierte Hostgruppe: **''- hosts: CentOS8''**
+  * **Teilmenge einer Hostgruppe**: Wollen wir die Webserver 1 - 10 ansprechen, wäre entsprechen z.B. das hier die zugehörige Definition: **''- hosts: www[1:10]''**
+  * **Ausschlussverfahren** : Einzelne Hosts aus einer Gruppe auszunehmen (exclude) ist natürlich auch einfach machbar. **''- hosts: CentOS8:!ansible''** exkludiert den Host **ansible** aus der Hostgruppe **CentOS8**
+  * **kombinierte Bereiche** : Natürlich ist es auch möglich, Kombinationen der obigen Definitionen anzuwenden, wie z.B.:  **''- hosts: www[1:9]:!www6,lbha[1:2]''**, also www1 - www9, aber ohne www6 sowie die beiden Loadbalancer lbha1 und lbha2.
+Neben der Variablenzuweiseung ist es auch ferner 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>---
@@ Zeile 361: / Zeile 393: @@
 **__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.
+Zunächst wird der wert der Variable **Output** ermittelt. Ausserdem 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.
@@ Zeile 367: / Zeile 399: @@
 ==== 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 ====
@@ Zeile 389: / Zeile 422: @@
   - **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!
+  - **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, 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 ====
@@ Zeile 436: / Zeile 469: @@
 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.
+So könnte man zum Beispiel einen reboot aller definierten Server anstoßen, in dem man den passenden 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.
+Der Befehl **''ansible-playbook''** wird für das Konfigurationsmanagement und das Deployment verwendet. Wird beim Aufruf von **''ansible''** keine zusätzlichen Befehle und Optionen angegeben bzw. beim Aufruf von **''ansible-playbook''** **__kein__** Playbook verwendet gibt der Befehl alle zur Verfügung stehenden Optionen aus.
 Bsp.:
@@ Zeile 737: / Zeile 770: @@
    # ansible --version
-<code>ansible 2.9.2
+<code>ansible 2.9.13
-  config file = /etc/ansible/ansible.cfg
+  config file = /home/django/.ansible.cfg
-  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
+  configured module search path = ['/home/django/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
-  ansible python module location = /usr/lib/python3.7/site-packages/ansible
+  ansible python module location = /usr/lib/python3.8/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>
+  python version = 3.8.5 (default, Aug 12 2020, 00:00:00) [GCC 10.2.1 20200723 (Red Hat 10.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.
@@ Zeile 767: / Zeile 800: @@
    $ ansible intranet -m yum -a "name = chrony state = latest"
+==== Module - Dokumentation ====
+Ansible bringt bei der Installation eine Vielzahl von Modulen, die sich im Verzeichnis **''../ansible/modules/''** befinden, mit, mit deren Hilfe wir uns die Abrit mit unseren Playbooks wesentlich vereinfachen können.
+Wie diese **[[https://docs.ansible.com/ansible/latest/modules/list_of_all_modules.html|Module]]** zu verwenden sind, kann man entweder über die Ansible-Dokuseite im **[[https://docs.ansible.com/ansible/latest/modules/modules_by_category.html|WEB]]** erkunden oder auch mit Hilfe des Befehls **''ansible#doc''** erfragen.
+Also entweder im Falle des Modules**dnf** die Webseite https://docs.ansible.com/ansible/latest/modules/dnf_module.html besuchen oder auf der Konsole den Befehl **''ansible-doc dnf''** bemühen.
+   $ ansible-doc dnf
+<code>> DNF    (/usr/lib/python3.6/site-packages/ansible/modules/packaging/os/dnf.py)
+        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: 2.7
+- autoremove
+        If `yes', removes all "leaf" packages from the system that were originally installed as
+        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: 2.4
+- bugfix
+        If set to `yes', and `state=latest' then only installs updates that have been marked
+        bugfix related.
+        [Default: no]
+        type: bool
+        version_added: 2.7
+- 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', disable excludes defined in [main] in dnf.conf.
+        If set to `repoid', disable excludes defined for given repo id.
+        [Default: (null)]
+        version_added: 2.7
+- disable_gpg_check
+        Whether to disable the GPG checking of signatures of packages being installed. Has an
+        effect only if state is `present' or `latest'.
+        [Default: no]
+        type: bool
+- disable_plugin
+        `Plugin' name to disable for the install/update operation. The disabled plugins will
+        not persist beyond the transaction.
+        [Default: (null)]
+        version_added: 2.7
+- disablerepo
+        `Repoid' of repositories to disable for the install/update operation. These repos will
+        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' is specified.
+        [Default: (null)]
+        type: str
+        version_added: 2.8
+- download_only
+        Only download the packages, do not install them.
+        [Default: no]
+        type: bool
+        version_added: 2.7
+- enable_plugin
+        `Plugin' name to enable for the install/update operation. The enabled plugin will not
+        persist beyond the transaction.
+        [Default: (null)]
+        version_added: 2.7
+- enablerepo
+        `Repoid' of repositories to enable for the install/update operation. These repos will
+        not persist beyond the transaction. When specifying multiple repos, separate them with
+        a ",".
+        [Default: (null)]
+- exclude
+        Package name(s) to exclude when state=present, or latest. This can be a list or a comma
+        separated string.
+        [Default: (null)]
+        version_added: 2.7
+- 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/compatibility with the `yum' module.
+        [Default: yes]
+        type: bool
+        version_added: 2.7
+- install_weak_deps
+        Will also install all packages linked by a weak dependency relation.
+        [Default: yes]
+        type: bool
+        version_added: 2.8
+- installroot
+        Specifies an alternative installroot, relative to which all packages will be installed.
+        [Default: /]
+        version_added: 2.3
+- list
+        Various (non-idempotent) commands for usage with `/usr/bin/ansible' and `not'
+        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: 2.8
+= name
+        A package name or package specifier with version, like `name-1.0'. When using
+        state=latest, this can be '*' which means run: dnf -y update. You can also pass a url
+        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: 2.6
+- security
+        If set to `yes', and `state=latest' then only installs updates that have been marked
+        security related.
+        [Default: no]
+        type: bool
+        version_added: 2.7
+- skip_broken
+        Skip packages with broken dependencies(devsolve) and are causing problems.
+        [Default: no]
+        type: bool
+        version_added: 2.7
+- state
+        Whether to install (`present', `latest'), or remove (`absent') a package.
+        Default is `None', however in effect the default action is `present' unless the
+        `autoremove' option is enabled for this module, then `absent' is inferred.
+        (Choices: absent, present, installed, removed, latest)[Default: (null)]
+- update_cache
+        Force dnf to check if cache is out of date and redownload if needed. Has an effect only
+        if state is `present' or `latest'.
+        (Aliases: expire-cache)[Default: no]
+        type: bool
+        version_added: 2.7
+- 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: 2.7
+- 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: 2.7
+NOTES:
+      * When used with a `loop:` each package will be processed individually, it is much
+        more efficient to pass the list directly to the `name` option.
+      * Group removal doesn't work if the group was installed with Ansible because
+        upstream dnf's API doesn't properly mark groups as installed, therefore upon
+        removal the module is unable to detect that the group is installed
+        (https://bugzilla.redhat.com/show_bug.cgi?id=1620324)
+REQUIREMENTS:  python >= 2.6, python-dnf, for the autoremove option you need dnf >= 2.0.1"
+AUTHOR: Igor Gnatenko (@ignatenkobrain) <i.gnatenko.brain@gmail.com>, Cristian van Ee (@DJMuggs) <cristian at cvee.org>
+        METADATA:
+          status:
+          - stableinterface
+          supported_by: core
+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: 'http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm'
+    state: present
+- name: install nginx rpm from a local file
+  dnf:
+    name: /usr/local/src/nginx-release-centos-6-0.el6.ngx.noarch.rpm
+    state: present
+- name: install the 'Development tools' package group
+  dnf:
+    name: '@Development tools'
+    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: '@postgresql:9.6/client'
+    state: present
+- name: install a modularity appstream with defined stream
+  dnf:
+    name: '@postgresql:9.6'
+    state: present
+- name: install a modularity appstream with defined profile
+  dnf:
+    name: '@postgresql/client'
+    state: present
+</code>
 ===== Installation =====
@@ Zeile 781: / Zeile 1087: @@
 ==== RPM-Paket ansible ====
 Einen Überblick über das Paket kann man mit Hilfe des Befehls **''rpm -qi''** sich anzeigen lassen.
-   # rpm -ai ansible
+   # rpm -qi ansible
 <code>Name        : ansible
-Version     : 2.9.2
+Version     : 2.9.13
-Release     : 1.fc31
+Release     : 1.fc32
 Architecture: noarch
-Install Date: Sa 21 Dez 2019 20:38:05 CET
+Install Date: Sa 03 Okt 2020 10:41:49 CEST
 Group       : Unspecified
-Size        : 102078689
+Size        : 102582504
 License     : GPLv3+
-Signature   : RSA/SHA256, Mo 09 Dez 2019 18:59:12 CET, Key ID 50cb390b3c3359c4
+Signature   : RSA/SHA256, Fr 04 Sep 2020 00:23:43 CEST, Key ID 6c13026d12c944d0
-Source RPM  : ansible-2.9.2-1.fc31.src.rpm
+Source RPM  : ansible-2.9.13-1.fc32.src.rpm
-Build Date  : So 08 Dez 2019 21:42:23 CET
+Build Date  : Do 03 Sep 2020 02:10:52 CEST
-Build Host  : buildvm-aarch64-24.arm.fedoraproject.org
+Build Host  : buildvm-ppc64le-38.iad2.fedoraproject.org
 Packager    : Fedora Project
 Vendor      : Fedora Project
@@ Zeile 810: / Zeile 1116: @@
 ===== 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.
+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 Konfiguration von Ansible und wagen uns an die ersten Playbooks im Kapitel **[[centos:ansible:first| Erste Schritte Rund um Ansible]]** heran.
 ====== Links ======