Ansible / Teil 3 – Erstellung eigener Facts

Aufbauend auf meinen letzten Ansible Beiträgen möchte ich an dieser Stelle noch eine Möglichkeit ergänzen, wie man sich die sogenannten ‚Facts‘ zunutze machen kann. Wie zuvor erwähnt, verfügen sowohl Ansible als auch Puppet über einen Mechanismus, um Host-spezifische Informationen von seinen Zielsystemen zu sammeln: IP-Adressen, Sofware-Ausstatung, Hardware-Informationen und vieles mehr. Neben den vordefinierten Facts lassen sich auch eigene setzen. Im folgenden Beispiel möchte ich die Möglichkeit zeigen, einen Fact basierend auf dem Patch Level zu setzen. Genauer gesagt, ob Security Updates verfügbar sind oder nicht.
Achtung: Das vorgestellte Beispiel-Playbook weiter unten funktioniert lediglich mit einem Ubuntu bzw. Debian System.

Benutzung von Facts

Facts fallen bei Ansible oder Puppet erstmal leider nicht vom Himmel, werden jedoch bei jeder Kontaktierung (sofern dies nicht explizit untersagt wird) gesammelt.
Ein einfaches Playbook in Ansible ohne weitere Anweisung, welches lediglich zum Sammeln der Facts dienen soll, kann in etwa so aussehen:

---
- name: "Register hosts"
  hosts: all
  tasks:

Hinter ‚hosts:‘ fügt ihr einfach den Namen der Hosts bzw. Hostgruppen ein. Das Codewort „all“ fragt sämtliche Hosts ab, welche unter /etc/ansible/hosts gelistet sind.

Möchtet ihr euch über die Facts-Ausstattung eines Hosts informieren, fragt diesen folgendermaßen ab:

ansible beispielhost -m setup

Ihr wurdet nun mit einer Unzahl an allen möglichen Einträgen erschlagen (mein Output lag bei mehreren 100 Zeilen.
Um nach bestimmten Einträgen zu suchen, ist der Parameter „-a filter=“ hilfreich:

ansible beispielhost –m setup –a „filter=ansible_distribution”

In diesem Beispiel wurde nach der Distribution gefiltert.

Eigene Facts ins Rennen schicken

Möchten wir nun unsere eigenen Labels auf die Maschinen bringen, können wir dies am bequemsten über ein Playbook tun. Im Folgenden präsentiere ich den Inhalt eines Beispiel-Playbooks, welches diese Aufgabe für uns erledigen könnte (wie ihr Playbooks bedient, könnt ihr euch in meinem vorherigen Beitrag anschauen, Link: https://derlinuxwikinger.de/ansible-teil-1-installation-und-einrichtung/):

---
  - hosts: beispielhost
    ### Festlegung einiger Variablen
    vars:
      facts_dir: /etc/ansible/facts.d/
      facts_file: /etc/ansible/config_files/scripts/custom.fact

    tasks:
    ### Erstellung des Facts-Verzeichnisses
    - name: Create custom fact directory
      ansible.builtin.file:
        path: "{{ facts_dir }}"
        state: directory
        recurse: yes

    ### Kopieren der Facts-Datei auf den Zielhost
    - name: Copy script to gather facts
      ansible.builtin.copy:
        src: "{{facts_file}}"
        dest: "{{facts_dir}}"
        mode: 0700
        owner: root
        group: root

Dieses Playbook ist recht simpel gehalten. Im Grunde genommen machen wir nichts anderes, als mit unserem Zielhost zu kommunizieren (in diesem Beispiel kreativerweise „beispielhost“ genannt), auf diesem das benötigte Verzeichnis unter /etc/ansible/facts.d/ zu erstellen und unsere lokale Datei von /etc/ansible/config_files/scripts/custom.fact (auf dem Server liegend) dort hinein zu kopieren. Aber halt, diese Datei „custom.fact“ unter /etc/ansible/config_files/scripts/ existiert ja noch gar nicht! Möglicherweise ja noch nicht einmal die darunterliegenden Ordner. Ich bin einfach Fan dieser Ordnerstruktur. Falls ihr lieber eine alternative Ablage-Hierarchie bevorzugt, passt diese einfach nach euren Wünschen an.
Nichtsdestotrotz muss die Datei so oder so noch angelegt werden:

sudo nano /etc/ansible/config_files/scripts/custom.fact

Kopiert hier folgenden Inhalt hinein:

#!/bin/bash

updates_found=$(apt list --upgradable | sed -n '1d;p')

if [ -z "${updates_found// }" ]; then
  apt_updates_avail=false
else
  apt_updates_avail=true
fi

cat << EOF
{ "apt_updates_avail": "${apt_updates_avail}" }
EOF

Dieses Bash-Skript fragt die Maschine, auf dem es ausgeführt wird, ob zu aktualisierende Sicherheits-Patches verfügbar sind und gibt das Ergebnis samt den Namen des Facts „apt_updates_avail“ in geschweiften Klammern wieder. Je nach Ergebnis sieht das Ergebnis dann folgendermaßen aus:

### Updates verfügbar
{ "apt_updates_avail": "true" }

### Updates nicht verfügbar
{ "apt_updates_avail": "false" }

Alternativ könnt ihr in diesem Beispiel an Fakten mitgeben was ihr wollt. In diesem Fall steckt im Fact gleichzeitig eine Abfrage.

Ist alles an Ort und Stelle, könnt ihr das Playbook abspielen:

sudo ansible-playbook /etc/ansible/playbooks/ubuntu/custom_facts.yml

Die Zielmaschine sollte nun mit ein paar neuen Ordnern samt Skript bestückt sein. Um das ganze abschließend zu testen, starten wir einen Durchlauf und suchen nach dem Schlüsselwort für eigene Ansible Facts „ansible_local“.

sudo ansible beispielhost -m setup -a "filter=ansible_local"