© mattlphotography / 123rf.com

Im zweiten Teil unseres Ansible-Workshops geht es ans Eingemachte. Dabei reicht die Bandbreite von Variablen und Passwörtern über Ansibles Template-Engine bis hin zum Erstellen eigener Rollen.

Zu Recht erfreut sich Ansible in der Welt der Automation großer Beliebtheit. Beispielsweise ist seine Deklarationssprache deutlich intuitiver und dadurch einfacher zu erlernen als jene der Konkurrenz – ganz davon abgesehen, dass ein gut geschriebenes Ansible-Playbook sich quasi selbst dokumentiert.

Neben der Klärung der grundlegenden Begrifflichkeiten des Ansible-Universums hat Teil 1 dieses Workshops die Wissensgrundlage geschaffen, um mit Ansible produktiv zu arbeiten: Außer um die günstigste Struktur für ein Ansible-Verzeichnis ging es etwa um die Frage, wie der Admin ein mit Ansible kompatibles Inventar-File anlegt, aus dem Ansible die Zielsysteme für seine Aktionen destilliert. Auch zentrale Begriffe standen auf dem Plan, sodass nun jedem Ansible-Neuling in etwa klar sein sollte, worum es sich bei Rollen und Playbooks handelt und was sie voneinander unterscheidet.

Der vorliegende Teil beschäftigt sich damit, das geballte Wissen aus Teil 1 sinnvoll mit weiteren Grundlagen zu verbinden und Administratoren so in die Lage zu versetzen, viele alltägliche Aufgaben mit Ansible zu meistern. Ein paar essenzielle Details fehlen noch: Extrem praktisch sind in Ansible etwa die Variablen. Damit lassen sich zum Beispiel auf Basis des Hosts, auf dem Ansible ein Playbook ausführt, bestimmte Konfigurationsparameter dynamisch übernehmen.

In dasselbe Horn stößt die Template-Engine des Werkzeugs. Sie rollt auf einzelnen Systemen spezifische Konfigurationsdateien aus, indem sie die in Templates genutzten Variablen durch konkrete Werte ersetzt. Schließlich geht es daran, die erste eigene Rolle zu verfassen. Das kann nötig sein, wenn es für ein bestimmtes – oft internes – Programm keine fertige Rolle im Netz gibt oder wenn es gilt, auf Systemen Aufgaben zu erledigen, für die noch keine vorbereiteten Rollen innerhalb der F/LOSS-Szene exisitieren.

Als sinnvolle Erweiterung dazu stehen auch Passwörter auf dem Lehrplan. Die meisten Administratoren verwalten Ansible-Rollen in Git. Vom Standpunkt der Sicherheit aus verbietet es sich jedoch, Passwörter im Klartext in Dateien zu vermerken, die anschließend frei zugänglich im Git-Verzeichnis landen. Ansible bringt als Lösung dafür Vault mit, um das es im Folgenden ebenfalls geht.

Mächtige Variablen

Variablen (Abbildung 1) kennen die meisten Administratoren schon vom Umgang mit Programmiersprachen. In Ansible lassen sie sich extrem effizient nutzen, um beispielsweise dasselbe Playbook auf Dutzenden verschiedenen Hosts ohne lokale Anpassungen zu betreiben. Dafür sollte man allerdings verstanden haben, wie Variablen funktionieren. Zum Glück ist das in Ansible nicht sehr kompliziert.

Abbildung 1: Variablen sind ein ausgesprochen effizientes Werkzeug, um in Ansible auf der Ebene einzelner Hosts Platzhalter durch konkrete Werte zu ersetzen.

Ansible unterscheidet zwischen Gruppen- und Host-Variablen. Wer sich an die Ausführungen in Teil 1 der Serie zum Thema Inventar erinnert, weiß auch um die Möglichkeit, Hosts in Gruppen einzuordnen. Genau hier setzen die Gruppenvariablen an: Sie gelten stets für die Mitglieder der im Inventar definierten Gruppe. Möchten Sie für den Log-Sammeldienst Promtail von Loki beispielsweise die Ziel-URL festlegen, an die sämtliche Log-Daten zu senden sind, könnte der passende Parameter dafür »loki_url« lauten und für die Gruppe all definiert sein. Sollen einzelne Host-Gruppen des Setups jeweils autarke Loki-Instanzen nutzen, könnten Sie denselben Parameter für die einzelnen Gruppen definieren, aber mit unterschiedlichen Inhalten. In den passenden Ansible-Rollen würden Sie später stets auf dieselben Variablen zugreifen, die Ansible automatisch pro Host anhand der definierten Werte befüllt.

Gruppenvariablen definieren Sie über Dateien im Ordner »group_vars/« im Ansible-Arbeitsverzeichnis. Der Name der Dateien muss dabei ohne Endungen dem Namen der Gruppe entsprechen, auf die die Variablen sich beziehen. Für die Gruppe compute definieren Sie die Gruppenvariablen entsprechend in »group_vars/compute«. Die Syntax von Variablen ist simpel: Sie folgen dem Schema »Name: “Wert“«, also beispielsweise »loki_url: “http://10.0.0.1:9200/api”«. Bei der Verwendung von »true« und »false« gilt es, Vorsicht walten zu lassen: Ansible interpretiert »true« und »false« als boolesche Werte, »”True”« und »”False”« jedoch als Strings. Das sollten Sie im Hinterkopf behalten.

Nach dieser Einführung ist es kein Hexenwerk, die Idee hinter Host-Variablen zu erkennen: Sie gelten stets nur für den Host, für den sie definiert wurden. Sie liegen im Ordner »host_vars/« innerhalb des Ansible-Arbeitsverzeichnisses. Ihr Name muss dabei jenem aus dem Inventar entsprechen, beispielsweise »host_vars/dc1-r1-ra42-1.mgmt.int« für den im Inventar als »dc1-r1-ra42-1.mgmt.int« geführten Host. Die syntaktischen Vorgaben für Host-Variablen sind mit jenen für Gruppen deckungsgleich.

Variablen können als einzelne Variable mit einem Wert auftreten oder mehrere Werte enthalten, durch die Sie in einer Rolle dann per »for« iterieren. Um etwa für Firewalld die Netzwerkschnittstellen für die internen Zonen zu definieren, käme das erste Konstrukt in Listing 1 infrage. Darüber hinaus lassen sich Variablen in Ansible als eine Art Array nutzen, wobei für jeden definierten Parameter zusätzliche Parameter festgelegt sind. Der zweite Abschnitt aus Listing 1 zeigt als Beispiel die Definition von VNI-Adressen für Setups mit EVPN und Layer-3-Routing.

# Beispiel Netzwerk-Schnittstellen
internal_interfaces:
  - br0
  - br2
# Beispiel VNI-Adressen
vni_interfaces:
  - id: 10010
    bridge_access: 10
    vxlan_mcastgrp: 239.1.45.1
  - id: 10020
    bridge_access: 20
    vxlan_mcastgrp: 239.1.45.2
    advertise_svi_ip: true

Die Hauptvariable dabei heißt noch immer »vni_interfaces«, aber in einer Rolle würden Sie mit »for« oder anderen Werkzeugen durch das Array iterieren und die einzelnen Werte abgreifen. Konstrukte wie diese kommen in Ansible fast ausschließlich zum Einsatz, wenn es um das Ausrollen von Konfigurationsdateien geht, die es mit entsprechenden Werten zu befüllen gilt.

Das wirft schließlich die Frage auf, wie aus Templates oder Rollen heraus der Zugriff auf die Variablen funktioniert. Grundsätzlich gilt: »”{{ Name }}”« bietet Zugriff auf den Inhalt der jeweiligen Variablen. Um auf ein Unterelement zuzugreifen, hängen Sie es an den Namen der Variablen an, etwa »”{{ interface.id }}”«. Das setzt jedoch voraus, dass Sie beispielsweise aus einer Template-Datei heraus das Array durchlaufen und »for« zum Einsatz kommt.

Um etwas mehr Ordnung in Ihre Variablenordner zu bringen, legen Sie darin für die jeweiligen Gruppen oder Hosts Unterordner an. Die Variablen für »dc1-r1-ra42-1.mgmt.int« können also auch in »host_vars/dc1-r1-ra42-1.mgmt.int/vars« stehen. Das bietet den Vorteil, dass der eigentlichen Variablendatei auch eine »secrets«-Datei zur Seite stehen kann, also »host_vars/dc1-r1-ra42-1.mgmt.int/secrets«. Darin erwartet »ansible-vault« seine Passwörter, wenn es zum Einsatz kommt. Für Gruppen gilt dieser Trick analog.

Nicht unerwähnt bleiben sollen schließlich die Variablen, die Ansible Ihnen ganz ohne Ihr Zutun zur Verfügung stellt. Die heißen im Ansible-Jargon allerdings nicht Variablen, sondern Facts, und enthalten allerlei nützliche Details über das System. Der Aufruf funktioniert anders als der von Variablen: Um beispielsweise den Host-Namen des jeweiligen Systems zu verarbeiten, verwenden Sie »ansible_facts[‘nodename’]«; die Version des laufenden Kernels steht im Fact »ansible_-Kernel«.

Facts sind deshalb praktisch, weil sie viele Fingerübungen sparen. Die laufende Version des Kernels wäre schließlich mit einigen Verrenkungen auch auf der Kommandozeile gut herauszufinden. Dass es den entsprechenden Fact aber schon gibt, macht jede Bastelei überflüssig. Eine aktuelle Referenz über die von Ansible bereitgestellten Facts enthält die Ansible-Dokumentation [1].

Die Anatomie einer Rolle

Im Folgenden wollen wir uns mit Ansible-Rollen beschäftigen. Zur Erinnerung: Als Rolle bezeichnet man einen üblicherweise auf eine spezifische Aufgabe zugeschnittenen Satz von Ansible-Anweisungen samt aller benötigten Anhänge. Anhänge können dabei Template-Dateien sein, die es mit den korrekten Inhalten auf das Zielsystem zu bringen gilt, oder statische Dateien, die ihren Weg auf das Zielsystem finden müssen. Vor allem aber handelt es sich dabei um Arbeitsanweisungen, die mit dem eigentlichen Dienst nur mittelbar etwas zu tun haben.

Oft findet sich in Ansible etwa die Situation, dass eine Rolle einen Dienst auf ein System ausrollen und konfigurieren soll. Damit läuft der Dienst aber noch nicht, und ein manueller Start per Ansible-Anweisung wäre auch nur die halbe Miete. Schließlich müssen auch Dienste mit Systemd irgendwie in die Boot-Reihenfolge integriert werden. Die gute Nachricht: Ansible verfügt über Schnittstellen zu allen gängigen Init-Systemen, darunter selbstverständlich auch Systemd. Den gesamten mehr oder minder komplexen Vorgang, der nötig ist, um einen Dienst auf einem System dauerhaft zum Laufen zu bringen, verbirgt Ansible vor dem Administrator. Der muss in seiner Rolle nur noch die entsprechenden Anweisungen hinterlegen.

Wenn Sie dieser Anleitung bis hierhin gefolgt sind, haben Sie zwar ein Ansible-Arbeitsverzeichnis mit den Variablenordnern und einem Playbook. Einen »roles«-Ordner gibt es aber noch nicht, und genau das soll sich jetzt ändern. Die Aufgabe ist denkbar simpel: Sie schaffen eine Ansible-Rolle, die auf den Zielsystemen den SSH-Login mit Passwort als root unterbindet. Sie rollt für Root eine passende Datei »~/.ssh/authorized_keys« aus und bohrt danach die Firewall in »firewalld/« auf, damit SSH-Verbindungen von außen auch in der »public«-Zone von Firewalld erlaubt sind.

Dazu gilt es zunächst, in »roles/« im Ansible-Arbeitsverzeichnis einen Ordner für die zu erstellende Rolle anzulegen (Abbildung 2). Es empfiehlt sich, lokale Rollen irgendwie gesondert zu kennzeichnen. Am einfachsten klappt das über ihren Namen: Weil es sich im Beispiel um eine Rolle für das Linux-Magazin handelt, könnte die nun zu erstellende Rolle »lm.sshd« heißen und im gleichnamigen Ordner liegen. Haben Sie ihn angelegt, ist es an der Zeit, sich mit der Anatomie einer Rolle und den von ihr benötigten Dateien zu befassen.

Abbildung 2: Die Rolle für den Node-Exporter von Prometheus fällt bereits etwas komplexer aus. Auch hier ist die grundlegende Anatomie einer Rolle mit den wichtigsten Ordnern aber gut zu erkennen.

Innerhalb des Ordners einer Rolle muss es zumindest einen Ordner »tasks/« mit einer Datei »main.yml« darin geben. Er dient quasi als Rückgrat der gesamten Rolle. Aus der hier hinterlegten »main.yaml« bezieht Ansible sämtliche Anweisungen für Arbeitsschritte auf den Zielsystemen. Hinzu gesellt sich ein weiterer Ordner namens »handlers/«, falls von Ansible auszuführende Arbeitsschritte auf den Systemen sekundäre Aktionen auslösen sollen (Abbildung 3), etwa den Neustart eines Diensts. Auch in »handlers/« gibt es wiederum eine Datei namens »main.yml«, in der die jeweiligen Aktionen aufgelistet sind.

Abbildung 3: Handler sorgen dafür, dass Ansible Dienste neu startet, falls sich ihre Konfiguration ändert. Wie hier setzen sie meist auf Systemd.

Achtung: In den Task-Definitionen kommt später das Schlüsselwort »notify« zum Einsatz, das eine sekundäre Aktion auslöst. Es bezieht sich stets auf die in den Handlern definierten Aktionen. Soll es also eine Aktion »restart ssh« geben, müssen Sie entlang der schon im ersten Teil des Workshops beschriebenen allgemeinen Ansible-Syntax in »handlers/main.yml« eine Aktion »restart ssh« definieren. Anderenfalls funktioniert »notify: restart ssh« aus der Aktion in »tasks/main.yml« heraus nicht.

Zwei weitere Ordner finden sich in vielen Ansible-Rollen: »templates/« enthält Templates im Jinja-2-Format. Sie dienen als Vorlage für Dateien, die mit Host-spezifischen Werten auf das Zielsystem ausgespielt werden sollen. Darüber hinaus gibt es den Ordner »files/«, der im Grunde identisch funktioniert. Hier liegen aber keine Templates, sondern fertige Dateien, deren Inhalt es 1:1 zu kopieren gilt.

Tasks für SSH

Im Fokus der Beobachtungen steht zunächst die »main.yml« im Ordner »tasks/« der frisch angelegten Rolle. Hier fallen drei Arbeitsschritte an: In der »sshd_config« auf dem Zielsystem muss die Zeile, die den Parameter »PasswordAuthentication« enthält, »PasswordAuthentication no« lauten. Das Beispiel geht also davon aus, dass OpenSSH zum Einsatz kommt und dessen Konfigurationsdatei sich an der Standardstelle für SSH-Installationen befindet. Weichen lokale Setups von diesen Werten ab, müssen Sie die Beispiele im Folgenden entsprechend abwandeln. Sie haben hier jedenfalls mehrere Möglichkeiten, das gewünschte Ziel zu erreichen.

Eine Möglichkeit bestünde darin, eine komplette »sshd_config« im Ordner »files/« auszuliefern und sie mittels der Ansible-Funktion »copy« auf die Zielsysteme zu kopieren. Auch ein Template im Ordner »templates/« böte eine Option; dann wäre es sogar möglich, die Regelungen zu SSH pro System individuell einzustellen. Im konkreten Kontext würden beide Lösungen aber dazu führen, dass eine riesige Datei im Ansible-Git landet, obwohl nur ein einzelner Parameter von der Standardkonfiguration abweichen soll.

Hier hilft die Funktion »lineinfile« von Ansible aus der Patsche. Sie kommt ab Werk mit ausgeprägtem Regex-Matching und erlaubt es so, einzelne Dateien direkt an Ort und Stelle zu modifizieren. Das Beispiel in Listing 2 zeigt, wie die Anweisung in »tasks/main.yml« dazu aussehen muss. Bitte beachten Sie den Trigger per »notify«, der nach der Änderungen einen Neustart des SSH-Daemons veranlasst.

- name: Disable password-based SSH login
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^PasswordAuthentication'
    line: 'PasswordAuthentication no'
  notify:
    - restart ssh

Die zweite anstehende Aufgabe besteht darin, in »~/.ssh/authorized_keys« sämtliche Schlüssel zu hinterlegen, die sich per SSH als root mit ihrem SSH-Schlüssel auf dem System anmelden sollen. Dafür deponieren Sie im Ordner »files/« zunächst sämtliche benötigten SSH-Schlüssel, im Beispiel etwa in Dateien mit den Namen »alice«, »bob« und »charlie«.

Dann springt Ihnen die Ansible-interne Funktion »authorized_keys« zur Seite: Diese Ansible-Besonderheit entfernt die gesamte Komplexität, die nötig wäre, um sich auf einem beliebigen System mit den lokalen Vorlieben von SSH zu befassen. Listing 3 enthält die vollständige Anweisung, die auf praktisch sämtlichen Linux-Systemen funktionieren sollte.

- name: Set up authorized keys
  authorized_key:
    user: root
    state: present
    key: '{{ item }}'
  with_file:
    - alice
    - bob
    - charlie

Die Firewall steuern

Schritt drei besteht schließlich darin, die Firewall so aufzubohren, dass sie eingehende Verbindungen per SSH in der »public«-Zone erlaubt. Wieder demonstriert Ansible seine Stärke: Die eingebaute Funktion »firewalld« steuert Regeln für Firewalld, ohne dass Sie irgendwelche Ausflüge auf die Kommandozeile unternehmen müssten.

Der Schatz der in Ansible integrierten Funktionen ist riesig. Das Bearbeiten von SSH-Schlüsseln oder der Firewalld-Regeln sind nur zwei kleine Beispiele. Wann immer eine in Ansible integrierte Funktion für eine Aufgabe zur Verfügung steht, sollten Sie ihr unter allen Umständen den Vorzug gegenüber einer selbst konstruierten Bastellösung geben. Die Builtin-Funktionen von Ansible werden von der gesamten Ansible-Community ständig verbessert und gewartet, sind also robust und sicher.

Obendrein wäre die Alternative zur Nutzung der eingebauten Module regelmäßig ein hässlicher Befehl für die Kommandozeile, den Sie direkt aus Ansible heraus aufrufen müssten. Dann würde aber auch eine eventuell daraus resultierende Fehlermeldung nicht durch Ansible abgefangen und sinnvoll interpretiert, sondern einfach nur an Sie durchgereicht. Eine umfangreiche und sinnvolle Systempflege, wie sie die Ansible-Anweisung in Listing 4 beschreibt, wäre damit nur schwer möglich.

- name: Enable SSH access
  firewalld:
    zone: public
    service: ssh
    permanent: yes
    state: enabled
  notify: reload firewalld

Trigger konfigurieren

Die Ansible-Anweisungen im Beispiel enthalten zwei Trigger für »notify«: »reload firewalld« und »restart ssh«. Um beide Trigger zu implementieren, hinterlegen Sie das Beispiel aus Listing 5 im Ordner der Rolle als »handlers/main.yml«.

- name: restart ssh
  service:
    name: sshd
    state: restarted
    enabled: yes
- name: reload firewalld
  shell: firewall-cmd --reload

Haben Sie die grundlegende Arbeitsweise von Ansible verstanden, können Sie die Datei nun bereits interpretieren: Der erste Handler nutzt die »service«-Funktion von Ansible, um den Systemd-Dienst »sshd« neu zu starten. Der zweite Handler führt auf der Kommandozeile den Befehl »firewall-cmd –reload« aus.

Hier ließe sich zu Recht kritisch anmerken, dass »shell« statt »service« zum Einsatz kommt, obwohl derselbe Effekt auch mittels »service« zu erreichen wäre, wie Listing 6 beweist. Die erste Option ist jedoch insbesondere auf Systemen mit älterem Systemd und älterem Firewalld nötig, denn dort funktionierte der Reload des Firewall-Daemons mittels Systemd nicht immer reibungslos.

- name: reload service firewalld
  systemd:
   name: firewalld
   state: reloaded

Die frisch angelegte Rolle ist damit fertig. Sie lässt sich in Betrieb nehmen, indem Sie ein Playbook anlegen und darin folgenden Befehl einfügen:

  roles:
    - lm.ssh

Bei jedem Aufruf des Playbooks führt Ansible danach sämtliche Anweisungen der genannten Rolle auf den im Playbook in »hosts« definierten Systemen aus.

Heikle Templates

Zugegeben: Das beschriebene Beispiel und insbesondere die »lineinfile«-Funktion von Ansible sind an dieser Stelle zwar praktisch, für die Mehrzahl der Fälle reicht dieses Konstrukt aber nicht aus. Wie beschrieben, wird der im Umgang mit Ansible etwas versiertere Administrator früher oder später zu Templates greifen; die sollen hier daher nicht zu kurz kommen.

Die gute Nachricht lautet: In der Mehrzahl der Fälle genügt es, in einem Template eine oder mehrere Variablen zu ersetzen. Dazu platzieren Sie das jeweilige Template im Ordner »templates/«, wobei Sie darauf achten, dass der Name der Datei mit ».j2« endet. Hier kann man einmal mehr erkennen, dass Ansible auf Jinja 2 als Template-Engine basiert. Variablen im Template, die Ansible zur Laufzeit durch tatsächliche Werte ersetzen soll, stellen Sie analog zum Vorgehen in Ansible selbst in geschweifte Klammern. Eine valide Zeile in einem Jinja-Template wäre folglich »listen_address = {{ listen_address }}«. Auf diese Weise lässt sich das Gros der Konfigurationsdateien abfrühstücken.

Der Vollständigkeit halber sei erwähnt, dass Jinja auch deutlich komplexere Konstrukte mit »if«, »foreach« und etlichen weiteren Operatoren erlaubt. Diese im Detail zu beschreiben, würde den Rahmen dieses Workshops sprengen. Zudem kommen Sie wie beschrieben im Alltag mit solchen Konfigurationsdateien eher selten in Berührung. Dem Autor dieses Artikels ist als Worst-Case-Beispiel der FRR-Daemon für BGP in Erinnerung (Abbildung 4). Dessen Template für eine EVPN-Konfiguration kommt auf über 200 Zeilen, die zum größten Teil aus Skriptanweisungen für Jinja bestehen. Das ist aber eben die Ausnahme, nicht die Regel.

Abbildung 4: Templates können dank Jinja 2 ausgesprochen mächtig werden, doch so komplex wie hier im Falle von FRR werden sie selten.

Haben Sie das Template fertiggestellt, müssen Sie es auf den Zielsystemen ausrollen. Dafür kommt die »template«-Funktion in Ansible zum Einsatz (Listing 7). Beim nächsten Aufruf rollt Ansible das Template komplett auf dem Zielsystem aus. Dabei ersetzt es die Inhalte der Variablen in der Konfigurationsdatei durch die Inhalte der für den Host definierten Variablen. Eventuelle »notify«-Anweisungen samt entsprechender Handler für den Neustart des betroffenen Daemons müssen Sie gegebenenfalls zusätzlich implementieren.

- name: Deploy /etc/daemon/daemon.conf
  template:
    src: daemon.conf.j2
    dest: /etc/daemon/daemon.conf
    owner: root
    group: root
    mode: 0644

Passwörter schützen

Am Ende dieses zweiten Workshop-Teils stellt sich die Frage, wie sich sensible Daten wie Passwörter in Ansible schützen lassen. Dabei spielt Ansible-Vault eine wichtige Rolle. Grundsätzlich handelt es sich auch bei einem Vault-File um eine Datei, die Variablen enthält. Allerdings sind diese anders als bei normalen Variablen-Dateien nicht im Klartext gespeichert.

Innerhalb des Ordners für einen Host legen Sie zunächst mittels »ansible-vault create secrets.yml« eine Datei namens »secrets.yml« an (Abbildung 5). Dabei öffnet sich der in »$EDITOR« definierte Editor und erlaubt nach dem Festlegen eines Passworts das Bearbeiten. Innerhalb der Datei könnte ein valider Eintrag etwa »password: strenggeheim« sein. In einer Rolle oder einem Template verweisen Sie später ganz regulär mit »{{ password }}« auf die Variable.

Abbildung 5: Nichts zu holen: Die verschlüsselten Vault-Dateien von Ansible verhindern ein Abfischen von Geheimnissen.

Damit Ansible später Vault aufruft, um Zugriff auf die Datei zu erhalten, müssen Sie zudem den »ansible-playbook«-Aufruf um den Parameter »–ask-vault-pass« erweitern. Dann fragt Ansible nach dem jeweiligen Passwort, und der Ablauf funktioniert wie gewohnt. (jcb)