Ansible besitzt eine vielfältige abgestufte Konfiguration.
1 | Einführung |
---|---|
2 | Das Inventory |
3 | Über Rollen und Tasks |
4 | Die Module |
5 | Playbooks |
6 | Konfiguration |
7 | gather_facts |
8 | eigene Module |
Konfigurationsdateien
Ansible benutzt auf verschiedenen Ebene Konfigurationsdateien, deren Format immer gleich ist und unterschiedliche Prioritäten haben
Ich hatte schon erwähnt, dass der Name der Konfigurationsdatei eigentlich immer ansible.cfg ist.Die Konfiguration geschieht immer auf dem Control Node.
Als Beispiel benutze ich hier mal den Key inventory=
mit dem die Datei eingestellt wird, die das Inventory enthält. Damit lässt sich der Mechanismus der verschiedenen Konfigurationsdateien am besten darstellen.
Konfiguration auf Systemebene
Unter /etc/ansible/ansible.cfg
kann die Konfiguration für den gesamten Control Node geschehen. Diese Einstellungen werden für alle Playbooks benutzt, so lang keine andere Konfigurationsdatei etwas anderes sagt. Diese Datei (nicht mal das Verzeichnis) muss nicht unbedingt vorhanden sein. Ich benutze sie nicht.
Zum Test für diesen Tutorialteil habe ich sie mal mit diesem Eintrag angelegt:
Inventory=/etc/ansible/hosts
Außerdem habe ih die Datei /etc/ansible hosts
wie folgt erzeugt:
alletc:
hosts:
etc1:
etc2:
Die Nodes darin existieren nicht wirklich und dienen nur der Veranschaulichung.
Wenn ich jetzt das Playbook starte, erhalte ich nur Fehlermeldungen.
Konfiguration auf Benutzerebene
Die Datei $HOME/ansible/.ansible.cfg
enthält die Konfiguration für den Benutzer. Sie überschreibt die Systemkonfiguration. Auch diese
Datei lege ich neu an:
inventory = ~/ansible/hosts
Das angeben Inventory ist ähnlich zu dem auf Systemebene:
allhome:
hosts:
home1:
home2:
Es existieren jetzt beide Konfigurationsdateien unter /etc/ansible/ansible.cfg
und ~/.ansible.cfg
.
Ich kann jetzt nochmal das Playbook für die allhome Group starten, auch diese Nodes existieren nicht.
Das war zu erwarten. Aber jetzt wird’s interessant, wenn ich das nochmal mit der alletc Gruppe von oben versuche:
Konfiguration auf Projektebene
Auch in jedem Projektverzeichnis kann eine ansible.cfg
liegen. Sie überschreibt sowohl die Konfiguration im Homeverzeichnis als auch die unter /etc/ansible
Die Group wird nicht gefunden, weil unsere Ansible Konfiguration im Homeverzeichnis ein eigenes Inventory konfiguriert, dass diese Group nicht definiert.
Den Inhalt der inventory.yml habe ich bereits gezeigt. In der ansible.cfg im Projektverzeichnis wird dieses so definiert:
inventory = inventory.yml
Damit kann ich das Playbook für die stack4 Group laufen lassen, während alletc und allhome nicht mehr verfügbar sind.
Environment Variablen
Die meisten Konfigurationsschlüssel lassen sich auch über Environment Variablen der Shell einstellen.
Beispielsweise kannst mit ANSIBLE_HOME
den Pfad zum Homeverzeichnis für Ansible überschreiben.
KonfigurationssParameter
Es gibt eine riesige Möglichkeit von Konfigurationsparametern in der ansible.cfg
. Da ich hier unmöglich alle im Einzelnen auflisten kann, verweise ich dich an diese Übersicht.
Exemplarisch möchte ich nur einige hervorheben, die ich häufig verwende.
- inventory= Damit stellst du den Pfad zum Inventory ein. Das habe ich ausführlich oben beleuchtet
- timeout= konfiguriert den Timeout in Sekunden für den Aufbau der ssh-Verbindung. Ich hab den üblicherweise auf 60 gesetzt, falls ein Raspi mal wieder etwas länger brauchen sollte.
- private_key_file= Der Pfad zum Private Key, dies ist i.d.R. wichtig, wenn du mit mehreren Keys arbeitest.
- ssh_args= Hier kannst du zusätzliche Argumente für den ssh Client eintragen.
Sicherheit
Gerade bei der Konfigurationsdatei auf Systemebene solltest du daran denken, dass diese von allen Benutzern auf dem System genutzt wird. Konfigurierst du dort mit private_key_file= einen privaten Schlüssel, kann jeder Nutzer ein Playbook schreiben, dass deine Managed Nodes manipuliert!
Das war’s für diesen Tutorialteil. Im nächsten wollen wir mal gather_facts einschalten und sehen, was passiert.