Ansible Konfiguration Tutorial Teil 6

Ansible besitzt eine vielfältige abgestufte Konfiguration.

Ansible Logo (Quelle: Von Ansible/Red Hat – Wikipedia)

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.

Ansible Konfiguration: Über die /etc//ansible/ansible.cfg wird das Inventory aus /etc/ansible/hosts geladen, die Nodes darin existieren aber nicht.

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.

Die Nodes in ~/ansible/hosts werden zwar gefunden, existieren aber nicht.

Das war zu erwarten. Aber jetzt wird’s interessant, wenn ich das nochmal mit der alletc Gruppe von oben versuche:

erneuter Aufruf des Playbook für die alletc Group

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.

Die ansible.cfg im Projektverzeichnis bindet die inventory.yml ein und das Playbook wird erfolgreich abgearbeitet.

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.