Select Page

NETWAYS Blog

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 verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

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:

Foreman wird 7 – Save the date

English version below
Foreman Logo
Ende nächsten Monat wird das Foreman-Projekt 7 Jahr alt und erwartet seinen Release 1.12, welcher solche interessante Features wie Support für Puppet 4 und IPv6 mitbringt. Dies nahm Greg Sutcliffe (Community Manager des Projekts) zum Anlass ein paar offizielle Parties zu organisieren und wie jeder weiß schmeißt Netways die besten Parties, weshalb ich nun die Ehre habe folgendes zu verkünden.
Am 21.07.2016 findet in unserem Eventraum, dem beliebten Kesselhaus, die deutsche Foreman-Geburtstagsparty statt und alle sind eingeladen vom interessierten Neuling bis zum alten Hasen.
Aktuell sieht das Programm folgendermaßen aus:
Wir werden um 12:30 mit einer Hands-on-Session beginnen. Für diese werde ich ein paar Demosysteme vorbereiten, die einige der Möglichkeiten von Foreman und Katello zeigen werden. Neben diesen Demosystemen stehe ich, weitere Kollegen und Mitglieder des Foreman-Projekts zur Verfügung um Fragen zu beantworten und jedem der sein eigenes Notebook mitbringt bei der Installation eines eigenen Demosetups zu helfen. Wer will geht also mit einer Foreman-Installation nach Hause mit der er jederzeit weitere virtuelle Maschinen bereitstellen kann.
So gegen 15 Uhr machen wir dann eine Kaffeepause um frisch gestärkt in eine Reihe von Vorträgen zu starten. Bisher ist es mir gelungen dafür Timo Goebel von Filiadata, dem IT-Dienstleister der Drogeriemarktkette dm, zu gewinnen. Dieser wird unter dem Motto “From 0 to 2000 – Life-Cycle-Management with Foreman at dm-drogeriemarkt” ihre Foreman-Installation vorstellen und zeigen wie tief diese in ihre Umgebung integriert ist. Michael Moll von der Mayflower GmbH wird als Mitglied des Foreman-Projekts auf die Neuerungen des 1.12 Release eingehen, insbesondere die “Puppet 4”-Unterstützung. Mein Kollege Achim Ledermüller aus unserem “Managed Service”-Team wird unsere Umgebung und die dafür so wichtige Foreman-OpenNebula-Integration vorstellen.
Für einen vierten oder gar fünften Vortrag bin ich noch an ein paar weiteren Personen dran, welche das hochkarätige Programm noch weiter aufwerten könnten. Ein paar weitere Mitglieder des Foreman-Teams kann ich schon als Teilnehmer versprechen und an weiteren bin ich dran, so dass hoffentlich keine Frage offen bleibt, wenn wir nach den Vorträgen zum gemütlichen Teil mit Essen und Getränken übergehen.
Zur kostenlosen Anmeldung geht hier.
Zur weiteren Planung halten wir euch über Twitter auf dem laufenden und sobald das Programm feststeht wird dieses auch auf der offiziellen Geburtstagsseite des Foreman-Projekts veröffentlicht.
P.S.: Und wer es nicht zur Party schafft oder danach nicht mehr genug von Foreman bekommen kann, hat gleiche in der folgenden Woche die Chance an unserer Schulung teilzunehmen.
read more…

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.

Wenn einer eine Reise tut

zur Zeit bin ich für Netways dabei, einen Kunden in Beijing vor Ort zu Betreuen. 3 Wochen dauert das Spektakel und ich bin in dieser Zeit in einem äußerst komfortablen Hotel in der Nähe des Diplomatenviertels der Chinesischen nördlichen(bei) Hauptstadt(jing) untergebracht.
Da so eine weite Tour auch für einen reiseerfahrenen Consultant wie mich nichts ganz gewöhliches ist, möchte ich euch mal ein paar Dinge berichten. Gestartet bin ich nämlich mit einigen Erwartungen und auch Vorurteilen die sich allerdings größtenteils nicht bestätigt haben.

way to work in beijing

Mein Arbeitsweg Beijing

Zuersteinmal:

der smog ist vorhanden, aber lange nicht so schlimm wie ich Ihn mir vorgestellt habe. Man sieht die Sonne und den blauen Himmel nahezu jeden Tag (außer es regnet). Viel dazu beigetragen hat wahrscheinlich, dass der allgegewärtige Motorroller zu 99,9% elektrisch voran kommt. Rücksicht auf Fußgänger wird deswegen zwar nicht genommen, d.h. es hält Keiner an Ampeln oder Zebrastreifen, aber auch nicht viel anders als z.B. in Paris oder Rom. Und da wo es an Verkehrssicherheit fehlt ist die persönliche Sicherheit um so höher. In Beijing braucht man keine Angst haben nachts im Dunkeln irgendwo entlang zu laufen. Es gibt sehr viel Polizei und ähnliches.
Ich fühle mich hier definitiv sicherer als z.B. in Berlin. Und dabei hat Beijing nach vorsichtigen Schätzungen 20, nach etwas offensiveren 30 Millionen Bewohner. Also mehr als 1/4 Deutschlands in einer Stadt.
Funfact: es gibt mehr als 180 Millionenstädte in China.

Die Ubahn funktioniert super.

DrollerSie ist komplett auch auf englisch beschildert und es gibt in jedem Wagon einen Plan auf dem man nicht nur die Stationen der Linie sieht, sondern auch wo man gerade ist. Die automatischen Ansagen sind auf Englisch und verständlich. Da könnten sich Nürnberg und Berlin eine Scheibe von abschneiden. Man hat eine elektronische Bezahlkarte, da lädt man ein paar RMB auf und kann dann frei fahren. Vor der ubahn an einen Scanner, nach der ubahn wieder und das Geld wird automatisch abgebucht. Eine Fahrt durch die halbe Stadt kostet umgerechnet ca. 50cent.
Da wären wir beim Preis. Beijing ist nicht so billig wie man durch chinesische Billigimporte vermuten könnte. Es ist hier und da zwar günstiger (bei Zigaretten und Ubahn z.B.) aber es gibt auch eine wachsende chinesische Oberschicht die nicht geizt und zeigt was sie hat. Ich habe zumindest noch nie so viele italienische und deutsche Luxuskarren auf einem Haufen gesehen.

last but not least . . .

der Mensch. Der Chinese als solcher ist ein Freundlicher. Egal ob auf der Arbeit (dauert wie bei uns geregelte 40 Stunden pro Woche) oder auf der Straße. Es hapert zwar auf der Straße häufiger mal am Englisch, was die leute allerdings nicht aus der Ruhe bringt. Ich habe an diversen Imbissen mit Händen und Füßen bestellt, war jedes mal überrascht was ich am Ende bekomme, aber nie negativ.
Es gibt noch so viel mehr was ich schreiben könnte aber der Platz auf der Seite geht langsam aus. Also möchte ich nur sagen: China ist eine Reise wert! Machen! Ganz dringend!

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.