Gitlab | self-hosted vs. Gitlab as a Service

Egal ob GitLab-CE oder GitLab-EE, es stellt sich die Frage, ob self-hosted oder vielleicht sogar als GitLab as a Service (im Folgenden GaaS genannt). Unterschiede gibt es bei diesen beiden Varianten genug. Doch wo sind die gravierendsten Unterschiede in diesen beiden Varianten, was ist das richtige für wen? Diese Fragen möchte in dem folgenden Blogpost beantworten.
 
 

Zeitaufwand

Fangen wir mit dem zeitlichen Aufwand an. Eine GitLab Instanz zu installieren, kann schon einmal etwas Zeit in Anspruch nehmen. Installation, Konfiguration, Wartung, etc, aber auch das Bereitstellen eines Systems (Hardware Server oder VM und eventuell sogar Storage), kann hier mehrere Stunden dauern. Im direkten Vergleich hierzu steht GaaS gehostet in unserem NWS Portal. Nach bestellen einer Gitlab-CE oder GitLab-EE App, dauert es ca 10 Minuten bis alle Funktionen installiert und konfiguriert sind und GitLab einsatzbereit ist.

Umfang

Bei der self-hosted Variante hat man natürlich alle Freiheiten, die ein Administrator der Anwendung haben sollte. Die Instanz kann mit allen gewünschten Features erweitert und somit sehr stark individualisiert werden. Man hat die Auswahl ob man gerne AutoDevOps mit Kubernetes oder GitLab Runner für das Ausführen von Build Jobs haben möchte.
In der GaaS Lösung ist es so, dass hier direkt ein GitLab Runner mit ausgeliefert wird, sodass ohne Verzögerung erste Jobs laufen können. Eine Umstellung auf AutoDevOps ist jedoch auch möglich. Ebenso bringt diese Variante alle standardmäßigen Features mit, die GitLab so haben sollte. Individuelle Features können leider nicht ohne weiteres hinzugefügt werden, da diese durch das NWS Team geprüft, getestet und für alle Kunden zur Verfügung gestellt werden müssen.

Backups

Wer GitLab nutzt möchte natürlich auch Backups seiner Daten und Arbeiten erstellen. GitLab selbst bietet hier die Möglichkeit Backups aller Daten zu erstellen und diese entsprechend auf dem Server zu speichern. Regelmäßiges Warten dieser Backups ist nötig, da diese Backups je nach Größe der Instanz entsprechend Speicherplatz verbrauchen.
NWS bietet hier etwas mehr Komfort, denn um Backups muss sich hier nicht gekümmert werden. Das System erstellt automatisch jede Nacht Snapshots der Apps und auf Wunsch können auch Tagsüber Snapshots erstellt werden, zum Beispiel wenn Änderungen vorgenommen werden sollen und ein zusätzliches Backup gewünscht ist.

Updates

Regelmäßig werden durch GitLab Updates veröffentlicht. Im normalen Zyklus geschieht dies jeden Monat am 22.ten, jedoch werden zwischendrin auch Security Updates oder Bug Fixes veröffentlicht. Als Administrator vertraut man Updates nicht immer und möchte diese vorher Testen, bevor sie in der Produktionsumgebung eingespielt werden. Hier ist ein Testsystem von Nutzen.
In der GaaS Lösung ist dies automatisch der Fall. Nach Veröffentlichung eines Updates wird in verschiedenen Phasen getestet:

  1. Lokales starten der neuen GitLab Instanz
  2. Starten in der Testing Umgebung
  3. Upgrade einer “veralteten” Instanz in der Testing Umgebung
  4. Starten in der Produktionsumgebung
  5. Upgrade einer “veralteten” Instanz in der Produktions Umgebung

Erst wenn diese 5 Phasen durchlaufen sind, werden Wartungsmails verschickt und die neue Version wird für alle Nutzer live genommen.

TLS

TLS ist aus der heutigen Zeit nicht mehr weg zu denken. Zertifikate sind jedoch unter Umständen etwas teurer. GitLab bietet hier jedoch die Möglichkeit, mittels Letsencrypt TLS Zertifikate für die jeweilige Instanz zu generieren. Sowohl in der Self-Hosted Variante als auch bei GaaS ist dies recht einfach. Der Unterschied besteht lediglich darin, dass in der NWS Plattform lediglich ein Haken gesetzt werden muss, um eben diese Verschlüsselung zu aktivieren.

Self-Hosted

sed -i "/letsencrypt\['enable'\] = true/d" /etc/gitlab/gitlab.rb
sed -i "s#^external_url 'https://.*#external_url 'https://$YOUR_DOMAIN'#g" /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure

GaaS

Monitoring

Monitoring ist ebenso ein essenzieller Bestandteil von Produktionsumgebungen. Bei der selbstständig gehosteten Lösung muss sich hier eigenständig darum gekümmert werden. Welches Tool hierzu verwendet wird, bleibt jedem selbst überlassen, wir empfehlen aber Icinga 2.
Mit der GaaS Lösung kommt ein Monitoring automatisch mit. Zwar ist dies für die Kunden nicht einsehbar, jedoch werden alle Funktionen der Instanz durch unser Support Team überwacht.

Fazit

Welche Variante für einen selbst nun die richtige muss jeder für sich entscheiden. Wenn man GitLab selbst hosted, hat man absolute Kontrolle über die Instanz. Backups, Updates, Ressourcen, es kann selbständig über die Dimensionen entschieden werden und man ist etwas flexibler als in der GaaS Lösung. Jedoch ist in eben dieser der Vorteil, dass Backups, Updates, sowie Konfiguration und Support von den Mitarbeitern von NWS übernommen werden. GitLab kann in NWS 30 Tage kostenlos getestet werden, probiert es also einfach mal aus – testen

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

NWS | Neuerungen und Updates

Die letzten Wochen hat sich auf unserer NWS Plattform sehr viel getan. Wir möchten uns an dieser Stelle auch bei unseren Nutzern bedanken, die Verbesserungsvorschläge der Apps an uns reported haben. Aufgrund dieser Aussagen ist es uns möglich, uns und NWS selbst stetig zu verbessern und so schließlich auch das Erlebnis der User zu verbessern! Im Folgenden möchte ich etwas darauf eingehen, welche Neuerungen die letzten Wochen vorgenommen wurden.
Migration der NWS Plattform auf OpenStack
Ein sehr großer Teil, wenn nicht sogar der größte Teil, war die Migration unserer Server auf das neue OpenStack Setup an unserem neuem RZ-Standort. Neue Server, neue Technologie und ein neues Rechenzentrum. All das ermöglicht uns eine Performance-Steigerung der Produkte sowie unserer Anwendung selbst. Es wurde hier eine komplett neue Umgebung aufgebaut, auf der nun auch NWS läuft. Die alte Umgebung wurde komplett abgeschaltet.

Gitlab-CE / Gitlab-EE

Natürlich haben wir auch Updates eingespielt. Gitlab-CE sowie Gitlab-EE wurde auf die Version 11.0.4 angehoben. Diese Version bringt AutoDevOps mit sich und diverse andere Neuerungen.

Icinga2 Satellite

Unsere Satelliten wurden auf die aktuelle Icinga2 Version angehoben, welche aktuell die 2.9.0-1 ist.

Icinga2 Master

Die Master App wurde ebenso auf die 2.9.0-1 angehoben. Wir haben hier auch das eingesetzte Grafana aktualisiert auf die Version 5, welches ein komplett neues Interface mit sich bringt. Ein Update für das neue icinga2-Web steht noch aus!

SuiteCRM

Die Version von SuiteCRM selbst, welche bisher bei NWS im Einsatz war, hatte leider einige wenige Bugs. Diese konnten wir mit der neuen Version 7.10.7 beheben und so die Produktivität der App verbessern. Wir haben hier auch kleinere Änderungen am Aufbau und Konfiguration der Container vorgenommen, welche die Start-Zeit enorm verkürzt haben. Hierzu beigetragen haben auch die Ressourcen, wovon wir den Containern mehr zuteilen.

Rocket.Chat

Rocket.Chat wurde mit der Version 0.66.3 auf die aktuellste verfügbare Version erhöht. Wir haben hier auch den Begrüßungstext, der in der Instanz angezeigt wird durch ein kleines “HowTo” ersetzt, um einen leichteren Einstieg in diese App zu ermöglichen.

WordPress

Auch WordPress wurde mit einem Update versehen. Wir haben hier die Version 4.9.7 aktiviert. Diese Version ist ebenso wie 4.9.6 DSGVO konform.

Nextcloud Verbesserungen

Wir haben einige Reports bekommen, dass die Performance unserer Nextcloud App noch verbesserungsfähig ist. Wir haben aufgrund dieser, gewisse Verhalten nachstellen können und konnten so die dafür verantwortlichen Fehler finden und beheben. Unsere Arbeiten resultierten in einer wesentlichen Performance-Steigerung der App, vor allem im Bereich der Dokumente, der Foto Galerie, sowie des Logins.

Diverse Fehlerbehebungen / Verbesserungen

Wie oben bereits erwähnt, haben wir unter anderem durch die Reports unserer Nutzer Fehlerstellen gefunden und konnte diese beheben. Daraus resultierend hat sich die Start-Zeit der Apps verkürzt, was wir auch bei den Restarts und bei den Updates beobachten konnten. Dies erleichtert uns natürlich die Wartungsarbeiten aber auch die Downtimes für unsere Nutzer, sofern ein Restart einmal nötig sein sollte. Wir haben ebenso falsche/hängende Flows gefunden, welche bisher dafür gesorgt haben, dass Container innerhalb eines Setups gelegentlich die Connection zueinander verlieren konnten. Dieser Fehler wurde behoben und tritt derzeit nicht mehr auf. Wir sind stets dabei weitere Verbesserungen vorzunehmen und Neuerungen zu testen. Um hier Up-to-date zu bleiben, kann ich unseren Twitter Account empfehlen. Hier werden alle Updates regelmäßig veröffentlicht!

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

Microsoft and GitHub – merge conflict?

For some time it has become clear that Microsoft is going to take over GitHub. As far as official sources can be trusted, GitHub will stay independent although a new CEO (Nat Friedman) will be introduced after the Microsoft takeover.

This question over GitHub’s future independence has raised a lot of skepticism within the developer community and many are considering moving their projects away from GitHub to a different location.
One alternative in this case could be GitLab. GitLab does not only have an online platform but it can as well be installed on your own hardware. Furthermore, it is an extremely solid piece of Open Source software you can fully rely on. This is also shown by the makers of GitLab themselves as they release updates each month – rolling out bug fixes, security updates and many recommendations regarding the use and configuration of your instance.
For those who would like to have their own GitLab instance, NETWAYS offers two options:
First one is available on our NETWAYS Web Services platform where we offer user-managed, hosted GitLab instances as Community or Enterprise Edition. The user does not need to take care of anything regarding installation or maintenance of his GitLab, but can directly go into production in no time with only a few steps needed. You as a customer are also free to decide for how long you would like to run your instances as any app is monthly callable. Furthermore, we regularly update these container based apps and monitor their health  for you. As a customer, you can register on NWS and try all the apps we offer 30 days for free.
The second product we offer is done by NETWAYS Managed Services which is exactly what it is called: With managed hosting you can get a virtual machine in our cloud or rented hardware running a full GitLab, either as Community or Enterprise Edition. You can choose the underlying ressources and we will do the rest for you, like installation with individual parameters and health monitoring. With managed hosting, our customers also have the choice to go full 24/7 support with “emergency” calls.

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Wie überwache ich eine Cluster-Applikation in Icinga 2?

Vor dieser Frage stand ich neulich bei einem Kunden. Und dank dem Rat netter Kollegen kam sogar eine ansehnliche Lösung hervor. Wer kennt das nicht – Applikationen, die in einem Linux-HA Cluster laufen worauf über eine Cluster-Virtual-IP zugegriffen wird. An diese VIP-Ressource sind der Applikationsprozess und womöglich eingehängter Speicher als weitere Cluster-Ressource angeknüpft. Somit sprechen wir von zwei Cluster-Ressourcen, die mit einer Cluster-Ressource der VIP verknüpft sind. Diese Abhängigkeit definiert, dass die Anwendung immer nur auf einem aktiven Cluster-Node im zugewiesener VIP laufen kann. Dies ergibt einen Active und einen Passive Node (in unserem Fallbeispiel!)
 

Was bedeutet das genau?

Die Cluster-VIP kann von Active zum Passive Host anhand von Fehler-Kriterien geschwenkt werden. Somit schwenkt der gesamte Betrieb der Applikation vom aktiven Host auf den passiven Host. Dort wird der Applikationsprozess gestartet und die Disk eingehängt. Würden wir jetzt einfach auf beiden Servern neben den System-Standards noch die Applikation gezielt überwachen, würden wir auf einem der beiden Nodes für den fehlenden Prozess und die fehlende Disk immer den Status “Critical”  bzw. den Status “Unknown” beim Ausführen des Disk-Checks zurückbekommen.
 

Lösung!

Um eine Überwachung über die Cluster-VIP zu realisieren, verwenden wir ein eigenes Plugin welches als Wrapper fungiert. Der Check verwendet die Cluster-VIP als Parameter und überprüft ob diese an einem lokalen Interface konfiguriert ist. Wird an einem Interface die Cluster-VIP-Ressource zugewiesen, führt das Plugin den eigentlichen Check aus. Dieser wird als zweiter Parameter übergeben und entspricht dem Namen des Checks, z.B. “check_disk”. Durch den Aufruf des Kommandos mit dem Argument “$@” werden alle Parameter des Wrapper-Scripts an das Plugin übergeben.
 

Plugin-Skript

#!/bin/bash
#
# License: GPLv2, Copyright: info@netways.de NETWAYS GmbH
#
#
plugin_dir=${0%/*}
VIP="$1"
vip_exists=`ip a|grep " inet ${VIP}/"`
echo $vip_exists
shift
command="$1"
shift
if [ ! "$vip_exists" ]; then
  echo "YES! VIP down & I'm STANDBY" && exit $OK
fi
exec ${plugin_dir}/${command} "$@"

Sollte auf einem Cluster-Node die Cluster-VIP nicht zugewiesen sein, gibt der Check den Status “OK” und den Plugin-Output “YES! VIP down & I’m STANDBY” zurück.
 

Einrichten des Check-Commands

Nun können wir dieses Plugin im PluginDir-Pfad auf dem zu überwachenden Host ablegen. Zusätzlich benötigen wir noch ein CheckCommand, welches das Wrapper-Script aufruft und dann die Parameter von “disk” erwartet. Dies kann man so lösen, dass mittels “import” das bestehende “disk” CheckCommand importiert wird und lediglich das auszuführende “command” mit dem Wrapper-Script überschrieben wird. Die Einbindung des CheckCommands sollte am Icinga-2-Master erfolgen, statisch in “commands.conf” oder im Director.
Im  folgenden sind die Beispiele für eine Disk, Prozess und Logfile-Check aufgeführt. Dieses Set könnte einer typischen Cluster-Applikation entsprechen. Wir definieren einen Service-Prozess und einen Filesystem-Mount/Disk die als Cluster-Ressource an die Cluster-VIP gebunden sind. Diese Applikation schreibt auch Log-Dateien, die möglicherweise zu überwachen sind.

object CheckCommand "vip-disk" {
  import "plugin-check-command"
  import "disk"
  command = [ PluginDir + "/check_vip_app", "$app_vip$", "check_disk" ]
}
object CheckCommand "vip-procs" {
  import "plugin-check-command"
  import "procs"
  command = [
   PluginDir + "/check_vip_app",
   "$app_vip$",
   "check_procs"
  ]
}
object CheckCommand "vip-logfiles" {
  import "plugin-check-command"
  import "check_logfiles"
  command = [
    PluginDir + "/check_vip_app",
    "$app_vip$",
    "check_logfiles"
  ]
  timeout = 1m
}

Die zugehörigen Service-Definitionen könnten so definiert werden:

apply Service "vip-disk" {
  check_command = "vip-disk"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
apply Service "vip-procs" {
  check_command = "vip-procs"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
apply Service "vip-logfiles" {
  check_command = "vip-logfiles"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
Und hier ein Auszug zur Darstellung im icingaweb2:

Service-List Icingaweb2


Service – Plugin Output Icingaweb2



Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner...

Noob vs. Icinga 2

Nachdem unser Michael Friedrich letzte Woche einen Blog-Post zum 9. Icinga Geburtstag auf icinga.com veröffentlicht hat, fängt man schon mal an, über die eigenen ersten Schritte mit dem Icinga 2 Stack nachzudenken. Vor allem, wenn man auf einem Live-System mal wieder über etwas aus der Anfangszeit stolpert.
 

Eines meiner ersten Aha!-Erlebnisse war recht klein, jedoch wurde mir dann versichert, dass da auch gestandene User bzw. Admins darüberstolpern. Kern der Frage war damals: “Warum geht dieser *biep* http-check nicht?!” Als Symptom zeigte sich, dass unserem Check der Zugriff verweigert wurde – und das, obwohl doch alle Permissions korrekt gesetzt waren. Da grübelt und googlet der Junior System Engineer erstmal eine Zeit lang. Um das Verfahren hier abzukürzen – es gibt folgende Möglichkeiten, das Problem anzugehen:
Der Grund liegt darin, dass der Check durch den Parameter –expect einen String mit dem Returnwert 200 als Default erwartet. Von daher kann man

  • als Quick’n’Dirty Lösung ganz einfach eine leere Datei mit dem Namen index.html im entsprechenden Verzeichnis angelegt werden
  • den String nach –expect auf einen sicher zu erwartenden Wert setzen, z. B. 302.
  • mit –url einen Pfad angeben, der geprüft werden soll, z. B. /start/menu

Auch schön war der Punkt, an dem man verstanden hat, was es mit dem Parameter command_endpoint auf sich hat – und man plötzlich merkt, dass unterschiedliche Festplatten z. B. auch unterschiedliche Füllstände aufweisen. Genauso faszinierend ist es natürlich auch, dass man durch Apply Rules viele Services weitläufig ausrollen oder umgekehrt auch einschränken kann.
Um nun abschließend einen unserer NETWAYS Consultants zu zitieren: “Das Kommando icinga2 daemon -C sollte man jedem neuen User irgendwohin tätowieren!”
Als Fazit aus den letzten zwei Jahren mit Icinga 2 kann ich ziehen, dass einem der Einstieg recht gut und schnell gelingt – egal, ob es sich um das Aufsetzen, die Wartung oder die täglich Nutzung handelt. Wer sich vor allem von letzterem gerne selbst überzeugen möchte, kann bei den NETWAYS Web Services in unserem kostenfreien Testmonat sowohl einen Icinga 2 Master als auch Satellite starten. Wer sich gerne tiefer in die Materie einarbeiten möchte, kann sich auf icinga.com schlau machen. Dort ist nicht nur die offizielle Dokumentation zu finden, sondern auch Termine zu Trainings und Events. Sehr zu empfehlen ist auch die überarbeitete Auflage des Buches Icinga 2: Ein praktischer Einstieg ins Monitoring von Lennart Betz und Thomas Widhalm.
Bildquelle: https://memegenerator.net/instance/40760148/jackie-chan-dafuq-is-wrong-with-ur-icinga-checks

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Anpassungen der Nextcloud Login Seite werden nicht geladen

Wie uns bei den NWS Apps aufgefallen ist, gibt es aktuell in der Nextcloud Version 13.0.1 den Bug, dass Anpassungen an der Login Seite nicht aktualisiert werden. Das Problem ist hier wohl der “Image Cache“, der nicht aktualisiert wird.
Es werden verschiedene Möglichkeiten geschildert, dieses Problem zu umgehen, beziehungsweise zu beheben. Zwei dieser Wege werden im folgenden beschrieben:
 

1) Installation von “Unsplash”
  • Gewünschte Anpassungen vornehmen
  • Installation der “Unsplash” App
  • Deaktivierung dieser App im Anschluss
2) Image Cache manuell aktualisieren

Eine weitere Möglichkeit ist den Image Cache manuell zu updaten. Dies funktioniert jedoch nicht in allen Fällen.

sudo -u www-data php occ maintenance:theme:update

Dieses Problem gab es in früheren Version schon einmal. Der Bug sollte in künftigen Versionen behoben sein.
Hier ein paar links zu diesem Thema:

 
 

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