| |
| edv:ansible:start [27 55 2026 14 : 55] – angelegt André Reichert-Creutz | edv:ansible:start [27 04 2026 15 : 04] (aktuell) – André Reichert-Creutz |
|---|
| //Ein praxisorientiertes Tutorial für den Einstieg in die Automatisierung mit Ansible.// | //Ein praxisorientiertes Tutorial für den Einstieg in die Automatisierung mit Ansible.// |
| |
| <note> | <WRAP center round info 90%> |
| **Über dieses Tutorial** | **Über dieses Tutorial** |
| |
| |
| **Zeitbedarf:** ca. 6–8 Stunden inklusive der Übungen. | **Zeitbedarf:** ca. 6–8 Stunden inklusive der Übungen. |
| </note> | </WRAP> |
| |
| <note tip> | <WRAP center round tip 90%> |
| **Hinweis zur Wiki-Syntax** | **Hinweis zur Wiki-Syntax** |
| |
| Dieses Dokument verwendet die Plugins ''note'' (für Kästen) und ''wrap'' ist //nicht// erforderlich. Ist das Note-Plugin nicht installiert, erscheinen die Kästen als normaler Text — der Inhalt bleibt lesbar. | Dieses Dokument verwendet das Plugin **wrap** für die farbigen Hinweiskästen. Installation über //Admin → Extension Manager → Suchen nach "wrap"//. Ist das Plugin nicht vorhanden, erscheinen die Kästen als normaler Text — der Inhalt bleibt vollständig lesbar. |
| </note> | |
| | Verwendete Kastentypen: |
| | |
| | * ''<WRAP info>'' — Erläuterung, Hintergrund |
| | * ''<WRAP tip>'' — Praxistipp, Empfehlung |
| | * ''<WRAP important>'' — muss man wissen |
| | * ''<WRAP alert>'' — Warnung, Gefahr von Schaden |
| | </WRAP> |
| |
| ---- | ---- |
| **Technik:** Drei Systeme — physisch, virtuell oder als Container. Für ein reines Lernsetup genügen jeweils 1 vCPU und 1 GB RAM. Alternativ funktioniert das gesamte Tutorial auch mit einer einzigen Maschine, auf der zwei VMs unter KVM, VirtualBox oder Vagrant laufen. | **Technik:** Drei Systeme — physisch, virtuell oder als Container. Für ein reines Lernsetup genügen jeweils 1 vCPU und 1 GB RAM. Alternativ funktioniert das gesamte Tutorial auch mit einer einzigen Maschine, auf der zwei VMs unter KVM, VirtualBox oder Vagrant laufen. |
| |
| <note important> | <WRAP center round important 90%> |
| Verwende für die Übungen **keine Produktivsysteme**. Ansible führt Änderungen ohne Rückfrage aus, sobald ein Playbook startet. | Verwende für die Übungen **keine Produktivsysteme**. Ansible führt Änderungen ohne Rückfrage aus, sobald ein Playbook startet. |
| </note> | </WRAP> |
| |
| ---- | ---- |
| | Managed Node 2 | ''ubuntu24'' | Ubuntu Server 24.04 | 192.168.56.12 | | | Managed Node 2 | ''ubuntu24'' | Ubuntu Server 24.04 | 192.168.56.12 | |
| |
| <note tip> | <WRAP center round tip 90%> |
| Wer keine RHEL-Subskription hat: Die **Red Hat Developer Subscription** ist für Einzelpersonen kostenlos und umfasst bis zu 16 Systeme. Alternativ funktionieren **AlmaLinux 9** oder **Rocky Linux 9** in diesem Tutorial identisch — beide melden sich als ''os_family = RedHat''. | Wer keine RHEL-Subskription hat: Die **Red Hat Developer Subscription** ist für Einzelpersonen kostenlos und umfasst bis zu 16 Systeme. Alternativ funktionieren **AlmaLinux 9** oder **Rocky Linux 9** in diesem Tutorial identisch — beide melden sich als ''os_family = RedHat''. |
| </note> | </WRAP> |
| |
| ==== 2.2 Netzwerk, Hostnamen und /etc/hosts ==== | ==== 2.2 Netzwerk, Hostnamen und /etc/hosts ==== |
| Auf **Ubuntu 24.04** identisch — Ubuntu verwendet ebenfalls ''/etc/sudoers.d/''. | Auf **Ubuntu 24.04** identisch — Ubuntu verwendet ebenfalls ''/etc/sudoers.d/''. |
| |
| <note warning> | <WRAP center round alert 90%> |
| ''NOPASSWD:ALL'' ist für eine Lernumgebung vertretbar. In produktiven Umgebungen schränkt man die erlaubten Kommandos ein oder hinterlegt das sudo-Passwort per ''--ask-become-pass'' bzw. über Ansible Vault. | ''NOPASSWD:ALL'' ist für eine Lernumgebung vertretbar. In produktiven Umgebungen schränkt man die erlaubten Kommandos ein oder hinterlegt das sudo-Passwort per ''--ask-become-pass'' bzw. über Ansible Vault. |
| </note> | </WRAP> |
| |
| ==== 2.4 SSH-Schlüssel erzeugen und verteilen ==== | ==== 2.4 SSH-Schlüssel erzeugen und verteilen ==== |
| </code> | </code> |
| |
| <note> | <WRAP center round info 90%> |
| **Warum das wichtig ist:** Ansible startet je Task eine SSH-Verbindung. Eine interaktive Passwortabfrage würde jeden Playbook-Lauf blockieren. Der Schlüsselaustausch ist die eigentliche Grundvoraussetzung — funktioniert er nicht, funktioniert nichts danach. | **Warum das wichtig ist:** Ansible startet je Task eine SSH-Verbindung. Eine interaktive Passwortabfrage würde jeden Playbook-Lauf blockieren. Der Schlüsselaustausch ist die eigentliche Grundvoraussetzung — funktioniert er nicht, funktioniert nichts danach. |
| </note> | </WRAP> |
| |
| **Übung 2.1:** Melde dich einmal manuell per SSH an jedem Managed Node an und führe ''sudo whoami'' aus. Die Ausgabe muss ''root'' lauten, ohne dass ein Passwort abgefragt wird. | **Übung 2.1:** Melde dich einmal manuell per SSH an jedem Managed Node an und führe ''sudo whoami'' aus. Die Ausgabe muss ''root'' lauten, ohne dass ein Passwort abgefragt wird. |
| * **python version** — der Interpreter auf dem Control Node, nicht auf den Zielen. | * **python version** — der Interpreter auf dem Control Node, nicht auf den Zielen. |
| |
| <note> | <WRAP center round info 90%> |
| **Begriffsklärung:** ''ansible-core'' ist die Engine. ''ansible'' ist ein Bundle aus der Engine plus rund 85 Collections. Beide melden dieselbe core-Version. Prüfen lässt sich das Bundle mit ''ansible-community --version''. | **Begriffsklärung:** ''ansible-core'' ist die Engine. ''ansible'' ist ein Bundle aus der Engine plus rund 85 Collections. Beide melden dieselbe core-Version. Prüfen lässt sich das Bundle mit ''ansible-community --version''. |
| </note> | </WRAP> |
| |
| ---- | ---- |
| | ''stdout_callback = yaml'' | macht die Ausgabe deutlich besser lesbar | | | ''stdout_callback = yaml'' | macht die Ausgabe deutlich besser lesbar | |
| |
| <note warning> | <WRAP center round alert 90%> |
| Ansible ignoriert eine ''ansible.cfg'' im aktuellen Verzeichnis, wenn dieses **für alle schreibbar** ist (''chmod 777''). Das ist eine Sicherheitsmaßnahme und eine häufige Ursache für "meine Konfiguration wird nicht gelesen". | Ansible ignoriert eine ''ansible.cfg'' im aktuellen Verzeichnis, wenn dieses **für alle schreibbar** ist (''chmod 777''). Das ist eine Sicherheitsmaßnahme und eine häufige Ursache für "meine Konfiguration wird nicht gelesen". |
| </note> | </WRAP> |
| |
| ==== 4.2 Das Inventory: INI- und YAML-Format ==== | ==== 4.2 Das Inventory: INI- und YAML-Format ==== |
| </code> | </code> |
| |
| <note> | <WRAP center round info 90%> |
| ''ping'' hat **nichts mit ICMP zu tun**. Das Modul meldet sich per SSH an, startet Python auf dem Ziel und lässt sich ''pong'' zurückgeben. Es testet also die komplette Kette: SSH, Authentifizierung und Python — genau das, was Ansible braucht. | ''ping'' hat **nichts mit ICMP zu tun**. Das Modul meldet sich per SSH an, startet Python auf dem Ziel und lässt sich ''pong'' zurückgeben. Es testet also die komplette Kette: SSH, Authentifizierung und Python — genau das, was Ansible braucht. |
| </note> | </WRAP> |
| |
| **Typische Fehler an dieser Stelle:** | **Typische Fehler an dieser Stelle:** |
| </code> | </code> |
| |
| <note tip> | <WRAP center round tip 90%> |
| **''command'' oder ''shell''?** ''command'' führt das Programm direkt aus — ohne Shell, also ohne Pipes, Umleitungen und Variablenexpansion. ''shell'' startet eine Shell und kann all das. Faustregel: **immer ''command'', außer man braucht wirklich Shell-Funktionen.** ''command'' ist sicherer, weil keine Sonderzeichen interpretiert werden. | **''command'' oder ''shell''?** ''command'' führt das Programm direkt aus — ohne Shell, also ohne Pipes, Umleitungen und Variablenexpansion. ''shell'' startet eine Shell und kann all das. Faustregel: **immer ''command'', außer man braucht wirklich Shell-Funktionen.** ''command'' ist sicherer, weil keine Sonderzeichen interpretiert werden. |
| </note> | </WRAP> |
| |
| ==== 5.3 Paketverwaltung: dnf, apt und package ==== | ==== 5.3 Paketverwaltung: dnf, apt und package ==== |
| </file> | </file> |
| |
| <note important> | <WRAP center round important 90%> |
| Der Dateimodus in Ansible sollte **immer in Anführungszeichen** stehen: ''mode: "0644"''. Ohne Anführungszeichen kann YAML den Wert als Dezimalzahl lesen, was zu falschen Berechtigungen führt. | Der Dateimodus in Ansible sollte **immer in Anführungszeichen** stehen: ''mode: "0644"''. Ohne Anführungszeichen kann YAML den Wert als Dezimalzahl lesen, was zu falschen Berechtigungen führt. |
| </note> | </WRAP> |
| |
| ==== 6.3 Editor-Unterstützung und Linting ==== | ==== 6.3 Editor-Unterstützung und Linting ==== |
| </file> | </file> |
| |
| <note> | <WRAP center round info 90%> |
| Schon im ersten Playbook zeigt sich der Distributionsunterschied: Der Dienst heißt unter RHEL ''chronyd'', unter Ubuntu schlicht ''chrony''. Kapitel 8 zeigt, wie man das sauberer löst als mit einem Inline-Ausdruck. | Schon im ersten Playbook zeigt sich der Distributionsunterschied: Der Dienst heißt unter RHEL ''chronyd'', unter Ubuntu schlicht ''chrony''. Kapitel 8 zeigt, wie man das sauberer löst als mit einem Inline-Ausdruck. |
| </note> | </WRAP> |
| |
| ==== 7.3 Playbook ausführen, --check und --diff ==== | ==== 7.3 Playbook ausführen, --check und --diff ==== |
| </code> | </code> |
| |
| <note tip> | <WRAP center round tip 90%> |
| ''--check'' ist die wichtigste Sicherheitsleine für Einsteiger. Ansible meldet, //was// es ändern würde, ohne es zu tun. Einschränkung: Die Module ''command'' und ''shell'' werden im Check-Modus standardmäßig übersprungen, und Tasks, die auf dem Ergebnis eines übersprungenen Tasks aufbauen, können dann fehlschlagen. Ein sauberer ''--check''-Lauf ist also ein gutes Zeichen, aber keine Garantie. | ''--check'' ist die wichtigste Sicherheitsleine für Einsteiger. Ansible meldet, //was// es ändern würde, ohne es zu tun. Einschränkung: Die Module ''command'' und ''shell'' werden im Check-Modus standardmäßig übersprungen, und Tasks, die auf dem Ergebnis eines übersprungenen Tasks aufbauen, können dann fehlschlagen. Ein sauberer ''--check''-Lauf ist also ein gutes Zeichen, aber keine Garantie. |
| </note> | </WRAP> |
| |
| ==== 7.4 Ausgabe lesen ==== | ==== 7.4 Ausgabe lesen ==== |
| Genau das ist **Idempotenz**: Ein Playbook beschreibt einen Zielzustand. Ist dieser erreicht, ändert ein erneuter Lauf nichts. | Genau das ist **Idempotenz**: Ein Playbook beschreibt einen Zielzustand. Ist dieser erreicht, ändert ein erneuter Lauf nichts. |
| |
| <note important> | <WRAP center round important 90%> |
| **Merksatz:** Ein Playbook, das bei jedem Lauf ''changed'' meldet, ist mit hoher Wahrscheinlichkeit fehlerhaft. Häufigste Ursache sind ''command''- oder ''shell''-Tasks, die keine Zustandsprüfung durchführen. Wie man das repariert, zeigt Kapitel 9.4 mit ''changed_when'' und ''creates''. | **Merksatz:** Ein Playbook, das bei jedem Lauf ''changed'' meldet, ist mit hoher Wahrscheinlichkeit fehlerhaft. Häufigste Ursache sind ''command''- oder ''shell''-Tasks, die keine Zustandsprüfung durchführen. Wie man das repariert, zeigt Kapitel 9.4 mit ''changed_when'' und ''creates''. |
| </note> | </WRAP> |
| |
| **Übung 7.1:** Schreibe ein Playbook, das die Pakete ''vim'', ''curl'' und ''git'' installiert. Führe es zweimal aus und prüfe, dass der zweite Lauf ''changed=0'' meldet. | **Übung 7.1:** Schreibe ein Playbook, das die Pakete ''vim'', ''curl'' und ''git'' installiert. Führe es zweimal aus und prüfe, dass der zweite Lauf ''changed=0'' meldet. |
| </code> | </code> |
| |
| <note> | <WRAP center round info 90%> |
| Variablen werden in **doppelten geschweiften Klammern** referenziert. Steht eine Variable am **Anfang eines Wertes**, sind Anführungszeichen zwingend, sonst hält YAML die Klammer für den Beginn eines Dictionaries: | Variablen werden in **doppelten geschweiften Klammern** referenziert. Steht eine Variable am **Anfang eines Wertes**, sind Anführungszeichen zwingend, sonst hält YAML die Klammer für den Beginn eines Dictionaries: |
| |
| ''name: "{{ paketname }}"'' — richtig | ''name: "{{ paketname }}"'' — richtig |
| ''name: {{ paketname }}'' — Syntaxfehler | ''name: {{ paketname }}'' — Syntaxfehler |
| </note> | </WRAP> |
| |
| ==== 8.2 group_vars und host_vars ==== | ==== 8.2 group_vars und host_vars ==== |
| </file> | </file> |
| |
| <note tip> | <WRAP center round tip 90%> |
| **Das ist das didaktische Herzstück dieses Tutorials.** Nicht der Task kennt den Unterschied zwischen RHEL und Ubuntu, sondern die Variablendatei. Der Task selbst bleibt distributionsneutral und damit lesbar. Diese Trennung von //Logik// und //Daten// ist der wichtigste Qualitätssprung beim Übergang vom Skript zur Automatisierung. | **Das ist das didaktische Herzstück dieses Tutorials.** Nicht der Task kennt den Unterschied zwischen RHEL und Ubuntu, sondern die Variablendatei. Der Task selbst bleibt distributionsneutral und damit lesbar. Diese Trennung von //Logik// und //Daten// ist der wichtigste Qualitätssprung beim Übergang vom Skript zur Automatisierung. |
| </note> | </WRAP> |
| |
| ==== 8.3 Fakten sammeln und auswerten ==== | ==== 8.3 Fakten sammeln und auswerten ==== |
| </file> | </file> |
| |
| <note> | <WRAP center round info 90%> |
| **''os_family'' statt ''distribution'' verwenden.** ''os_family'' liefert ''RedHat'' für RHEL, CentOS Stream, Rocky, AlmaLinux und Fedora — das Playbook funktioniert damit auf allen. ''distribution'' unterscheidet diese Systeme und macht die Bedingung unnötig eng. | **''os_family'' statt ''distribution'' verwenden.** ''os_family'' liefert ''RedHat'' für RHEL, CentOS Stream, Rocky, AlmaLinux und Fedora — das Playbook funktioniert damit auf allen. ''distribution'' unterscheidet diese Systeme und macht die Bedingung unnötig eng. |
| </note> | </WRAP> |
| |
| ==== 8.5 Vorrangregeln der Variablen ==== | ==== 8.5 Vorrangregeln der Variablen ==== |
| - ''--extra-vars'' auf der Kommandozeile — **gewinnt immer** | - ''--extra-vars'' auf der Kommandozeile — **gewinnt immer** |
| |
| <note tip> | <WRAP center round tip 90%> |
| **Praxisregel:** Werte, die überschreibbar sein sollen, gehören in ''defaults''. Werte, die nicht überschrieben werden dürfen, gehören in ''vars''. Und wenn eine Variable sich unerklärlich verhält, hilft ''ansible-playbook playbook.yml -e "..." -vvv'' oder ein ''debug''-Task an der richtigen Stelle. | **Praxisregel:** Werte, die überschreibbar sein sollen, gehören in ''defaults''. Werte, die nicht überschrieben werden dürfen, gehören in ''vars''. Und wenn eine Variable sich unerklärlich verhält, hilft ''ansible-playbook playbook.yml -e "..." -vvv'' oder ein ''debug''-Task an der richtigen Stelle. |
| </note> | </WRAP> |
| |
| **Übung 8.1:** Lege ''group_vars/all.yml'' mit einer Variablen ''projekt_name'' an und gib sie in einem Playbook per ''debug'' aus. Überschreibe sie anschließend per ''-e'' und beobachte das Ergebnis. | **Übung 8.1:** Lege ''group_vars/all.yml'' mit einer Variablen ''projekt_name'' an und gib sie in einem Playbook per ''debug'' aus. Überschreibe sie anschließend per ''-e'' und beobachte das Ergebnis. |
| </file> | </file> |
| |
| <note important> | <WRAP center round important 90%> |
| In ''when'' stehen Variablen **ohne** geschweifte Klammern: ''when: os_family == "RedHat"'', nicht ''when: "{{ os_family }} == ..."''. Der Ausdruck wird bereits als Jinja2-Bedingung ausgewertet. | In ''when'' stehen Variablen **ohne** geschweifte Klammern: ''when: os_family == "RedHat"'', nicht ''when: "{{ os_family }} == ..."''. Der Ausdruck wird bereits als Jinja2-Bedingung ausgewertet. |
| </note> | </WRAP> |
| |
| ==== 9.2 loop — Wiederholungen ==== | ==== 9.2 loop — Wiederholungen ==== |
| </file> | </file> |
| |
| <note tip> | <WRAP center round tip 90%> |
| Bei Paketmodulen ist die **zweite Variante deutlich schneller**: Statt zehn einzelner ''dnf''-Aufrufe gibt es eine einzige Transaktion. ''loop_control.label'' sorgt dafür, dass die Ausgabe nicht das ganze Dictionary zeigt, sondern nur den Namen. | Bei Paketmodulen ist die **zweite Variante deutlich schneller**: Statt zehn einzelner ''dnf''-Aufrufe gibt es eine einzige Transaktion. ''loop_control.label'' sorgt dafür, dass die Ausgabe nicht das ganze Dictionary zeigt, sondern nur den Namen. |
| </note> | </WRAP> |
| |
| ==== 9.3 Handler und notify ==== | ==== 9.3 Handler und notify ==== |
| </file> | </file> |
| |
| <note important> | <WRAP center round important 90%> |
| ''changed_when: false'' bei reinen Abfragen ist die häufigste Korrektur, die Einsteiger-Playbooks brauchen. Ohne sie meldet jeder ''command''-Task bei jedem Lauf ''changed'' — und die Idempotenz-Prüfung aus Kapitel 7.5 wird wertlos. | ''changed_when: false'' bei reinen Abfragen ist die häufigste Korrektur, die Einsteiger-Playbooks brauchen. Ohne sie meldet jeder ''command''-Task bei jedem Lauf ''changed'' — und die Idempotenz-Prüfung aus Kapitel 7.5 wird wertlos. |
| </note> | </WRAP> |
| |
| ==== 9.5 Tags zur selektiven Ausführung ==== | ==== 9.5 Tags zur selektiven Ausführung ==== |
| </file> | </file> |
| |
| <note tip> | <WRAP center round tip 90%> |
| ''{{ ansible_managed }}'' erzeugt einen Kommentarhinweis, dass die Datei von Ansible verwaltet wird. Das erspart Kollegen die Frage, warum ihre manuelle Änderung beim nächsten Lauf verschwunden ist. ''validate'' prüft die erzeugte Datei, **bevor** sie an ihren Platz kopiert wird — eine fehlerhafte Konfiguration erreicht den Server damit gar nicht erst. | ''{{ ansible_managed }}'' erzeugt einen Kommentarhinweis, dass die Datei von Ansible verwaltet wird. Das erspart Kollegen die Frage, warum ihre manuelle Änderung beim nächsten Lauf verschwunden ist. ''validate'' prüft die erzeugte Datei, **bevor** sie an ihren Platz kopiert wird — eine fehlerhafte Konfiguration erreicht den Server damit gar nicht erst. |
| </note> | </WRAP> |
| |
| ==== 10.3 Kontrollstrukturen im Überblick ==== | ==== 10.3 Kontrollstrukturen im Überblick ==== |
| </file> | </file> |
| |
| <note> | <WRAP center round info 90%> |
| Der Filter ''default()'' ist das wichtigste Werkzeug für robuste Templates. Er verhindert, dass ein Playbook mit ''undefined variable'' abbricht, nur weil eine optionale Variable nicht gesetzt wurde. | Der Filter ''default()'' ist das wichtigste Werkzeug für robuste Templates. Er verhindert, dass ein Playbook mit ''undefined variable'' abbricht, nur weil eine optionale Variable nicht gesetzt wurde. |
| </note> | </WRAP> |
| |
| **Übung 10.1:** Erstelle ein Template für ''/etc/motd'', das Hostname, IP-Adresse, Distribution und Anzahl der CPU-Kerne ausgibt, und bringe es auf beiden Systemen aus. | **Übung 10.1:** Erstelle ein Template für ''/etc/motd'', das Hostname, IP-Adresse, Distribution und Anzahl der CPU-Kerne ausgibt, und bringe es auf beiden Systemen aus. |
| Anschließend im Browser ''http://192.168.56.11/'' und ''http://192.168.56.12/'' aufrufen. | Anschließend im Browser ''http://192.168.56.11/'' und ''http://192.168.56.12/'' aufrufen. |
| |
| <note important> | <WRAP center round important 90%> |
| **Wenn die Seite unter RHEL nicht erscheint**, ist fast immer eine von drei Ursachen schuld: firewalld blockiert Port 80, SELinux verweigert den Zugriff auf den DocumentRoot, oder der Dienst läuft nicht. Diagnose auf dem Zielsystem: | **Wenn die Seite unter RHEL nicht erscheint**, ist fast immer eine von drei Ursachen schuld: firewalld blockiert Port 80, SELinux verweigert den Zugriff auf den DocumentRoot, oder der Dienst läuft nicht. Diagnose auf dem Zielsystem: |
| |
| sudo ausearch -m AVC -ts recent | sudo ausearch -m AVC -ts recent |
| </code> | </code> |
| </note> | </WRAP> |
| |
| ---- | ---- |
| </file> | </file> |
| |
| <note tip> | <WRAP center round tip 90%> |
| ''include_vars'' mit ''{{ ansible_facts['os_family'] }}.yml'' ist ein Muster, das in praktisch jeder professionellen Rolle vorkommt. Neue Distributionen werden unterstützt, indem eine weitere Variablendatei hinzukommt — der Task-Code bleibt unverändert. | ''include_vars'' mit ''{{ ansible_facts['os_family'] }}.yml'' ist ein Muster, das in praktisch jeder professionellen Rolle vorkommt. Neue Distributionen werden unterstützt, indem eine weitere Variablendatei hinzukommt — der Task-Code bleibt unverändert. |
| </note> | </WRAP> |
| |
| ==== 12.4 Rollen einbinden ==== | ==== 12.4 Rollen einbinden ==== |
| </file> | </file> |
| |
| <note> | <WRAP center round info 90%> |
| **Vollqualifizierte Modulnamen (FQCN)** wie ''ansible.builtin.package'' statt nur ''package'' sind seit Ansible 2.10 die empfohlene Schreibweise. Sie machen eindeutig, aus welcher Collection ein Modul stammt — wichtig, seit mehrere Collections gleichnamige Module enthalten können. | **Vollqualifizierte Modulnamen (FQCN)** wie ''ansible.builtin.package'' statt nur ''package'' sind seit Ansible 2.10 die empfohlene Schreibweise. Sie machen eindeutig, aus welcher Collection ein Modul stammt — wichtig, seit mehrere Collections gleichnamige Module enthalten können. |
| </note> | </WRAP> |
| |
| **Übung 12.1:** Überführe das Playbook aus Kapitel 11 in eine Rolle ''webserver'' mit ''vars/RedHat.yml'' und ''vars/Debian.yml''. Das aufrufende ''site.yml'' sollte danach nur noch wenige Zeilen umfassen. | **Übung 12.1:** Überführe das Playbook aus Kapitel 11 in eine Rolle ''webserver'' mit ''vars/RedHat.yml'' und ''vars/Debian.yml''. Das aufrufende ''site.yml'' sollte danach nur noch wenige Zeilen umfassen. |
| </code> | </code> |
| |
| <note warning> | <WRAP center round alert 90%> |
| **Die Passwortdatei gehört niemals ins Git-Repository.** Ein passender ''.gitignore''-Eintrag: | **Die Passwortdatei gehört niemals ins Git-Repository.** Ein passender ''.gitignore''-Eintrag: |
| |
| |
| Eine bewährte Konvention ist die Trennung in eine unverschlüsselte ''vars.yml'' mit sprechenden Variablennamen und eine verschlüsselte ''vault.yml'', die die eigentlichen Werte unter dem Präfix ''vault_'' enthält. So bleibt im Klartext sichtbar, //welche// Geheimnisse existieren, ohne ihren Inhalt preiszugeben. | Eine bewährte Konvention ist die Trennung in eine unverschlüsselte ''vars.yml'' mit sprechenden Variablennamen und eine verschlüsselte ''vault.yml'', die die eigentlichen Werte unter dem Präfix ''vault_'' enthält. So bleibt im Klartext sichtbar, //welche// Geheimnisse existieren, ohne ihren Inhalt preiszugeben. |
| </note> | </WRAP> |
| |
| ---- | ---- |
