linux:ansible:playbook_example_09

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung		 Vorhergehende Überarbeitung
linux:ansible:playbook_example_09 [22.09.2022 15:46. ] – angelegt djangolinux:ansible:playbook_example_09 [19.11.2024 13:26. ] (aktuell) – [Ansible - Erweiterte Konfigurationsbeispiel: Inventory] django
Zeile 1: Zeile 1:
-====== Ansible - erweiterte Konfigurationsbeispiele: Ansible mit Hilfe von Ansible einrichten ======+====== Ansible - Erweiterte Konfigurationsbeispiel: Inventory ======
 {{:centos:ansible:ansible_logo.png?nolink&125|Bild: Ansible Logo}} \\ \\ {{:centos:ansible:ansible_logo.png?nolink&125|Bild: Ansible Logo}} \\ \\
  
-===== Ausgangssituation ===== +Nachdem wir uns bereits eingehend mit den **[[basics#grundlagen|Grundlagen]]**, mit der **[[basics#installation|Installation von Ansible]]** und auch schon mit der Grundkonfiguration beschäftigt sowie erste Erfahrungen mit **[[playbooks|Playbooks]]** gesammelt haben, wollen wir uns nun mit der tiefer gehenden Konfiguration von Ansible beschäftigen. Ein wesentlicher Punkt, den wir bei unseren Überlegungen im Kapitel **[[detail|Ansible - Erweiterte Konfigurationsbeispiele]]** angestellt hatten, war unter anderem **//Woher beziehen wir die Hostdefinitionen und deren Eigenschaften?//**.
-In verteilten und getrennten Netz(werk)umgebungen ist es sehr oft nicht ohne Aufwand möglich zu Administrations- und Orchestrierungsaufgaben alle Hosts zu erreichen. +
  
-Schauen wir uns hierzu einfach mal nachstehende Skizze an.+Klar ist natürlich dass sich da eine Hobby-mässige Installation mit einer Hand voll Geräten sich wohl erheblich von einer professionellen Umgebung mit hunderten oder gar mehr Hosts unterscheiden wird. Bei ersteren wird man vermutlich alle Information bestmöglich versuchen z.B. in einer Datei oder in einem Verzeichnis vor zuhalten. Bei grösseren Installationen wird man hingegen eine **[[#cmdb-basierte_professionelle_umgebungen|CMDB]]**((**C**onfiguration **M**anagement **D**ata**B**ase)) zurück greifen und dort die Informationen pflegen, wie z.B.: 
 +  * **[[https://netboxlabs.com/docs/netbox/en/stable/|netbox]]** 
 +  * **[[https://www.cmdbuild.org|CMDBuild -Platform for Asset Management]]** 
 +  * **[[https://www.i-doit.org/|i-doit - Open Source CMDB & ITSM Tool ]]** 
 +  * **[[https://www.combodo.com/itop-193|iTop - IT Service Management & CMDB iTop - IT Service Management & CMDB]]**
  
-<uml> +Egal was wir als Basis verwenden, Ziel sollte immer sein aus den aktuell gepflegten Daten alle Informationen so für Ansible aufzubereiten, dass alle relevanten Daten, die zum Abarbeiten eines Playbooks benötigt werden, auch zur Verfügung stehen.
-state Firewall_A { +
-  Firewall_A : ----------- +
-  Firewall_A : A-Firewall +
-  Firewall_A : ----------- +
-}+
  
-state Internet { +===== Inventory ===== 
- state fremdgehostetes_System +Zur Verwaltung/Inventarisierung von mehreren Knoten oder Hosts in unserer Infrastrukturumgebung verwendet Ansible Listen oder eine Gruppe von Listen, die man als **Inventory** bezeichnet. Im einfachsten Fall beschreibt solch eine Inventory-Datei lediglich Hosts und/oder deren Hostnamen bzw. IP-Adressen. Auf der anderen Seite kann man aber auch komplexe Landschaften abbilden und Eigenschaften einzelnen Hosts und /oder Gruppe zuordnen.
-  fremdgehostetes_System : Host beim Housing-Provider +
-  fremdgehostetes_System : Hostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag> +
-  fremdgehostetes_System : IP-Adresse: aa-bb-cc-dd +
-}+
  
- state DMZ { +Im Kapitel **[[first#etc_ansible_hosts|(Grund-)Konfiguration - /etc/ansible/hosts]]** hatten wir uns schon einmal kurz mit dem Thema **Inventory** beschäftigt. In den nachfolgenden Beispielen wollen wir nun intensiver auf Details dazu eingehen.
-  state bredmz { +
-    bredmz : EDMZ-Netzwerkswitch (bredmz) +
-    bredmz : Netz:10.0.0.0/24 +
-  } +
-    state bridmz { +
-    bridmz : EDMZ-Netzwerkswitch (bridmz) +
-    bridmz : Netz:10.10.0.0/24 +
-  } +
-  state edmz_switch { +
-    edmz_switch : EDMZ-Switch  +
-    edmz_switch : Netgear Typ: x +
-  }+
  
-   +Im Kapitel **[[https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html|How to build your inventory]]** der Ansible-Onlinedoku finden sich dazu viele tiefergehende Informationen.
-  state FWB { +
-    FWB : FQDN: vml000010.dmz.nausch.org +
-    FWB : ------------------------------------ +
-    FWB : Services: iptables +
-  } +
-  state FWC { +
-    FWC : FQDN: vml000020.dmz.nausch.org +
-    FWC : ------------------------------------ +
-    FWC : Services: iptables +
-  }+
  
- state DMZ_HOSTs { +==== Ansible-Konfigurationsdatei und Inventory-Definition ==== 
-  state IDMZ_Repository_Host { +In der Ansible-Konfigurationsdatei **''/etc/ansible/ansible.cfg''** zeigt zu Beginn der default-Eintrag auf die vorgenannte Datei **''/etc/ansible/hosts''**. 
-     IDMZ_Repository_Host : FQDN: vml000050.dmz.nausch.org +   $ less /etc/ansible/ansible.cfg 
-     IDMZ_Repository_Host : CNAME : syslog, tftp, install +<code bash> ...
-     IDMZ_Repository_Host : IP (IDMZ) : eth0 - 52:54:00:19:08:67 - 10.0.0.50 +
-     IDMZ_Repository_Host : Services : syslog, httpd, rpm-repository, tftp/pxe  +
-  } +
-  state EDMZ_Repository_Host { +
-     EDMZ_Repository_Host : FQDN: vml100080.dmz.nausch.org +
-     EDMZ_Repository_Host : CNAME : mail +
-     EDMZ_Repository_Host : IP (EDMZ) : eth0 - 52:54:00:14:12:71 - 10.0.0.50 +
-     EDMZ_Repository_Host : Services : syslog, httpd, rpm-repository, tftp/pxe  +
-  } +
- } +
-}+
  
 +[defaults]
  
-state Intranet { +# some basic default values...
-  state Switch { +
-    Switch : Physikalischer Netzwerk-Switch +
-    Switch : Netz 10.10.10.0/26 +
-  } +
-  state Workstation { +
-    Workstation : Gerät: Djangos Admin-Workstation +
-    Workstation : Hostname: pml010040 +
-    Workstation : CNAME: office-work +
-    Workstation : MAC:  +
-    Workstation : IP:10.10.10.40 +
-  } +
-}   +
-   +
-  FWB -down-> edmz_switch  +
  
-  bredmz -down-> FWB   +#inventory      = /etc/ansible/hosts 
-  FWC -up-> bredmz +... 
-  FWC -up-> bridmz +</code>
-  bredmz -up-> EDMZ_Repository_Host+
  
-  bridmz -up-> IDMZ_Repository_Host +Unsere eigene Konfigurationsdatei für die Hosts wollen wir aber künftig unserer Ansible-Administationsumgebung beim jeweiligen Admin-Users vorhalten. Im Beispiel unseres Adminusers **django** wäre dies entsprechend der Pfad **''/home/django/ansible/inventories/production''**. Das entsprechende **[[first#ansibledirectory_layout|Ansible: Directory Layout]]** haben wir ja mit Hilfe unsere **[[playbook_example_08|Ansible-Playbooks zur initialen Einrichtung]]** bereits erfolgreich angelegt.
-        +
-  Switch -up-> FWC +
-   +
-  Workstation -up-> Switch+
  
-  edmz_switch --> Firewall_A +In unserer benutzerspezifischen Ansible-Konfigurationsdatei wird auch bereits auf das entsprechende Ziel verwiesen. 
-  Firewall_A -right-> fremdgehostetes_System +   $ less ~/.ansible.cfg  
-</uml>+<code bash> some basic default values...
  
-Von der Admin-Workstation bzw. dem Ansible-Controll-Node aus, wollen wir nun nicht nur zum nächstgelegenen Host erreichen, sondern auch zum übernächsten oder gar zu einem Host im Internet, den wir aber aus Sicherheitsgründen nicht direkt erreichen dürfen und auch können.+# Generated by Ansible on 2022-09-22, do not edit manually! 
 +# default: #inventory      = /etc/ansible/hosts 
 +inventory       = /home/django/ansible/inventories/production 
 +</code>
  
-Die Komfortabelste Variante ist nun die Nutzung der Option **ProxyCommand**. Bei "nur" einem Jump-Host kann man dies im Inventory noch recht bequem und einfach abbilden. Weitaus schwieriger wird die Sache, bei Umgebungen, bei denen mehrere Jumphost beteiligt sind. Hier bietet es sich an, die SSH-Client Konfiguration des Ansible Control- bzw Admin-Users zu verwenden!+=== inventory - Beispiel mit einer yml-Datei=== 
 +Dort legen wir uns unsere erweiterte Host-Datei im YAML-Format an. 
 +   $ vim ~/ansible/inventories/production/hosts.yml>
  
-Weitaus einfacher gestaltet sich o.g. Szenario in dem man auf die SSH-Clientkonfigurationsdatei ~/.ssh/config zurückgreift. Nachfolgendes Beispiel zeigt exemplarisch solch eine Clientspezifische Konfigurationsdatei:+<file bash ~/ansible/inventories/production/hosts.yml>--- #YAML start syntax (optional)  
 +all: 
 +  hosts:                                                                       # nicht zugeordnete Hosts 
 +    n3r0.intra.nausch.org: 
 +    g33k.intra.nausch.org: 
 +  children:                                                                    # Untermenge/-gruppe aller Hosts  
 +    centos8:                                                                   # Gruppe der definierten CentOS 8 Hosts 
 +      vars:                                                                    # Variablen, die für die ganze Gruppe gelten 
 +        ansible_ssh_port: 22 
 +        ansible_ssh_user: ansible 
 +        ansible_ssh_private_key_file: /home/django/.ssh/id_ed25519_ansible 
 +      hosts:                                                                   # Liste aller Hosts die dieser gruppe zugehören 
 +        www8.dmz.nausch.org: 
 +          ansible_ssh_host: 10.0.0.90                                          # Hostspezifische Ansible-Systemvariable 
 +    centos7:                                                                   # Gruppe der definierten CentOS 7 Hosts 
 +      vars:                                                                    # Variablen, die für die ganze Gruppe gelten 
 +        ansible_ssh_port: 22 
 +        ansible_ssh_user: ansible 
 +        ansible_ssh_private_key_file: /home/django/.ssh/id_rsa_ansible        
 +      hosts:                                                                   # Liste aller Hosts die dieser gruppe zugehören 
 +        www7.dmz.nausch.org: 
 +          ansible_ssh_host: 10.0.0.97                                          # Hostspezifische Ansible-Systemvariable 
 +                                                                               # optische Abtrennung zu nachfolgenden Definitionen 
 +    ffmucgluon:                                                                # Definition der Gruppe aaler Freifunk Knoten/Hosts 
 +      vars:                                                                    # Variablen, die für die ganze Gruppe gelten 
 +        ansible_ssh_port: 22 
 +        ansible_ssh_user: root 
 +        ansible_ssh_private_key_file: /home/django/.ssh/id_rsa4096_freifunk_2014 
 +        contact_info: 'Django [BOfH] | django@nausch.org | chat -> @django' 
 +      hosts:                                                                   # Liste aller Hosts die dieser gruppe zugehören 
 +        ff_pliening_gbw_ug:                                                    # Host 
 +          hostname: ff_pliening_gbw_ug                                         # Hostspezifische Informationen / Variablen 
 +          latitude: -48.19861319429455 
 +          longitude: -168.2017571420684 
 +          branch: stable 
 +          domain: ffmuc_muc_ost 
 +          director: ffmuc_muc_ost 
 +          modell: TP-Link TL-WDR4300 v1 
 +          ansible_ssh_host: 2001:608:a01:102:32b5:c2ff:fe56:62b1
  
-   $ vim ~/.ssh/config +        ff_pliening_gbw_egod:                                                  # Host  
-<file bash ~/.ssh/config># Default Werte +          hostname: ffplieninggbwegod                                          # Hostspezifische Informationen / Variablen 
-Host *  +          pretty_hostname: ff_pliening_gbw_egod 
-    Port 22 +          latitude: 48.198652080 
-    Protocol 2 +          longitude: 11.797969940 
-    user admin +          branch: stable 
-            +          domain: ffmuc_muc_ost 
-# Django : 2012-06-13 +          director: ffmuc_muc_ost 
-# ssh-jumps über mehrere Sprunghosts+          modell: Ubiquiti UniFi-AC-MESH 
 +          ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fea9:22ed
  
-# Erster Sprunghost (fwc) - direkt erreichbar +        ff_pliening_gbw_ogod:                                                  # Host 
-# Host -->  fwc +          hostname: ffplieninggbwogod                                          # Hostspezifische Informationen / Variablen 
-Host fwc +          pretty_hostname: ff_pliening_gbw_ogod 
-    Hostname firewall-c.idmz.nausch.org +          latitude: 48.198699460 
-    IdentityFile ~/.ssh/id_ed25519_idmz +          longitude: 11.798053090 
 +          branch: stable 
 +          domain: ffmuc_muc_ost 
 +          director: ffmuc_muc_ost 
 +          modell: Ubiquiti UniFi-AC-MESH 
 +          ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fec0:aaae
  
-# Zweiter Sprunghost (fwb) - nur über fwc erreichbar +        ff_pliening_gbw_dgod:                                                  # Host 
-# Host -->  fwc --> fwb +           hostname: ffplieninggbwdgod                                         # Hostspezifische Informationen / Variablen 
-Host fwb +           prettyhostname: ff_pliening_gbw_dgod 
-    Hostname firewall-b.edmz.nausch.org +           latitude: 48.198671230 
-    IdentityFile ~/.ssh/id_ed25519_edmz +           longitude: 11.798122820 
-    ProxyCommand  ssh -A -q -W %h:%p fwc+           branch: stable 
 +           domain: ffmuc_muc_ost 
 +           director: ffmuc_muc_ost 
 +           modell: Ubiquiti UniFi-AC-MESH 
 +           ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fec6:c8eb
  
-# Dritter Sprunghost (fwa) - nur über fwb erreichbar +        ff_pliening_gbw_cpod:                                                  # Host 
-# Host --> fwc --> fwb --> fwa  +           hostname: ffplieninggbwcpod                                         # Hostspezifische Informationen / Variablen 
-Host fwa +           pretty_hostname: ff_pliening_gbw_cpod 
-    Hostname firewall-a.nausch.org +           latitude: 48.198726280 
-    Port 22222 +           longitude: 11.798159030 
-    user sysadmin +           branch: stable 
-    IdentityFile ~/.ssh/id_ed25519_edmz +           domain: ffmuc_muc_ost 
-    ProxyCommand  ssh -A -q -W %h:%p fwc+           director: ffmuc_muc_ost 
 +           modell: Ubiquiti UniFi-AC-MESH 
 +           ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fec6:c8dd
  
-# externer Server im Internet nur über externe Firewall "A" erreichbar +        ff_pliening_gbw_kvm_ol:                                                # Host 
-# also: Host --> fwc --> fwb --> fwa --> daxie +           hostname: ffplieninggbwkvmol                                        # Hostspezifische Informationen / Variablen 
-Host s1u7 +           pretty_hostname: ff_pliening_gbw_kvm_ol 
-    Hostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag> +           latitude: 48.198646720 
-    Port 42422 +           longitude: 11.798047720 
-    user n3rd +           branch: stable 
-    IdentityFile ~/.ssh/id_ed25519_n3rd +           domain: ffmuc_muc_ost 
-    ProxyCommand  ssh -A -q -W %h:%p fwa+           director: ffmuc_muc_ost 
 +           modell: Red Hat KVM 
 +           ansible_ssh_host: 2001:608:a01:102:5054:ff:fe9e:b358 
 + 
 +... #YAML end syntax</file> 
 + 
 +Die YAML-Konfigurationsdatei enthält entsprechende Bemerkungen, die die einzelnen Blöcke und Funktionen ausreichend beschreiben. Wie können so individuelle und Anwendungsspezifische Lösungen abbilden.  
 + 
 +<WRAP center round info 80%> 
 +Natürlich gilt zu bedenken, dass das gezeigte Beispiel mit nur 8 Hosts und überschaubaren Variablen doch schon recht umfangreich geworden ist, wenn dies alles in eine Inventory-Datei gepackt wird. Bei Dutzenden oder Hunderten von Maschinen wird dies dann daraus schwer zu handeln - von verschachtelten Gruppen in Gruppen, oder Hosts die Mitglied in mehreren Gruppen sein sollen, sprechen wir dann besser gar nicht. 
 + 
 +<WRAP center round alert 90%> 
 +Wollen wir später auch noch vertrauliche Informationen in einzelnen **''vault''**-Dateien vorhalten werden wir mit einer derartigen Inventarisierung Grenzen stossen! 
 +</WRAP> 
 + 
 +Hier werden wir später auf eine **[[#komplexere_und_groessere_umgebungen|andere/aufgeteilte Lösung]]** einschwenken müssen.  
 + 
 +</WRAP> 
 + 
 +Zum Testen, ob die definierten Hosts in unserem **inventory**-File auch erreichbar ist, können wir nun z.B. mit dem Befehl **''ansible -m ping all''** überprüfen. 
 + 
 +<html> 
 +<pre class="code"> 
 +<font style="color: rgb(25, 100, 5)">www7.dmz.nausch.org | SUCCESS => { 
 +    "ansible_facts": { 
 +        "discovered_interpreter_python": "/usr/bin/python2.7" 
 +    }, 
 +    "changed": false, 
 +    "ping": "pong" 
 +}</font> 
 +<font style="color: rgb(0, 0, 0)"> 
 +... 
 +</font> 
 +<font style="color: rgb(239, 41, 41)">www8.dmz.nausch.org | UNREACHABLE! => { 
 +    "changed": false, 
 +    "msg": "Failed to connect to the host via ssh: ssh: connect to host 10.0.0.90 port 22: No route to host", 
 +    "unreachable": true 
 +}</font> 
 +<font style="color: rgb(0, 0, 0)"> 
 +...</font> 
 +</pre> 
 +</html> 
 + 
 +==== Komplexere und grössere Umgebungen ==== 
 +Wie schon im vorhergehenden Beispiel angemerkt, wird es bei einer grösseren Anzahl von Hostdefinitionen mit umfangreichen oder verschachtelten (Gruppe in Gruppe) Gruppenzugehörigkeiten mit verschiedensten zugeordneten Variablen sehr schnell "schmutzig". All das in einer ein zigsten Konfiguration abbilden zu wollen, wird man vermutlich in die Ecke "Hang zu masochistischen Tendenzen" oder Selbstgeisselung eines Admins einordnen - kurzum hier muss ein anderer Lösungsansatz her! 
 + 
 +In dem nachfolgenden Konfigurationsbeispiel sehen wir uns eine kleinere Installation an, die zwar nicht genau dem Kriterien **"gross"**, aber an Hand dieses Beispiels lässt sich das grundsätzliche Struktur und der Umgang mit verschachtelten Gruppen anschaulich erklären. Wir gehen bei diesem Beispiel von einer mittleren Freifunk-Installation mit folgenden unterschiedlichen Systemkomponenten und -eigenschaften aus.  aus: 
 + 
 +  * **Standard-Nodes**: Dies sind einfach ausgedrückt Standard-WLAN-Access-Points((**A**ccess **P**oint)), die für Endanwender einen Zugang zum Internet bereitstellen. In einfachen Installationen spannen diese einen Tunnel in Richtung des zentralen Gateways auf. Auf diesen Nodes läuft in aller Regel eine Firmware, die auf dem **[[https://github.com/freifunk-gluon/gluon|Gluon-Framework]]** sowie **[[https://openwrt.org/|OpenWrt]]** basiert. 
 +  * **Offloader**: Bei entsprechenden Verkehrsmengen (Traffic und Nutzer) nutzt man meist in kleinen vermaschten Netzen sog. Offloader, die leistungsfähigere Hardware verbaut haben um einen Tunnel zum zentralen Gateway der Freifunk Community aufzuspannen. Als Offloader kommen meist **x86-Hardware** in Form von **futro-thinclients**, virtualisierte Systeme **KVM** oder auch **Raspberry 4** Auf letzterem läuft als Betriebssystem ein spezielles Debian, auf den beiden anderen i.d.R. **Gluon**. 
 + 
 +In unserem Konfigurationsbeispiel haben wir folgende Komponenten und (Betriebs-)Systeme im Einsatz, woraus sich unterschiedliche Gruppenkonstellationen ergeben, die im Betrieb zum Tragen kommen bzw. verwendet werden. 
 +  - **Gruppe** aller WiFi-AccessPoints mit **Gluon** **''ffmuc''**: 
 +    * ff_pliening_gbw_cpod 
 +    * ff_pliening_gbw_dod 
 +    * ff_pliening_gbw_egod 
 +    * ff_pliening_gbw_ogod 
 +    * ff_pliening_gbw_ug 
 +    * ff_roding_as_nausch  
 +  - **Gruppe** aller Offloader **''olall''**: 
 +    * ff_pliening_gbw_client 
 +    * ff-django-raspi 
 +    * ff_pliening_gbw_futro_mesh 
 +    * ff_pliening_gbw_kvm_ol 
 +  - **Gruppe** **''gluonall''** aller Gluon-Systeme 
 +    * ff_pliening_gbw_cpod 
 +    * ff_pliening_gbw_dod 
 +    * ff_pliening_gbw_egod 
 +    * ff_pliening_gbw_ogod 
 +    * ff_pliening_gbw_ug 
 +    * ff_roding_as_nausch 
 +    * ff_pliening_gbw_futro_mesh 
 +    * ff_pliening_gbw_kvm_ol 
 +  - **Gruppe** **''olfutro''** der Offloader mit Futro-Hardware: 
 +    * ff_pliening_gbw_futro_mesh 
 +  - **Gruppe** **''ololkvm''** der KVM virtualisierten Offloader: 
 +    * ff_pliening_gbw_kvm_ol 
 +  - **Gruppe** **''olgluon''** aller Offloader mit **Gluon** 
 +    * ff_pliening_gbw_futro_mesh 
 +    * ff_pliening_gbw_kvm_ol 
 +  - **Gruppe** **''oldeb''** aller Offloader mit **Debian** 
 +    * ff_pliening_gbw_futro_mesh 
 +    * ff_pliening_gbw_kvm_ol 
 +  - **Gruppe** **''all''** aller Nodes: 
 +    * ff_pliening_gbw_cpod 
 +    * ff_pliening_gbw_dod 
 +    * ff_pliening_gbw_egod 
 +    * ff_pliening_gbw_ogod 
 +    * ff_pliening_gbw_ug 
 +    * ff_roding_as_nausch 
 +    * ff_pliening_gbw_client 
 +    * ff-django-raspi 
 +    * ff_pliening_gbw_futro_mesh 
 +    * ff_pliening_gbw_kvm_ol 
 + 
 +Nachfolgendes Schaubild visualisiert die einzelnen Gruppen und die entsprechenden Überlappungen. 
 +  
 +{{ :centos:ansible:inventory.png?direct&900 |Bild: Übersicht einer möglichen (Infra)Struktur}} 
 + 
 +=== inventory - Beispiel === 
 +Die **Inventory**-Datei **''inventory.yml''** unseres Beispiels legen wir im Arbeitsverzeichnis unseres Ansible-Administrationshost ab. 
 +   $ vim ~/ansible/inventories/production/inventory.yml 
 + 
 +<file bash ~/ansible/inventories/production/inventory.yml>--- #Inventory - YAML syntax  
 +all: 
 +  children: 
 +    ffmuc: 
 +      hosts: 
 +        ff_pliening_gbw_cpod: 
 +        ff_pliening_gbw_dgod: 
 +        ff_pliening_gbw_egod: 
 +        ff_pliening_gbw_ogod: 
 +        ff_pliening_gbw_ug: 
 +        ff_roding_as_nausch: 
 +    oldeb: 
 +      hosts: 
 +        ff_pliening_gbw_client: 
 +        ff-django-raspi: 
 +    olfutro: 
 +      hosts: 
 +        ff_pliening_gbw_futro_mesh: 
 +    olkvm: 
 +      hosts: 
 +        ff_pliening_gbw_kvm_ol: 
 +    olgluon: 
 +      children: 
 +        olkvm: 
 +        olfutro: 
 +    olall: 
 +      children: 
 +        oldeb: 
 +        olgluon: 
 +    gluonall: 
 +      children: 
 +        ffmuc: 
 +        olgluon: 
 +    ffmucall: 
 +      children: 
 +        ffmuc: 
 +        olall: 
 +... #YAML end syntax
 </file> </file>
  
-Nun können wir ganz einfach direkt einen Tunnel zu unserem Zielhost aufspannen, genauso also würden wir den Zielhost direkt "sehen". +Die Datei ist relativ übersichtlich und doch recht einfach zu verstehen. Würden wir nun aber die Host- und Gruppenspezifischen Variablen mit in die Datei aufnehmen, wäre dies jedoch gänzlich anders. Dabei haben wir hier nur 10 Hosts und noch keine 100 oder noch mehr.  
-   $ ssh fwa+ 
 +Ansible bietet daher einen skalierbareren Ansatz, um den Überblick über Host- und Gruppenvariablen zu behalten. Man kann für jeden Host und jede Gruppe die Variablen in einer jeweils zugehörigen Datei auslagern. Ansible wir beim Aufruf und Abarbeiten eines Playbooks diese hostspezifischen Dateien im Verzeichnis **''host_vars''** und die gruppenspezifischen Variablen im Verzeichnis **''group_vars''**. Diese Verzeichnisse werden von Ansible entweder im dem Verzeichnis erwartet, in dem das aufgerufene Playbook gespeichert wurde oder alternativ dazu im Verzeichnis in dem das die **Inventory**-Datei gespeichert wurde. 
 + 
 +Diese beiden Verzeichnisse wurden bereits bei der initialen Konfiguration unserer Ansible-Umgebung mit Hilfe des Ansible-Playbooks **''[[playbook_example_08#aufgabenstellung_2_-_erweiterte_grund-_basis-installation_fuer_ansible-vault|~/ansible/playbooks/ansible_grundconfig_v2.yml]]''** angelegt. 
 +   $ tree inventories/production/ -d 
 +<code>inventories/production/ 
 +├── group_vars 
 +│   └── all 
 +└── host_vars</code> 
 + 
 + 
 +Je **Gruppe** speichern wir also eine individuelle Datei im Verzeichnis **''~/ansible/inventories/production/group_vars''** ab. 
 +   $ vim ~/ansible/inventories/production/group_vars/ffmuc.yml 
 + 
 +<file bash ~/ansible/inventories/production/group_vars/ffmuc.yml>ffmuc: 
 +  ansible_ssh_port: 22 
 +  ansible_ssh_user: root 
 +  ansible_ssh_private_key_file: /home/django/.ssh/id_rsa4096_freifunk_2014.pub 
 +  contact_info: 'Django [BOfH] | django@nausch.org | chat -> @django' 
 +</file> 
 + 
 +Für die anderen Gruppe(n) verfahren wie ebenso. 
 + 
 +Je **Host** speichern wir dann jeweils eine individuelle Datei im Verzeichnis **''~/ansible/inventory/hosts_vars''** ab. 
 +   $ vim ~/ansible/inventories/production/host_vars/ff_pliening_gbw_egod.yml 
 + 
 +<file bash ~/ansible/inventories/production/host_vars/ff_pliening_gbw_egod.yml>ff_pliening_gbw_egod: 
 +  hostname: ffplieninggbwegod 
 +  pretty_hostname: ff_pliening_gbw_egod 
 +  latitude: 48.198652080 
 +  longitude: 11.797969940 
 +  branch: stable 
 +  domain: ffmuc_muc_ost 
 +  director: ffmuc_muc_ost 
 +  modell: Ubiquiti UniFi-AC-MESH 
 +  ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fea9:22ed</file> 
 + 
 +Auch für die anderen Hosts legen wir entsprechende Dateien mit den Variablen an. 
 + 
 +=== Zusammenfassung === 
 +Nun haben alle unsere eigenen definierten Freifunk Knoten haben nun auf der **[[https://map.ffmuc.net/#!/de/map/18e829a922ed|Freifunk München Karte]]** die aktualisierten GeoDaten. Zum anderen ist der Administrative Aufwand entsprechend überschaubar, so könnte man erst einmal den Stand der "Ermittlungen" zusammenfassen. 
 + 
 +<WRAP center round info 80%> 
 +Zum Thema administrativer Aufwand wollen wir uns kurz noch ein kleines Rechenbeispiel ansehen. Nehmen wir mal an, wie hätten eine etwas grössere Installation mit folgenden Eckdaten: 
 +  * **145** Zeilen (ohne Variablen): 
 +    * mit **76** Hosts 
 +    * und **13** Unter-/Gruppen 
 + 
 +Bei durchschnittlich 15 Variablen pro Host und 5 Variablen pro Gruppe ergäbe das eine Inventory-Datei mit 
 +  * **145** Zeilen (ohne Variablen): 145 
 +    * mit **76** Hosts ~15 Variablen pro Host: 1.140  
 +    * und **13** Unter-/Gruppen ~5 Variablen je Gruppe: 65  
 +ergäbe dies eine Inventory-Datei mit **__1.350__** Zeilen. 8-o 
 + 
 +Wir sehen, dass sich die Pflege hier doch sehr schnell zu einer doch erheblichen Herausforderung auswachsen wird! Ein weiteres Thema ist, dass YML-Files bedingt durch Ihre Struktur zwar für den Menschen recht gut zu lesen und auch zu bearbeiten sind. \\ 
 + 
 +**__Aber__** wenn man solch eine Datei aus einer **CMDB** automatisiert erzeugen möchte, klappt dies schon nicht mehr so einfach, wie anfänglich angenommen. Wir werden uns daher im nächsten Beispiel eine doch geeignetere Variante ansehen. 
 +</WRAP> 
 + 
 +==== CMDB-basierte professionelle Umgebungen ==== 
 +Wie schon im vorhergehenden Beispiel angemerkt, wird es zum einen bei professionellen Umgebungen, nicht mehr praktikabel pflegbar sein, alle Informationen in einer YML-Datei mit verschiedenen Host- oder Gruppen basierenden Variablen-Definitionen versuchen vor zuhalten. Der Export und das automatische Generieren von Inventory-Daten in strukturierter **''bash''**-Notation eignet sich hier wesentlich besser!   
 + 
 +Bei der Grundkonfiguration unserer Ansible-Umgebung mit Hilfe des Ansible-Playbooks **''[[playbook_example_08#aufgabenstellung_2_-_erweiterte_grund-_basis-installation_fuer_ansible-vault|~/ansible/playbooks/ansible_grundconfig_v2.yml]]''** wurde bereits das entsprechend benötigte  **[[first#ansibledirectory_layout|Ansible: Directory Layout]]** automatisch angelegt. 
 +<code>inventories/production/ 
 +├── group_vars 
 +│   └── all 
 +└── host_vars</code> 
 + 
 +Wir können nun entweder eine Inventory-Datei **''hosts''** im betreffenden Verzeichnis manuell anlegen oder eben aus unserer **CMDB** scriptiert erstellen lassen. Nachfolgend sehen wir, wie solch eine Inventory Datei aufgebaut und strukturiert sein könnte. Das exemplarische Beispiel ist hier entsprechend gekürzt und die Stellen mit Hilfe von **''%%...%%''** markiert wiedergegeben" 
 +   $ less ~/ansible/inventories/production/hosts 
 + 
 +<file bash hosts># Generiert mit Hilfe von Ansible am 2022-09-20 - diese Datei nicht manuell bearbeiten! 
 +# Inventory Datei für die System-Umgebung bei nausch.org 
 +# 
 +# Hinweise: 
 +#           Kommentare beginnen mit einem '#'-Zeichen 
 +#           leere Zeilen werden ignoriert 
 +#           Host- und Gruppendefinitionen werden mit [] abgegrenzt 
 +#           Hosts können über ihren Hostnamen, FQN oder ihrer IP-Adresse definiert 
 +#           übergeordnete Gruppen werden durch [:children] abgegrenzt 
 +# 
 +# Host-Definitionen 
 + 
 +# Hosts ohne Gruppenzuordnung 
 +localhost 
 + 
 +[intranet] 
 +pml010002 
 +pml010003 
 +pml010004 
 +... 
 +... 
 +pml010124 
 +pml010125 
 +pml010126 
 + 
 +[IDMZ] 
 +vml030010 
 +vml030020 
 +vml030030 
 +vml030040 
 +... 
 +... 
 +vml030230 
 +vml030240 
 +vml030250 
 + 
 +[EDMZ] 
 +vml050010 
 +vml050020 
 +vml050030 
 +vml050040 
 +vml050250 
 + 
 +[TKDMZ] 
 +vml070010 
 +vml070020 
 +vml070030 
 + 
 +[external] 
 +customer_no_001 
 +customer_no_002 
 +... 
 +... 
 +customer_no_042 
 + 
 +[gluon] 
 +ff_pliening_gbw__ug_ 
 +ff_pliening_gbw_egod 
 +ff_pliening_gbw_ogod 
 +ff_pliening_gbw_dgod 
 +ff_pliening_gbw_cpod 
 +ff_roding_fwg_nausch 
 + 
 +[raspbian] 
 +ff_pliening_rpb4_ol_v6 
 + 
 +# Host-Gruppen-Definitionen  
 +# (zu welcher Gruppe gehören Untergruppen bzw. Hosts) 
 + 
 +[freifunk:children] 
 +gluon 
 +raspbian 
 + 
 +[linux:children] 
 +intranet 
 +IDMZ 
 +EDMZ 
 +TKDMZ 
 +external 
 +</file> 
 + 
 +Die betreffenden Host- bzw. Gruppenspezifischen Variablen halten wir hier in entsprechenden Dateien bzw. Unterverzeichnissen vor, wie z.B. die automatisch erzeugte Datei **''ansible_environment.ym''** mit den Ansible Konfiguration zur Rechteerweiterung. 
 +   $ less inventories/production/group_vars/all/ansible_environment 
 +<file c++ ansible_environment># Generated by Ansible on 2022-09-22, do not edit manually! 
 +ansible_become: True 
 +ansible_become_method: sudo 
 +ansible_become_user: root 
 +ansible_become_ask_pass: False</file> 
 + 
 +Oder z.B. die Definitionen für eine bestimmte Gruppe. 
 +   $ less inventories/production/group_vars/IDMZ/ssh_environment 
 +<file c++ ssh_environment># Generated by Ansible on 2022-09-22, do not edit manually! 
 +ssh_port: 22 
 +ssh_user: django 
 +ssh_protocol: 2 
 +ssh_keyfile: ~/.ssh/id_idmz</file> 
 + 
 +Das Beispiel hier zeigt die Host-spezifischen Variablen eines Hosts im Intranet. 
 +   $ less inventories/production/host_vars/pml111002 
 + 
 +<file c++ pml111002># Generated by Ansible on 2022-09-20, do not edit manually! 
 +host_alias: printer 
 +host_mac: "84:3a:de:ad:be:ef" 
 +host_ipv4: "10.111.0.2" 
 +host_ipv6: "::1" 
 +host_sshjump: "vml070010"</file> 
 + 
 +Unser Inventory hat nun in etwa nachfolgenden strukturellen Aufbau, bei dem auch wieder die entsprechend gekürzt und die Stellen mit Hilfe von **''%%...%%''** markiert wurden. 
 +<code>inventories/production/ 
 +├── group_vars 
 +│   ├─── all 
 +│   |   ├── ansible_environment 
 +│   |   ├── ssh_environment 
 +│   |   └── vault 
 +|   ├─── IDMZ 
 +|   |   └── ssh_environment 
 +|   ├─── EDMZ 
 +|   |   └── ssh_environment 
 +|   ├─── TKDMZ 
 +|   |   └── ssh_environment 
 +|   └─── external 
 +│       ├── ssh_environment 
 +|       └── vault 
 +├── hosts 
 +└── host_vars 
 +    ├── ff_pliening_gbw_cpod 
 +    ├── ff_pliening_gbw_dgod 
 +    ├── ff_pliening_gbw_egod 
 +    ├── ff_pliening_gbw_ogod 
 +    ├── ff_pliening_gbw__ug_ 
 +    ├── ff_pliening_rpb4_ol_v6 
 +    ├── ff_roding_fwg_nausch 
 +    ├── pml111002 
 +    ├── pml111003 
 +    ├── pml111004 
 +... 
 +... 
 +    ├── pml010124 
 +    ├── pml010125 
 +    ├── pml010126 
 +    ├── vml030010 
 +    ├── vml030020 
 +    │   ├── dhcpd 
 +    │   ├── named 
 +    │   └── hostconfig 
 +    ├── vml030030 
 +    ├── vml030040 
 +... 
 +... 
 +    ├── vml030230 
 +    ├── vml030240 
 +    ├── vml030250 
 +    ├── vml050010 
 +    ├── vml050020 
 +    │   ├── vhosts 
 +    │   └── hostconfig 
 +    ├── vml000030 
 +    │   ├── exporter 
 +    │   ├── github 
 +    │   └── hostconfig 
 +    ├── vml050030 
 +    ├── vml050040 
 +    │   ├── prometheus 
 +    │   ├── grafana 
 +    │   ├── apache 
 +    │   └── hostconfig 
 +    ├── vml050250 
 +    ├── vml070010 
 +    ├── vml070020 
 +    ├── vml070030 
 +    ├── customer_no_001 
 +    ├── customer_no_002 
 +... 
 +... 
 +    └── customer_no_002 
 +</code>
  
-Auch können wir nun ohne großem Heckmeck Dateien von einem Ende zum anderen Ende kopieren. 
-   $ scp ~/Downloads/enigmail-1.4-sm+tb.xpi 51u7:/tmp/ 
  
-   $ scp 51u7:/home/babe/51lv14/04x.png .+=== Zusammenfassung === 
 +<WRAP center round tip 80%> 
 +Wir haben nun eine standardisiertes Inventory. Die hilft uns zum einen bei der ggf. manuellen Pflege, da Informationen strukturiert immer an definierten Stellen stehen. Dies verlangt natürlich den Admins einiges an Disziplin ab, aber so können sich alle darauf verlassen, dass benötigte Informationen und Konfigurationsoptionen an den gleichen Stellen stehen (sollten).
  
-Somit ist natürlich auch Ansible in der Lage die definierten Zielhost aus dem Inventory ohne Probleme zu erreichen, da hier die **SSH-Client-Konfiguration** unseres Admin-Accounts auf unserem Ansible-Controll-Node verwendet wird.+Pflegt man die Inventory-Daten hingegen über eine (WEB)UI einer CMBD-Anwendung und generiert dann automatisiert die entsprechenden Inventory-Daten, ist dann auch sicher gestellt, dass alle Daten wirklich gleich strukturiert und an den vorgesehenen Stellen stehen. Wie das von Statten geht, werden wir uns später noch eingehender ansehen. 
 +</WRAP>
  
-===== Lösungsmöglichkeit ===== 
  
  
-FIXME+====== Links ====== 
 +  * **[[detail|zurück zum Kapitel "Ansible - Erweiterte Konfigurationsbeispiele"]] <= ** 
 +  * **=> [[playbook_example_10|weiter zum Kapitel "Ansible Controll Node]]** 
 +  * **[[start|Zurück zur "Ansible"-Übersicht]]** 
 +  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]** 
 +  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
  • linux/ansible/playbook_example_09.1663861588.txt.gz
  • Zuletzt geändert: 22.09.2022 15:46.
  • von django