Mein Platz im Internet für Themen wie Linux, BSD, Server, Netzwerk, Knowhow und Besserwisserei

Mit Ansible die Landschaft aktualisieren


Das Ansible für mich der logische nächste schritt nach der Shell ist, sobald es um die Verwaltung von Servern geht, habe ich vielleicht hier und da schon mal durchblicken lassen. Der Hintergrund ist einfach:

  • Es sollte ein Anliegen sein wiederkehrende Arbeitsschritte systematisch gleich durchzuführen
  • Es sollte ein Anliegen sein die zu erledigenden Aufgaben transparent zu halten
  • Es sollte ein Anliegen sein seine Arbeiten reproduzierbar auf andere Systeme anwenden zu können
  • Es macht einfach Spaß, wenn man sich nicht mehr mit dem quatsch der unterschiedlichen Systeme befassen zu müssen.

Mit Ansible Playbooks habe ich als Systemverwalter die Möglichkeit meine Schritte in einfacher Art und Weise (fast schon stenografisch) nieder zuschreiben und so einen Ablauf zu skizzieren, welche Arbeiten/Schritte/Rahmenbedingungen auf dem von mir zu verwaltenden System durchgeführt/vorhanden sein sollen.

Ansible selbst kümmert sich dann um die Abstraktion zum System hin, auf dem ich dann letztendlich die Skizze ausführe.

Wenn ich nun eine gewachsene Landschaft mit unterschiedlichen Linux-Distributionen habe, kann Ansible mir helfen diese aktuell zu halten. Das einfache Playbook dazu sieht wie folgt aus:

---
- hosts: all:!switche:!windows
 user: root
 gather_facts: true

 tasks:
 - name: apt update
 action: apt update_cache=yes
 when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian"

 - name: apt upgrade
 action: apt upgrade=dist force=yes
 when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian"

 - name: yum upgrade
 action: yum name=* state=latest
 when: ansible_distribution == "CentOS"

 - name: dnf upgrade
 action: yum name=* state=latest
 when: ansible_distribution == "Fedora"

Wenn ich dieses Playbook nun auf meine Landschaft loslasse:

ansible-playbook playbooks/linux-upgrade.yml

 spielt es keine Rolle mehr, ob die Eingesetzte Distribution ein Debian, Ubuntu, Fedora oder CentOS ist. Alle werden mit den eigenen Paketmanagern aktualisiert

Erste Schritte in Ansible


In meinem vorherigen Beitrag habe ich erwähnt, wie cool ich Ansible finde. Dabei hab ich wohl nicht genug erwähnt, wie logisch und dennoch verspätet die Entwicklung kam. Mich fragt ja keiner…

Nun gut, da Ansible das logische nächste Level des Qualitätsbewussten, Keep it stupid and simple Administrator ist, ist es nur plausible dass man damit beginnt es zu benutzen.

In Ansible dreht sich alles um das zu verwaltende Inventar. Dieses wird in einer „hosts“ Datei definiert. Das coole daran: wenn man unterwegs in verschiedenen Netzwerken ist, kann man diese Datei zum Beispiel für jeden Kunden eigens definieren. In der Hosts Datei wird im einfachsten Falle einfach eine Liste mit Rechnernamen und IP-Adressen geführt.

Rechner1
192.168.2.189
weibserver.domain.com

und schon kann es los gehen.

Auf allen Adressen im Inventar kann man direkt nach dem einpflegen schon so genannten Ad-Hoc Kommandos absetzen. Also Kommandos auf der Shell welche auf den entfernen Rechner ausgeführt werden.

ansible all -a „ifconfig eth0“

würde in einem solchen Fall dafür sorgen, dass die Ausgabe des Kommandos „ifconfig eth0“ auf dem entfernen Rechner ausgeführt wird und man das Ergebnis ausgegeben bekommt.

An dieser Stelle hat man mit Ansible schon ein mächtiges Werkzeug, denn es gibt einen ganzen Eimer voller Module, die schon implementiert sind und daher fast keine Wünsche offen lassen. Angefangen vom einfachen Ausführen von Kommandos, über das kopieren von Dateien bis hin zum Ansprechen von Diensten, Programmen und Funktionen (List der Ansible Module).

Wer jetzt noch nicht überzeugt ist, dass Ansible die Erfüllung von Adminträumen ist, der soll doch bitte Windows benutzen :).

Schlagwörter Admin, Ansible, Automatisierung

Warum Ansible die geile Sau der Massenadministration ist


Seit ein paar Wochen beschäftige ich mich erneut mit der Strukturierung, Organisation und Administration von Servierlandschaften im Linux-Umfeld.

Wie die Jungfrau zum Kinde ergab es sich, dass mein Bauchgefühl mich auf die Reise schickte um nach Möglichkeiten eine vorhandene, gewachsene Struktur sowohl zu begreifen, als auch zu übernehmen.

Nach meinem Leitbild von "Keep it stupid and simple" sind einige "prominente" Lösungen schon gleich durch das Raster gefallen.

  • Schlank sollte es sein.
  • Einfach zu verstehen sollte es sein.
  • Mitwachen können muss es
  • und natürlich auch flexibel
  • und kurzfristig einsetzbar

wenn es im Alltag einen Platz finden muss. Nach ein paar Stichproben war die Entscheidung schon gefallen. Ansible sollte es sein. Es hatte von Anfang an die Wirkung einer ausgereiften Skiptsammlung. Das allein macht es zwar schon sympathisch, doch oben drauf kommen die Funktionen die wirklich nützlich sind und dennoch "nur" abstrahiert. So können Dienste über ihren Namen angesprochen werden wenn man sie in einem Task neustarten mag und Ansible erledigt den Rest. Ebenso das installieren von Software und so weiter.

Maßlos überzeugt wurde ich allerdings durch die Python typische Eigenschaft, dass man sich ein wenig disziplinieren und Einrückungen einhalten muss. Dadurch ergibt sich eine saubere Datei schon fast von allein.

Den Anfang findet man darin überhaupt einen Überblick über sein Inventar zu bekommen indem man die hosts Datei pflegt. Hier hinein kommen Geräte über DNS Namen oder IP-Adresse und auch Variablen und Tags könnten hier gleich mit gepflegt werden. Eine Gruppierung von Geräten ist selbstverständlich und so können auch logische Strukturen oder Geografische Abbildungen geschaffen werden. 

Weiter geht es mit dem einfachen Aufbau von Playbook. Den Batch-Files von Ansible. Hier werden Themenmäßig Aufgaben zusammengefasst um sie dann gezielt auf einem Host, einer Gruppe oder allen Maschinen anzuwenden. Beispielsweise das ein- oder auspflegen von SSH-Keys, aktualisieren von Systemen und so weiter. Die Krönung allerdings ist das erschaffen von Rollen. In diesen Rollen können Variablen, Aufgaben, Templates, Dateien und alles weitere zusammengefasst werden um eben diese Rolle zu definieren.

Mit Rollen schafft man sich quasi einen Status Quo zu einem System und kann so die Grundlage für einheitliche Konfiguration schaffen. Wie immer für mich steht die Kommunizierbarkeit im Vordergrund. Durch mein Vorgehen gleich zu Beginn die sich mir bietende Struktur zu begreifen und sie in Ansible abzubilden hatte ich quasi so etwas wie den heiligen Gral der kausalen Zusammenhänge und Prozessketten. Denn wenn eine Aufgabe einmal ordentlich in ein Playbook oder eine Rolle gepresst wurde, hat man in aller Regel verstanden worum es geht. Noch besser: man kann es auch gleich dokumentieren und stellt zusätzlich sicher, dass auch die lieben Kollegen nicht sonderlich vom Weg abweichen.

In diesem Sinne kann ich Ansible nur empfehlen und vor allem ein Blick in die Ansible-Galaxy lässt keine Wünsche mehr offen. Man kann sich also sicherlich darüber freuen, dass in Zukunft wieder mehr zu technisch/praktischen Themen hier zu lesen sein wird.