26 – 30 May ended the month with a webinar and tips for VM provisioning, an Icinga 2 Beta release, and musings on development and Logstash training.
Much ado about VMs, Christian and Lennart held their webinar on Puppet: Provisioning on VMWare, as Achim brought Foreman, Fog and OpenNebula together with an OpenNebula Fog provider.
Bernd celebrated the release of Icinga 2 Beta while Gunnar meditated on writing user-friendly error alerts as a developer.
To end the week, Thomas reflected on the last few rounds of our Logstash training courses, and the development of our workshop materials to keep pace with software releases.
NETWAYS Blog
Reminder für das morgige Puppet-Webinar
Ich möchte noch einmal die Gelegenheit nutzen und auf unser morgiges Puppet-Webinar zum Thema „Puppet: Provisionierung von VMware“ aufmerksam machen. Das Webinar findet morgen um 10:30 Uhr statt. Die Registrierung erfolgt wie immer über unsere Webinar-Seite.
Da Virtualisierungslösungen mittlerweile in fast jeder IT-Landschaft eingesetzt werden, wollen wir aufzeigen wie man diese sinnvoll mit einem Configuration Management Tool wie Puppet kombinieren kann. Wer Puppet noch nicht kennt, dem empfehle ich unser Webinar-Archiv von der Open Source Variante von Puppet und der Puppet Enterprise Variante als kleine Vorbereitung.
Lennart und ich freuen uns bereits.
Bis morgen!
Christian Stein
Manager Sales
Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".
Weekly Snap: VMware & FreeBSD, End-to-End Monitoring & Headless
31 March – 4 April started a new month with monitoring tips and fun galore, a how-to guide or two, as well as new hardware.
Eva started the week by counting 8 days to the OSDC and sharing Jan Gehring’s talk on “Orchestrating Servers with Rex” as Bernd peddled our last two tickets to the Berlin event.
He also released the ultimate check_netways plugin just in time for April 1st and offered video evidence that we are home to Germany’s most flexible salesman.
Johannes then gave a guide to installing VMware tools on a FreeBSD 6-8 guest while Christoph showed how to set up end-to-end monitoring with Watir WebDriver and Headless.
Christian continued the monitoring theme, reminding interested attendees to join our Icinga Web webinar and Georg announced newcomers to our hardware store: Braintower SMS Gateway S & L with workshops to boot.
Deployment virtueller Maschinen – Cloud Provisoner vs. Compute Resource
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
Principal 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.
Virtuelle Entwicklungsumgebungen mit Vagrant
Mit Vagrant beschreibt und erstellt man virtuelle Entwicklungsumgebungen, was Entwicklern das Leben deutlich vereinfacht. Es läuft unter Linux, Windows und Mac OS X. Wenige Handgriffe reichen, um eine virtuelle Maschine in Betrieb zu nehmen und einzurichten.
Die Umgebung wird über ein Vagrantfile konfiguriert, welches u.a. port forwarding, mounts, Netzwerkkonfiguration und automatische Installation von Software steuert. Letzteres ist über Shellskripte, Ansible, Chef oder Puppet möglich.
Vagrant kann out of the box mit VirtualBox verwendet werden. VMWare ist auch möglich, aber kostenpflichtig. Weitere provider wie lxc findet man auf github.
Warum Vagrant?
Hauptgrund ist die klar definierte Umgebung. Jeder arbeitet mit den exakt gleichen Bibliotheken und identischen Versionen von Software. Infrastrukturkomponenten müssen nicht lokal installiert werden und die Umgebung ist reproduzierbar.
Zum Weiterlesen empfehle ich die Anleitung für Einsteiger.
Eric Lippmann
CTO
Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.
