In meinem Blogpost möchte ich zwei Lösungen vorstellen um virtuelle Maschinen unter VMware zu deployen, so dass diese danach mit Puppet weiter gemanaget werden können. Beide Lösungen folgen hierbei ganz unterschiedlichen Ansätzen, weshalb ich die Vor- und Nachteile wie ich sie sehe aufzeigen möchte und sehr an eurer Meinung interessiert wäre.
Die erste Lösung, die ich in den Ring werfen möchte, nennt sich Cloud Provisioner, wird von Puppetlabs entwickelt und ist Teil von Puppet Enterprise. Die Installation ist recht simpel, einfach beim Installation-Assistenten mit ausgewählt, schon erhält man das Kommandozeilen-Tool. Da es sich um ein Kommandozeilen-Tool handelt ist die Konfiguration auch relativ einfach in einer Datei erledigt, in der die Zugangsdaten hinterlegt werden.
War Installation und Konfiguration erfolgreich kann das Puppet-Subkommando node_vmware genutzt werden um die virtuellen Maschinen in der Umgebung aufzulisten, zu starten, stoppen und gleich ganz zu löschen. Die wichtigste Option ist natürlich create, mit dieser kann aus einem bestehenden Template eine neue virtuelle Maschine angelegt werden. In diesem Template sollte idealerweise bereits Puppet installiert sein. Ist dies nicht der Fall kann (ssh-Zugriff vorausgesetzt) mit puppet node install auch noch Puppet nachinstalliert werden. Nun lässt sich die virtuelle Maschine ganz wie gewohnt über die Weboberfläche oder Kommandozeile managen.
Die Alternative stellt Foreman und nennt sich Compute Resource. Auch hier ist die Installation recht einfach. Nachdem bereits Foreman installiert ist, wird über den Paketmanager der Distribution ein Paket foreman-vmware nachinstalliert. Danach hat man in der Oberfläche die Möglichkeit ein Virtual Center als Compute Resource anzulegen, wofür auch nur ein entsprechend berechtigter Account nötig ist. Hier schon mal ein Hinweis für Ausprobierwillige ein einzelner ESX-Host geht nicht, da Foreman nach Clustern sucht.
Installation und Konfiguration geschafft, kann über die Compute Resource direkt mit den virtuellen Maschinen kommuniziert werden. Zusätzlich zu den Optionen wie starten und stoppen ist auch der Konsolenzugiff möglich, wenn man noch etwas Konfigurationsaufwand in Firewallregeln steckt. Das Deployment erfolgt genauso wie bei physikalischen Systemen aus der Hostansicht heraus. Wählt man beim Anlegen eines neuen Hosts die Compute Resource, bekommt man einen zusätzlichen Reiter mit den Optionen für die virtuelle Maschine und kann alles hierbei festlegen. Anschließend wird die VM erzeugt und beispielsweise über PXE gebootet und mittels Kickstart installiert. Hierbei wird auch Puppet gleich mit installiert und die virtuelle Maschinen von Anfang damit konfiguriert.
Wie man sieht zwei völlig unterschiedliche Ansätze. Auf den Unterschied bei Installation und Verwendung auf Kommandozeile oder in der Weboberfläche möchte ich nicht eingehen, hier hat jeder persönliche Präferenzen und der Admin ist meist zufrieden solang es zuverlässig geht. Interessanter finde ich etwas unter die Haube zu schauen:

  • Geschwindigkeit: Hier gewinnt klar das Deployment aus einem Template. In meinen Augen ist die Frage, ob 5 Minuten oder 30, aber nur in den wenigsten Umgebungen entscheidend.
  • Sauberkeit: Hier gewinnt für mich das Deployment durch automatisierte Installation. Zum einen ist es aufwendig ein sauberes Template aus einem installierten System zu machen (zu beachten: Host-Keys, Puppet-Zertifkate, Netzwerkkonfiguration, Regeln für persistente Gerätenamen, Logs, …), dieses dann immer sauber und aktuell zu halten und zum anderen muss ich diesen Aufwand immer wieder neu betreiben und gewährleisten dass auch der nächste Betriebssystemrelease ähnlich aussieht.
  • Übertragbarkeit: Hier gewinnt auch wieder die automatische Installation, denn ich kann den gleichen Automatismus für physikalische Systeme und virtuelle Maschinen nutzen, sogar egal welche Virtualisierungslösung.
  • Nachvollziehbarkeit: Diese habe ich leider bei beiden Lösungen nur bedingt. Klone ich meine VM aus dem Template driften diese genauso auseinander wie bei der Autoinstallation. Aber einen leichter Vorteil sehe ich für letztere da man die Installationsanweisung (nach der installiert wurde) auf dem System ablegen kann, diese im Deploymenttool versionieren kann, etc.
  • Arbeitsaufwand: Auch hier kann ich weder für die eine Seite noch für die andere stimmen. Die manuelle Installation für das Template kann für manch proprietäre Software einfacher sein, aber nachdem unser Ziel ist alles mit Puppet zu erschlagen, sollte der Aufwand unabhängig von der Lösung gleich sein. Der initiale Aufwand für die automatische Installation ist aber typischerweise etwas höher, je nach Betriebssystem sogar drastisch höher (Windows hat leider kein Kickstart 😉 ).
  • Dokumentation: Klarer Sieg für Autoinstallation, da ich auf der Seite von “Quelltext ist die beste Dokumentation” stehe.
  • Security und Rollentrennung: Die internen Vorgaben brechen hier leicht der automatisierten Installation das Genick. Dürfen die Admins für das Betriebssystem nicht auf die Virtualisierung zugreifen ist dies für beide Lösungen nicht hilfreich, aber Templates vorbereiten und dann durch den VMware-Admin ausrollen zu lassen ist meist noch durchsetzbar.

Dies sind in meinen Augen die wichtigsten Punkte und für mich hat nicht nur aufgrund persönlicher schlechter Erfahrung die automatische Installation und somit Foreman mit seinen Compute Ressourcen die Nase vorn. Beide Lösungen lassen aber noch ein Feature vermissen, denn wenn ich nachträglich die virtuelle Hardware noch anpassen könnte, bräuchte ich keinen Zugriff mehr auf eine andere Management-Oberfläche.
Wie gesagt mich würde die Lesermeinung zu dem Thema interessieren, darum schaut euch die Lösungen Cloud Provisioner und Compute Ressource gegebenfalls nochmal an und dann kommentiert fleißig.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.