centos:ansible:detail

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
centos:ansible:detail [23.09.2022 12:59. ] djangocentos:ansible:detail [24.09.2022 14:12. ] – [Module] django
Zeile 1: Zeile 1:
 ====== Ansible - Erweiterte Konfigurationsbeispiele ====== ====== Ansible - Erweiterte Konfigurationsbeispiele ======
-{{:centos:ansible:ansible_logo.png?nolink&125|Bild: Ansible Logo}} \\ \\ 
  
-Nachdem wir uns bereits eingehend mit den **[[centos:ansible:start#grundlagen|Grundlagen]]**, mit der **[[centos:ansible:start#installation|Installation von Ansible]]** und auch schon mit der Grundkonfiguration beschäftigt sowie erste Erfahrungen mit **[[centos:ansible:first#playbook_-_beispiele|Playbooks]]** gesammelt haben, wollen wir uns nun mit der tiefergehenden Konfiguration von Ansible beschäftigen. +<WRAP center round alert 60%> 
 +Artikel befindet sich aktuell in der Überarbeitung! 
 +</WRAP>
  
-===== Module ===== 
-==== Grundlagen ==== 
-Bevor wir nun in die Welt der **roles** bei Ansible eintauchen, werfen wir kurz noch einen Blick aufzwei gängige Szenarien: 
-  * **Bsp. 1**: \\ Hat man nur eine Aufgabe, wie z.B. den **[[centos:ansible:ffmuc-rpb4-ol|automatisierten Bau eines Freifunk-Offloaders auf Basis eines Raspberry 4B]]** zu bewältigen, liegt es natürlich nahe, ein Playbook anzulegen, in dem alle Schritte nacheinander aufgeführt werden, die zum Erledigen der Aufgabe nötig sind. Ehe man sich's vbersieht hat man am Ende ein **[[centos:ansible:ffmuc-rpb4-ol#raspi_offloader_menuyml|Playbook]]** vor Augen welches **//390//** Zeilen umfasst. Sowas kann natürlich alsbald doch sehr umfangreich und vor allem pflegeintensiv werden. 
  
-  * **Bsp. 2**: \\ In ambitionierteren Umgebungen hat man es meist mit einer Vielzahl unterschiedlicher Systeme, wie z.B. Web-, Datenbank-, Mail-, Infrastrukturserver und/oder Loadbalancer-Systeme zu tun. In Ihren Aufgabestellungen unterscheiden sich diese doch erheblich, haben aber jedoch in aller Regel eine grundlegende Basisinstallation und Konfiguration. Die sind z.B. Definitionen zu Admin-Acounts, NTP-Client-Definitionen oder z.B. beim MTA-Relayhost. Nun könnte man natürlich auch hier pragmatisch vorgehend und ein Playbook mit diesen grundlegenden Einzelaufgaben wie z.B. **[[centos:ansible:playbooks1#benutzer_anlegen|Userkontenanlage]]** oder **[[centos:ansible:playbooks1#ntp-daemon_chrony_installieren_und_konfigurieren|NTP-Clientinstallation und -konfiguration]]** als Vorlage erstellen wollen. So eine Vorlage könnte man dann entsprechend vervielfältigen und mit den Hostspezifischen Installations- und Konfigurationsanweisung anreichern. \\ \\ Aus folgenden Gründen ist so ein Vorgehen aber nicht zu empfehlen: 
-    - Bei Änderungen an grundlegenden gemeinsamen Punkte, wie z.B. neuer Mitarbeiter, müsste man später jedes einzelne Playbook anfassen und anpassen. 
-    - Je nach Freunde am Umgang mit Ansible, kann im Arbeitsverzeichnis des Ansible-Nutzers es durch die vielen playbooks und/oder includierten Konfigurationsdateien sehr schnell unübersichtlich werden.  
-    - Daten wie Aufgaben (tasks), Variablen (vars) oder "Spezielle Aufgaben" (handlers) sind so mehrfach definiert und vorhanden, was eine fortlaufende Pflege mehr als erschwert. 
-    - Da es keine Trennung zwischen variablen Daten und den Aufgaben (tasks  und handlers) gibt, ist es sehr schwierig unser spezielles Ansible-Playbook oder auch Teile daraus wiederzuverwenden oder mit anderen zu teilen bzw. weiterzugeben. In aller Regel sind nämlich die Daten eines Playbook organisations- und firmenspezifisch, der dazu verwendete Code natürlich allgemeingültig und allgemein an- und verwendbar. Sind die Daten und der Code nun in einer großen Datei (Playbook) zusammengefasst, ist es damit nicht mehr möglich Inhalte zu teilen oder wiederzuverwenden! 
- 
-Wenn wir das Thema nun nüchtern und wertfrei betrachten werden wir feststellen, dass wir so eine Vielzahl von Systemen nicht auf dauer ohne große Aufwände mit Ansible verwalten können. Um nun diese Herausforderungen elegant zu lösen bringt uns Ansible die Funktion der Rollen (**[[https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse.html#playbooks-reuse|roles]]**) mit.  
- 
-Rollen sind im Grunde nichts anderes als Verzeichnisse, die auf eine bestimmte Art und Weise angelegt sind. Rollen folgen vordefinierten Verzeichnis-Layout-Konventionen und erwarten, dass sich debei die zugehörigen Komponenten in dem für sie vorgesehenen Verzeichnispfad befindet. Bei der Grundkonfiguration unseres Ansible-Hosts hatte wir bereits diese Verzeichnisstruktur beim Anlegen des **[[centos:ansible:first#ansibledirectory_layout|Ansible: Directory Layout]]** angelegt. 
- 
-<code>/home/ansible/ansible/roles/ 
-└── roles                          # Verzeichnis für die einzelnen (unterschiedlichen) Rollen 
-    └── common                     # Verzeichnis "role" common mit seinen entsprechenden Definitionen - Vorlage zum Kopieren 
-        ├── defaults               # Verzeichnis "defaults" 
-        │   └── main.yml           # Standardvariablen mit niedrigerer Priorität für diese Rolle 
-        ├── files                  # Verzeichnis "files" 
-        │   └── main.yml           # (Skript-)Dateien zur Verwendung als Kopier- bzw. Script-Rressource 
-        ├── handlers               # Verzeichnis "handlers" 
-        │   └── main.yml           # Datei mit den Definitionen zu den rollenspezifischen "handlers" 
-        ├── library                # Verzeichnis für benutzerdefinierte Module einer der Rolle (role) "common" 
-        ├── lookup_plugin          # Verzeichnis für weitere Arten von Plugins, wie in diesem Fall "lookup" 
-        ├── meta                   # Verzeichnis "meta" für Rollenspezifische Definitionen/Abhängigkeiten 
-        │   └── main.yml           # Datei mit Rollenspezifischen Definitionen 
-        ├── module_utils           # Verzeichnis "module_utils", die benutzerdefinierte module_utils der Rollen enthalten könnte 
-        ├── tasks                  # Verzeichnis "tasks" für kleinere Aufgabendateien 
-        │   └── main.yml           # Datei für kleinere Aufgaben, falls diese benötigt werden würden  
-        ├── templates              # Verzeichnis mit den Templates 
-        │   └── main.j2            # Template-Datei mit dem Dateisuffix/-Ende .j2 
-        └── vars                   # Verzeichnis "vars", mit den zu dieser Rolle zugeordneten Variablen 
-            └── main.yml           # Datei mit den Rollenspezifischen Variablen 
-</code> 
-Diese Kopiervorlage **''common''** brauchen wir nur noch für jede entsprechende Rolle dann kopieren, so z.B. für die Rolle **''postfix''** 
-   $ cd ~/ansible/roles 
-   $ cp -avr common/ postfix/ 
  
 ==== Konfigurationsbeispiel ==== ==== Konfigurationsbeispiel ====