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.:

• Wie und wo wollen wir Passwörter, Schlüssel und z.B. API-Key vorhalten?
• Wo laufen die Ansible Scripte?
• Woher beziehen wir die Hostdefinitionen und deren Eigenschaften?
• Wie wird sicher gestellt, dass alle Ziele auch erreichbar sind?
• Wo sollen Ansible-Daten wie Inventories, Playbooks, Rollen und Variablen vorgehalten werden?
• Wie stellen wir sicher, dass der Code einheitlich und sauber ist?
• Spaß bei der Arbeit? Mitnichten, bei uns hier doch nicht, oder doch?
• … ?

Nennen wir das der Einfachheit halber kurz: Plan A.

Wir werden uns also zunächst grundlegende Gedanken zu unserer Ansible-Umgebung machen und die wesentlichen Dinge festzurren!

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 einiger 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.
• Anschliessend werfen wir einen Blick auf das Thema Ansible-Vault, sprich wie gegen wir mit vertraulichen Informationen/Daten rund um Ansible um.
• Bei Beispiel Nummer drei werden wir unsere Ansible-Umgebung mit Hilfe von Ansible selbst konfigurieren.
• Das Thema „Woher beziehen wir die Hostdefinitionen und deren Eigenschaften?“ sehen wir uns beim Konfigurationsbeispiel 4 etwas genauer an.
• Eine entscheidende Frage bei einem Ansible-Controll-Node ist natürlich immer die Gretchenfrage, wie erreicht man von diesem alle gewünschten Ziele? Muss dies zwingend eine fest definierte Maschine ein Linux-Host im Intranet bzw, in einer eigens vorgegebenen DMZ sein, der via speziale Firewall-Regeln eine Freischaltung für alle betreffenden Hosts seine Ziele erreichen kann? Oder kann man das auch anderes, einfacher und ebenso sicher bewerkstelligen? Diese Fragestellung werden wir im vierten Konfigurationsbeispiel genauer beleuchten.
• Befasst man sich über einen längeren Zeitraum mit Ansible wird man unweigerlich feststellen, dass sich die Art und Weise wie man Playbooks verfasst unweigerlich ändert, da man unentwegt lernt und seinen Code optimiert. Feste Strukturen und Rahmenbedingungen in Form von Eigendisziplin, kann hier ungemein helfen. Arbeitet man in einem Team an verschiedenen Projekten, sind solche Leitplanken Voraussetzung, damit alle möglichst schnell verstehen, was mit Hilfe der Playbooks erreicht werden soll und kann und vor allem wie. Bei der Sicherstellung dass Code auch einheitlich, modular und wiederverwendbar wird, greifen wir bei der Erstellung von Playbooks auf Rollen und Ansible-Module zurück. Diese Themen beleuchten wir im fünften Abschnitt dieser Doku-Reihe hier.
• Beim Thema Code-Überprüfung greifen wir auf das Projekt Ansible-Lint zurück, welches helfen kann seinen Code einheitlich, strukturiert und code-technisch sauber zu halten. Wollen wir doch damit bewährte Praktiken, Muster und Verhaltensweisen fördern sowie gleichzeitig häufige Fallstricke vermeiden, die oft genug leicht zu Fehlern führen und dabei die Wartung des Codes erschweren können.

1. Admin Benutzer verwalten (v1)
   Oft steht man vor der Herausforderung, Admin-Konten auf unzähligen Zielsystemen anzulegen und wieder zu löschen. So sind im Zuge eines onboarding von neuen Admins jeweils Konten anzulegen und mit Passworten und Schlüsselmaterial zu versorgen. Beim Ausscheiden eines Admins, müssen dessen|ihre Konten samt Passworten und Schlüssel wieder gelöscht werden.
   Möchte ein bestehender Admin sein|ihr Passwort oder Schlüssel ändern, kann dies auch zu einer zeitraubenden Tätigkeit ausarten. In diesem Beispiel werden wir also das Anlegen und Löschen der Konten samt Passwörter und Schlüsselmaterial sowie die Pflege dieser Daten mit Hilfe von Ansible automatisieren?
2. Admin Benutzer verwalten (v2)
   im zweiten Beispiel werden wir uns mit dem Thema: „Wie prüfen wir die Variablen aus dem Inventory auf Validität, Plausibilität und ob diese gesetzte sind?“ Hierzu verwenden wir das Ansible Modul ansible.builtin.assert und verfeinern unser Playbook aus dem Beispiel 1.

• Zurück zur "Ansible"-Übersicht
• Zurück zu >>Projekte und Themenkapitel<<
• Zurück zur Startseite