Heimnetzwerksetup mit Ansible mit Ansible I

Als Programmierer bin ich natürlich faul und möchte mir die Arbeit soweit wie möglich erleichtern. Was bisher in Softwareentwicklung immer sehr gut und einfach war, man konnte sich ja jederzeit seine eigenen Skripte für alles schreiben, war in der Konfiguration der verschiedenen Computer und Server daheim immer eine Plage. Für jedes einzelne System musste man mühsam Konfiguration pflegen, sich Notizen machen, wo man wie was geändert hatte, um nach einem möglichen Crash wieder das System irgendwie auf die Beine zu kriegen.

Seit einiger Zeit gibt es aber dafür auch ein wunderbares Tool namens Ansible. Dieses konfiguriert Computer mit Hilfe von Dateien, die sich in einer Sourceverwaltung sichern lassen. Infrastructure-as-code ist hier das gängige Stichwort: man verwaltet Konfigurationen exakt genau so, wie Softwaresourcen.

In dieser Artikelserie möchte ich Euch zeigen, wie ich meine Systeme mit Ansible konfiguriere.

Ausgangssituation ist ein Cluster aus vier Raspberries. Diese sollen verschiedene Aufgaben im Heimnetzwerk aufnehmen. Eines davon soll als Datenbankserver dienen (MariaDB), ein anderes soll später mal Daten aus einem Temperatursensor im Teich aufziechnen etc. Da mir es langsam zu blöd wurde, all diese Server manuell zu konfigurieren, habe ich beschlossen, hier komplett auf Ansible umzusteigen. Im Laufe der Zeit soll dann Ansible auch die Verwaltung meiner anderen Server (immerhin fünf weitere DELLs, Suns und diverser sonstige Kisten) übernehmen. Die Verwaltung selbst erfolgt von meiner Workstation mit Ubuntu, später von einem separaten Raspberry.

Die Raspberries wurden von mir im Vorfeld mit Raspbian installiert. Sie sind per LAN ins Netzwerk angebunden und ganz jungfräulich. Die Konfiguration lautet:

rasalas-pi  => 192.168.178.109
rastaban-pi => 192.168.178.110
rotanev-pi  => 192.168.178.111
rukbat-pi   => 192.168.178.112

Um die Sourcen anschließend zu sichern, habe ich mir in GitLab ein neues Repository AnsibleHomeNetwork angelegt, wo diese gespeichert werden. Das Repository ist zwar privat, aber trotzdem muss man natürlich im Auge behalten, dass dort keine Passwörter etc. gespeichert werden dürfen. Daher erfolgt überall die Ansible Konfiguration so, dass das Passwort erst beim Ausführen des Playbooks angegeben wird. Dort, wo es notwendig ist, es zu speichern (i.e. mysql-playbook) wird es über eine separate Datei lokal gespeichert, die dann via gitignore ausgeschlossen wird.

SSH User auf den Raspberries

Für die Verwaltung der Raspberries nehme ich einen neuen User thorgal. Damit sind die Ansible-Tasks schön separiert von dem standardmässigen pi User. Die Anlage zeige ich hier am Beispiel eines der Rechners, die Schritte müsen auf allen weiteren Raspberries wiederholt werden.

Zuerst loggen wir uns auf dem Raspberry an:

ssh pi@192.168.178.107

und legen einen neuen User sowie vergeben das gewünschte Passwort:

sudo adduser thorgal

Damit der User thorgal die gewünschten Änderungen dürchführen kann, muss er ein paar Berechtigungen erhalten:

sudo usermod -a -G  adm,dialout,cdrom,sudo,audio,video,plugdev,games,users,input,netdev,gpio,i2c,spi thorgal

Danach können wir uns von dem Raspberry abmelden und prüfen, ob wir uns mit der Kennung thorgal anmelden können:

ssh thorgal@192.168.178.107

Damit Ansible sich anmelden kann, muss der SSH-Key auf der Maschine abgelegt werden. Dazu verlassen wir den Raspberry und landen wieder auf unserem Rechner. Den Schlüssel erstellen wir mit:

ssh-keygen -t rsa -b 4096 -C "unsereemail@unserhost.de"

Den Schlüssel speichern wir unter /home/unseruserid/.ssh/rasp damit man künftig problemlos erkennen kann, dass dies der Raspberryschlüssel ist.

Wenn die Passwortanfrage erscheint, einfach nur bestätigen, so dass wir einen Schlüssel ohne Passwort haben.

Anschließend muss der Public-Teil des Schlüssels auf alle Raspberries übertragen werden:

ssh-copy-id -i ~/.ssh/rasp thorgal@192.168.178.107

Wenn alles geklappt hatte, können wir uns mit dem folgenden Befehl auf dem Raspberry einloggen:

ssh thorgal@192.168.178.107

Ansible Kontrollrechner konfigurieren

Die Kontrolle des Ansibleclusters erfolgt erst einmal von meinem Arbeitsrechner. Es ist eine Ubuntu-Workstation. Dort muss zunächst einmal Ansible installiert werden:

sudo apt-get update && sudo apt-get upgrade
sudo apt-get install -y ansible

Hat die Installation funktioniert, haben wir nun lokal Ansible installiert und können uns an die Konfiguration machen.

Wie schon eingangs erwähnt, möchte ich meine Konfigurationen als Infrastructure-As-Code in GitLab speichern. Dazu klone ich daher erst einmal das erstelle Repository lokal:

git clone git@gitlab.com:$GITLABUSERID/ansiblehomenetwork.git

Der Pfad muss natürlich auf die eigene Repository angepasst werden! Es ist völlig egal, ob GitHub oder GitLab. Ich bevorzuge zuletzt den letzten, da ich in GitLab Free auch private Repositories erstellen kann. Diese Konfiguration hier sollte auf jeden Fall privat sein, da zum einen IP Adressen mitgeteilt werden, zum anderen auch Details der Konfiguration des eigenen Netzwerkes. Das sollte eher nicht öffentlich sein!

Standardmässig speichert Ansible alles in /etc/ansible. Das finde ich nicht so glücklich, da ich als normaler User in /etc nur mit sudo schreiben darf und eigentlich möchte ich lieber meine Konfiguration in meinem $home haben. Das ist aber mit Ansible kein Problem. Es gibt einen Pfad, in welcher Reihenfolge Ansible auf die Konfigurationsdateien greift und als erste wird immer das aktuelle Verzeichnis abgespeichert. Daher wechseln wir in das Repository-Verzeichnis und erstellen dort die benötigten Dateien:

cd ansiblehomenetwork
touch ansible.cfg
touch hosts

Diese beiden Dateien sind unser Ausgangspunkt: ansible.cfg beinhaltet die Konfiguration und hosts die einzelnen Rechner. Starten wir anschließend ansible aus dem ansiblehomenetwork – Verzeichnis, werden diese automatisch geladen und man braucht das /etc gar nicht.

Wir ändern die ansible.cfg wie folgt:

[defaults]
interpreter_python=auto_silent
force_valid_group_names = ignore # muss sein, weil meine Hosts ein - im Namen haben
remote_user = thorgal
inventory = /home/daniel/ansiblehomenetwork/hosts
become_ask_pass=true

[all:vars]
ansible_user = thorgal
ansible_become=yes
ansible_become_method=sudo
ansible_python_interpreter='/usr/bin/env python3'

Die ersten beiden Parameter sind notwendig, da wegen dem – im Namen Ansible bzw. Python etliche Warnings ausloggt. Danach definieren wir, mit welchem User wir auf dem Raspberry uns einloggen, welches Inventory wir benutzen sowie das Ansible jedes mal nach dem Passwort fragen soll.

Unter all:vars kommen noch ein paar allgemeine Variablen.

Nun zu der Datei hosts. Hier werden unsere Maschinen konfiguriert sowie bei Bedarf zu Gruppen zugeordnet. Ich erstelle für jeden der Rechner eine eigene Gruppe sowie eine gemeinsame Gruppe raspi für alle Raspberries:

[raspi]
rukbat-pi
rasalas-pi
rastaban-pi
rotanev-pi


[rukbat-pi]
192.168.178.108
[rasalas-pi]
192.168.178.109
[rastaban-pi]
192.168.178.110
[rotanev-pi]
192.168.178.111

Dann können wir probieren, ob Ansible soweit korrekt funktioniert und alles klappt:

ansible all -m ping

Hat alles funktioniert, erhalten wir überall ein SUCCESS zurück.

Update der Raspberries

Was macht man normalerweise nach der Installation eines Systems? Richtig, man aktualisiert ihn auf den neusten Stand. Dazu erstellen wir uns ein Playbook und lassen ihn damit die Raspis aktualisieren. Ich schränke bewusst diese Aktualisierung auf die Gruppe Raspis, da auf meinen anderen Servern auch mal CentOS oder Suse laufen, die natürlich anders aktualisiert werden.

Wir erstellen ein Playbook (ich habe mir angewöhnt, allen Playbooks Präfix playbook- voranzustellen):

touch playbook-update-pi.yml

und füllen diesen mit Inhalt:

- hosts: raspi
  become: true
  tasks:
    - name: Update apt repo and cache on all Raspberries
      apt: update-cache=yes force_apt_get=yes cache_valid_time=3600

    - name: Upgrade all packages on servers
      apt: upgrade=dist force_apt_get=yes

Wie üblich bei YAML, bitte auf die genauen Abstände achten. Immer je zwei Zeichen von links bei jeder tieferen Stufe!

Das Playbook führen wir aus mit:

ansible-playbook playbook_update-pi.yml -K

Das -K hinten habe ich mir angewöhnt, damit Ansible immer nach dem Passwort fragt. Das braucht man eigentlich nicht mehr, das haben wir vorher so konfiguriert, aber so erspare ich mir diverse Fehlermeldungen, sollte ich auf einem Server agieren, wo das eben nicht so ist.

Das Playbook dauert nun eine Weile, je nachdem, wie viele Images zu aktualisieren sind. Am Ende müssten wir eine Statistik bekommen, dass alles gut funktioniert hatte.

Shutdown

So, das ist erst einmal genug für heute. Die Raspberries brauchen wir nicht mehr, sie können ausgeschaltet werden. Was wäre da einfacher, als dazu ebenfalls ein Playbook zu benutzen?

Wir erstellen daher ein neues Playbook playbook_shutdown-pi.yml und füllen es mit Inhalt:

---
- hosts: raspi
  become: true
  gather_facts: no
  tasks:
    - name: Shutdown all Raspberries
      command: /sbin/shutdown -h now

Speichern und analog wie das Update-Playbook ausführen. Damit gehen alle Raspberries schön schlafen.

GitLab

Am Ende des Tages sollte, wie eigentlich üblich, alles in Git landen. Wir fügen daher alles hinzu, pushen und committen:

git add -A .
git commit -m "Initial setup of Ansible for Raspberries"
git push

Und voila, erster Teil des Infrastructure-As-Code haben wir.