Distributions-übergreifende Kurse – Lauter verschiedene Pinguine

Im Artikel zum Setup für den Datacenter Services-Kurs erläuterte ich, wie ich mit Hilfe von virtuellen Maschinen mit Proxmox Virtual Environment, die mittels verschachtelter Virtualisierung auf VMware ESX laufen, für jeden Teilnehmer ein eigenes Rechenzentrum bereitstelle. Jeder Teilnehmer bekommt ein eigenes Proxmox VE samt Web-Oberfläche, um dort nach Herzenslust Debian-, RHEL- oder SLES-VMs auszurollen. In diesem Blog-Beitrag erläutere ich, wie ich Proxmox VE mit Hilfe von Cloud Init dazu einsetze, die virtuellen Maschinen für meine anderen Kurse bereitzustellen.

In meinen üblichen Kursen Linux/UNIX Basics, Linux Advanced, Linux Performance-Analyse und Tuning, den ich auch bei der Heinlein Akademie halte, sowie Elasticsearch, Logstash, Kibana Logfile-Analyse mit OpenSource Tools verwendete ich im Schulungszentrum manuell geklonte VMs auf VMware ESX. Das lief ganz gut, bis eine Aktualisierung fällig war. Mit gewissen Tricks lassen sich zwar auch 10 VMs schnell aktualisieren, aber so ganz passt das nicht ins Zeitalter der Automatisierung.

Proxmox VE mit Cloud Init für Schulungs-VMs

Es entstand die Idee, auch dafür gleich Proxmox VE zu nutzen. Proxmox VE läuft auf Basis von Debian GNU/Linux. Das bietet die ideale Ansatzfläche, um automatisiert via SSH VMs zu klonen. Der Befehl qm aus dem Paket qemu-server von Proxmox ermöglicht es, auf einfache Weise VMs zu starten, zu stoppen, zu klonen und vieles Weitere mehr.

Doch welche Software übernimmt die Anpassungen der geklonten virtuellen Maschinen? Hier bin ich nach kurzer Recherche auf Cloud Init gestoßen. Cloud Init individualisiert VMs für Cloud-Umgebungen. Es setzt z.B. Hostnamen, IP-Adresse, Standard-Gateway, DNS-Server und erneuert SSH-Host-Schlüssel, legt bestimmte Benutzer an und/oder packt einen bestimmten Schlüssel in die authorized_keys-Datei eines Benutzers.

Da Proxmox VE Cloud Init bereits unterstützt, bleibt für das Bereitstellen der VMs im Wesentlichen nur das Anpassen der Konfigurationsdaten für die VMs und das eigentliche Klonen und Starten der VMs übrig. Das ließe sich sicherlich auch mit einem Werkzeug wie Terraform erledigen. In diesem Fall kam auch aufgrund der speziellen Anforderungen für die Schulungsumgebung ein zusammen mit meinem Kollegen Chris Frage entwickeltes Bash-Skript zum Einsatz. Dieses erledigt anhand einer Konfigurationsdatei mit einem Inhalt wie

und Befehlsoptionen, die das Ganze noch weiter anpassen, die Arbeit. Das Skript legt dazu erst einen vollständigen Klon an, wandelt diesen in eine Vorlage um und klont von dieser Vorlage die eigentlichen VMs als Thin Clones. Im Grunde könnte die ursprüngliche VM bereits eine Vorlage sein, die sich per Thin Provisioning klonen lässt. Diese lassen sich in Proxmox VE jedoch ohne das Klonen nicht in eine neue VM ändern, was das Vornehmen von Anpassungen verkomplizieren würde.

Damit ich zu Beginn eines Kurses das Skript nicht für jede Konfiguration einzeln durchlaufen lassen muss, gibt es mittlerweile noch ein weiteres Skript, das VMs für jede vorliegende Konfiguration erstellt. Das Skript braucht nur drei Angaben:

So ergibt ein Aufruf von ./clone-or-remove-all-vms.sh clone nuc 2 das folgende Ergebnis:

Die Web-Oberfläche zeigt für die VM centos01 die Cloud Init-Konfiguration. Proxmox VE und Cloud Init arbeiten über die NoCloud-Datenquelle für Cloud Init zusammen. Dazu erstellt Proxmox aus den Konfigurationsdaten eine ISO-Datei, die Cloud Init innerhalb der VM einhängt, um die gewünschte Konfiguration auszulesen. Das sieht innerhalb der VM so aus:

Das ganze läuft bei qSkills auf einer Fujitsu S8 mit 256 GiB RAM und 20 Prozessoren, die mit Hyperthreading 40 logische CPU-Kerne in Linux ergeben. Das Referenz-Setup läuft indes wie gehabt auf einem Intel NUC.

Erweiterungen

Natürlich bleiben gelegentliche Erweiterungen und Anpassungen bei so einem Setup nicht aus. Das Skript zum Klonen der VMs entfernt mittlerweile optional auch die alten Fingerabdrücke für die SSH-Schlüssel und es kamen mittlerweile so einige Distributionen dazu. Auch gibt es mittlerweile einen eigenen NFS-Server für den Austausch von Daten während eines Kurses. Ein teilweise Skript-gesteuert konfigurierter DNS-Server auf Basis dnsmasq sorgt dafür, dass auf jeder VM die anderen VMs mit Namen bekannt sind. Ein Logfile-Analyse-Setup auf Basis von Elasticsearch, Fluentd und Kibana vervollständigt die Infrastruktur.

Für die Schulungen stehen derzeit folgende Distributionen bereit:

• Debian 9 aka Stretch
• Devuan 2.0 aka Ascii
• Ubuntu 18.04 LTS
• CentOS 7
• SLES 15 SP 1
• SLES 12 SP 4

In der Test-Umgebung laufen auch bereits:

• Debian 10 aka Buster
• Devuan 3.0 aka Beowolf (als Prerelease)

Die Cloud Init-Konfiguration ist derzeit minimal. Ich habe ziemlich viele Funktionen abgeschaltet. Allerdings erwäge ich mittlerweile, Sicherheitsaktualisierungen automatisch einspielen zu lassen. So würden sich die automatisch gestarteten Vorlagen-VMs von allein aktualisieren und ich würde dann nur das Skript zum Klonen laufen lassen. Idealerweise nachdem Cloud Init den Aktualisierungsprozess auf den Vorlagen abgeschlossen hat, damit es das auf den geklonten VMs nicht noch einmal macht. Derzeit lasse ich die Updates am Anfang noch manuell durchlaufen – aus alter Gewohnheit, sehen zu wollen, was da passiert. Mit steigender Anzahl an Distributionen wird das aber immer unpraktischer.

Aber bereits das Klonen und Anpassen der VMs erspart sehr viel Arbeit und so freue ich mich darauf, beim nächsten Kurs wieder eine Ausgabe wie:

zu sehen.

Unsere Schulungen

In unseren Schulungen Linux/UNIX Basics, Linux Advanced, Linux Performance-Analyse und Tuning – auch bei der Heinlein Akademie – sowie Elasticsearch, Logstash, Kibana Logfile-Analyse mit OpenSource Tools haben Sie die freie Wahl, welche Distribution Sie verwenden möchten. Zudem gibt es jederzeit die Gelegenheit, über den Tellerrand zu schauen. Dabei erzähle ich gerne von Dingen, die ich (noch) nicht schule. Beispielsweise wie ich mit Proxmox VE und Cloud Init virtuelle Maschinen für die Kurse bereitstellen lasse.

Series Navigation