linux:ansible:playbook_example_09

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
linux:ansible:playbook_example_09 [23.09.2022 10:39. ] – [inventory - Beispiel] djangolinux:ansible:playbook_example_09 [30.11.2023 14:27. ] (aktuell) – [Ansible - Erweiterte Konfigurationsbeispiel: Inventory] Typofix django
Zeile 4: Zeile 4:
 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?//**. 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?//**.
  
-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**((**C**onfiguration **M**anagement **D**ata**B**ase)) zurück greifen und dort die Informationen pflegen, wie z.B.:+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://www.cmdbuild.org|CMDBuild -Platform for Asset Management]]**   * **[[https://www.cmdbuild.org|CMDBuild -Platform for Asset Management]]**
   * **[[https://www.i-doit.org/|i-doit - Open Source CMDB & ITSM Tool ]]**   * **[[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]]**   * **[[https://www.combodo.com/itop-193|iTop - IT Service Management & CMDB iTop - IT Service Management & CMDB]]**
  
-Egal was wir als Bai 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.+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.
  
 ===== Inventory ===== ===== Inventory =====
Zeile 152: Zeile 152:
 </WRAP> </WRAP>
  
-Hier werden wir später auf eine **[[#inventarisierung_groesserer_umgebungen|andere/aufgeteilte Lösung]]** einschwenken müssen. +Hier werden wir später auf eine **[[#komplexere_und_groessere_umgebungen|andere/aufgeteilte Lösung]]** einschwenken müssen. 
  
 </WRAP> </WRAP>
Zeile 176: Zeile 176:
 }</font> }</font>
 <font style="color: rgb(0, 0, 0)"> <font style="color: rgb(0, 0, 0)">
-... +...</font>
-</font>+
 </pre> </pre>
 </html> </html>
Zeile 285: Zeile 284:
 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. 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 +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.
-Wir legen also die beiden Verzeichnisse an.+
    $ tree inventories/production/ -d    $ tree inventories/production/ -d
 <code>inventories/production/ <code>inventories/production/
Zeile 322: Zeile 320:
 Auch für die anderen Hosts legen wir entsprechende Dateien mit den Variablen an. Auch für die anderen Hosts legen wir entsprechende Dateien mit den Variablen an.
  
-===== lorem ipsum dolor sit amet =====+=== 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> 
 + 
 + 
 +=== 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). 
 + 
 +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> 
 + 
  
-:KRIT: FIXME :KRIT:+====== 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.1663929549.txt.gz
  • Zuletzt geändert: 23.09.2022 10:39.
  • von django