| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| linux:ansible:playbook_example_09 [23.09.2022 13:02. ] – [lorem ipsum dolor sit amet] django | linux:ansible:playbook_example_09 [19.11.2024 13:26. ] (aktuell) – [Ansible - Erweiterte Konfigurationsbeispiel: Inventory] django |
|---|
| 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://netboxlabs.com/docs/netbox/en/stable/|netbox]]** |
| * **[[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 ===== |
| </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> |
| }</font> | }</font> |
| <font style="color: rgb(0, 0, 0)"> | <font style="color: rgb(0, 0, 0)"> |
| ... | ...</font> |
| </font> | |
| </pre> | </pre> |
| </html> | </html> |
| |
| ==== CMDB-basierte professionelle Umgebungen ==== | ==== 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/ | <code>inventories/production/ |
| ├── group_vars | ├── group_vars |
django