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 09:58. ] – [~/ansible/hosts.yml] django | linux:ansible:playbook_example_09 [23.09.2022 12:47. ] – [lorem ipsum dolor sit amet] django | ||
---|---|---|---|
Zeile 42: | Zeile 42: | ||
</ | </ | ||
+ | === inventory - Beispiel mit einer yml-Datei=== | ||
+ | Dort legen wir uns unsere erweiterte Host-Datei im YAML-Format an. | ||
+ | $ vim ~/ | ||
+ | <file bash ~/ | ||
+ | all: | ||
+ | hosts: | ||
+ | n3r0.intra.nausch.org: | ||
+ | g33k.intra.nausch.org: | ||
+ | children: | ||
+ | centos8: | ||
+ | vars: # Variablen, die für die ganze Gruppe gelten | ||
+ | ansible_ssh_port: | ||
+ | ansible_ssh_user: | ||
+ | ansible_ssh_private_key_file: | ||
+ | hosts: | ||
+ | www8.dmz.nausch.org: | ||
+ | ansible_ssh_host: | ||
+ | centos7: | ||
+ | vars: # Variablen, die für die ganze Gruppe gelten | ||
+ | ansible_ssh_port: | ||
+ | ansible_ssh_user: | ||
+ | ansible_ssh_private_key_file: | ||
+ | hosts: | ||
+ | www7.dmz.nausch.org: | ||
+ | ansible_ssh_host: | ||
+ | # optische Abtrennung zu nachfolgenden Definitionen | ||
+ | ffmucgluon: | ||
+ | vars: # Variablen, die für die ganze Gruppe gelten | ||
+ | ansible_ssh_port: | ||
+ | ansible_ssh_user: | ||
+ | ansible_ssh_private_key_file: | ||
+ | contact_info: | ||
+ | hosts: | ||
+ | ff_pliening_gbw_ug: | ||
+ | hostname: ff_pliening_gbw_ug | ||
+ | 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: | ||
+ | ff_pliening_gbw_egod: | ||
+ | hostname: ffplieninggbwegod | ||
+ | pretty_hostname: | ||
+ | latitude: 48.198652080 | ||
+ | longitude: 11.797969940 | ||
+ | branch: stable | ||
+ | domain: ffmuc_muc_ost | ||
+ | director: ffmuc_muc_ost | ||
+ | modell: Ubiquiti UniFi-AC-MESH | ||
+ | ansible_ssh_host: | ||
+ | ff_pliening_gbw_ogod: | ||
+ | hostname: ffplieninggbwogod | ||
+ | pretty_hostname: | ||
+ | latitude: 48.198699460 | ||
+ | longitude: 11.798053090 | ||
+ | branch: stable | ||
+ | domain: ffmuc_muc_ost | ||
+ | director: ffmuc_muc_ost | ||
+ | modell: Ubiquiti UniFi-AC-MESH | ||
+ | ansible_ssh_host: | ||
+ | ff_pliening_gbw_dgod: | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | ff_pliening_gbw_cpod: | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | ff_pliening_gbw_kvm_ol: | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | ... #YAML end syntax</ | ||
+ | |||
+ | Die YAML-Konfigurationsdatei enthält entsprechende Bemerkungen, | ||
+ | |||
+ | <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 **'' | ||
+ | </ | ||
+ | |||
+ | Hier werden wir später auf eine **[[# | ||
+ | |||
+ | </ | ||
+ | |||
+ | Zum Testen, ob die definierten Hosts in unserem **inventory**-File auch erreichbar ist, können wir nun z.B. mit dem Befehl **'' | ||
+ | |||
+ | < | ||
+ | <pre class=" | ||
+ | <font style=" | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | " | ||
+ | " | ||
+ | }</ | ||
+ | <font style=" | ||
+ | ... | ||
+ | </ | ||
+ | <font style=" | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | }</ | ||
+ | <font style=" | ||
+ | ... | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | ==== 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 " | ||
+ | |||
+ | In dem nachfolgenden Konfigurationsbeispiel sehen wir uns eine kleinere Installation an, die zwar nicht genau dem Kriterien **" | ||
+ | |||
+ | * **Standard-Nodes**: | ||
+ | * **Offloader**: | ||
+ | |||
+ | 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** **'' | ||
+ | * 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 **'' | ||
+ | * ff_pliening_gbw_client | ||
+ | * ff-django-raspi | ||
+ | * ff_pliening_gbw_futro_mesh | ||
+ | * ff_pliening_gbw_kvm_ol | ||
+ | - **Gruppe** **'' | ||
+ | * 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** **'' | ||
+ | * ff_pliening_gbw_futro_mesh | ||
+ | - **Gruppe** **'' | ||
+ | * ff_pliening_gbw_kvm_ol | ||
+ | - **Gruppe** **'' | ||
+ | * ff_pliening_gbw_futro_mesh | ||
+ | * ff_pliening_gbw_kvm_ol | ||
+ | - **Gruppe** **'' | ||
+ | * ff_pliening_gbw_futro_mesh | ||
+ | * ff_pliening_gbw_kvm_ol | ||
+ | - **Gruppe** **'' | ||
+ | * 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. | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | === inventory - Beispiel === | ||
+ | Die **Inventory**-Datei **'' | ||
+ | $ vim ~/ | ||
+ | |||
+ | <file bash ~/ | ||
+ | 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 | ||
+ | </ | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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 **'' | ||
+ | |||
+ | Diese beiden Verzeichnisse wurden bereits bei der initialen Konfiguration unserer Ansible-Umgebung mit Hilfe des Ansible-Playbooks **'' | ||
+ | $ tree inventories/ | ||
+ | < | ||
+ | ├── group_vars | ||
+ | │ └── all | ||
+ | └── host_vars</ | ||
+ | |||
+ | |||
+ | Je **Gruppe** speichern wir also eine individuelle Datei im Verzeichnis **'' | ||
+ | $ vim ~/ | ||
+ | |||
+ | <file bash ~/ | ||
+ | ansible_ssh_port: | ||
+ | ansible_ssh_user: | ||
+ | ansible_ssh_private_key_file: | ||
+ | contact_info: | ||
+ | </ | ||
+ | |||
+ | Für die anderen Gruppe(n) verfahren wie ebenso. | ||
+ | |||
+ | Je **Host** speichern wir dann jeweils eine individuelle Datei im Verzeichnis **'' | ||
+ | $ vim ~/ | ||
+ | |||
+ | <file bash ~/ | ||
+ | hostname: ffplieninggbwegod | ||
+ | pretty_hostname: | ||
+ | latitude: 48.198652080 | ||
+ | longitude: 11.797969940 | ||
+ | branch: stable | ||
+ | domain: ffmuc_muc_ost | ||
+ | director: ffmuc_muc_ost | ||
+ | modell: Ubiquiti UniFi-AC-MESH | ||
+ | ansible_ssh_host: | ||
+ | |||
+ | 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 | ||
+ | ├── vml000030 | ||
+ | │ ├── exporter | ||
+ | │ ├── github | ||
+ | │ └── hostconfig | ||
+ | ├── vml050030 | ||
+ | ├── vml050040 | ||
+ | │ ├── prometheus | ||
+ | │ ├── grafana | ||
+ | │ ├── apache | ||
+ | │ └── hostconfig | ||
+ | ├── vml050250 | ||
+ | ├── vml070010 | ||
+ | ├── vml070020 | ||
+ | ├── vml070030 | ||
+ | ├── customer_no_001 | ||
+ | ├── customer_no_002 | ||
+ | ... | ||
+ | ... | ||
+ | └── customer_no_002 | ||
+ | </ | ||
+ | |||
+ | |||
+ | === Zusammenfassung === | ||
+ | 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, | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | ===== lorem ipsum dolor sit amet ===== | ||
:KRIT: FIXME :KRIT: | :KRIT: FIXME :KRIT: |