Seite wählen

NETWAYS Blog

Wer GitLab sucht, wird bei NETWAYS fündig!

Als Softwareentwickler kommt man um eine Anwendung für eine Versionsverwaltung nicht herum.

Mit GitLab haben wir für Euch ein extrem beliebtes und umfangreiches VCS (Version Control System) im Programm. Hiermit könnt Ihr agil und effizient an Euren Software- und Webprojekten arbeiten.

GitLab ist OpenSource, basiert auf Git und wurde im Jahr 2011 in der Programmiersprache Ruby on Rails geschrieben.

GitLab ermöglicht Dir eine teamübergreifende und ortsunabhängige agile Software-Entwicklung. Du kannst Deinen Code geschützt speichern, kooperativ daran arbeiten und Git Repositories und CI/CD Pipelines erstellen. Der Clou ist, dass Ihr in einer einzigen Anwendung zusammenzuarbeiten könnt, anstatt mehrere Arbeitsschritte über verschiedene Tools hinweg verwalten zu müssen.

In der kostenlosen Community Edition (CE) stehen Dir viele Features für die Bereiche Source Code Management, Projekt Management und Sicherheit/Complience ( wie z.B. Wiki, Secret Detection, Time Tracking,…) zur Verfügung. Hierfür benötigst Du auch keine Lizenzen.

Lizenzen

Mit dem Wechsel auf die kostenpflichtige Enterprise Edition (EE) lässt sich das Feature-Set noch einmal gehörig ausbauen. Hier habt Ihr die Wahl zwischen dem Premium- und dem Ultimate-Set. Mit Hilfe der Übersicht findest Du raus, welche Funktionen wo dabei sind.

Als offizieller GitLab Partner kümmern wir uns gerne um die Beschaffung Deiner GitLab Enterprise Lizenzen. Melde Dich einfach hier und fordere ein Lizenz-Angebot bei uns an.

GitLab – lokal oder gehostet?

Egal ob CE oder EE, nun steht noch die Entscheidung an, wo Dein GitLab liegen soll: Du kannst Deine GitLab Instanz lokal auf Deinen eigenen Servern betreiben oder Du buchst Dir einen managed GitLab Service bei dem Hosting Provider Deines Vertrauens.

Für welche Variante Du Dich auch entscheidest, innerhalb unserer NETWAYS Gruppe findest Du für jegliche Vision die richtige Option.

GitLab mit NPS

Unsere Kollegen der NETWAYS Professional Services kümmern sich um die Installation und Konfiguration von GitLab auf Deinen lokalen Systemen und helfen Dir gerne u.a. beim Aufbau einer schlagkräftigen CI/CD Pipeline. Im Rahmen unserer IT Outsourcing Services übernehmen wir auch gerne die anschließende Wartung und kümmern uns um das Einspielen aller Updates.

GitLab mit NWS

Du willst auf das umfangreiche Toolset von GitLab nicht verzichten, hast aber keine freien Rechen-Kapazitäten mehr zur Verfügung und scheust den Hardware-Invest?  Dein GitLab soll lieber auf modernster Hardware in professionellen, zertifizierten Rechenzentren liegen und Du willst mit der Systempflege nichts zu tun haben? Dann bist Du bei unseren NETWAYS Web Services genau richtig.

Wähle einfach auf unserer SaaS Plattform den für Dich passenden GitLab Plan aus und klicke auf Start. Innerhalb von 3-4 Minuten ist die App einsatzbereit und Du kannst loslegen.  Wir kümmern uns im Hintergrund darum, dass das Deine App verfügbar und up to date bleibt. Und wenn Du mal Hilfe benötigst, steht Dir unser SaaS-Team per Mail, Chat oder telefonisch gerne mit Rat und Tat zur Seite.

Für alle Kunden, die besondere Wünsche und spezielle Anforderungen an ihre GitLab-Instanz haben, gibt es in unserem Hosting-Bereich noch eine zweite Möglichkeit:

Unser MyEngineer-Team baut Euch in unserer NETWAYS Cloud (basierend auf OpenStack) eine individuelle GitLab Instanz auf und Ihr bestimmt wie diese aussehen soll.

Hier bekommt Ihr individuelle Gestaltungsmöglichkeiten (GitLab Pages, Plant UML, Service Desk,…).

Ihr bestimmt wann neue Updates eingespielt werden sollen – unser MyEngineer-Team richtet sich ganz nach Eurem Zeitplan.

Die Ressourcen (CPU, RAM, Storage) können jederzeit individuell angepasst werden. Ihr könnt also klein anfangen und bei Bedarf das Setup ausweiten.

So bezahlt Ihr nur das, was Ihr wirklich braucht und bekommt genau das GitLab, das Ihr Euch wünscht.

Trainings mit NES

Du bist von den Möglichkeiten von GitLab überzeugt, Dein Team hat aber noch keinerlei Erfahrungen mit GitLab gemacht?

Kein Problem – auch dafür haben wir eine Lösung.

Über unsere NETWAYS Event Services könnt Ihr einfach unser zweitägiges GitLab- DevOps-Lifecycle – Training buchen.

Dieses gibt es wahlweise als Online-Training oder als Vor-Ort-Veranstaltung mit exquisiter Vollverpflegung in unserem Trainingszentrum.

Es ist auch möglich Inhouse Schulungen in Deiner Firma mit unserem Trainingsteam zu vereinbaren. Hierfür kannst Du Dich einfach bei direkt bei den Kollegen melden.

In der Schulung erhaltet Ihr einen tiefen Einblick in die Basics von Git, dessen Konfiguration sowie Shell- und GUI-Clients. Zudem bekommt Ihr GitLab-Grundwissen rund um Repositories, Issues, Releases und übt die Konfliktlösung in unterschiedlichen Git-Historien und Branches. Später bekommt Ihr praxisnahe Git-Workflows für kleine und große Teams und damit verbundenen Merge-/Rebase-Strategien. Ebenso stehen u.a. Continuous Integration/Continuous Delivery (CI/CD) auf dem Programm.

Am Ende des Trainings ist Dein Team dann fit für den Umstieg auf GitLab.

Ihr seht also: wer GitLab sucht, wird bei NETWAYS fündig.

Kommt einfach auf uns zu und wir finden gemeinsam heraus, welcher Weg für Euch der beste ist.

Stefan Schneider
Stefan Schneider
Account Manager

Vor seiner Zeit bei NETWAYS hat Stefan als Projektmanager in einer Nürnberger Agentur dabei geholfen, Werbeprojekte auf die Straße zu bringen. Seit Juni 2017 ist er nun stolzes Mitglied der NETWAYS-Crew. Hier war er zuerst der Ansprechpartner für unserer Schulungen und kümmert sich aktuell um alle Anfragen rund um unser Hostingangebot. Die Freizeit vertreibt sich Stefan am liebsten mit Sport. Vom Joggen über Slacklining bis zum PennyBoard fahren ist er für alles zu haben.

Divide and Conquer – Verteilte Git-Konfiguration

In meinem zehnten Monat als Consultant bei NETWAYS angekommen, bin ich inzwischen gut in verschiedenste Kundenprojekte integriert. Das sorgt einerseits für einen abwechslungsreichen Alltag mit immer neuen Herausforderungen, andererseits stellte sich irgendwann ein grundlegendes Problem heraus: Ich kann nicht jonglieren!

Dabei wäre das bei der Vielzahl an geschäftlichen Email-Adressen, SSH- und GPG-Schlüsseln und anderen Kleinigkeiten, die sich von Kunde zu Kunde, Plattform zu Plattform und Projekt zu Projekt unterscheiden, dringend notwendig. Ein unsignierter Commit mit falscher Email auf Github, Gitlab oder sonstiger Plattform ist da bei meinem Talent für Schusseligkeit nur eine Frage der Zeit. Glücklicherweise gibt es ein Git-Feature, das hier unterstützen kann: Die hierarchische Einbindung mehrerer .gitconfig Dateien.

Theorie und Möglichkeiten

Standardmäßig liest git die hinterlegte Konfiguration laut offizieller Dokumentation aus vier Verzeichnissen/Dateien aus:

  • $(prefix)/etc/gitconfig – der systemweiten Git-Konfiguration
  • $XDG_CONFIG_HOME – einer userspezifischen Git-Konfiguration, oftmals unter $HOME/.config/git
  • ~/.gitconfig – einer weiteren userspezifischen Git-Konfiguration, auch „globale Git-Konfiguration“ genannt
  • $GIT_DIR/config – einer Git-Konfiguration auf Repositoryebene

Die Dateien werden hierbei von jeder Routine, die auf git-Konfiguration zurückgreift, in obiger Reihenfolge ausgelesen, bei mehrfach definierten Werten greift hierbei der letzte, sodass ein „Feintuning“ von globaler Konfiguration hin zu projektspezifischen Einstellungen im Repository schon einmal möglich ist. Für noch bessere Verteilung und optionale Einbindung von erweiternder Konfiguration gibt Git Dir eine praktische Direktive an die Hand: includeIf.

Sie erlaubt es Dir, optional Konfiguration von beliebigen Stellen in die gerade betrachtete Datei einzubinden – die dort hinterlegten Einstellungen werden also zeitgleich evaluiert. Für eine bessere Kontrolle darüber, wann zusätzliche Einstellungen importiert werden sollen, können wir uns erneut die Dokumentation von git, genauer gesagt den Abschnitt zu Conditional Includes anschauen, denn hier gibt es verschiedene Optionen:

  • gitdir – die Einbindung erfolgt, wenn die Auswertung (via Befehl, Script, etc.) der Git-Konfiguration aus einem der Angabe entsprechenden (Unter-)Verzeichnis erfolgt. gitdir unterstützt Wildcards und Case(in)sensitivity.
  • onbranch – die Einbindung erfolgt aus einem momentan ausgecheckten Branch erfolgt, der der Angabe entspricht. Wildcards und Case(in)sensitivity werden auch hier unterstützt
  • hasconfig:remote.*.url – die Schreibweise ist etwas gewöhnungsbedürftig und auch die Anwendungsmöglichkeiten nicht so geradlinig wie bei den anderen Optionen: Hierbei werden optional Einstellungen eingebunden, wenn sich irgendwo in der lokalen Git-Konfiguration (nicht zwingend in der gleichen betrachteten Datei) eine remote URL findet, die der Angabe entspricht. Das ist bspw. nützlich, um mehrere Repositories mit bestimmter, immer gleicher Konfiguration zu versehen  (z.B. alle Repositories, die Icingaweb2-Module bereitstellen)

Praxis

Doch wie kann so etwas in der Praxis aussehen? Wie eingangs erwähnt, war mir vor Allem die Handhabe mehrerer kundenbezogener Email-Adressen und damit verknüpfter GPG-Schlüssel zu lästig, sodass ich hier für die Konfiguration zu einem hierarchischen Ansatz zurückgriff. Meine globale Git-Konfiguration unter ~/.gitconfig gestaltete ich also wie folgt:

Screenshot einer globalen Gitkonfiguration

Globale Gitkonfiguration unter ~/.gitconfig

Neben „Standardeinstellungen“ wie meinem im Commit zu setzenden Namen, der Defaultbranch bei der Erstellung neuer Repositories, die Anweisung, Commits immer mittels GPG zu signieren und das dafür zu nutzende Programm finden sich hier vier includeIf-Abschnitte.

Diese decken die verschiedenen Unterverzeichnisse meines Entwicklungsverzeichnisses ~/repositories/ ab – die trailing Slashes am Ende der jeweiligen Pfaddefinition sorgen dafür, dass die jeweiligen Unterverzeichnisse rekursiv gematcht werden. Im Beispiel hieße das, dass sowohl ein Repository unter ~/repositories/netways/blogpost_dbodky als auch ein Repository unter ~/repositories/netways/icinga-related/director-patches die zusätzlichen Git-Einstellungen unter ~/repositories/netways/.gitconfig einbinden würde.

In den in meiner globalen Git-Konfiguration referenzierten optional einzubindenden Dateien finden sich dann die Kunden- oder projektspezifischen Einstellungen für Git – das können mal mehr, mal weniger sein, um das Beispiel einfach zu halten hier die minimalistische Version für meine privaten Repositories, in der ich nur meine private Emailadresse sowie den damit verknüpften GPG-Schlüssel für die Signierung angebe:

Screenshot einer spezifischen Gitkonfiguration unter ~/repositories/private/.gitconfig

Spezifische Gitkonfiguration unter ~/repositories/private/.gitconfig

Was ihr jetzt in eure Gitkonfigurationen einbauen möchtet und wie ihr sie strukturiert, ist komplett euch überlassen – Git macht hierbei keine Vorschriften sondern arbeitet stur die vier eingangs erwähnten Dateien und alle optional einzubindenden Verzeichnisse und Dateien ab. Wichtig ist lediglich die Reihenfolge der Angaben, da sich diese gegebenenfalls überschreiben können.

Falls Du diesen Blogpost interessant fandest, aber bei Git noch Steigerungsbedarf siehst oder bei der Erwähnung von remote URLs ausgestiegen bist, kann ich Dir an dieser Stelle die NETWAYS Gitlab Schulung ans Herz legen, wo Du in Sachen Versionsverwaltung und DevOps voll durchstarten kannst.

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

HUGO: GitLab-CI/CD-Pipeline für eine statische Website

Vor etwa 4 Monaten habe ich hier einen Blogpost geschrieben, in dem ich Hugo vorgestellt habe – eine Software zum Generieren statischer Webseiten aus Markdown-Dateien.

Im Lauf meiner Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS habe ich vor kurzem an einer GitLab Fundamentals Schulung teilgenommen, um mehr über Git im allgemeinen und die Besonderheiten von GitLab im speziellen zu lernen. Auf Basis dieser Schulung und dem Projekt hinter oben genannten Blogpost habe ich nun eine CI/CD-Pipeline – CI/CD steht für Continous Integration and Continous Deployment – zum automatisierten Testen, Bauen und Ausrollen einer mit Hugo erzeugten Website gebaut.

Für dieses Projekt habe ich NETWAYS Web Services (NWS) eine GitLab CE App gestartet und außerdem in der Cloud von NWS zwei Webserver – einen als Testumgebung, einen als Produktivumgebung. Mithilfe meines Laptops als Client habe ich an der Website gearbeitet und die anfallenden Daten regelmäßig in ein eigenes GitLab Repository gepusht. Zum Testen, Bauen und Ausrollen auf die beiden Webserver laufen in der GitLab App zwei GitLab Runner. Das sind im Prinzip Agenten die für die GitLab App auf einem anderen System Befehle ausführen können.

Die CI/CD Pipeline

Die CI/CD Pipeline wird über die .gltiab-ci.yml gesteuert. Anfangs werden in der Pipeline die Quelldateien mithilfe zweier Markdown-Linter (vale.sh und markdownlint) getestet – in der .gitlab-ci.yml schaut das so aus:

lint:
   stage: lint
   tags: 
    - hugo
   allow_failure: true
   script:
    - cd tutorial
    - mdl ./content
    - vale ./content

Diese überprüfen die Inhalte der Website auf die Einhaltung eines Styleguides und auch auf die Sprachliche Korrektheit. Anschließend wird die Webseite mit Hugo gerendert, das heißt aus den Markdown-Dateien für den Websiteinhalt entsteht nun die wirkliche Website:

testBuild:
   stage: build
   tags:
    - test
   script:
    - cd tutorial
    - mkdir test
    - hugo -DEF --debug -d test
   artifacts:
   paths:
    - tutorial/test

Falls diese Operation auf der Testumgebung erfolgreich ist, wird sie auch auf der Produktivumgebung durchgeführt. Als Abschluss wird die gerenderte Webseite noch für den genutzten Webserver (z.B. Apache HTTPD oder nginx) bereitgestellt):

testDeploy:
   stage: deploy
   needs: [testBuild]
   tags:
    - hugotest
   script:
    - cp -r tutorial/test/* /var/www/html/
   only: 
    - main

Grafisch sieht diese Pipeline so aus:

Wenn auch Du solche interessanten Projekte in Deiner Ausbildung zum Fachinformatiker machen möchtest, kannst du Dich gerne für eine Ausbildung ab Herbst 2022 bewerben!

Björn Berg
Björn Berg
Junior Consultant

Björn hat nach seinem Abitur 2019 Datenschutz und IT-Sicherheit in Ansbach studiert. Nach einigen Semestern entschied er sich auf eine Ausbildung zum Fachinformatiker für Systemintegration umzusteigen und fing im September 2021 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er viel vor seinem PC und hat Spaß mit diversen Spielen, experimentiert auch mit verschiedenen Linux-Distributionen herum und geht im Sommer gerne mal campen.

GitLab – Merge Requests

Merges werden verwendet, um den Code zwischen anderen Personen, die Sie an einem Projekt vorgenommen haben, auszutauschen und die Änderungen einfach miteinander zu konsolidieren.

Schritt 1: Vor dem Erstellen einer neuen Merge sollte im GitLab ein Branch erstellt werden.
Schritt 2: Melden Sie sich bei Ihrem GitLab-Konto an und gehen Sie zu Ihrem Projekt im Abschnitt Projekte.

Schritt 3: Klicken Sie auf die Registerkarte Merge und dann auf die Schaltfläche Neue Merge.

Schritt 4: Um den Request zu mergen, wählen Sie den Quell-Branch und den Ziel-Branch aus der Dropdown-Liste aus und klicken Sie dann auf die Schaltfläche Zweige vergleichen und fortfahren, wie unten gezeigt.

Merge kann verwendet werden, um den Code zwischen anderen Personen, die Sie an einem Projekt vorgenommen haben, auszutauschen und die Änderungen einfach mit ihnen zu besprechen.

Schritt 5: – Sie sehen den Titel, die Beschreibung und andere Felder wie Zuweisen des Benutzers, Festlegen des Meilensteins, Beschriftungen, Name des Quell-Branches und Name des Ziel-Branches und klicken auf die Schaltfläche „Merge senden“

Schritt 6: – Nach dem Absenden der Merge wird ein neuer Bildschirm für Merge angezeigt (siehe unten).

Noch kein Gitlab? Jetzt bei uns im NWS anmelden und Gitlab sorgenfrei 30 Tage lang testen.

From Monitoring to Observability: Distributed Tracing with Jaeger

Modern cloud environments and microservice architectures need a changed mindset when it comes to monitoring. Classic host/service object relations are not always applicable, containers run in Kubernetes are short lived, and application performance within distributed networks is hard to monitor. Especially with applications running millions of operations, where to start the root cause analysis for slow client responses in your web shop? Is it just slow connections to MySQL, or does the application’s debug log slow down the entire fleet?

This is where observability with tracing comes into play. In the cloud native space, OpenTracing evolved as vendor neutral standardized API including client instrumentation. Famous tools are Zipkin and Jaeger which was contributed from Uber to the CNCF.

Let’s have a look into Jaeger today.

 

Getting Started

The easiest way to try Jaeger is with using the Docker container explained in the documentation.

docker run -d --name jaeger \
  -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14268:14268 \
  -p 9411:9411 \
  jaegertracing/all-in-one:1.16

Navigate to http://localhost:16686 to get greeted by Jaeger.

 

Try it

A sample application is available as container. I’m using a modified port mapping with 8081-8084 here since port 8080 is already assigned.

docker run --rm -it \
  --link jaeger \
  -p8081-8084:8080-8083 \
  -e JAEGER_AGENT_HOST="jaeger" \
  jaegertracing/example-hotrod:1.16 \
  all

Navigate to http://localhost:8081 and click the buttons to order some cars.

Within Jaeger itself, start analyzing the traces and for example learn that Redis runs into timeouts quite often delaying the HTTP responses to the clients.

 

Traces for applications

Jaeger provides officially supported client libraries for Go, Java, Python, NodeJS, C/C++, C#/.NET, others are in the making. Let’s see if we can add it into Icinga 2 and do some tracing here.

First off, clone the repository, build and install the client libraries. You’ll need CMake, a C++ compiler, etc. – basically everything which is required for Icinga 2 too and documented here. In this example, I’m compiling on my Macbook. There are additional libraries and headers required. Hint: Boost 1.72 has a bug which needs a patch.

brew install yaml-cpp thrift 
git clone https://github.com/opentracing/opentracing-cpp && cd opentracing-cpp
# 1.6.0 doesn't work atm
git checkout v1.5.1
mkdir -p build && cd build
cmake ..
make && make install
cd ..

Then clone, cmake, make, install.

git clone https://github.com/jaegertracing/jaeger-client-cpp && cd jaeger-client-cpp
git checkout v0.5.0
# regenerate thrift headers for 0.11.0
find idl/thrift/ -type f -name \*.thrift -exec thrift -gen cpp -out src/jaegertracing/thrift-gen {} \;
mkdir -p build && cd build
cmake ..
make && make install
cd ..

In order to add Jaeger into Icinga 2, there are the following steps necessary:

  • Add CMake functions to lookup yaml-cpp, opentracing, jaeger headers and libraries
  • Optionally enable Jaeger tracing code, link the icinga2 binary against it
  • Add a new tracer into the Config Compiler CLI command to measure the timing points

The majority of development time today was to resolve compile and linking issues, adding spans and traces is really simple. You can follow my progress in this Icinga PR – developers, get started wtih the client libraries and help your colleagues with enhanced observability!

 

Conclusion

Tracing application performance, cluster messages, end2end tests and any sort of event span provides valuable insights for both, devs and ops. With the new cloud native landscape evolving fast, we have additional possibilities to analyze our environments. Next to the now standardized tools for parsing and ingesting logs with Elastic Stack or Graylog, tracing has found its place in the observability stack.

Jaeger Tracing also is part of the GitLab observability suite which will be moved to the free core edition in 2020. Metrics, logging, alerts and tracing are key elements in modern cloud environments. Prometheus monitors everything from classic load checks to Kubernetes containers, Jaeger provides application performance insights and on top of that, Grafana combines the view on problems and trends. You can learn more about GitLab’s vision here.

Exploring these cool new features in GitLab are our mission in future trainings and workshops, watch this space in 2020!