Dies ist eine alte Version des Dokuments!
Ansible - Erweiterte Konfigurationsbeispiele
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 und Überlegungen anstellen, wie z.B.:
- Wo laufen die Ansible Scripte?
- Wie wird sicher gestellt, dass alle Ziele auch erreichbar sind?
- Woher beziehen wir die Hostdefinitionen und deren Eigenschaften?
- Wo wollen wir Passwörter, Schlüssel und z.B. API-Key vorhalten?
- Wo sollen Ansible-Daten wie Inventories, Playbooks, Rollen und Variablen vorgehalten werden?
- Wie stellen wir sicher, dass der Code einheitlich und sauber ist?
- … ?
Nennen wir das der Einfachheit halber kurz: Plan A.
Alternativ könnte man aber auch, sinnlos wertvolle Arbeitszeit totschlagen, und sich in zahlreichen Besprechungsrunden austauschen und ausdiskutieren, wie man z.B. Hostinformationen aus einer /etc/genders1) extrahiert, in eine Inventory-Datei konvertiert und manuell mit Variablen anreichert oder sich abstimmen zu wollen, welcher Editor nun die bessere Wahl sein, nano, vim oder vscode mit diversen add-ons nun die bessere Wahl sei. Der geneigte Leser und verantwortlich agierende Admin wird sich doch wohl eher und das auch sehr schnell im Klaren sein, dass es keinerlei Sinn macht, sich in Nebensächlichkeiten zu verlieren, sondern eher Plan A zum Ziel führen wird.
Wir werden uns also zunächst grundlegende Gedanken zu unserer Ansible-Umgebung machen und die wesentlichen Dinge festzurren!
Plan A - die Aufgabenblöcke
Wo laufen die Ansible Scripte?
Auf welchem Host unsere Ansible-Scripte aka Playbooks laufen sollen, hängt im Wesentlichen erst einmal von den zu Grunde liegenden Sicherheitsvorgaben ab, die dem Admin als Leitplanken vorgegeben sind. Die könnte sein, ein dedizierter Linux-Administrations-Rechner oder ein speziell abgestellter Linux-Host im Intranet bzw, in einer eigens vorgegebenen DMZ sein. Wichtig ist dabei nur dass dieser Host reproduzierbar wiederhergestellt oder bei Bedarf auch dupliziert werden kann. Ziel muss dabei immer sein, dass auf allen Maschinen der Admin die gleiche sichere Umgebung vorfindet und keine manuellen Anpassungen mehr vorgenommen werden müssen.
Wie so eine Umgebung geschaffen werden kann, wollen wir uns nun an Hand zweier Beispiele genauer ansehen.
- Im ersten Beispiel wollen wir mit Hilfe eines Kickstart Files in einer PXE-Umgebung automatisiert in einer KVM-Umgebung einen eigens vorgesehenen Linux-Host installieren.
- Bei Beispiel zwei werden wir unsere Ansible-Umgebung mit Hilfe von Ansible selbst konfigurieren.
django