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:
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
Es wäre gelogen wenn ich sagen würde, das ich "immer wieder" in die Situation gelange KVM Hosts zu bearbeiten oder zu migrieren. Dennoch ist KVM ein toller Hypervisor der sowohl Spaß macht, als auch interessante Features mit sich bringt und gleichzeitig vom Handling her den Eindruck vermittelt vieles noch handhaben zu können, auch wenn es mal zu dicken Schwierigkeiten kommt.
Daher habe ich für mein Setup ein Skript gebastelt, welches mir die Konfigurationen (XML - Daten) der eingerichteten virtuellen Maschinen mittels virsh exportiert um im falle eines Ausfalls die Maschinen wieder rekonstruieren zu können (mit wirsch define oder wirsch create).
Wichtig dafür ist natürlich das es ein externes Medium gibt auf dem die Daten gespeichert werden können. In meinem Fall ist es ein zentrales FreeNAS Storage.
Wenn man noch zwischen unterschiedlichen Linux Distributionen hin- und her switched hat man unter umständen das Problem, dass bestimmte Maschine types nicht vorhanden sind oder andere Werte angepasst werden müssen. Dazu nutze ich einfach "sed" das mir unter die Arme greift.
Als Ergebnis habe ich mittels Cron alle voll Stunde frische Konfigurationsdateien die ich einfach auf einem anderen KVM Host importieren kann.
Mit Hilfe meines Skript kann ich nun mit Hilfe von Parametern sowohl alle virtuellen Maschinen an ohne Angabe eines Parameters an einen in "CONFIGDESTDIR" definiertenOrt speichern, oder diesen angeben.
Beim Import verhält es sich ein wenig anders. Hier kann ich zusätzlich noch eine bestimmte Maschine angeben
#!/bin/bash
CONFIGDESTDIR=/PATH/TO/STORAGE/
if [ "$1" == "export" ]; then
if [ -z "$2" ]; then
echo "Konfigurationen werden nach $CONFIGDESTDIR exportiert!";
else
CONFIGDESTDIR=$2
echo "Konfigurationen werden nach $CONFIGDESTDIR exportiert!";
fi
if [ -d $CONFIGDESTDIR ]; then
echo "Exportverzeichnis ist vorhanden.";
else
echo "Exportverzeichnis ist nicht vorhanden und wird angelegt!";
mkdir $CONFIGDESTDIR;
fi
for i in $(virsh list --all | sed '1,2d' | awk '{print $2}')
do
VMNAME=$(basename $i .xml)
virsh dumpxml --migratable $VMNAME > $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/\/usr\/bin\/kvm/\/usr\/libexec\/qemu-kvm/" $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/machine='pc-1.1'/machine='pc-i440fx-rhel7.0.0'/" $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/machine='pc-0.12'/machine='pc-i440fx-rhel7.0.0'/" $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/type='vmvga'/type='vga'/" $CONFIGDESTDIR/$VMNAME.xml;
done
fi
if [ "$1" == "import" ]; then
if [ -z "$2" ]; then
echo "Konfigurationen werden aus $CONFIGDESTDIR importert!";
else
CONFIGDESTDIR=$2
echo "Konfigurationen werden aus $CONFIGDESTDIR importert!";
fi
if [ -d $CONFIGDESTDIR ]; then
echo "Importverzeichnis ist vorhanden.";
else
echo "Importverzeichnis ist nicht vorhanden!";
exit;
fi
if [ -z "$3" ]; then
echo "Es werden alle Maschinen importiert!";
for i in $(ls $CONFIGDESTDIR/*.xml)
do
echo "Definiere Maschine $i";
virsh define $i;
echo "Richte Autostart ein fuer: $i";
virsh autostart $i;
done
else
echo "Definiere Maschine $3";
virsh define $CONFIGDESTDIR/$3;
echo "Richte Autostart ein fuer: $3";
virsh autostart $CONFIGDESTDIR/$3;
fi
fi
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 :).