In diesem Artikel stelle ich euch meine Ansible-Rolle vsphere_provision_lab vor. Mit dieser ist es möglich, vordefinierte Labor-Umgebungen, bestehend aus virtuellen Maschinen (VMs), in einem VMware vSphere Cluster zu provisionieren.
Um dem Text folgen zu können, ist es hilfreich zu wissen, was eine Ansible-Rolle (engl.) ist und worum es sich bei VMware vSphere handelt.
Anwendungsfall
Zum Test von Ansible-Modulen, -Playbooks und -Rollen sowie neuer Shell-Skripte und Konfigurationsparameter benötige ich wiederholt Test- bzw. Labor-Umgebungen. Diese bestehen aus VMs, welche im Vergleich zum Provisionierungszeitpunkt möglichst wenig Änderungen aufweisen sollten.
Da die Konfiguration der Gast-Betriebssysteme durch einen Testlauf verändert wird, soll eine solche Labor-Umgebung nach einem Test möglichst schnell dekommissioniert und neu-provisioniert werden können.
Der Vorgang der Provisionierung und Dekommissionierung soll automatisiert erfolgen.
Voraussetzungen
Um die Ansible-Rolle vsphere_provision_lab nutzen zu können, benötigt man:
- Einen Ansible Control Node mit einer Ansible-Version >= 2.9
- Eine vCenter Server Appliance oder einen vCenter Server; getestet habe ich die Rolle mit Version 6.7 U3
Die Ansible-Rolle verwendet die Module vmware_guest und vmware_guest_disk aus der Collection community.vmware. Um diese nutzen zu können, muss auf dem Ansible Control Node Python in einer Version >= 2.6 und PyVmomi installiert sein.
Da die Rolle neue VMs aus Templates erstellt, müssen entsprechende vSphere Templates vorhanden sein.
Variablen
In diesem Abschnitt werden die Variablen dokumentiert, welche mit Werten zu belegen sind. Diese sind in defaults/main.yml definiert und können entsprechend der Variablen-Präzedenz überschrieben werden.
vCenter-Variablen
vsphere_provision_lab_vc_hostname – Der FQDN für die vCenter Server Appliance.vsphere_provision_lab_vc_username – Ein Benutzeraccount mit der Berechtigung, neue VMs zu erstellen.vsphere_provision_lab_vc_password – Spezifiziert das Benutzer-Passwort.vsphere_provision_lab_vc_datacenter – Name des vSphere Datacenter in der Bestandsliste, das verwendet werden soll.vsphere_provision_lab_vc_cluster – Der zu verwendende vSphere Cluster aus der Bestandsliste.vsphere_provision_lab_vc_datastore – Name des Datenspeichers, in dem die VMDK-Datei(n) erstellt wird/werden.vsphere_provision_lab_vc_folder – Der vSphere Folder Name, in dem die VM erstellt wird. Der Wert kann zuvor mit dem Playbook find_vmware_guest_folder.yml ermittelt werden.
Ich empfehle, sensible Informationen wie z.B. Benutzername und Passwort in einer verschlüsselten Ansible-Vault-Datei zu speichern.
Dictionary zur Spezifikation der VMs
Namen und Parameter der zu erstellenden VMs werden in einem YAML-Dictionary gespeichert. Der folgende Code-Block zeigt ein Beispiel für ein solches Dictionary mit einem Eintrag:
vm1:
vm_template: rhel8-en
vm_ram_mb: 1024
vm_vcpu: 2
vm_net: VLAN123
vm_ip: 192.168.0.5
vm_netmask: 255.255.255.0
vm_gateway: 192.168.0.254
vm_domain: sub.example.com
vm_hostname: host2
vm_dns_servers:
- 192.168.0.2
- 192.168.0.3
vm_dns_suffix:
- sub.example.com
- sub2.example.com
- sub3.example.com
vm_second_hdd: true
vm_second_hdd_size_gb: "10"
vm_second_hdd_type: "thin"
vm_second_hdd_datastore: "DS1"
vm_scsi_controller: "1"
vm_unit_number: "1"
vm_scsi_type: 'paravirtual'
Aus dem obigen Dictionary wird eine VM mit den folgenden Parametern erstellt:
- vSphere-Template ‚rhel8-en‘ wird als Vorlage verwendet.
- Der VM werden 1 vCPU und 512 MB RAM zugewiesen.
- Die vNIC an das VM-Netz ‚VLAN123‘ angeschlossen.
- Die VM wird mit der IP 192.168.0.1/24 und dem Standardgateway 192.168.0.254 konfiguriert.
- Im Gast-Betriebssystem wird der Hostname ‚host1‘ konfiguriert.
- Es werden DNS-Server und DNS-Suffixe konfiguriert.
- Es wird eine zweite Festplatte für die VM erstellt.
Diesen Block kann man nun für weitere VMs wiederholen. Wird keine zweite HDD benötigt, setzt man vm_second_hdd auf false.
Beispiel-Playbook
---
- hosts: localhost
connection: local
gather_facts: no
vars_files:
- /path/to/vault-with-vcenter-creds.vars
- roles/vsphere_provision_lab/vars/rhel-lab.yml
roles:
- vsphere_provision_lab
In diesem Beispiel werden die Variablen aus zwei Dateien geladen.
- /path/to/vault-with-vcenter-creds.vars ist eine Ansible-Vault-Datei, welche die Anmeldeinformationen für den vCenter Server beinhaltet.
- roles/vsphere_provision_lab/vars/rhel-lab.yml enthält das Dictionary mit den zu erstellenden VMs.
Wie kann man diese Rolle nutzen?
Die Rolle steht unter der Lizenz GPLv2-or-later und kann aus dem GitLab-Repo vsphere_provision_lab heruntergeladen bzw. das Repo geklont werden. Sie ist im Role Path der Ansible-Installation zu speichern. Anschließend kann man sich an folgendem Ablaufplan orientieren:
- Im Vorfeld sollten IP-Adressen und FQDNs für die zu erstellenden VMs registriert werden. Dieser Punkt ist spezifisch für eure jeweilige Umgebung.
- Die Variablen sind mit gültigen Werten zu belegen.
- Die Rolle ist in ein Playbook einzubinden.
- Und schon kann das Playbook ausgeführt werden.
Fazit
Die Ansible-Rolle vsphere_provision_lab ermöglicht es, Labor-Umgebungen, bestehend aus VMs, als YAML-Dictionary zu definieren und auf einem VMware vSphere Cluster zu provisionieren.
Damit eignet sie sich, um wiederholt eine Umgebung mit gleichen Ausgangsbedingungen zu schaffen. Gleichzeitig wird die Zeit für die Provisionierung verkürzt, da manuelle Schritte entfallen.
So richtig idempotent arbeitet das Modul vmware_guest allerdings nicht. Führe ich das Playbook ein zweites Mal aus, wird der Status „Changed“ zurückgegeben, obwohl die VMs bereits existieren. Die VMs selbst überstehen den zweiten Lauf auch unbeschadet, jedoch zeigt der vSphere Client, dass sie rekonfiguriert wurden. Das könnte ich mir noch genauer ansehen, um der Ursache auf die Schliche zu kommen.
Was haltet ihr davon? Findet ihr diese Role nützlich, oder bevorzugt ihr andere Wege zur Provisionierung eurer VMs auf vSphere?
Anmelden
