Puppet Camp Nürnberg 2013

Am 19. April 2013 fand das zweite Puppet Camp in Nürnberg statt. Veranstalter war wie schon beim ersten Puppet Camp 2012 Netways aus Nürnberg. Auch in diesem Jahr war der Raum bis zum letzten Platz besetzt.

Das Camp begann mit der Keynote von Nigel Kersten (CTO von Puppet Labs) mit seinem Bericht über den aktuellen Stand der Entwicklung von Puppet. Bereits verfügbar ist die neue Version 1.7 von facter. Neu in dieser Version ist die Möglichkeit den Inhalt von yaml, json und txt Dateien als Facts zu importieren. Der nächste Schritt der Entwicklung ist hier die Unterstützung von typisierten und strukturierten Facts. Als Beispiel sei die Auflistung aller Netzwerkschnittstellen mit deren MAC und IP-Adressen genannt.

neu in Puppet 3.2

Interessant sind auch die Neuerungen im kommenden Puppet 3.2. Für mich weniger wichtig ist die Unterstützung “externer” CAs bzw. integration der Puppet CA in eine bereits bestehende PKI (public key infrastructure). Nützlicher finde ich das Profiling für die Erstellung der catalogs. Gerade bei umfangreichen Katalogen besteht damit die Möglichkeit die Laufzeit von Puppet besser zu analysieren.

Highlight wird für mich der “future parser” für die Manifeste. Puppet Labs reagiert damit auf die recht “sperrige” Ruby DSL für Puppet. Stück für Stück sollen über den (optionalen) Future Parser neue Sprachelemente in Puppet integriert werden. Der neue Parser muss explizit aktiviert werden, so dass Probleme in vorhandenen Umgebungen ausgeschlossen werden.

Als erstes wird die Bearbeitung von Hashes und Arrays integriert. So kann man über Arrays iterieren und für die einzelnen Elemente Resourcen definieren.

$array = [ 1, 2, 3 ]
each ($array) | $value | { notice $value }

Der Syntax ist – für mich nicht überraschend – an Ruby angelehnt.

Puppet everywhere

Puppet soll in Zukunft auf weiteren Geräten eingesetzt werden können. Schon jetzt gibt es eine “Portierung” von Puppet auf Junos um die Switches und Router von Juniper mit Puppet zu verwalten. Begeistert zeigte sich Nigel über die Unterstützung von OpenWRT die mit Puppet 3.2 geliefert wird.

Refactoring Puppet

Im zweiten Vortrag beschäftigte sich James Fryman von GitHub mit dem Refactoring von Puppet Code. Aus Sicht eines Softwareentwicklers erzählte James nichts neues. Der Code muss wartbar und lesbar sein, damit man auch in Zukunft versteht, was passiert. Er zeigte hierzu praktische Beispiele und Strategien die jeder sofort umsetzen kann.

James verstand es sehr gut die Vorteile von sauberen Code an die versammelten Nutzer von Puppet zu bringen. Ich hätte als Argument für lesbaren Code noch angemerkt, dass Code wesentlich öfter gelesen als geschrieben wird.

Überzeugt hat er allerdings mit dem Argument, dass man seine Zeit lieber angenehmeren Dingen verbringt. Ein guter Administrator ist ein fauler Administrator und ein fauler Administrator kann Bier trinken gehen. Womit er auch gleich zum DrinkHub einlud.

Puppet bei Porsche

Eine Praxisbericht zum Einsatz von Puppet bei Porsche Informatik präsentierte Michael Haslgruebler. Interessant war vor allem der Einsatz eines ENC (external nodes classifier) um den Operatern das Leben möglichst einfach zu machen. Gefallen hat mir, dass Michael – wie auch ich – nicht aus der Administration sondern aus der Softwareentwicklung kommt. Auch beim letzten Puppet Camp wurde ein Vortrag von einem Softwareentwickler gehalten. Ich bin mit meinem Hintergrund – administrierender Software-Entwickler – also nicht allein.

Voodoo with Thomas

Der Voodoo-Master vom letzten Puppet Camp hatte auch in diesem Jahr wieder einen Auftritt. Das Thema hörte sich erst relativ unspektakulär an. Thomas Gelf von Netways verstand es auf die Besonderheiten und Fallen bei der Nutzung der CA von Puppet hinzuweisen.

Sicherlich werden am Montag einige ihre Zertifikate untersuchen und hoffen, dass diese nicht in den nächsten Monaten ablaufen. Wenn dem so wäre, müsste neben den Client-Zertifikaten die komplette CA neu erstellt werden. Bei einer dreistelligen Anzahl an Clients sind da ein paar Überstunden angesagt. Mir war bisher nicht bekannt, dass die derzeitige Implementierung der CA Zertifikate nicht regenerieren kann!

The Foreman

Gespannt war ich auf den Vortrag des Maintainers von The Foreman Ohad Levy. Ich bin derzeit damit beschäftigt diese Software bei einem Kunden einzuführen. Neben einem “Ersatz” für das Dashboard bietet The Foreman eine hervorragende Unterstützung beim Provisioning von Bare Metal undVirtuellen Systemen.

Der Vortrag von Ohad hat einen guten Überblick über die umfangreichen Funktionen von The Foreman gegeben. Die Life-Präsentation war faszinierend. Obwohl ich mich bereits intensiver mit der Software beschäftigt habe, konnte Ohad noch den einen oder neuen Aspekt für mich präsentieren. Ich bin mir sicher, dass ich mit der Auswahl von The Foreman auf das “richtige Pferd” gesetzt habe.

Islands of Puppets

Über ganz spezielle Aspekte beim Einsatz von Puppet sprach Lindsay Homwood von Bulletproof Networks. Der Hosting Provider betreibt für jeden Kunden einen eigenen Puppet Master – islands of puppets. Trotz der unterschiedlichen „Inseln“ sollen alle Module Repositories mit dem gleichen Stand arbeiten. Allerdings muss bei dem einen oder anderen Modul eine kundenspezifische Änderung möglich sein.

Durch den Einsatz verschiedener Tools haben die Jungs von Bulletproof Networks trotzdem ein homogenes und hoch automatisiertes System erstellt. Kern ist hier die umfangreiche Nutzung des Deployments Tools capastrino.

Cloud Provisioning mit Razor

Einen beeindruckenden Schlusspunkt setzte für mich Jonas Rosland von EMC mit seiner Präsentation von Razor. Das Tool wird von EMC zusammen mit Puppet Labs entwickelt und supported. Es bietet die Möglichkeit Systeme in einer Cloud automatisiert mit einem Betriebssystem und anschließend Puppet zu versorgen. Die Besonderheit hier ist, dass der Start der Installation nicht vom Benutzer sondern von einem Ereignis (System wird eingeschaltet) angestoßen wird.

Über PXE wird das System mit einem Micro-Kernel gebootet. In diesem Kernel ist Facter integriert. Nach einem Factor-Lauf wendet sich der Kernel mit den Facts an den Razor Server. Dieser wählt aufgrund der Facts das zu installierende System aus. Der Micro-Kernel versorgt das System mit dem passenden Image. Nach dem Booten des Images wird die Kontrolle an Puppet für die weitere Konfiguration des Systems übergeben.

Fazit

Das Puppet Camp 2013 war eine gelungene Veranstaltung. Begeistert bin ich über die hohe Fachkompetenz der Speaker. Schön finde ich, dass einzelne Redner extra wegen des Puppet Camps aus dem Ausland anreißen. Mein herzlicher Dank an Netways und Puppet Labs für die hervorragende Organisation.

Das nächste Puppet Camp findet nicht mehr in Nürnberg sondern in Berlin im Anschluss an die OSDC 2014 statt. Für mich ergibt sich damit eine längere Anreise inkl. Übernachtung. Aufgrund der letzten beiden Puppet Camps werde ich diese “Last” aber gerne auf mich nehmen.