Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:ansible:playbook_example_09 [23.09.2022 11:47. ] – [CMDB-basierte professionelle Umgebungen] django
+++ linux:ansible:playbook_example_09 [19.11.2024 13:26. ] (aktuell) – [Ansible - Erweiterte Konfigurationsbeispiel: Inventory] 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?//**.
-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://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]]**
-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 =====
@@ Zeile 152: / Zeile 153: @@
 </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>
@@ Zeile 176: / Zeile 177: @@
 }</font>
 <font style="color: rgb(0, 0, 0)">
-...
+...</font>
-</font>
 </pre>
 </html>
@@ Zeile 342: / Zeile 342: @@
 ==== CMDB-basierte professionelle Umgebungen ====
-Wie schon im vorhergehenden Beispiel angemerkt, wird es zum einen bei professionellen Umgebungen, nicht mehr praktikabel pflegbar sein, alle Infoarmastionen 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!
+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 Absible-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.
+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
@@ Zeile 369: / Zeile 369: @@
 [intranet]
-pml111002
+pml010002
-pml111003
+pml010003
-pml111004
+pml010004
 ...
 ...
@@ Zeile 460: / Zeile 460: @@
 host_sshjump: "vml070010"</file>
-Unser Inventory hat nun in etwa folgenden strukturellen Aufbau:
+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></code>
+<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>
-===== lorem ipsum dolor sit amet =====
-: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]]**