Dies ist eine alte Version des Dokuments!
Ansible - Erweiterte Konfigurationsbeispiel: Inventory
Nachdem wir uns bereits eingehend mit den Grundlagen, mit der Installation von Ansible und auch schon mit der Grundkonfiguration beschäftigt sowie erste Erfahrungen mit 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 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 CMDB1) zurück greifen und dort die Informationen pflegen, wie z.B.:
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.
Inventory
Zur Verwaltung/Inventarisierung von mehreren Knoten oder Hosts in unserer Infrastrukturumgebung verwendet Ansible Listen oder eine Gruppe von Listen, die man als Inventory bezeichnet. Im einfachsten Fall beschreibt solch eine Inventory-Datei lediglich Hosts und/oder deren Hostnamen bzw. IP-Adressen. Auf der anderen Seite kann man aber auch komplexe Landschaften abbilden und Eigenschaften einzelnen Hosts und /oder Gruppe zuordnen.
Im Kapitel (Grund-)Konfiguration - /etc/ansible/hosts hatten wir uns schon einmal kurz mit dem Thema Inventory beschäftigt. In den nachfolgenden Beispielen wollen wir nun intensiver auf Details dazu eingehen.
Im Kapitel How to build your inventory der Ansible-Onlinedoku finden sich dazu viele tiefergehende Informationen.
Ansible-Konfigurationsdatei und Inventory-Definition
In der Ansible-Konfigurationsdatei /etc/ansible/ansible.cfg zeigt zu Beginn der default-Eintrag auf die vorgenannte Datei /etc/ansible/hosts.
$ less /etc/ansible/ansible.cfg
... [defaults] # some basic default values... #inventory = /etc/ansible/hosts ...
Unsere eigene Konfigurationsdatei für die Hosts wollen wir aber künftig unserer Ansible-Administationsumgebung beim jeweiligen Admin-Users vorhalten. Im Beispiel unseres Adminusers django wäre dies entsprechend der Pfad /home/django/ansible/inventories/production. Das entsprechende Ansible: Directory Layout haben wir ja mit Hilfe unsere Ansible-Playbooks zur initialen Einrichtung bereits erfolgreich angelegt.
In unserer benutzerspezifischen Ansible-Konfigurationsdatei wird auch bereits auf das entsprechende Ziel verwiesen.
$ less ~/.ansible.cfg
some basic default values... # Generated by Ansible on 2022-09-22, do not edit manually! # default: #inventory = /etc/ansible/hosts inventory = /home/django/ansible/inventories/production
inventory - Beispiel mit einer yml-Datei
Dort legen wir uns unsere erweiterte Host-Datei im YAML-Format an.
$ vim ~/ansible/inventories/production/hosts.yml>
- ~/ansible/inventories/production/hosts.yml
--- #YAML start syntax (optional) all: hosts: # nicht zugeordnete Hosts n3r0.intra.nausch.org: g33k.intra.nausch.org: children: # Untermenge/-gruppe aller Hosts centos8: # Gruppe der definierten CentOS 8 Hosts vars: # Variablen, die für die ganze Gruppe gelten ansible_ssh_port: 22 ansible_ssh_user: ansible ansible_ssh_private_key_file: /home/django/.ssh/id_ed25519_ansible hosts: # Liste aller Hosts die dieser gruppe zugehören www8.dmz.nausch.org: ansible_ssh_host: 10.0.0.90 # Hostspezifische Ansible-Systemvariable centos7: # Gruppe der definierten CentOS 7 Hosts vars: # Variablen, die für die ganze Gruppe gelten ansible_ssh_port: 22 ansible_ssh_user: ansible ansible_ssh_private_key_file: /home/django/.ssh/id_rsa_ansible hosts: # Liste aller Hosts die dieser gruppe zugehören www7.dmz.nausch.org: ansible_ssh_host: 10.0.0.97 # Hostspezifische Ansible-Systemvariable # optische Abtrennung zu nachfolgenden Definitionen ffmucgluon: # Definition der Gruppe aaler Freifunk Knoten/Hosts vars: # Variablen, die für die ganze Gruppe gelten ansible_ssh_port: 22 ansible_ssh_user: root ansible_ssh_private_key_file: /home/django/.ssh/id_rsa4096_freifunk_2014 contact_info: 'Django [BOfH] | django@nausch.org | chat -> @django' hosts: # Liste aller Hosts die dieser gruppe zugehören ff_pliening_gbw_ug: # Host hostname: ff_pliening_gbw_ug # Hostspezifische Informationen / Variablen 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: 2001:608:a01:102:32b5:c2ff:fe56:62b1 ff_pliening_gbw_egod: # Host hostname: ffplieninggbwegod # Hostspezifische Informationen / Variablen pretty_hostname: ff_pliening_gbw_egod latitude: 48.198652080 longitude: 11.797969940 branch: stable domain: ffmuc_muc_ost director: ffmuc_muc_ost modell: Ubiquiti UniFi-AC-MESH ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fea9:22ed ff_pliening_gbw_ogod: # Host hostname: ffplieninggbwogod # Hostspezifische Informationen / Variablen pretty_hostname: ff_pliening_gbw_ogod latitude: 48.198699460 longitude: 11.798053090 branch: stable domain: ffmuc_muc_ost director: ffmuc_muc_ost modell: Ubiquiti UniFi-AC-MESH ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fec0:aaae ff_pliening_gbw_dgod: # Host hostname: ffplieninggbwdgod # Hostspezifische Informationen / Variablen prettyhostname: ff_pliening_gbw_dgod latitude: 48.198671230 longitude: 11.798122820 branch: stable domain: ffmuc_muc_ost director: ffmuc_muc_ost modell: Ubiquiti UniFi-AC-MESH ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fec6:c8eb ff_pliening_gbw_cpod: # Host hostname: ffplieninggbwcpod # Hostspezifische Informationen / Variablen pretty_hostname: ff_pliening_gbw_cpod latitude: 48.198726280 longitude: 11.798159030 branch: stable domain: ffmuc_muc_ost director: ffmuc_muc_ost modell: Ubiquiti UniFi-AC-MESH ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fec6:c8dd ff_pliening_gbw_kvm_ol: # Host hostname: ffplieninggbwkvmol # Hostspezifische Informationen / Variablen pretty_hostname: ff_pliening_gbw_kvm_ol latitude: 48.198646720 longitude: 11.798047720 branch: stable domain: ffmuc_muc_ost director: ffmuc_muc_ost modell: Red Hat KVM ansible_ssh_host: 2001:608:a01:102:5054:ff:fe9e:b358 ... #YAML end syntax
Die YAML-Konfigurationsdatei enthält entsprechende Bemerkungen, die die einzelnen Blöcke und Funktionen ausreichend beschreiben. Wie können so individuelle und Anwendungsspezifische Lösungen abbilden.
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.
Wollen wir später auch noch vertrauliche Informationen in einzelnen vault-Dateien vorhalten werden wir mit einer derartigen Inventarisierung Grenzen stossen!
Hier werden wir später auf eine andere/aufgeteilte Lösung einschwenken müssen.
Zum Testen, ob die definierten Hosts in unserem inventory-File auch erreichbar ist, können wir nun z.B. mit dem Befehl ansible -m ping all überprüfen.
www7.dmz.nausch.org | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python2.7"
},
"changed": false,
"ping": "pong"
}
...
www8.dmz.nausch.org | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: ssh: connect to host 10.0.0.90 port 22: No route to host",
"unreachable": true
}
...
lorem ipsum dolor sit amet
django