Ansible - Erweiterte Konfigurationsbeispiele

Bild: Ansible Logo

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

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. Vielmehr wird dieser zum Schluss kommen, dass wohl eher Plan A zum Ziel führen wird! Da hilft auch kein Verweis auf altbackene Slogans wie z.B. Spezialisten wissen mehrm(

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.

Links


1)
aus dem Jahre 2004!
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
  • linux/ansible/detail.txt
  • Zuletzt geändert: 01.12.2022 20:19.
  • von django