Icinga2 GitLab Health Check

GitLab

Neulich hatten wir bei einigen GitLab Updates auf die neueste Version das Problem, dass die Dienste nach dem Update zwar korrekt alle wieder gestartet wurden und daher unser alter Monitoring Check “Service: gitlab” den Status “Gitlab OK: All services are running!” zurückgeliefert hat, auch der Check “Service: http git.netways.de” “HTTP OK: HTTP/1.1 200 OK” geliefert hat, und daher hat ohne manuelle Prüfung niemand vermutet, dass im Hintergrund doch etwas schief gelaufen war (z.B. die Datenbank Migration während einem Update, oder ein vergessenes skip-XXX File im /etc/gitlab Verzeichnis).

Auch wenn man das Update direkt auf der command line ausgeführt hat, konnte man in der abschliessenden Meldung nicht sehen, ob noch alles o.k. ist.

Festgestellt hat man das dann erst, wenn man sich in der GitLab Admin Area unter “Health Check” den Status angesehen hat.

Unten ein Beispiel wie es aussieht, wenn alles i.O. ist (Zur Info: Die Beispiel URL und Token gibt es nicht):

GitLab Status

D.h. ein neuer Check musste her, und den gibt es auch direkt bei GitLab zum Downloaden unter:

https://gitlab.com/6uellerBpanda/check_gitlab/blob/master/check_gitlab.rb

Der alte Check lief dabei direkt auf den einzelnen GitLab Hosts. Das war mit dem neuen Check allerdings ein Problem, weil er als Voraussetzung Ruby >2.3 hat, und wir z.B. noch einige Hosts unter Ubuntu Trusty betreiben.

Deshalb wird der neue Check direkt auf dem Monitoring Server (auch Ubuntu Trusty) ausgeführt, der zu diesem Zweck zusätzlich per rvm mit einem z.Zt. neuen Ruby 2.5.1 ausgestattet wurde, wobei im Ruby Skript das Shebang leider hardcoded eingetragen werden musste, weil es (zumindest unter Trusty) nicht anders funktioniert hatte (ohne grösseren Aufwand und vielen Änderungen an anderen Systemdateien):

#!/usr/local/rvm/rubies/ruby-2.5.1/bin/ruby

Nachdem die Token zum Zugriff im Bild oben seit einigen GitLab Versionen deprecated sind zugunsten einer IP Whitelist, hat das den Deploy des Checks zusätzlich erleichtert.

Der Aufruf des Checks sieht dann z.B. so aus:

root@icinga2-server:~# check_gitlab.rb -m health -s https://gitlab.netways.de -k
OK - Gitlab probes are in healthy state

Damit das dann auch funktioniert, muss auf der entfernten GitLab Instanz noch die IP Whitelist unter /etc/gitlab/gitlab.rb eingetragen werden:

gitlab_rails['monitoring_whitelist'] = ['127.0.0.1/8','10.XX.XX.XX/24']

Am besten checkt man natürlich nur über ein internes Netz, wie oben im Beispiel angegeben.

Das ganze kann man auch über ein GitLab Puppet Modul realisieren, indem man die Whitelist über Hiera oder Foreman verteilt:

Beispiel Hierarchie im Foreman:

gitlab:
    gitlab_rails:
      monitoring_whitelist:
      - 127.0.0.1/8
      - 10.XX.XX.XX/24  
Stefan Gundel

Autor: Stefan Gundel

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Mission Loadbalancer Upgrade

Mission Loadbalancer Upgrade
Heute Nacht hatte das Managed Services Team die spannende Aufgabe unseren Loadbalancer Cluster auf neue Systeme umzuziehen.

Der alte Cluster lief zwar seit Jahren problemlos, allerdings erhoffen wir uns von dem neuen Setup eine gesteigerte Netzwerk Performance und durch neuere Cluster Management Pakete insgesamt auch eine bessere Wartbarkeit, wie z.B. bei unserem halbjährlichen Failovertest.

Sehr wichtig ist dabei natürlich, dass auch in der Nacht die Downtime der Services so gering wie möglich ausfällt.

Da bei uns die komplette Loadbalancer Cluster Konfiguration über Puppet provisioniert wird, war es daher auch kein Problem die Neuinstallation der Cluster Knoten sehr zügig durchzuführen.

Die tatsächliche Downtime der Services betrug daher nach der Neuprovisionierung wie erwartet auch nur wenige Sekunden und die ersten Performance Tests waren sehr vielversprechend.

Ein Beispiel für einen Service Eintrag im Puppetlabs Hiera sieht in etwa so aus (wir verwenden dafür den ldirectord aus dem Linux Virtual Server Projekt):

ldirector::member:
  "web-host1.netways.de_%{::hostname}":
    ip: "%{ipaddress_bond0_XX}"
    weight: 1
    service_name: 'web-host1.netways.de'
    ssl: true
    password: 'XXXXXXXXXX'
    ensure: 'present'

Dieser Eintrag in einer Hostname FQDN YAML Datei genügt somit, um den entsprechenden Host in den Loadbalancer Pool eines Services mit den entsprechenden Parametern (Gewichtung u.s.w.) aufzunehmen.

Im zugrundeliegenden ldirectord Puppetmodul werden zudem ausgiebig ‘Exported resources’ in Verbindung mit der PuppetDB verwendet, um am Ende die komplette Loadbalancer Konfiguration Live zu nehmen.

Wenn Sie sich für mehr Informationen zu einem redundanten, jederzeit skalierbaren Loadbalancer Setup und mehr interessieren, schauen Sie sich doch einfach ein mal unser Hosting & Services Angebot an.

Stefan Gundel

Autor: Stefan Gundel

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Rückblick Debian Wheezy Distribution Upgrade

wheezy

Seit Anfang Mai 2013 gibt es ja nun die neue stabile Debian Distribution Wheezy.
Natürlich freut man sich auch immer darauf, dass eine neue Version kommt, weil das System im Lauf der Jahre generell immer besser geworden ist.

Aber spätestens ein paar Wochen danach wird auch jedem klar, es hilft nichts, man “muss” auch upgraden um ein Jahr nach dem Release weiterhin Security Updates zu erhalten, weil ab dann die Oldstable – in dem Fall Debian Squeeze – nicht mehr unterstützt wird.

Das Upgrade sollte man auch nicht zu lange aufschieben, weil man sich sonst Anfang nächsten Jahres nur unnötig selbst unter Druck setzt.

Ab einer gewissen Anzahl Server ist natürlich der Aufwand alle komplett neu zu installieren, und das im laufenden Serverbetrieb, trotz aller Installations Automatisierung zuviel, zumal es auch immer wieder genug Spezialfälle gibt.

Wenn man sich sicher ist, dass man die alten Konfigurationsfiles der Pakete behalten möchte, und um die Downtime der einzelnen Server möglichst kurz zu halten und nicht ständig unnötige Fragen beantworten zu müssen, kann man dann auch ein “unattended-upgrade” machen.

Falls man mehrere Server vom gleichen Typ hat empfiehlt es sich allerdings zunächst mindestens ein “normales” interaktives Upgrade zu machen.

Deshalb an dieser Stelle ein Beispiel, wie man so ein unattended-upgrade durchführen kann:

1. Zuerst alle vorhandenen Updates für Debian Squeeze einspielen, damit das System vor dem Distributionsupgrade auf einem aktuellen Stand ist.

2. Die Debian Wheezy Quellen in die /etc/apt/sources.list eintragen. Falls man noch weitere Listen im Verzeichnis /etc/apt/sources.list.d hat, müssen diese noch zusätzlich angepasst werden. Man kann die Änderung auch automatisieren mit:


sed -i 's/squeeze/wheezy/g' /etc/apt/sources.list

und/oder


sed -i 's/squeeze/wheezy/g' /etc/apt/sources.list.d/*.list 

3. Das eigentliche Distributions Upgrade kann man dann starten mit:


export DEBIAN_FRONTEND=noninteractive

yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" upgrade

yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

Das ganze in upgrade und danach erst dist-upgrade aufzuteilen hat den Vorteil, dass man beim “upgrade” noch sieht, ob es gravierende Probleme mit Paketabhängigkeiten gibt, und diese noch fixen kann vor dem abschliessenden endgültigen Distributions Upgrade.

Bisher haben alle Upgrades bei uns gut geklappt. Falls aber die Applikation z.B. wegen dem PHP Versionsupgrade von Squeeze 5.3.3 auf Wheezy 5.4.4 nicht mehr funktioniert, kann man sich immer noch durch ein Downgrade der PHP Version retten, um anschliessend die Fehler vor einem weiteren Upgrade in Ruhe beheben zu können.

Eine entsprechende Anleitung findet man z.B. hier.

Stefan Gundel

Autor: Stefan Gundel

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

SCP und Rsync Boost Parameter

speedy

Wer kennt es nicht: Es muss schnell etwas per scp oder rsync aus dem Backup oder einem LVM Snapshot auf einen anderen Server im internen Netz kopiert werden, weil gerade zur ungünstigsten Zeit z.B. eine Datenbank nicht korrigierbar ausgefallen ist.

Da die dabei anfallenden Datenvolumen heuzutage wohl eher beständig mehr als weniger werden, ist jedes bisschen Übertragungs-Speed, das man aus der Leitung kitzeln kann, sehr wichtig.

Was gerne übersehen wird: SSH bietet da zumindest einen Parameter an, mit dem man die Geschwindigkeit ordentlich nach oben schrauben kann durch die Wahl eines anderen Cypher Algorithmus, auch über rsync.

Das ganze bringt satte rund 30% mehr an Daten über die Leitung und spart dadurch natürlich auch entsprechend viel Zeit beim Kopieren.

Als Beispiel ein rsync Befehl, den ich in so einem Fall immer verwende:


rsync -aPHxz --delete -e 'ssh -c arcfour' root@:/foo/bar/* /foo/bar/

Wem das immer noch nicht reicht, der kann zusätzlich auch noch einen anderen ‘message authentication code’ angeben über den Parameter: ‘-m hmac-md5-96″

Stefan Gundel

Autor: Stefan Gundel

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Batch Mode Cluster ssh mit der Distributed Shell dsh

muscheln

Auch in Zeiten von Puppet und Mcollective braucht man manchmal einfach auf die Schnelle die Möglichkeit, sich per ssh aus einem Server-Cluster bestimmte Informationen holen zu können, oder einfache Befehle ausführen zu können.

Hier bietet sich die oftmals in Vergessenheit geratene Distributed Shell dsh an, die sich für alle gängigen Distributionen einfach per Paketmanagement installieren lässt.

Ein getaggter Puppet Lauf über bestimmte Servertypen, z.B. um nur bestimmte Klassen auszuführen, ist nur eine Anwendung bei der sich die Distributed Shell geradezu aufdrängt.

Das ist eigentlich kein Problem, wenn man die Möglichkeit hat sich die entsprechenden Serverlisten entweder anhand der Namen aus dem DNS, der Icinga Konfiguration, oder auch nur anhand eines bestimmten abgetrennten Subnetzes für die Servertypen, zu generieren.

Nun hatte ich neulich den Fall, dass keiner der o.g. Punkte möglich war, und zusätzlich erschwerend nur ein einziges grosses Netz vorhanden war, in dem sich so ziemlich alle Geräte, inklusive Switches etc. befunden haben.

Man möchte ja, dass der ssh Lauf ohne manuellen Eingriff durchläuft und man nicht jedesmal abbrechen/bestätigen muss, wenn gerade ein Gerät in der Schleife erreicht wird, das eigentlich nicht abgefragt werden soll.

Unter der Voraussetzung, dass alle “normalen” Server per PublicKey Authentifizierung erreichbar sind (was ja z.B. beim Icinga Monitoring Benutzer i.d.R. der Fall ist) hat sich dabei folgende Befehlszeile bewährt (als einfaches Beispiel z.B. um sich den Distributions Namen ausgeben zu lassen):


dsh -M -o-oBatchMode=yes -o-oStrictHostKeyChecking=no -o-oConnectTimeout=3 \
-f ./serverliste.txt 'lsb_release -c' | \
tee /tmp/debian_version.txt

Gerade die Option BatchMode=yes ist hier alles andere als intuitiv, sorgt aber dafür, dass alle Server in der Liste, die für den Benutzer nicht per Key Authentifizierung erreichbar sind, sofort übersprungen werden.

Wenn man möchte, kann man zusätzlich noch die Option -F angeben, um den Befehl parallel auf der angegebenen Anzahl an Servern ausführen zu lassen.

Stefan Gundel

Autor: Stefan Gundel

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.