The Puppet Anchor Pattern in Practice

Recently, my team rewrote all Puppet manifests for Mayflower’s core infrastructure with our two year long Puppet experience in mind. Many mistakes were made in the past, but this time we decided to write clean and structured Puppet code based on the latest language features from Puppet 3. More blog posts about advanced Puppet topics are going to be published in 2014.

The main theme of the rewrite was abstraction. Our goal was to use as many third-party modules as possible. Because many modules needed fixes, we contributed a lot of code back to the community. We adopted the Roles, Profiles, Components Design and use Hiera extensively to separate business logic, modules, manifests and data. Our manifests basically glue the modules together and embed them sensibly in our environment, seeded with data from Hiera.

The Problem

If you’ve written your fair share of Puppet manifests, you can imagine that such an architecture requires the definition and inclusion of lots of classes. Sadly, Puppet’s dependency system treats classes different than resources: If you include class foo in class bar, then class  foo and all its contained resources and dependencies won’t have any dependency relations with class bar. Weiterlesen

Development Environments with Vagrant and Puppet

Motivation

Setting up the infrastructure for new projects can be quite a pain in the ***. Even after the initial setup is done, adding new developers to the team requires a lot of time. Besides explaining the project to the new team member, the project’s development environment has to be installed on the new developer’s computer. This includes setting up virtual machines, web- and database-servers, updating libraries etc.

Many IT companies use the same technologies repeatedly which leaves them with multiple development environments that look very similar but have been set up separately. This problem can be solved by using a configuration management software and a smart tool for handling virtual machines.

Weiterlesen

IPC die Zweite – DevOps

Nach einem sehr guten Mittagessen, in tollem Ambiente ging es weiter mit dem Powerworkshop von Soenke Ruempler (Jimdo) und Johann-Peter Hartmann (SektionEins GmbH, Mayflower GmbH).
Da sich, vielleicht zum Glück, nur wenige Teilnehmer für diesen Workshop fanden, ging die Vorstellungsrunde recht flink und es wurde schnell deutlich was wir als Publikum zu erwarten hatten.
Die Vortragenden stellten klar das PHP seinen größten Vorteil, das schnelle umsetzen von Anforderungen, durch fortschreitende Professionalisierung eingebüßt habe und Scrum nur einen Teil der Lösung darstellt.
Grund für die Tatsache, dass der Scrumprozess bei dem Benutzer nicht ankommt sind seltene Deployments, welche mehrere Features zusammenfassen.
Dadurch wird der in kurzen Iterationen angelegte Scrumprozess von einem wasserfallartigen Deployment überdeckt.
Grund für die seltenen Deployments ist der erhebliche Zeitaufwand für die Administratoren und der fehlende Projekt überblick, auch als Silo-Problematik bekannt.

Eine mögliche Lösung für das fehlende Betrachten des Gesamtprojektes, wurde mit Kanban recht ausführlich vorgestellt.
Dieses kann genutzt werden, um Engpässe im Projekt zu visualisieren, vor allem wenn diese zwischen Abteilungen entstehen.

Wichtigster Teil des Vortrages war es aber, die Lücke zwischen Development und Administration zu schließen.
Während die Developer vorrangig die Features im Blick haben, steht für die Administration der Reibungslose Ablauf im Tagesbetrieb im Vordergrund.

Schließen kann man diese Lücke durch das richtige Toolset.
Die Administrationsseite kümmert sich darum, eine Infrastruktur zu schaffen, damit das Deployment von den Entwicklern übernommen werden kann und bekommt im Gegenzug das lästige Deployment abgenommen.
Dadurch werden Kapazitäten frei, um die Infrastruktur zu erweitern, was beiden Seiten zu gute kommt.

Für diesen Zweck wurden Puppet und Vagrant vorgestellt.

Puppet ist ein System zur automatisierten Verteilung und Durchführung von Serverkonfigurationen.
Mit Vagrant wurde er Tool vorgestellt, welches anhand von Konfigurationsbeschreibungen beliebig viele virtuelle Maschinen aufsetzten kann.
Konfigurationen können dabei auch aus einem Puppet-Repository stammen, was den Verwaltungsaufwand reduziert.
Mit beiden Tools in Kombination ist es möglich, lokal das Produktivsystem nachzustellen und zu testen.
Das anlegen mehrerer vorkonfigurierter Server wurde dabei ausführlich vorgeführt.

Anschließend wurde noch das Buildpipelining vorgestellt, am Beispiel des Mapolis Projektes.
Buildpipelining beschreibt die Möglichkeit PHPUnit Test und Selenium Test getrennt voneinander auszuführen, letztere nur nach erfolgreichem Verlauf der voran gegangenen Tests.
Theoretisch kann nach erfolgreichem Bestehen aller Buildprojekte ein automatischer Deploy erfolgen.
Praktisch wird jedoch oftmals noch die Freigabe des Projektleiters benötigt.

Das Ziel des Workshops, Administratoren und Entwicklern Tools aufzuzeigen, die die Deploymentrate erhöhen können, wurde in 4 Stunden gut vermittelt und es wurde klar gestellt, dass es mithilfe dieser Tools möglich ist, PHP seinen verlorenen Wettbewerbsvorteil zurück zu geben.
Dennoch waren die 4 Stunden sehr knapp bemessen, die größtenteils abstrakten Inhalte zu vermitteln, weshalb ich trotz der vielen mitgenommenen Ideen danach froh war entspannen zu können.