Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
linux:ansible:playbook_example_09 [23.09.2022 10:30. ] – [lorem ipsum dolor sit amet] django | linux:ansible:playbook_example_09 [23.09.2022 12:50. ] – [CMDB-basierte professionelle Umgebungen] django | ||
---|---|---|---|
Zeile 236: | Zeile 236: | ||
{{ : | {{ : | ||
- | |||
- | |||
- | |||
- | |||
- | |||
=== inventory - Beispiel === | === inventory - Beispiel === | ||
Die **Inventory**-Datei **'' | Die **Inventory**-Datei **'' | ||
- | $ vim ~/ | + | $ vim ~/ansible/ |
- | <file bash ~/ | + | <file bash ~/ansible/ |
all: | all: | ||
children: | children: | ||
Zeile 290: | Zeile 285: | ||
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 **'' | 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 **'' | ||
- | Wir legen also die beiden Verzeichnisse | + | Diese beiden Verzeichnisse |
- | $ mkdir ~/ansible/inventory/host_vars | + | |
- | | + | < |
+ | ├── | ||
+ | │ └── all | ||
+ | └── host_vars</ | ||
- | Somit haben wir dann aktuell folgende Verzeichnisstruktur auf unserem Admin-/ | ||
- | < | ||
- | ├── authkeys | ||
- | ├── files | ||
- | │ ├── CentOS7 | ||
- | │ └── CentOS8 | ||
- | ├── includes | ||
- | ├── inventory | ||
- | │ ├── group_vars | ||
- | │ └── host_vars | ||
- | ├── playbooks | ||
- | └── templates | ||
- | └── chrony-client</ | ||
- | Je **Gruppe** speichern wir also eine individuelle Datei im Verzeichnis **'' | + | Je **Gruppe** speichern wir also eine individuelle Datei im Verzeichnis **'' |
- | $ vim ~/inventory/ | + | $ vim ~/ansible/ |
- | <file bash ~/inventory/ | + | <file bash ~/ansible/ |
ansible_ssh_port: | ansible_ssh_port: | ||
ansible_ssh_user: | ansible_ssh_user: | ||
Zeile 321: | Zeile 306: | ||
Je **Host** speichern wir dann jeweils eine individuelle Datei im Verzeichnis **'' | Je **Host** speichern wir dann jeweils eine individuelle Datei im Verzeichnis **'' | ||
- | $ vim ~/ansible/inventory/ | + | $ vim ~/ansible/inventories/ |
- | <file bash ~/ansible/inventory/ | + | <file bash ~/ansible/inventories/ |
hostname: ffplieninggbwegod | hostname: ffplieninggbwegod | ||
pretty_hostname: | pretty_hostname: | ||
Zeile 336: | Zeile 321: | ||
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. | ||
+ | === Zusammenfassung === | ||
+ | Nun haben alle unsere eigenen definierten Freifunk Knoten haben nun auf der **[[https:// | ||
+ | |||
+ | <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-/ | ||
+ | |||
+ | 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-/ | ||
+ | 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. | ||
+ | </ | ||
+ | |||
+ | ==== 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 **'' | ||
+ | |||
+ | Bei der Grundkonfiguration unserer Absible-Umgebung mit Hilfe des Ansible-Playbooks **'' | ||
+ | < | ||
+ | ├── group_vars | ||
+ | │ └── all | ||
+ | └── host_vars</ | ||
+ | |||
+ | Wir können nun entweder eine Inventory-Datei **'' | ||
+ | $ less ~/ | ||
+ | |||
+ | <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: | ||
+ | # | ||
+ | # leere Zeilen werden ignoriert | ||
+ | # Host- und Gruppendefinitionen werden mit [] abgegrenzt | ||
+ | # Hosts können über ihren Hostnamen, FQN oder ihrer IP-Adresse definiert | ||
+ | # | ||
+ | # | ||
+ | # 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: | ||
+ | gluon | ||
+ | raspbian | ||
+ | |||
+ | [linux: | ||
+ | intranet | ||
+ | IDMZ | ||
+ | EDMZ | ||
+ | TKDMZ | ||
+ | external | ||
+ | </ | ||
+ | |||
+ | Die betreffenden Host- bzw. Gruppenspezifischen Variablen halten wir hier in entsprechenden Dateien bzw. Unterverzeichnissen vor, wie z.B. die automatisch erzeugte Datei **'' | ||
+ | $ less inventories/ | ||
+ | <file c++ ansible_environment># | ||
+ | ansible_become: | ||
+ | ansible_become_method: | ||
+ | ansible_become_user: | ||
+ | ansible_become_ask_pass: | ||
+ | |||
+ | Oder z.B. die Definitionen für eine bestimmte Gruppe. | ||
+ | $ less inventories/ | ||
+ | <file c++ ssh_environment># | ||
+ | ssh_port: 22 | ||
+ | ssh_user: django | ||
+ | ssh_protocol: | ||
+ | ssh_keyfile: | ||
+ | |||
+ | Das Beispiel hier zeigt die Host-spezifischen Variablen eines Hosts im Intranet. | ||
+ | $ less inventories/ | ||
+ | |||
+ | <file c++ pml111002># | ||
+ | host_alias: printer | ||
+ | host_mac: " | ||
+ | host_ipv4: " | ||
+ | host_ipv6: ":: | ||
+ | host_sshjump: | ||
+ | |||
+ | Unser Inventory hat nun in etwa folgenden strukturellen Aufbau: | ||
+ | < | ||
+ | ├── group_vars | ||
+ | │ ├─── all | ||
+ | │ | ├── ansible_environment | ||
+ | │ | ├── 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 | ||
+ | </ | ||
+ | |||
+ | |||
+ | === 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, | ||
+ | </ | ||