Was gibt’s Neues vom Director?

Gleich zwei neue Releases stehen an, und während die v1.3.2 bereits vor einer Woche inoffiziell getagged wurde, werden bei der v1.4.0 gerade noch die letzten Kanten rund geschliffen. Wenn nichts dazwischen kommt werden dann Anfang nächster Woche beide gemeinsam offiziell angekündigt werden.

Director v1.4.0 Dashboard

Director v1.4.0 Dashboard

Warum aber gleich zwei Releases auf einmal?

Director v1.4.0 versucht zwar, optisch möglichst nah an seinem Vorgänger zu bleiben, ist aber unter der Haube in großen Teilen komplett neu. In diesem Zuge haben wir die System-Anforderungen minimal erhöht, PHP 5.4 anstelle von PHP 5.3 ist jetzt vonnöten. Wer beste Performance und minimalen Ressourcenverbrauch schätzt, sollte auf 7.x wechseln.

Property Modifier "Combine"

Property Modifier “Combine”

PHP 5.4 sollte in allen aktiv von uns unterstützten Linux-Distributionen verfügbar sein, lediglich Nutzer von RHEL/CentOS 6.x müssten deren Konfiguration auf die in den offiziellen SCLs (Software Collections) vorhandenen Pakete umstellen. Das Standardverhalten beim Packaging von Icinga Web 2 werden wir vermutlich heuer noch entsprechend umbauen.

Property Modifier "Array Filter"

Property Modifier “Array Filter”

Für all jene, die jetzt auf die Schnelle nicht umstellen können/wollen ist die neue Version 1.3.2 gedacht. Diese enthält eine ganze Menge kleinerer und größerer Bugfixes, welche seit der 1.3.1 entstanden sind. Zudem haben wir ein paar neue nützliche Import Property Modifier einfließen lassen. Da sie am bestehenden Verhalten nichts ändern, durften sie gemeinsam mit ein paar neuen CLI-Befehlen mit in dieses Patch-Release:

Einfachere Suche, flexiblere Tabellen

Sämtliche Tabellen unterstützen intern zwar weiterhin unsere mächtigen Filter-Funktionen, stellen in der GUI aber vorerst nur noch ein einfaches Suchfeld bereit. Einfach testen, mehrere Wörter kombinieren, auch wenn diese in unterschiedlichen Spalten stecken – es sollte ziemlich intuitiv sein.

Beim Umbau der Tabellen sind neue generische Features entstanden. So konnten wir ohne großen Aufwand an mehreren Stellen historische Darstellungen säuberlich nach Tagen getrennt übersichtlicher gestalten.

Director Deployment History

Historie der Deployment

 

Template Choices

Der Director trennt strikt zwischen Objekten und Templates und erlaubt bestimmte Optionen nur an Templates. Das hat einen einfachen Grund: Templates sollen von Icinga-Admins betreut werden, “normale” Objekte (also Hosts und Services) sollen aber durchaus Systembetreuer nutzen dürfen, die sich nicht täglich um’s Monitoring kümmern. Alles was potentiell “gefährlich” sein kann wird aus dem Grund dort nicht angeboten.

Host Template Choices: Dashboard, Table

Host Template Choices: Dashboard, Tabelle

Nun ist es aber nicht gerade intuitiv, bei jedem zweiten Host zusätzlich ein Template namens “Schnelle Checks” einzubinden. Also erstellt man sich jetzt sogenannte Choices, gibt denen einen schönen Namen – und bietet sie auf diese Weise elegant im Formular an.

Template Choice in Action

Template Choices in Aktion

 

Schnelleres Arbeiten mit einzelnen Services

Die letzten Director-Releases kamen mit so einigen neuen Tricks. Gerade die “Variable Overrides” werden gern genutzt. Sie erlauben das Ändern von Schwellwerten für einzelne Hosts auch dann, wenn der zugehörige Service eigentlich via Apply-Rule erstellt wird.

Mehrere Services auswählen

Die Version 1.4.0 legt jetzt den Fokus auf schnelleres Arbeiten mit einzelnen Services. Neu ist eine Übersicht aller Einzel-Services auf allen Hosts. Von hier kann man mit SHIFT/STRG-Klick mehrere Services auswählen und gemeinsam anpassen. Oder löschen. Selbiges geht auch in die andere Richtung bei den Hosts: mehrere auswählen, Service oder Service Set hinzufügen, wählen, speichern:

Mehrere Services auf einmal bearbeiten

Mehrere Services auf einmal bearbeiten

Autocompletion

Neu an Board ist endlich ein Mechanismus zur Autovervollständigung. Dieser hat bereits so einige Dropdownfelder abgelöst und wird in Zukunft noch intensiv für weitere Aufgaben genutzt werden.

Autovervollständigung

Autovervollständigung

Gerade Formulare welche potentiell viele Objekte verknüpfen müssen, können wir damit jetzt schonend für den Browser umsetzen. Dependencies, Ein Punkt der schon lange auf der Wunschliste steht, kommen damit jetzt in Reichweite!

Neue Dashboards und Dashlets

Wie schon der Screenshot eingangs gezeigt hat: das Dashboard wurde umgestaltet und aufgeräumt. Die Tabs passen zu den Dashlets, wenn man umschaltet wird optisch hervorgehoben, wo man sich befindet. Aber nicht nur das, es kamen viele neue Unter-Dashboards hinzu. Und, neu in Kombination mit den Tabs: im Zweispalten-Modus macht ein Doppelklick auf den Tab-Titel jetzt die aktuelle Spalte “groß”.

Mobiles Director Dashboard

Mobiles Director Dashboard

Das Layout wurde übrigens für breitere Bildschirme auf ein 50/50 Spaltenverhältnis umgestellt, statt wie bisher 33/66. Sehr viele Verbesserungen gab es auch beim mobilen Layout. Dashboards sind dort jetzt angenehmer und auch die Formulare wurden für mobile Nutzung optimiert:

Formulare - mobile

Formulare – mobile

Vererbung ist alles

Bugs im Template-Baum wurden gefixt, und ganz neu ist eine Übersicht welche die Nutzung von Templates anzeigt:

Template-Baum

Template-Baum

Zudem werden Apply-Regeln für Hostgruppen jetzt voll aufgelöst und Gruppenmitglieder sowie der Typ der Mitgliedschaft (direkt oder via Apply) werden angezeigt.

Benutzung von Templates

Benutzung von Templates

Berechtigungen

Damit wären wir auch schon beim nächsten Thema. Das Auflösen von Vererbung und Apply-Regeln erlaubt uns jetzt endlich, entsprechende Restrictions freizugeben. Begonnen haben wir mit dem was einige unserer Kunden am dringendsten benötigt hatten. Hostgruppen, unterschiedliche Prefix-basierte Filter, sogar einzelne Einträge in Data Lists können jetzt nur für bestimmte Rollen freigegeben werden.

Genutzte Custom Variablen

Eher an Admins richtet sich ein neues Feature, das eine Übersicht aller benutzten Custom Variablen und deren Varianten anzeigen kann:

Übersicht Custom-Variablen

Übersicht Custom-Variablen

Genutzte Varianten einer bestimmten Variable

Genutzte Varianten einer bestimmten Variable

An dieser Stelle möchten wir in Zukunft noch die Möglichkeit anbieten, gleich an Ort und Stelle umfangreiche Massen-Changes und Aufräumarbeiten vornehmen zu können.

Stark überarbeitet wurde übrigens auch die Inspect-Funktionalität. Wer tiefer in den Core blicken möchte findet dort jetzt detaillierte Informationen zu den verfügbaren Eigenschaften und Methoden der unterschiedlichen Objekt-Typen. Auch der aktuelle Status der einzelnen Komponenten lässt sich abrufen, wenn auch noch nicht sehr schön formatiert.

VMware vSphere/ESXi Import

Diese Funktionalität wurde im Kundenauftrag als dediziertes Icinga Web 2 Modul entwickelt. Vorerst stellt es “nur” eine Import-Quelle für den Icinga-Director bereit. Wir haben damit aber noch so einiges vor. So möchten wir das Modul so aufbohren, dass es in einem kleinen eigenen DB-Schema ein Subset der in vSphere verfügbaren Informationen vorhält und ständig aktuell hält.

VMware vSphere Import

VMware vSphere Import

Festhalten wollen wir vor allem:

  • Welche VM mit welchen Eigenschaften seit wann wo läuft
  • Eine Historie der Migrationen
  • Ein paar wenige aggregierte aktuell Kennzahlen/Performancewerte

Diese Informationen möchten wir dann gleich mehrfach nutzen:

  • Für schnellere und schonendere Check-Plugins, da diese darauf verzichten können bei jedem Aufruf mit teuren API-Abfragen die benötigten Komponenten zu suchen
  • Für ein kleines Visualisierungsmodul
  • Um Zusatz-Informationen via Hook anderen Modulen in Icinga Web 2 bereitzustellen, in erste Linie natürlich dem zentralen Monitoring-Modul.

Bei der Entwicklung wurde auf sämtliche SDKs von VMware verzichtet. Mit selbigen hatten wir bisher keine guten Erfahrungen gesammelt. Probleme beim Upgrade, Inkompatibilitäten anderen Bibliotheken und/oder je nach Sprache auch einfach vollständiger Entwicklungsstillstand machten das Leben schwer.

Bei diesem Modul sind wir jetzt einen anderen Weg gegangen und nutzen zu 100% eigenem Code. Der deckt natürlich nicht die volle API ab – aber all das was wir brauchen. Damit fällt einiges an Overhead weg, und wir haben bei Bedarf die Möglichkeit viel flexibler auf Inkonsistenzen bei neuen Releases reagieren zu können. Wir sprechen direkt mit der SOAP-Schnittstelle und schaffen es damit, einen ziemlich breiten Bereich von vSphere- und ESXi-Versionen abdecken zu können. Für Nutzer des Moduls heißt das: runterladen, aktivieren, loslegen.

Es wird jedenfalls nicht langweilig. Und in diesem Sinne wünsche ich schon mal ein schönes Wochenende!

Thomas Gelf

Autor: Thomas Gelf

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

AnsibleFest London

Thilo, mein alter Azubi Kollege, und ich haben dieses Jahr das erste mal am AnsibleFest in London teilgenommen. Ziel davon war es, den Blickwinkel zu erweitern und zu sehen, welche Möglichkeiten es mit Ansible gibt und wie sie von anderen Unternehmen ausgeschöpft werden.
Die Unternehmen, die Vorträge gehalte oder an Interviews teilgenommen haben, erstrecken sich von Siemens, über Ansible selbst bis hin zur britischen Armee. Mich hat sehr erstaunt, dass sogar die britische Armee Ansible im produktiven Einsatz hat und dann auch einen Talk darüber abhält!

Das Ambiente war sehr vornehm. Die Veranstaltung fand im “InterContinental London” statt. Wie wir es von NETWAYS Veranstaltungen schon gewohnt sind, gab es reichlich zu Essen und zu Trinken, was uns nach der etwas längeren Anreise, doch zu Gute kam.

Als OpenSource Firma kommen wir bei NETWAYS immer mehr in Kontakt mit dem Configuration Management Tool Ansible. Bereits die ersten Kunden sind auf uns, eben wegen Ansible zugekommen und haben in Zusammenarbeit mit uns ihr Setup aufgebaut. Die Verwaltung der Produktivsysteme läuft demnach mit Ansible und diese Konfigurationen sind sowohl für uns als Administratoren als auch für den Kunden selbst mittels Git zugänglich. Falls auch ihr euch überlegt, eure Systeme mit Ansible zu verwalten, dann kommt gerne auf uns zu! Wir helfen gerne.

Zum Abschluss sind hier noch Bilder vom Hotel sowie von der Anreise hinterlegt.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Request Tracker Starterpakete verfügbar

rt_centred_200x100 Seit vielen Jahren setzen wir nun bei uns intern die Ticket Lösung Request Tracker ein und bieten hierfür Dienstleistungen im Bereich Konzeptionierung, Einrichtung, Entwicklung und Support an.

Um einen kostengünstigen und vereinheitlichten Einstieg in die Open Source Ticketlösung zu ermöglichen, haben wir unser Portfolio in diesem Zuge um zwei Starterpakete erweitert. Somit kann ohne große finanzielle Vorleistungen ein Basissetup aufgebaut werden, welches als Test- und Reviewumgebung dient. Ein späterer Ausbau bzw. eine Erweiterung kann im Vorfeld natürlich berücksichtigt werden, sollte die Ticketlösung Produktiv genommen werden.

Im Standard-Paket sind hierbei folgende Leistungen zum Festpreis beinhaltet:

  • Grundinstallation des Request Trackers auf Debian / Ubuntu / CentOS
  • Anbindung an ein Mail-System per SMTP-Transport oder Fetch-Mail
  • Anbindung an einen ActiveDirectory / LDAP-Dienst
  • Beispielhafte Einrichtung von Queues und Benutzern
  • Beispielhafte Einrichtung von Berechtigungen
  • Grundeinführung in die Bedienung der Oberfläche

Für das Premium-Paket gibt es weiterführende Leistungen, wie bspw. Anbindung externer Datenquellen, Customizing und RT-Assets:

  • Anbindung Externer Datenquellen per Schnittstellen (API, Soap, Sql)
  • Grundeinrichtung und Einführung in RT Assets
  • Customizing von Templates und Articles
  • Konfiguration von Lifecycles, Status, SLA’s

Wer sich allgemein über den Request Tracker informieren möchte, kann dies mit unserer Übersichtsseite Warum Request Tracker oder unserem RT Webinar tun.
Selbstverständlich stehen wir bei Rückfragen natürlich zur Verfügung und bieten weiterführende Dienstleistungen und Workshops für Projekte an. Nehmen Sie hierfür einfach direkt Kontakt mit uns auf.

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer 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".

Foreman wird 7 – Wie war die Party?

Foreman Logo

Wie sich einige vielleicht erinnern, hatte ich vor ein paar Wochen zur Feier zum 7. Geburtstag des Foreman-Projekt eingeladen. Nun möchte ich den in meinen Augen gelungenen Event Review passieren lassen.

Mehr oder weniger pünktlich hat sich ein Teilnehmer-Kreis von 20 Leuten (zu Spitzenzeiten) eingefunden, der auch einige Mitglieder des Foreman-Teams umfasst hat. Besonders erwähnenswert sind hier Greg Sutcliffe, der es sich nicht nehmen lies als Community Manager aus Schottland herunterzukommen, und Ewoud Kohl van Wijngaarden, der den weiten Weg aus den Niederlanden auf sich nahm.

Den Anfang durfte ich machen, hatte aber wirklich nur ein paar Folien vorbereitet um nochmal ans geplante Programm zu erinnern, die Räumlichkeiten vorzustellen und die für die Hands-On-Session vorbereiteten Demo-Systeme zu erläutern. 4 Stück hatte ich vorbereitet, von denen zwei Foreman 1.12 mit alle den Möglichkeiten zeigten die ich auch in der Schulung vorstelle, einmal auf Basis Puppet 3 und einmal Puppet 4. Eines zeigte Katello 3.0, das Foreman unter anderem mit seinen Lifecycle-Environments um Staging für Content erweitert. Als viertes Demo-Setup hatte ich mir vorgenommen was besonderes zu zeigen und da es aufgrund fehlender Zeit zum Testen mit Windowsdeployment nicht geklappt hat, habe ich mich dem Docker-Hype angepasst und das Docker-Plugin für Foreman installiert. Nachdem die Teilnehmer auf die Systeme losgelassen wurden, konnte sich wohl keiner der “Foreman-Wissenden” mehr vor Fragen retten. Ein hohes Interesse bestand an nach meiner Auffassung vor allem an der Funktionsweise der Compute Resources, welche es erlaubt virtuelle Maschinen aus Foreman heraus anzulegen und direkt zu provisionieren, und dem Remote Execution Plugin, welches Orchestration ermöglicht. Erfreut war ich aber auch einigen OpenSCAP zur Überwachung von Compliance-Policies und ABRT als zentrales Crash-Reporting näher bringen zu dürfen. Alle waren am Ende so in Systeme und Diskussionen vertieft, dass wir gar keine offizielle Pause machten und stattdessen nahtlos zu den Vorträgen übergingen.

Foreman Event

Für die Vorträge haben wir eine gute Mischung gefunden, was ich so dem Feedback entnehmen durfte. Michael Moll stellte die Neuerungen in Foreman 1.12 vor und wenn man von einem der beteiligten Entwickler hört wie viel unter der Haube nötig war um sowas wie den “Puppet 4”-Support hinzubekommen, merkt man erst nochmal wie sehr sich die Versionen unterscheiden und versteht warum dieses Feature gefühlt anderthalb Jahre gebraucht hat. Der Ausblick auf 1.13 mit vollständigem IPv6-Support erfreute auch sicher viele. Timo Goebel stellte vor wie Filiadata, die IT-Tochter von dm, in nur 3 Jahren von 0 auf 2000 Linux-Server kam, welche zentrale Rolle Foreman dabei spielte und wie gut es hierbei gelungen ist die Integration in die Umgebung durch die Erweiterungsmöglichkeiten von Foreman umzusetzen. Hierbei hat er auch immer wieder die Hilfsbereitschaft der Forman-Community betont und dies hat Timo auch vom reinen Foreman-Anwender zum Core Contributor geführt. Interessant war auch seine noch offene Wunschliste zum Abschluss, man kann also sicher noch mit weiteren interessanten Plugins in der Zukunft rechnen. Den Abschluss der Vortragsreihe bildete Achim Ledermüller mit einem Einblick in die Opennebula-Foreman-Integration, die er mit den Kollegen entwickelt hat. Alles inklusive einer Livedemo mit den aktuellsten Versionen!

Foreman T-Shirt

Den gemütlichen Teil leitete dann unser Events-Team ein, welches uns dankenswerterweise mit Pizza versorgte. Netways-typisch konnte jeder Teilnehmer, der nicht mehr mit dem eigenen Auto fahren musste, noch bei Bier und Gin-Tonic weiter diskutieren und den Tag ausklingen lassen bis ich 2,5 Stunden später hinter den letzten das Licht aus machen durfte.

Mein vorläufiges Fazit ist es war ein gelungener Event und es wurde schon angeregt es zum 8. Geburtstag zu wiederholen. Ein paar Dinge habe ich auch schon dafür gelernt. Nächstes Mal gibt es die Einladung also hoffentlich früher und dann schon mit vollständigem Programm und Registrierungslink an allen Stellen. Für die Hands-On-Session, die auch gut ankam, werde ich nächstes Mal noch ein paar Slides einbauen, die nicht nur sagen was auf den Demo-Systemen installiert ist, sondern auch direkt ein paar Hinweise zur Nutzung geben. Und Greg hat schon mitgenommen die T-Shirt-Box muss größer sein! 😉

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.

Warum wir uns immer zu viel vornehmen?!

Ich weiss nicht wie es euch geht, aber ich mache eigentlich täglich die Erfahrung, daß geplante Dinge nicht erledigt werden. Dies gilt sowohl für komplexe Softwareprojekte, aber auch für kleine Änderungen an bestehenden Systemen.

Klar, eine punktgenaue Zeitschätzung für größere Projekte ist nicht ganz einfach. Hat man sich im Laufe seines Arbeitslebens mal mit klassischen Methoden wie COCOMO oder Delphi-Methode beschäftigt, hat man zwar ein paar Werkzeuge die einen bei der Beschätzung und Bewertung unterstützen, trotzdem ist auch ganz viel Erfahrung, Fingerspitzengefühl und permanenter Review des Ist-Standes notwendig um den Fortschritt in einem Projekt zu messen.

An wie vielen Tagen hast Du in der letzten Woche genau das erreicht, was Du dir vorgenommen hast? (Natürlich setzt die Hypothese voraus, das Du überhaupt irgendwas zu tun hast, sonst ist es zugegeben etwas schwierig) Durchschnittlich gelingt es einem normalen Menschen nur alle 20 Tage genau das zu erreichen, was er sich vorgenommen hat. Jetzt sollte man denken das die gemachte Negativerfahrung automatisch zu einer besseren Bewertung von kommenden Aufgaben führt. Genau das ist aber häufig leider nicht der Fall.

Die Ursache, dass wir unser geplantes Tagespensum und somit auch die Gesamtaufgabe nicht in der geplanten Zeit erledigen, ist im Grunde jedoch wesentlich trivialer und spannender. Wir bewerten anstehende Aufgaben in der Regel eher nach unserem Wunschdenken und unter einer zu optimistischen Betrachtung.

Der Begriff des sogenannte  Planungsfehlschlusses (Planning Fallacy) wurde erstmals 1979 von Daniel Kahneman und Amos Tverksky in einer Veröffentlichung geprägt. Er beschreibt das wir unsere eigene Leistungsfähigkeit deutlich optimistischer und unrealistischer bewerten, als es uns nach eigenem Wissen und Erfahrung möglich wäre. Trotz besserem Wissen glauben wir letztendlich wirklich, eine acht Stunden benötigende Aufgaben an einem Tag zu erledigen. Den Fakt und Erfahrungswert, dass uns Meetings, Anrufe, Kollegen und Verwaltungstätigkeiten 20% des Tages ausradieren lassen wir dabei völlig außen vor. Jetzt sollte man denken das die gemachte Negativerfahrung automatisch zu einer besseren Bewertung von kommenden Aufgaben führt. Genau das ist aber häufig leider nicht der Fall. Ich mache es kurz:

Wir bescheissen uns täglich selbst aufs Neue

Aus diesem Muster auszubrechen ist also nicht besonders einfach, aber es gibt einige Tricks die einem das Leben leichter machen:

  • Versucht aus der Vergangenheit (Timesheets oder Zeiterfassung) zu ermitteln wieviel Nettoarbeitszeit ihr täglich zu Verfügung habt. Dies verhindert zwar nicht die gnadenlose Selbstüberschätzung, garantiert jedoch ein realistischeres Bild über das zeitlich erreichbare.
  • Reflektiert ähnliche Projekte, die bereits in der Vergangenheit zeitlich aus dem Ruder gelaufen sind. Dies erlaubt einen realistischeren Blick auf die realen Auswirkungen und Seiteneffekte in der täglichen Arbeit
  • Beschätzt Aufgaben anonym und nicht im persönlichen Gespräch. Wir haben das angeborene Bedürfnis einen guten Eindruck zu machen und das hindert uns oft an einer realistischen Betrachtung der zu erledigenden Aufgabe wenn wir dem Chef gegenüber sitzen
  • Mein persönlicher Favorit ist die Durchführung eines Pre-Mortem. Setzt Euch bei größeren Projekten einige Tage vor Beginn zusammen und stellt Euch vor, in einem Monat oder Jahr von den Scherben Eures Projektes zu sitzen, welches ihr gnadenlos an die Wand gefahren habt. Malt euch dabei aus wie es nur dazu kommen konnte und ihr werdet auf das ein oder andere Problem stoßen, dass ihr bisher nicht berücksichtigt habt.

Aus eigener Erfahrung weiss ich, dass auch das Wissen um die Planning Fallacy nicht zwingend zur Vermeidung führt. Sie führt jedoch zu Verständnis. Wie oft habt ihr schon über eine Kollegin oder Kollegen geflucht, weil er das Versprochene nicht gehalten hat oder Projekte über Monate nicht an Land gewinnen.

Vorausgesetzt sie oder er ist kein fauler Hund, lohnt es sich durchaus mal hinter die Fassade zu blicken und ein Gefühl dafür zu entwickeln, welche Einflüsse auf andere und deren Tätigkeit so einwirken. Manchmal dauert es eben. Übrigens habe ich gedacht ich schreibe diesen Blog in 30 Minuten. Hat nicht geklappt!

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

GitLab – Webhooks

gitlab-webhooks

Da ich vor kurzem für einen unserer namhaften Kunden ein GitLab Setup aufsetzten durfte und dieser sich nun auch Automatische Checkouts seiner Live Branches auf seinen Produktiv Systemen wünschte, habe ich mich dazu entschlossen euch ein bisschen an der Einrichtung dieser Mechaniken teilhaben zu lassen, natürlich nicht im vollem Umfang des Projektes für unseren Kunden, das eine oder andere habe ich für diesen Artikel verständlicherweise leicht abwandeln müssen, das hier gezeigte funktioniert trotzdem, ich habe es selber ausprobiert.

Dann legen wir mal los…

In einem klassischen Git Setup werden die Hooks direkt im Repository im Unterordner hooks abgelegt, hier mal ein Beispiel wie das aussehen kann…

$ MyAwesomeProject/hooks $ ll
-rwxrwxr-x 1 enzo enzo  452 Jun 28 11:46 applypatch-msg.sample*
-rwxrwxr-x 1 enzo enzo  896 Jun 28 11:46 commit-msg.sample*
-rwxrwxr-x 1 enzo enzo  189 Jun 28 11:46 post-update.sample*
-rwxrwxr-x 1 enzo enzo  398 Jun 28 11:46 pre-applypatch.sample*
-rwxrwxr-x 1 enzo enzo 1642 Jun 28 11:46 pre-commit.sample*
-rwxrwxr-x 1 enzo enzo 1239 Jun 28 11:46 prepare-commit-msg.sample*
-rwxrwxr-x 1 enzo enzo 1352 Jun 28 11:46 pre-push.sample*
-rwxrwxr-x 1 enzo enzo 4898 Jun 28 11:46 pre-rebase.sample*
-rwxrwxr-x 1 enzo enzo 3611 Jun 28 11:46 update.sample*

GitLab geht hier allerdings einen anderen Weg, da dieses das hooks Verzeichnis durch einen Symbolischen Link auf System eigene Hooks umlenkt (wie hier Beispielhaft zu sehen ist)…

gitlab-webhooks-art2

…nun sollte man hier auch besser die Finger heraus lassen, da GitLab dieses Verzeichnis für allerlei anderen Mechaniken benötigt, der Weg über die Webhooks ist meiner Meinung nach aber auch flexibler (allein schon wegen der einfachen Anbindung an Web Dienste wie GitHub, Bitbucket, Heroku, etc.).

Nun direkt zum spaßigen Teil, im GitLab benötigen wir einen neuen User ohne irgendwelche besonderen Rechte incl. SSH Public Key, fangen wir mit dem Key selbst an, da der Checkout User keinen besonderen Rechte benötigt außer einen Pull/Fetch zu tätigen, reicht es uns den Key also entsprechend Unprivilegiert zu preparieren (bei der Passwortabfrage bitte nichts angeben, einfach mit Enter bestätigen)…

$ ssh-keygen -t rsa -b 2048 -O clear -O no-agent-forwarding -O no-port-forwarding -O no-pty -O no-user-rc -O no-x11-forwarding -f gitlab.key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in gitlab.key.
Your public key has been saved in gitlab.key.pub.
The key fingerprint is:
4b:f3:ae:60:d4:5d:5e:02:75:64:4c:7f:ce:09:ec:8a enzo@ebony
The key's randomart image is:
+--[ RSA 2048]----+
|          ...+=  |
|           ..o.. |
|            oo. o|
|       . . o.o.oo|
|      . S . .. .o|
|     . . +. .    |
|      o .E..     |
|     . . .       |
|        ...      |
+-----------------+
$ ll
insgesamt 8
-rw------- 1 enzo enzo 1675 Jun 28 11:52 gitlab.key
-rw-r--r-- 1 enzo enzo  392 Jun 28 11:52 gitlab.key.pub

…nun benötigen wir lediglich noch einen User im GitLab, das sollte keine große Herausforderung darstellen, bitte stellt auch sicher das ihr den SSH PublicKey in unserem Beispiel gitlab.key.pub dem User, lasst ihn uns hier der Einfachheit halber checkout nennen zuweist, da die Webhooks mit den Berechtigungen des Standard Apache User www-data läuft (das ist zumindest unter Debian/Ubuntu der Fall, unter Redhat Systemen heißt dieser wwwrun) solltet ihr dem Key als Identifier so etwas wie www-data to gitlab oder ähnliches benennen, damit ihr später ganz einfach den Überblick behalten könnt…

gitlab-webhooks-art4
gitlab-webhooks-art5

…nun müssen wir unserem User checkout lediglich noch in unser Projekt aufnehmen, die Rechte eines Reporter sollten dafür ausreichend sein um Fetch/Pull oder auch Clone zu können, mehr benötigen wir an dieser Stelle nicht…

gitlab-webhooks-art9

…somit sind wir auf schon fast fertig, zumindest was das GitLab Setup selbst betrifft, nun müssen wir lediglich noch die URL unseres Webhook konfigurieren und schon können wir uns dem Hook selber widmen…

gitlab-webhooks-art7

gitlab-webhooks-art8…bitte beachtet auch, das es beim Entwickeln eines Webhooks sehr hilfreich sein kann wenn ihr über den Button [Test Hook] den Push Event einfach mal Manuell triggert, ansonsten würde euer Webhook erst aufgerufen werden wenn ihr wirklich in das Repository Pusht (das geht natürlich auch, legt euch hierzu einfach ein neues Repository zum spielen an).

So nun geht es an den Server der unseren Webhook ausführen soll, ihr benötigt lediglich einen simplen Apache/NginX vHost mit Standard Rechten, man kann selbstverständlich auch ein komplizierteres Deployment bauen aber darum geht es in diesem Artikel nicht (ich nutzte hier den Apache2 mit PHP5, da dieser bereits auf dem Kunden System vorhanden wahr und zusätzliche Scriptsprachen installieren ist meist schlechte Praxis sowie auch unnötiger Aufwand).

Ich habe mich hier für den Standard Pfad des Apache Setups entschieden da der Standard vHost bereits auf diesen zeigt und dieser auch nur aus dem internen Netz bedienbar ist, somit ist sichergestellt das Niemand von außerhalb Unfug treiben kann.

Dort habe ich im DocumentRoot des Apache ein Verzeichnis api erstellt, der volle Pfad lautet hier /var/www/html/api, dort habe ich mein Webhook mit Namen on-push.php abgelegt, dieser hat nun folgenden Inhalt…

<?php
    // global settings
    define( "DEBUG", true );
    define( "OK", "Status: 200" ); 
    define( "ERR", "Status: 503" );
    define( "LOGFILE", getcwd()."/on-push.log" );
 
    // project settings
    define( "PROJECTROOT", "/var/www/project1/htdocs" );
    define( "BRANCH", "staging" );
    define( "COMMAND", "/bin/bash -c \"git fetch --all && git reset --hard origin/".BRANCH."\"" );
 
    // user which can do/trigger some updates on our staging branch
    $USERS = array( 'operator', 'developer1', 'developer2' );
 
    // =================================== MAIN =============================================
 
    try { 
        if( DEBUG ) {
            if( file_exists( LOGFILE ) ) unlink( LOGFILE );
            msg( "====== SERVER VARIABLES BEGIN ======" );
            msg( print_r( $_SERVER, true ) ); 
            msg( "====== SERVER VARIABLES END ======" );
        } 
 
        if( $_SERVER['REQUEST_METHOD'] === 'POST' ) {
            $obj = getRequestBody();
            msg( "====== JSON OBJ BEGIN ======" );
            msg( print_r( $obj, true ) );
            msg( "====== JSON OBJ END ======" );
 
            if( $obj->object_kind == 'push' ) {
                if( $obj->ref == 'refs/heads/'.BRANCH ) {
                    $allowed = false;
                    foreach( $USERS as $user ) {
                        msg( "permission test ( ".$obj->user_name ." == ". $user." ) ..." );
                        if( preg_match( "/$user/i", $obj->user_name ) ) {
                            msg( $user . " allowed to do updates on refs/heads/".BRANCH." branch" );
                            $allowed = true;
                            break;
                        }
                    } 
 
                    if( $allowed ) {
                        if( $obj->before != "0000000000000000000000000000000000000000" ) {
                            msg( "changing directory to ".PROJECTROOT );
                            chdir( PROJECTROOT );
 
                            msg( "executing: ". COMMAND );
                            $fh = popen( COMMAND." 2>&1", "r" );
                            $result = fread( $fh );
                            while( !feof( $fh ) ) {
                                msg( rtrim(fgets( $fh, 4096 )) );
                            } 
                            pclose( $fh );
                        } else {
                            msg( "it's a empty repository, we'll do nothing at this point" );
                        } 
                    } else {
                        msg( "permission denied for ". $obj->user_name );
                    }
                } else {
                    msg( "everybody can push to ". $obj->ref.", but we'll do nothing, please check your project settings" );
                }
            } else {
                msg( "[ ". $obj->object_kind ." ] event handler not yet implemented" );
            }
        } else {
            msg( strtoupper($_SERVER['REQUEST_METHOD'])." from [ ".$_SERVER['REMOTE_ADDR'] ." ] is not allowed, please check your server settings" );
            return_status( ERR );
        }
    } catch( Exception $e ) {
        msg( "======= EXCEPTION BEGIN ========" );
        msg( $e->getMessage() );
        msg( "======= EXCEPTION END ==========" );
        return_status( ERR );
    }
 
    return_status( OK ); 
 
    // ================================ FUNCTIONS ===========================================
    function return_status( $status = ERR ) { header( $status ); }
    function getRequestBody() { return json_decode( file_get_contents('php://input') ); }
    function msg( $message ) { if( $message != null ) file_put_contents( LOGFILE, $message."\n", FILE_APPEND ); } 
?>

..damit das nun funktionieren kann, müssen wir nun noch das Projekt Klonen und die SSH Settings anlegen, fangen wir daher direkt mit den SSH Settings an…

# (beginne mit Root Login)
su - -s /bin/bash www-data
mkdir -p .ssh && chmod 0600 .ssh
exit
cp gitlab.key /var/www/.ssh/ && chown www-data. /var/www/.ssh/gitlab.key && chmod 0400 /var/www/.ssh/gitlab.key
su - -s /bin/bash www-data
vi .ssh/config

…die .ssh/config sieht dabei wie folgt aus…

Host gitlab.example.org
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no
    IdentityFile ~/.ssh/gitlab.key
    User git
    LogLevel VERBOSE

…speichert nun das ganze und Klont eurer Projekt nach /var/www/project1/htdocs

# (beginne mit Root Login)
su - -s /bin/bash www-data
cd /var/www/project1
git clone git@gitlab.example.org:test/number1.git htdocs

…wenn ihr nun Lokal mit eurer Arbeitskopie arbeitet und an dem Punkt seit das ihr alles fertig zuhaben scheint und dann einen Push in euren staging Branch macht, wird GitLab jedesmal den Webhook on-push.php Aufrufen und auf dem Projekt/Web -Server einen Fetch/Pull ausführen lassen, um das Projekt auf den selben Stand wie eure Arbeitskopie zu bringen.

Zugegeben der PHP Handler oben ist keinesfalls perfekt, ich bin auch kein guter PHP Programmierer, genau genommen eigentlich gar keiner ;). Der Hook für das Kunden Projekt umfasst zudem noch mehr Fähigkeiten und würde mit seine zu diesem Zeitpunt ca. 800 Zeilen diesen Artikel in jedem Fall sprengen, aber ich denke das der gezeigte Webhook oben bereits eine gute Ausgangsbasis darstellt, sodass ich euch hoffentlich dazu Animieren konnte, das ganze doch einmal selber nachzubauen.

Zum zweck des Debugging, loggt dieser zur Kontrolle nach /var/www/html/api/on-push.log , hier lohnt also ein Blick.

Noch ein kleiner Hinweis meinerseits, der eine oder andere von euch wird schnell feststellen, das GitLab selber im Admin Panel auch einen Menü Eintrag mit der Bezeichnung [Deploy Keys] bereitstellt, womit sich das oben gezeigte auch umsetzten lässt, aufgrund einiger bedenken bzgl. Sicherheit dieses allerdings nicht immer gewünscht ist, da alle Keys die dort hinterlegt werden automatisch, für allen Projekte (auch für zukünftige) direkt verwendet werden können.

Nützliche Links:

Enrico Labedzki

Autor: Enrico Labedzki

Enrico ist beruflich ganz schön rumgekommen – IT hat ihn aber immer beschäftigt. Nach einem Ausflug in die Selbstständigkeit im Bereich Webentwicklung und Network Solutions, wurde es dann Zeit Nägel mit Köpfen zu machen und endlich den Weg als Softwareentwickler und Systemintegrator einzuschlagen. In seiner Freizeit widmet sich der passionierte Bastler der Elektrotechnik und Animatronik. Bei Netways bereichert er mit seinem vielseitigen Know-How das Managed Service-Team.