Select Page

NETWAYS Blog

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
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

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
Christian Stein
Lead Senior Account Manager

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
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.

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
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und...

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…

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:

Veranstaltungen

Tue 19

Icinga 2 Advanced Training (englisch class) | Online

January 19 @ 09:00 - January 21 @ 17:00
Feb 02

Elastic Stack Training | Online

February 2 @ 09:00 - February 4 @ 17:00
Feb 10

GitLab Fundamentals Training | Online

February 10 @ 09:00 - February 11 @ 17:00
Feb 23

Terraform mit OpenStack Training | Online

February 23 @ 09:00 - February 24 @ 17:00
Feb 23

Fundamentals for Puppet | Online

February 23 @ 09:00 - February 25 @ 17:00