vRealize Automation (vRA) unterstützt einige Methoden zur Provisionierung von virtuellen Maschinen basierend auf Blueprints. Neben Template-basierten Varianten werden auch unbeaufsichtigte Installationen unterstützt, um virtuelle Maschinen auszurollen. Einige Kunden haben bereits existierende Prozesse basierend auf unbeaufsichtigten Installationstechnologien wie z.B. SCCM, AutoYaST oder RedHat Kickstart. Alle genanten Methoden werden von vRealize Automation untersützt.
Dieser Blog beschreibt, wie ein Kickstart-Mechanismus verwendet werden kann, um eine virtuelle Maschine in vRealize Automation mit CentOS 6.4 x86 als Betriebssystem automatisiert zu betanken. Der Prozess wurde mit vRealize Automation 6.2.3 als auch Version 7 getestet.
An dieser Stelle möchte ich darauf hinweisen, dass die Zusammenstellung hier nicht als vollständige Schritt-für-Schritt-Anleitung gedacht ist. Vielmehr werden die einzelnen Schritte im Überblick aufgezeigt und Punkte hervorgehoben, die nicht klar aus der Dokumentation hervorgehen.
An English version of this blog is available here.
Architekturelle Betrachtungen
Ein Deployment-Prozess in vRealize Automation (vRA) basiert auf der Erstellung eines Blueprints, der bei einer Benutzeranfrage ausgerollt wird. Welche Methode für das Deployment verwendet wird, ist im jeweiligen Blueprint definiert. Im RedHat/CentOS Kickstart-Fall beinhaltet der Blueprint einen Workflow “LinuxKickstartWorkflow” der verwendet wird. Kickstart ist Bestandteil des RedHat Linux Betriebssystem und die empfohlene Methode für unbeaufsichtigte Installationen basierend auf einer Kickstart Beschreibungsdatei.
Die folgenden, grundsätzlichen Schritte sind notwendig, um eine Kickstart-Installation durchzuführen:
- Vorbereitung einer CentOS-ISO-Datei. Diese Datei muss so konfiguriert werden, dass der Pfad zur Kickstart-Beschreibungsdatei hinterlegt ist. Das CentOS-ISO wird auf einem vSphere Datastore abgelegt.
- Eine Kickstart-Datei wird erstellt, in der die Parameter für die unbeaufsichtigte Installation hinterlegt werden. Ebenso muss dort die Installation des vRA Gast-Agenten definiert sein. Die Kickstart-Datei wird auf einem externen Server (z.B. Webserver) abgelegt.
- Die Installationsdateien des vRA-Gastagenten werden auf einer Netzwerkfreigabe (z.B. Webserver) abgelegt.
- Auf dem vRA-Blueprint werden custom properties hinterlegt, die z.B. den Pfad zu den Installationsquellen definieren.
High-level Deployment-Prozess:
- Ein Benutzer fordert einen Blueprint an
- Die virtuelle Maschine wird auf vSphere erstellt und das CentOS ISO wird angehängt
- VM startet von dem angehängten ISO
- Das ISO lädt die Kickstart-Datei vom Webserver herunter und die unbeaufsichtigte Installation wird ausgeführt.
- Der letzte Teil der Installation lädt automatisch den vRA Gastagenten auf die virtuelle Maschine und installiert diesen ebenfalls unbeaufsichtigt
- Nach dem Reboot der VM wird der Gast-Agent automatisch gestartet und meldet eine erfolgreiche Installation an vRA zurück.
- Der Prozess in vRA ist abgeschlossen und die VM kann nun in vRA verwaltet werden.
Vorbereitung eines CentOS ISOs
Als erster Schritt muss ein CentOS ISO z.B. von www.centos.org heruntergeladen werden, die danach mit der entsprechenden Kickstart-Datei vorbereitet wird. Es gibt unterschiedliche Methoden, um den Inhalt einer ISO-Datei anzupassen, einige davon verweisen auf kommerzielle Tools, da Freeware-Tools oft auf Dateigrößen von 300 oder 500 MB beim Schreiben limitiert sind. Aufgrund dessen wird in diesem Blog ein Standart-Linux-Betriebssystem verwendet, das die notwendige Funktionalität beinhaltet. Folgende Schritte sind dafür erforderlich:
- Bereitstellung eines Web-Servers (wird später für die ks.cfg benötigt)
- Kopieren des CentOS ISO auf das Linux-System
- Loop-Mount des ISOs im System z.B. nach dieser Beschreibung: http://bencane.com/2013/06/12/mkisofs-repackaging-a-linux-install-iso/
- Anpassung der Datei /var/tmp/linux/isolinux/isolinux.cfg
- “make your changes” Sektion aus o.g. Link: Anpassung der Datei /var/tmp/linux/isolinux/isolinux.cfg file, Hinzufügen der Fett markierten Punkte aus der Beispieldatei unten. <web srv> muss mit dem Pfad und den Dateinamen der auf die ks.cfg-Datei verweist angepasst werden. Die Erstellung der ks.cfg-Datei ist in der nächsten Sektion beschrieben.
| /var/tmp/linux/isolinux/isolinux.cfg |
|---|
| label linux menu label ^Install or upgrade an existing system menu default kernel vmlinuz append initrd=initrd.img –bootproto=dhcp ks=http://<websrv>/vra/ks.cfg |
- Speichern der Datei und Erstellung des ISOs nach der o.g. Beschreibung
- Die ISO wird dann auf einen vSphere Datastore kopiert (z.B. durch Kopieren der Datei auf ein Windows-System mit WinSCP und anschließendem Upload auf einen Datastore per vCenter)
- Namen des Datastores (in diesem Fall “VM-NFS-01”) notieren sowie den Pfad zur ISO-Datei (hier: /ISO/centos64-unattended.iso)
Vorbereitung der Kickstart-Datei und des Gast-Agenten
Die Vorbereitung einer Kickstart-Datei ist grundsätzlich in der offiziellen vRA-Dokumentation beschrieben, siehe hier: http://pubs.vmware.com/vra-62/topic/com.vmware.vra.iaas.virtual.doc/GUID-13EDB88E-DF34-4D82-B17A-CDF6289A2DC8.html
Die Erstellung der Datei kann über einen einfachen Texteditor erfolgen. In diesem Fall wurde eine leicht modifizierte Variante im Vergleich zur Dokumentation verwendet, die ebenfalls funktioniert:
| ks.cfg |
|---|
| auth –useshadow –enablemd5 bootloader –append=”rhgb quiet” –location=mbr –driveorder=sda zerombr clearpart –all –initlabel text firewall –disabled keyboard us lang en_US logging –level=info network –bootproto=dhcp –device=eth0 –onboot=on reboot rootpw secret selinux –enforcing timezone –isUtc America/New_York install part / –asprimary –fstype=”ext3″ –size=4096 part swap –asprimary –fstype=”swap” –size=512 %packages vim-enhanced %postrpm -i http://<websrvip>/vra/gugent-6.2.2-05062015.i386.rpm export AXIS2C_HOME=axis2 export PYTHONPATH=/usr/share/gugent/site/dops echo | openssl s_client -connect <vra-iaas-srv-fqdn>:443 | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > /usr/share/gugent/cert.pem cd /usr/share/gugent ./installgugent.sh <vra-iaas-srv-fqdn>:443 ssl |
Alle Komponenten, die Fett markiert sind, müssen auf die jeweilige Umgebung (Pfad, IP-Adressen, Server-Namen) angepasst werden. Nach Erstellung der Datei wird diese als ks.cfg im entsprechenden Pfad auf dem Web-Server abgelegt. Dabei muss der Pfad mit dem, der in der isolinux.cfg im CentOS ISO hinterlegt wurde, übereinstimmen.
Die Installations-Datei des vRA Gast-Agenten (RPM-Datei) wird ebenfalls auf dem Web-Server im Pfad analog zur Konfiguration in der ks.cfg abgelegt.
Vorbereitung des Blueprints
Es wird ein neuer Blueprint in vRA erstellt und dabei die Action “Create” mit dem provisioning workflow “LinuxKickstartWorkflow” verwendet. Alle anderen Werte können nach den individuellen Anforderungen angepasst werden. Zusätzlich sind custom properties erforderlich, um eine erfolgreiche Kickstart-Installation zu ermöglichen:
Image.ISO.Location = Name des vSphere Datastores, in dem das CentOS ISO abgelegt ist.
Image.ISO.Name = Pfad und Name der CentOS ISO-Datei bezogen auf das root des o.g. Datastores
VMware.VirtualCenter.OperatingSystem = ID des zu installierenden Betriebssystems
Eine vollständige Liste der verfügbaren Betriebssystem-IDs ist hier zu finden: http://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.wssdk.apiref.doc%2Fvim.vm.GuestOsDescriptor.GuestOsIdentifier.html
Nach Abspeichern des Blueprints, Veröffentlichung in vRA und Definition der entsprechenden Entitlements kann die VM über den Katalog angefordert werden und wird dabei per Kickstart installiert (root-Passwort = secret, siehe ks.cfg).
Troubleshooting
Falsche ISO Checksumme
Wenn ein Fehler bei der ISO-Erstellung aufgetreten ist (z.B. falsche Checksumme), wird der Bootvorgang nicht erfolgreich ablaufen. Bereits im frühen Boot-Stadium wird eine entsprechende Fehlermeldung angezeigt.
Für diesen Fall wird empfohlen, die in diesem Blog beschriebene Methode zur Erstellung der ISO zu verwenden (über ein Linux-System).
Fehleranalyse Gast-Agent
Ein wichtiger Schrit im gesamten Prozess ist die Installation des vRA Gast-Agenten. Wenn dieser Schritt nicht erfolgreich durchgeführt wird, bleibt vRA während des Provisionierungsprozesses im Status “in progress” und wartet auf einen Timeout (was mdst. 24 Stunden dauert). Daher ist es extrem wichtig, dass der Gast-Agent erfolgreich installiert und nach einem Reboot gestartet wird, um die erfolgreiche Installation an vRA zurückmelden zu können. Hier sind einige Punkte aufgeführt, die bei der Fehleranalyse unterstützen:
- Nach dem Deployment sollte der Gast-Agent installiert sein. Dies kann durch die Ausführung des Befehls “rpm -qa | grep gugent” überprüft werden. Bei erfolgreicher Installation sollte ein Paket mit dem Namen “gugent” und der entsprechenden Versionsnummer gelistet sein. Ist das nicht der Fall, ist bereits die Installation fehlgeschlagen. Mögliche Ursachen sind Syntax-Fehler in der ks.cfg-Datei (rpm -i Befehl) oder eine fehlerhafte DHCP-Konfiguration (DHCP wird während der Installation verwendet, um auf die Kickstart-Datei zugreifen zu können).
- Der Gast-Agent kommuniziert mit dem vRA IaaS-Server über eine verschlüsselte Verbindung. Dafür benötigt er ein Client-Zertifikat, das vom IaaS-Server geladen und in einer Datei abgespeichert wird. Per Default wird eine Datei namens “cert.pem” unter /usr/share/gugent abgelegt. Wenn diese Datei nicht vorhanden oder leer ist, ist die Verfügbarkeit des IaaS-Servers während der VM-Installation zu überprüfen (DHCP, DNS-Einstellung, Syntax in ks.cfg). Wie oben erwähnt, wird während der Installation per Default ein DHCP-Server verwendet. Dort ist es erforderlich, dass mit den DHCP-Adressen eine Auflösung des vRA IaaS-Server-Namens möglich ist (wenn der Name in ks.cfg hinterlegt wurde)
- Überprüfung, ob der vrm-agent auf der installierten VM läuft: “ps aux” sollte den entsprechenden Prozess listen (VRM_daemon.pl). Zusätzlich sollte überprüft werden, dass der vrm-agent für den automatischen Start konfiguriert ist (chkconfig –list). Falls dort kein runlevel-Eintrag für vrm-agent enthalten ist, wurde der Agent zwar installiert, aber die Sektion mit “installgugent.sh” aus der ks.cfg ist fehlgeschlagen. Mögliche Ursachen können sein, dass die cert.pem-Datei nicht verfügbar ist oder der IaaS-Server nicht erreichbar war.
- Für tiefere Fehleranalyse kann die GuestAgent.log Datei verwendet werden. Ebenfalls ist folgende Datei hilfreich: /usr/share/gugent/axis2/logs/gugent-axis.log
