Schlagwort-Archive: resolv.conf

DNS-Konfiguration mit Ansible

Um neue Linux-VMs mit einer funktionierenden und zu unserer Umgebung passenden DNS-Konfiguration zu provisionieren, habe ich mir eine kleine Ansible-Rolle namens resolv.conf erstellt, welche ich im Folgenden vorstellen möchte.

Die Rolle resolv.conf

# tree roles/resolv.conf
roles/resolv.conf
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
└── templates
    └── resolv.conf.j2

Die Rolle kommt sehr minimalistisch daher und umfasst nur die zwingend erforderlichen Verzeichnisse und Dateien.

tasks/main.yml

---
- name: make sure line 'dns=none' is set in /etc/NetworkManager/NetworkManager.conf
  ini_file:
    path: /etc/NetworkManager/NetworkManager.conf
    state: present
    no_extra_spaces: yes
    section: main
    option: dns
    value: none
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - reload NetworkManager

- name: deploy resolv.conf template
  template:
    src: roles/resolv.conf/templates/resolv.conf.j2
    dest: /etc/resolv.conf
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - reload NetworkManager

Um die Datei /etc/resolv.conf mit Ansible verwalten zu können, habe ich zuerst dem NetworkManager abgewöhnt, diese Datei zu anzufassen. Dazu habe ich das Ansible-Modul ini_file verwendet, welche die benötigte Option dns=none in der Sektion [main] setzt.

Der zweite Task nutzt das Modul template, um aus der Datei unter roles/resolv.conf/templates/resolv.conf.j2 die Zielkonfiguration in der Datei /etc/resolv.conf auf dem Zielsystem zu erstellen. Aktuell enthält mein Template statischen Text und ich hätte auch das Modul copy nutzen können, um diese Datei auf das Zielsystem zu bringen. Ich verwende jedoch das template-Modul, um mir die Möglichkeit offen zu halten, durch Verwendung von Variablen den Inhalt dynamisch erstellen zu lassen.

Mit dem Parameter notify: wird an zwei Stellen ein Handler namens ‚reload NetworkManager‘ benachrichtigt. Auf diesen gehe ich im nächsten Abschnitt ein.

handlers/main.yml

Mit den Ansible Handlers lassen sich Aktionen auslösen, welche nur dann ausgeführt werden sollen, wenn durch einen Task Änderungen auf dem Zielsystem durchgeführt wurden. Die Handler werden erst am Ende eines Playbooks abgearbeitet und nur einmal ausgeführt, auch wenn Sie von mehreren Tasks über Änderungen benachrichtigt wurden.

# cat resolv.conf/handlers/main.yml 
---
  - name: reload NetworkManager
    service:
      name: NetworkManager
      state: reloaded

Bei dem in diesem Text beschriebenen Beispiel führt der Handler mit dem Namen ‚reload NetworkManager‘ den darunter definierten Task aus. Jedoch nur dann wenn einer der beiden Tasks (oder beide) aus tasks/main.yml zu einer Änderung auf dem Zielsystem geführt hat.

Es gilt zu beachten, dass Handler erst dann ausgeführt werden, wenn alle Tasks erfolgreich ausgeführt wurden. Dies kann in einigen Fällen die Fehlersuche etwas erschweren. Ich habe dazu ein Beispiel in Ansible: Up and Running von Rene Moser und Lorin Hochstein gefunden, welches ich hier gerne wiedergeben möchte. Stellt euch vor, euer Playbook hat folgenden Ablauf:

  1. Ihr führt ein Playbook aus
  2. Einer der Tasks verwendet notify bei Änderungen
  3. In einem folgenden Tasks tritt ein Fehler auf, welcher zum Abbruch der Verarbeitung führt
  4. Ihr behebt das Problem und führt das Playbook erneut aus

Der Task aus Schritt 2 hat seine Änderungen bereits erfolgreich durchgeführt. Bei der erneuten Ausführung des Playbooks wird sein Status daher OK und nicht CHANGED sein. Der Handler wurde jedoch nicht ausgeführt, da die Verarbeitung zuvor abgebrochen wurde. Auch bei der erneuten Ausführung des Playbooks wird der Handler nicht mehr ausgeführt, da der dazu erforderliche Task zu keiner Änderung im Zielsystem mehr führt.

Hochstein schreibt, dass Handler meist genutzt werden, um Dienste neuzustarten oder deren Konfiguration neu zu laden. Dies kann selbstverständlich auch erreicht werden, wenn man auf den Einsatz von Handlern verzichtet und einen Dienst am Ende des Playbooks explizit neustartet. Welches der bessere Weg ist, möge jeder für sich selbst entscheiden.

Fazit

Dies war eine meiner ersten Ansible-Rollen überhaupt. Ob dies der geschickteste Weg ist, die DNS-Konfiguration herzustellen, oder ob es noch elegantere Ansätze gibt, mag ich nicht abschließend beurteilen. Zumindest scheint auch diese Lösung robust zu sein und hat mich bisher nicht im Stich gelassen.

Falls ihr Fragen oder Anregungen habt, hinterlasst gern einen Kommentar. Ich freue mich stets neue Lösungswege kennen zu lernen.