Wer mich und diesen Blog kennt, der weiß, ich bin ein großer Fan von Bash Skripten. Diese sind zwar auf den ersten Blick relativ oldschool, aber dennoch lässt sich mit den passenden Skripten alles in kürzester Zeit installieren und konfigurieren. Gerade wenn man, wie ich, seine Skripte über die Jahre hinweg entwickelt und immer wieder upgedatet hat. Mit meinem lazy_server Skript z.B. lässt sich in wenigen Minuten ein Webserver vollständig konfigurieren und absichern, auch ohne die geringsten Linux Kenntnisse.

Nachdem ich nun aber immer wieder im Internet über Ansible gestolpert bin und es mir vor einigen Tagen auch von einem Kollegen auf der Arbeit empfohlen wurde, dachte ich, es ist mal an der Zeit sich genauer damit zu beschäftigen.

Ansible

Was genau ist Ansible eigentlich? Bei Ansible handelt es sich im ein Open-Source Automatisierungs-Werkzeug zur Orchestrierung und allgemeinen Konfiguration und Administration von Computern. Das zumindest steht bei Wikipedia. Aber was genau bedeutet das?

Vereinfacht gesagt, ihr könnt mit Hilfe von Ansible wiederkehrende Aufgaben bequem simultan auf mehreren System ausführen, ohne dass auf dem jeweiligen System eine zusätzliche Software verwendet wird. Ansible logt sich also via SSH auf dem zu administrierenden System ein und führt  vorher definierte Aufgaben aus. Diese Aufgaben werden in sog. Playbooks gespeichert. Playbooks werden im YAML-Format erstellt, erkennbar durch die Endung .yaml. Weitere Infos zur Syntax und Notation von YAML findet ihr in der Ansible-Dokumentation.

Installation unter Windows

Wie bereits beschrieben, eignet sich Ansible hervorragend zur Administration von mehreren Linux/UNIX Servern. Idealerweise läuft Ansible hierbei ebenfalls auf einem Server und ist somit von überall aus der Welt erreichbar. Wenn man jetzt gerade aber keine freien Kapazitäten hat, oder aus welchen Gründen auch immer, Ansible lokal installieren will, steht man als Windows Benutzer erst mal vor einem Problem, da es keinen nativen Client für Windows gibt. Praktischer weise gibt es aber seit einiger Zeit unter Windows die Möglichkeit ein Linux Subsystem zu installieren.

Windows Subsystem

Wir installieren quasi innerhalb unseres bestehenden Windows Systems ein Linux Subsystem. Alles in Allem dauert der Vorgang keine 5 Minuten.

Zunächst öffnen wir unter Windows als Administrator die PowerShell. Hierfür drücken wir einfach die Windowstaste, geben „PowerShell“ ein und wählen nach einem Rechtsklick auf „Windows PowerShell“  den Menüpunkt „Als Adminsitrator ausführen“ aus.

In die nun geöffnete PowerShell geben wir folgenden Befehl ein:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Nachdem nun der Rechner neugestartet wurde, verfügen wir zwar noch über kein einsatzbereites Linux System, aber immerhin haben wir nun im nächsten Schritt die Möglichkeit uns für eine Linux Distribution zu entscheiden.

Dazu öffnen wir den Windows Store (wer nicht genau weiß, wo sich der befindet; einfach wieder die Windows Taste drücken und „Store“ eingeben). Anschließend können wir im Windows Store entweder nach Linux, oder direkt nach der gewünschten Distro suchen und diese installieren.

Während der Installation werdet ihr nach einem Nutzernamen und Passwort gefragt, beides ist komplett unabhängig von eurem Windowsbenutzer. Et voilà, nun haben wir ein vollwertiges Linux Subsystem innerhalb unseres Windows Systems, auf welches wir jederzeit drauf zugreifen können.

Nützliche Infos

Ihr könnt von eurem Linux Subsystem ohne Probleme auf das Windows Hostsystem zugreifen, wobei Windows unter /mnt/…, d.h. /mnt/C/Users/… gemountet ist.

Die eigentlichen Linux Files findet ihr hingegen hier:

C:\Users\User\AppData\Local\Packages\TheDebianProject.DebianGNULinux_xxxx\LocalState\rootfs

Wenn ihr nicht zwingend die Linux Console verwenden, sondern stattdessen liebe runter Windows die Eingabeaufforderung (cmd) verwenden wollt, müsst ihr die passenden Entwickleroption aktivieren. Hierfür suchen wir wieder nach Drücken der Windowstaste nach „Settings“ und wählen „Für Entwickler-Einstellungen“ aus. Dort navigieren wir zum Vorletzen Punkt „Für Entwickler“ und aktivieren den Entwicklermodus.

Jetzt könnt ihr auch innerhalb der Windows Eingabeaufforderung mit dem Befehl „bash“ auf euer Linux Subsystem zugreifen.

Ansible Installation

Nachdem wir nun erfolgreich im vorherigen Schritt unser Linux Subsystem installiert haben, können wir Ansible problemlos installieren.

Da wir die neuste Version von Ansible installieren wollen, erfolgt die Installation mit Hilfe des Python Paketverwaltungsprogramm Pip, welches wir zuerst selbst installieren müssen

apt-get update && sudo apt-get -y upgrade
apt-get -y install python-pip python-dev libffi-dev libssl-dev

Anschließend können wir nun via Pip Ansible auf unserem Linux Subsystem installieren:

pip install ansible

Wundert euch nicht, die Installation kann etwas Zeit in Anspruch nehmen!

Das wars auch schon. Ihr solltet nun in der Lage sein Ansible unter Windows 10 über euer Linux Subsystem auszuführen. Zum Testen erstellen wir eine test.yml mit folgendem Inhalt:

  ---
  - hosts: localhost
    tasks:
      - debug: msg="Ansible is working!"

Der Befehl ansible-playbook test.yml –connection=local sollte nun in etwa folgenden Ausdruck anzeigen:

Konfiguration unter Windows

Kommen wir nun zur Konfiguration unter Windows. Die Konfiguration von Ansible erfolgt hierbei innerhalb eures Linux Subsystems genau so, wie auf einem vollwertigen Linux System, d.h. sämtliche config files sollten in /etc/ansible abgelegt werden. Playbooks hingegen könnt ihr speichern, wo auch immer ihr wollt. Ich z.B. speichere meine in der DropBox, so habe ich immer bequem Zugriff darauf. (Nicht vergessen, Windows Files werden unter /mnt/Laufwerk/…. eingebunden)

SSH Login

Da wir in der Regel ein Passwort benötigen, um uns auf dem jeweiligen Server via SSH anzumelden, würde das die Automation stark ausbremsen, bzw. müssten wir ständig vor dem Terminal hocken und das Passwort eingeben, bzw. es irgendwo ungeschützt zwischenspeichern.

Aus diesem Grund erstellen wir uns auf unserem Linux Subsystem einen SSH Key, welchen wir später zum Login auf dem jeweiligen Server verwenden.

ssh-keygen -t rsa

Alle weiteren Eingaben können mit Enter bestätigt werden. Ein weiteres Passwort für diesen Schlüssel müssen wir in diesem Fall nicht setzten, da wir es sonst ebenfalls jedes Mal eingeben müssten.

Als nächstes loggen wir uns auf dem zu administrierenden Server ein und erstellen, wenn nicht bereits vorhanden, den passenden Ordner

mkdir -p ~/.ssh

Nun kopieren wir unseren, im ersten Schritt erstellten Schlüssel, auf den Server. Dazu wechseln wir wieder in unser lokales Linux Terminal

cat ~/.ssh/id_rsa.pub | ssh root@server.de 'cat >> .ssh/authorized_keys'

Da wir uns ja ein letztes Mal „normal“ per SSH mit unserem Server verbinden, müssen wir das Passwort hierbei einmal eingeben. Danach können wir uns, zumindest von diesem Rechner/ unserem Linux Subsystem bequem ohne Passwort auf unserem Server einlogen.

Der Vorgang ist natürlich für jeden weiteren Server zu wiederholen.

Ansible

Da wir Ansible via Pip installiert haben, kommt es ziemlich nackt daher. Es ist zwar direkt einsatzbereit, aber verfügt über keine Config Files etc. Diese besorgen wir uns also erst einmal über GitHub

wget https://raw.githubusercontent.com/ansible/ansible/devel/examples/ansible.cfg -O "/etc/ansible/ansible.cfg"

Auf die Config möchte ich an dieser Stelle nicht weiter eingehen, da sie relativ selbsterklärend ist. Viele der dort gesetzten Parameter können auch jederzeit über die jeweiligen Playbooks überschrieben werden. Ich persönlich habe dort nicht wirklich viel geändert. Da meine Server alle nicht über den Standardport erreichbar sind, habe ich diesen dort z.B. geändert.

Als nächstes benötigen wir eine /etc/hosts Datei, in welcher wir unsere zu verwaltenden Server abspeichern. Hier können wir entweder die IP, oder die Domain verwenden. Sollte der SSH Port vom Standardport abweichen und ihr diesen auch nicht in der Config geändert haben, könnt ihr ihn dort zusätzlich angeben. Hier mal ein kurzes Bespiel:

[webserver]
server1.de
server2.de:22444

[mailserver]
mx.server3.de
mx.server5.de

[andere Kategorie]
server6.de
123.123.123.123
123.123.123.123:3435

Wollt ihr die Aufgaben auf allen Server ausführen, gebt ihr dafür folgenden Befehl ein:

ansible all .....

Wollt ihr die Aufgaben hingegen nur auf einem Server oder nur auf einer Gruppe von Server ausführen

ansible mx.server5.de ....
ansible mail ....

Eigentlich eine super Sache!

Hier mal ein kurzes Beispiel, um zu zeigen, wie genau das Ganze Funktioniert:

ssh root@server1.de "date"
ansible server1 -m shell -a "date"

Im ersten Beispiel verbinden wir uns manuell via SSH mit unserem Server1 und führen den Befehl date aus. Als Antwort erhalten wir dementsprechend das aktuelle Datum, sowie die Uhrzeit. Im zweiten Beispiel hingegen übernimmt Ansible die Verbindung zum Server via SSH und liefert uns das gleiche Ergebnis. Schon wenn wir nun server1 durch z.B. all oder eine bestimme Serverliste unter Ansible ersetzen, sollte deutlich werden, welchen Vorteil Ansible einem hierbei bietet. Statt sich manuell auf 30 Servern einzuloggen, um „date“ abzurufen, reicht ein einziger Befehl via Ansible aus.

Wirklich Interessant wird es, wenn die sog. Playbooks ins Spiel kommen. Wie bereits oben beschrieben, lassen sich mit Hilfe dieser Playbooks komplexe Aufgaben voll automatisieren. Diese lassen sich über folgenden Befehl aufrufen/ausführen:

ansible-playbook playbook-name.yml

Damit lassen sich dann bequem auf 10, 20, 30, oder auch 100 Servern LEMP Stacks installieren und konfigurieren, oder einfach up-to-date halten.

Für alle weiteren Informationen empfehle ich euch die Ansible Dokumentation des Herstellers.

 

 

 

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein