OpenStack made easy – Snapshots erstellen, rotieren, einspielen

OpenStack made easy – Snapshots erstellen, rotieren, einspielen

This entry is part 4 of 4 in the series OpenStack made easy

Früher oder später gelangt wohl jede/r, die / der einen Server am Laufen hat einmal an den Punkt, dass es ihr / ihm die VM (oder Teile davon) irreversibel “zerreißt” – wodurch auch immer.
Wer sich im Vorfeld der Sicherung seiner Daten gewidmet hat, ist jetzt klar im Vorteil und hat signifikant niedrigere Adrenalinpegel zu erwarten – besonders, wenn die letzte Sicherung keine 24 Stunden her ist. Unsere OpenStack-Plattform bietet für die Sicherung Ihrer virtuellen Maschine(n) Funktionalität zum automatischen oder auch manuellen Erstellen von Schattenkopien (im Folgenden Snapshots genannt) an.

 > Automatischen Snapshot einrichten

Man wähle den Reiter Snapshots und setze ein Häkchen bei der automatisch zu sichernden VM und die Einstellung wird übernommen.

Et voilà! Ab sofort kümmert sich die OpenStack-App jede Nacht nach 00:00 Uhr darum, dass ein Snapshot dieser virtuellen Maschine erstellt wird. Wie im Bild erwähnt macht sie sieben Stück, beim achten Mal Snapshot-Erstellen löscht sie den ältesten, also den ersten, usw.
Ergo ist “7” ist der Rotations-Standardwert. Wer diesen gerne verändern möchte, d. h. weniger als eine Woche täglicher Snapshots vorhalten will, beispielsweise nur deren drei, kann das wie folgt tun: Zurück zum Reiter “LiveView” > Compute > Instanzen > Drop-down-Menü (ganz rechts neben der Instanz, die modifiziert werden soll) > “Aktualisiere Metadaten”.
Hier sieht man nun, dass unter “Existing Metadata” “nws_backup” existiert und auf “true” gesetzt ist.

Man schreibe unter “Available Metadata” neben das Feld “Custom” “rotation” hinein, füge es mit dem Pluszeichen der “Existing Metadata” hinzu, trage dort den Wert “3” ein und klicke auf “Speichern”.
Fertig.

¡¡¡ Im Fall von Datenbanken auf der zu sichernden VM !!!
Da Snapshots im laufenden Betrieb genommen werden, ist die Konsistenz der Datenbanken darin nicht garantiert. Ich empfehle die Einrichtung eines Cronjobs, der einen Dump der laufenden DBs oder anderer nicht-persistenter Daten anlegt. Gut wäre, wenn dieser vor 24:00 Uhr fertig ist und somit nahtlos mitgebackupt werden kann.

 > Manuellen Snapshot erstellen

Wer hingegen nur einen bestimmten Zustand – beispielsweise nach Durchführung aller Installationshandgriffe seiner Software-Landschaft – gesichert haben möchte, kann das manuell tun: Compute > Instanzen > Schattenkopie erstellen (neben der zu sichernden VM). Es ist dann noch ein aussagekräftiger Schattenkopiename zuzuteilen und Schattenkopie erstellen zu klicken.

Eine grüne Erfolgsmeldung wird hierauf oben rechts aufpoppen.
Hier sollte – wie oben beschrieben – ebenfalls auf Datenbanken geachtet werden.

 > Snapshot einspielen

Sollte es dann eben zur Havarie oder einem sonstigen Fall notwendiger Zurücksetzung kommen, läuft das Einspielen der Sicherung so ab, als würde man eine neue VM starten.
Compute > Instanzen > Instanz starten.

Details > Instanzname setzen

Quelle > Bootquelle auswählen:
Hier gibt es zwei Möglichkeiten, wo sich Ihr Snapshot befindet:

  • entweder > “Datenträger Snapshot” (i. F. v. VMs “mit Datenträger” bzw. “mit Volume”: Systemdatenträger in unserem Ceph-Storage, insgesamt dreifache Replikation an zwei Standorten)
  • oder > “Abbild” oder “Instanz Snapshot” (i. F. v. VMs “ohne Datenträger” bzw. “ohne Volume”: Systemdatenträger lediglich auf dem Hypervisor)

Variante, Netzwerke, Sicherheitsgruppen und Schlüsselpaar sind wie gehabt zu setzen.

Als Ergebnis wird man jetzt zwei ähnliche VMs haben:

Um den neuen Sollzustand zu verkomplettieren, bleibt, der zu verwerfenden Instanz die Floating-IP abzutrennen (Drop-down-Menü ganz rechts neben der Instanz) und diese der neuen zuzuweisen. Wenn sicher ist, dass die alte nicht mehr benötigt wird, kann diese dann auch gelöscht werden, um nicht weiterhin nutzlos Kosten zu verursachen.

Dieses Vorgehen eignet sich nicht nur zur Desaster-Recovery. Auch das Aufsetzen einer baugleichen VM oder das Testen größerer Patches abseits der produktiven Areale kann so bewerkstelligt werden.

> Snapshot als Datenträger einbinden

Für den Fall, dass man nur an die enthaltenen Daten heranwill, existiert auch die Möglichkeit, aus dem Snapshot einen Datenträger zu erstellen und diesen einer anderen laufenden VM anzuhängen.
Dies ist möglich über zwei Schritte:
Compute > Abbilder > Drop-down-Menü (ganz rechts neben dem zu benutzenden Abbild) > Datenträger erstellen > Datenträger erstellen.
Weiter über Datenträger > Datenträger > Drop-down-Menü (ganz rechts neben dem zu benutzenden Datenträger) > Anhänge verwalten.

Es ist noch die Instanz, mit der das Laufwerk verbunden werden soll auszuwählen und zu bestätigen.
Jetzt steht die Platte zur Verfügung, auf Ubuntu beispielsweise als /dev/sdb1 .

Martin Scholz
Martin Scholz
Systems Engineer

Martin sattelte unlängst vom sozialen Bereich auf die IT um und ist im Managed-Services-Support tätig. Praktischerweise nutzt ihm hier, dass er sich bereits vor geraumer Zeit Linux als User zugewandt hat. Privat ist er bekennende Couch-Potatoe. Es sei denn, er fühlt sich einmal wieder gedrängt, einen Marathon-Marsch zu unternehmen. Kein feliner oder kanider Passant ist vor seiner Kontaktaufnahme sicher.

OpenStack made easy… Mit Icinga 2-Master Maschinen überwachen

This entry is part 2 of 4 in the series OpenStack made easy

Mit unserer OpenStack Cloud ist es kinderleicht seine eigene Umgebung nach eigenen Vorstellungen aufzubauen. Schnell und einfach mittels Terraform einige Maschinen starten, per angehängter Floating IP und zugehöriger Security Group den Dienst für die Außenwelt verfügbar machen und schon läuft das Projekt.

Aber keine Umgebung läuft fehlerfrei und Monitoring ist ein großes Thema – man merkt gerne vor seinen eigenen Benutzern, oder Kunden, wenn einmal etwas nicht ganz so funktioniert wie es soll. Ich denke jedem Leser dieses Blogs ist zum einen die Wichtigkeit eines Monitorings bewusst aber auch die Auswertung von Performancedaten wichtig. Wie überwache ich nun unkompliziert meine OpenStack Umgebung, vor allem wenn meine Server von der Außenwelt gar nicht erreichbar sind? Wir haben da mal etwas vorbereitet!

Neben unserem IaaS Angebot stellen wir – wie sicherlich bekannt – auch diverse SaaS Lösungen bereit. Darunter auch die App Icinga 2 Master, mit welcher man binnen weniger Minuten einen vollständigen Icinga 2 Master, mitsamt Graphite und Grafana erhält.

Ist dieser erstmal gestartet, findet man nach dem Login unter dem Reiter “Agenten hinzufügen” – oder je nach Browsersprache auch “Add Agent” – diverse Integrationsskripte für unterschiedliche Betriebssysteme.

Diese lädt man einfach nach Anleitung auf den Server, führt es aus und schon ist der Server an den Icinga2 Master angebunden.

server01:~# chmod +x createHost.sh; ./createHost.sh

Alles wichtige wird hier automatisiert. Per default werden einige Checks direkt mit angelegt und mithilfe des Directors ist es auch einfach weitere Checks für seine Hosts zu verteilen. Auch die API des Directors kann direkt angesprochen werden, es sind einem fast keine Grenzen gesetzt. Zusätzlich findet man noch einige Graphen zu den Performancedaten des angebundenen Agents direkt beim jeweiligen Check. Damit können nicht nur Probleme erkannt werden, sondern auch Trends werden direkt visualisiert. Diese Daten werden wohlgemerkt bei unseren Paketen ein Jahr vorgehalten um auch eine Langzeitübersicht zu gewährleisten.

Der erste Monat des Icinga 2 Masters ist außerdem kostenlos – ein Test lohnt sich. Unser MyEngineer hilft auch gerne bei der Einrichtung!

Fabian Rothlauf
Fabian Rothlauf
Senior Systems Engineer

Fabian kehrte nach seinem fünfjährigen Ausflug nach Weimar zurück in seine Geburtsstadt Nürnberg und hat im September 2016 bei NETWAYS als Systems Engineer im Hosting Support angefangen. Der Mopsliebhaber, der schon seit seinem 16. Lebensjahr ein Faible für Adminaufgaben hat, liebt außerdem Grillen, Metal und Computerspiele. An seinem Beruf reizt ihn vor allem die Abwechslung, gute Weiterentwicklungsmöglichketen und dass es selten mal einen Stillstand gibt. Nachdem er die Berufsschulzeit bereits mit Eric und Georg genießen...

NETWAYS Web Services auf der TECHWEEK

Der deutsche Cloud-Markt wächst stetig und die digitale Industrie in Deutschland boomt. Die Veranstaltungsreihe Techweek ist das Event zur digitalen Transformation. Natürlich dürfen wir mit den NETWAYS Web Services bei der Techweek in Frankfurt nicht fehlen! Wir freuen uns darauf, mit den wichtigsten Entscheidungsträgern der deutschen Unternehmenslandschaft ins Gespräch zu kommen und sie von unserer NETWAYS Cloud zu überzeugen!

Ihr seid auch auf der Techweek in Frankfurt? Kommt vorbei, holt euch die neueste NETWAYS Cloud Broschüre und sprecht mit uns! Ihr findet uns an Stand 975.

techweekfrankfurt.de / nws.netways.de/cloud

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.
OpenStack made easy – Sicherheitsgruppen verwalten und zuweisen

OpenStack made easy – Sicherheitsgruppen verwalten und zuweisen

This entry is part 3 of 4 in the series OpenStack made easy

Nachdem man sich in unserer OpenStack-Weboberfläche die erste neue Instanz zurecht geklickt und dabei einen SSH-Public-Key, mit dem man sich auf diese VM verbinden möchte, zugewiesen hat, steht der/die frisch gebackene AdministratorIn vor dem kleinen Problem, dass er/sie von außen nicht auf die Instanz kommt; das “verdanken” wir der “default”-Sicherheitsgruppe.

Sie beinhaltet die Regeln:


– Erlaube  eingehende Verbindungen mit jedem Protokoll, auf jedem Port, aber nur von Hosts im internen Netzwerk, die auch die “default”-Sicherheitsgruppe nutzen (IPv4 und IPv6)
– Erlaube ausgehende Verbindungen mit jedem Protokoll, auf jedem Port und nach überallhin (IPv4 und IPv6)

Auf diese Weise wird der Schutz der neuen VM sichergestellt. Jeder Verbindende von außen kommt nur wirklich durch die Zugangsöffnung, die dafür vorgesehen und geschaffen wurde. Um eine solche zu kreieren gibt es zwei Wege: Es kann eine neue Sicherheitsgruppe angelegt und mit einer Regel versehen oder die default-Sicherheitsgruppe um eine Regel ergänzt werden. Zweites bietet den Nachteil, dass die einzugebende Regel künftig für alle neuen Instanzen mit der default-Sicherheitsgruppe angewandt wird, was nicht immer auf allen VMs sinnvoll sein wird.

 > Neue Sicherheitsgruppe erstellen

Man klicke: Netzwerk > Sicherheitsgruppen > “+ Sicherheitsgruppe erstellen”.

Ein Dialogfeld erscheint, in dem, zwar nach Gusto, jedoch obligatorisch ein Name eingegeben werden muss (und optional eine Beschreibung eingegeben werden kann). Hier nenne ich die neue Gruppe “Beispiel”, aber jeder andere Name, der z. B. eigene Gruppierungsstrategien verfolgt, wird es tun. Dann noch Sicherheitsgruppe erstellen.

Dann erscheint in der Liste:

 > SSH-Erreichbarkeit von extern als Regel einer Sicherheitsgruppe hinzufügen

Man mause: Netzwerk > Sicherheitsgruppen > Regeln verwalten (bei der Sicherheitsgruppe, die editiert werden soll).

In einer neuen, noch unbearbeiteten Sicherheitsgruppe wird man nur jeweils eine Regel zum Austritt (IPv4 und IPv6) finden. Weiter geht es mit: “+ Regel hinzufügen”. Hier wähle man im Drop-down-Menü Regel den Unterpunkt SSH und “Hinzufügen”.

– Wenn eine bereits der VM zugewiesene Sicherheitsgruppe (z. B. default) mit dieser Regel versehen wurde, findet die Regel sofort Anwendung und die VM kann über die CLI kontaktiert werden.

– Falls eine Regel in einer neuen Sicherheitsgruppe erstellt wurde, die noch nicht der VM zugewiesen wurde:

 > Der VM eine neue Sicherheitsgruppe zuweisen

Navigiere: Compute > Instanzen > Drop-down-Pfeil (ganz rechts neben der Instanz, die modifiziert werden soll) > Sicherheitsgruppen bearbeiten. Unter “Alle Sicherheitsgruppen” findet sich die neue, mit dem weiß-auf-blauen Plus füge man die neue Sicherheitsgruppe den “Instanz-Sicherheitsgruppen” hinzu und “Speichern”.

 > ICMP-Erreichbarkeit von extern als Regel erstellen

Netzwerk > Sicherheitsgruppen > Regeln verwalten (bei der Sicherheitsgruppe, die editiert werden soll) > “+ Regel hinzufügen” > Regel = “Alle ICMP” > Hinzufügen.

 > Genauso funktioniert auch z. B. eine Regel für HTTP / HTTPS oder die folgenden

 > Regelbeispiel mit mehr Schikanen
 > Erreichbarkeit von extern mit TCP im Portbereich 65530-65535 nur von IP 200.135.41.125 aus

Netzwerk > Sicherheitsgruppen > Regeln verwalten (bei der Sicherheitsgruppe, die editiert werden soll) > “+ Regel hinzufügen” > Regel = “Angepasste TCP-Regel > Port öffnen = Port-Bereich >
“Von-Port” = 65530 > “Bis-Port” = 65535 > CIDR = 200.135.41.125/32 > “Hinzufügen”

Für alle, denen das Aufsetzen und Konfigurieren neuer VMs zu umfangreich oder schwierig erscheint, übernimmt gerne MyEngineer das Erstellen jedes gewünschten Setups.

Das erste Projekt in unserer NWS-Cloud kann hier gestartet werden.

Wie man sich die erste Maschine aufsetzt, ist in diesem Artikel beschrieben.

Martin Scholz
Martin Scholz
Systems Engineer

Martin sattelte unlängst vom sozialen Bereich auf die IT um und ist im Managed-Services-Support tätig. Praktischerweise nutzt ihm hier, dass er sich bereits vor geraumer Zeit Linux als User zugewandt hat. Privat ist er bekennende Couch-Potatoe. Es sei denn, er fühlt sich einmal wieder gedrängt, einen Marathon-Marsch zu unternehmen. Kein feliner oder kanider Passant ist vor seiner Kontaktaufnahme sicher.

OpenStack made easy – OpenStack Projekt starten und die erste Maschine anlegen

This entry is part 1 of 4 in the series OpenStack made easy

Mit unserer neuen OpenStack-Umgebung feiern wir Erfolge – Performance, Stabilität, Flexibilität und günstige Preise überzeugen unsere Kunden. Die Vielzahl von Funktionen überfordert aber den ein oder anderen Anwender bei der ersten Nutzung. Wir helfen aber auch hier sehr gern Licht ins Dunkel zu bringen und zeigen auf, wie einfach es eigentlich ist.

Zu Beginn benötigen wir einen NWS-Account. Dieser lässt sich kostenfrei unter https://nws.netways.de anlegen. Hier gibt man lediglich eine Mailadresse und das gewünschte Passwort an, sowie ob es sich um ein Business oder Stanard-Konto handelt. Kurze Zeit später kommt ein Validierungslink per Mail. Nach der Bestätigung des Kontos kann man sich bereits einloggen. Für den Quick-Start ist eine Demo-Kreditkarte hinterlegt, es empfiehlt sich hier aber direkt über den Menüpunkt “Konto”->”Zahlungsmethode bearbeiten” die gewünschte Zahlungsweise (Kreditkarte/Rechnung/PayPal) zu hinterlegen.

Nun geben wir im Menüpunkt “Konto”->”Konto bearbeiten” unsere gewünschten Rechnungsdaten, Mailadresse für den Rechnungsversand etc. an und validieren unser Konto via Anruf oder SMS.

Jetzt ist es an der Zeit unser OpenStack zu starten. Hierzu reicht ein kurzer Klick auf “Ihre Apps” in der oberen rechten Ecke.

Final bringt uns der Klick auf “Start your first app now” zum Ziel – hier folgt man nur noch dem OpenStack-Button und bestätigt die ungeliebten Klauseln zu AGB und Datenschutz – aber was sein muss, muss sein.

Nun taucht in unserer App-Übersicht unser OpenStack auf. Nur einen Klick entfernt warten hinter der unscheinbaren Kachel schon alle wichtigen Informationen zum Start.

Auch erscheint bereits das OpenStack Anmeldefenster. Die Anmeldedaten hier unterscheiden sich von denen, die im NWS ausgewählt wurden, sind aber im Tab “Zugang” einfach zu entnehmen.

Also fügen wir die erspähten Daten nun im Tab “LiveView” ein. Alternativ steht die OpenStack-Anwendung natürlich auch Fullscreen unter https://cloud.netways.de zur Verfügung.

Das wärs dann auch schon – unser OpenStack ist betriebsbereit und wartet auf den Einsatz der ersten Maschine.

Die erste Maschine starten

Keine Sorge – auch das geht fast genauso einfach.

Navigieren wir zu “Compute”->”Instances” und starten im oberen rechten Eck eine neue Instanz

Im ersten Schritt vergeben wir einen Namen für unsere Instanz

Nun arbeiten wir die weiteren Register auf der linken Seite durch und besuchen den Punkt “Source”

Hier wählen wir als Boot-Source “Image” aus und suchen uns unten aus der Liste das gewünschte Betriebssystem (ganz rechts der Pfeil zum auswählen). Die anderen Buttons lassen wir unangetastet – eine Erklärung hierzu folgt in späteren Posts. Einzig beim Start von Windows-Maschinen klicken wir bei “Create New Volume” auf “No” – warum? Dazu in einem späteren Artikel mehr!

Der Menüpunkt Flavor bietet verschiedene Presets für die gewünschten Größen der Maschinen. Hier wählt man aus, was man benötigt. Fehlt ein gewünschtes Flavor? Einfach eine kurze Mail schreiben und wir kümmern uns drum!

Im nächsten Register dreht sich alles um Netzwerk, dort wird unser OpenStack-Netzwerk ausgewählt, was gleichlautend mit unserem OpenStack-Projekt ist.

Für den Moment ignorieren wir vorerst ein paar Menüpunkte und widmen unsere Aufmerksamkeit dem Menüpunkt Key-Pair.

Über den Button “Import Key Pair” importieren wir unseren SSH-Pubkey in seiner ungekürzten Schönheit und vergeben einen beliebigen Namen. Auch dieser wird wieder “nach oben” reingeklickt.

Final kann die Instanz gestartet werden – schon wenige Sekunden später steht diese bereit.

Für die erste Nutzung müssen jedoch noch 2 Dinge erledigt werden.

Floating-IP zuweisen

Hierzu klicken wir in der Maschinenübersicht rechts bei der gewünschten Maschine auf den kleinen Pfeil nach unten auf “Associate Floating IP”, beziehen mittels “+” eine Neue IP aus dem Pool und weisen Sie der Maschine zu.

Nun sehen wir, dass die Maschine eine IP im internen Netz hat, sowie die gerade zugewiesene Floating-IP – diese brauchen wir später, um uns auf die Maschine zu verbinden.

Security-Groups bearbeiten

Unser OpenStack bring bereits eine Firewall mit. Deshalb funktioniert der Zugang via SSH oder RDP noch nicht. Dies ist jedoch mit wenigen Klicks ebenfalls erledigt.

In der Hauptnavigation von OpenStack besuchen wir Network->Security Groups. Hier “Managen” wir die “Rules” unserer default Security-Gruppe via “Manage Rules” und fügen mittels “Add Rule” eine neue Regel für SSH hinzu und geben vorerst alle Netze für den Zugriff frei.

Da alle angelegten Maschinen die “default” Regel bereits enthalten, funktioniert ab jetzt der Zugriff auf die Maschine via SSH. In späteren Artikeln gehen wir näher auf die Handhabung mit Security-Gruppen und Zuweisung dieser zu Maschinen ein, aber das würde in diesem Artikel jetzt den Rahmen sprengen.

Mit Maschine verbinden

Wenn alle Schritte wie beschrieben durchgeführt wurden, kann man sich jetzt via SSH mit der Maschine via Floating-IP verbinden. Für Ubuntu-Systeme verbindet man sich als User ubuntu, bei Debian als debian usw. Bei Windows-Maschinen kann man das Passwort beim ersten Starten eingeben, hierzu muss man sich etwas durch die Details in der Instance-Übersicht der Maschine klicken.

Kosten

Zeit ist Geld – auch bei uns! Deshalb werden alle Maschinen bzw. die einzeln genutzten Ressourcen stundengenau abgerechnet (Preise hier) und zwar zu fairen und transparenten Preisen. Damit man alles im Auge behält, haben wir die aktuell aufgelaufenen Kosten und den Forecast für den laufenden Monat (bei gleichbleibender Nutzung) in unserem Kosten Rechner festgehalten.

Need more?

Kein Problem. Mit etwas Geduld kommen hier mehr und mehr Artikel. Wer nicht warten kann oder sich nicht kümmern will, kann bei uns eine Remote-Schulung buchen, unser Webinar ansehen oder unsere kompetenten MyEngineers buchen.

 

In diesem Artikel gehen wir genauer auf die Sicherheitsgruppen ein.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

GitLab CI Runners with Auto-scaling on OpenStack

 

With migrating our CI/CD pipelines from Jenkins to GitLab CI in the past months, we’ve also looked into possible performance enhancements for binary package builds. GitLab and its CI functionality is really really great in this regard, and many things hide under the hood. Did you know that “Auto DevOps” is just an example template for your CI/CD pipeline running in the cloud or your own Kubernetes cluster? But there’s more, the GitLab CI runners can run jobs in different environments with using different hypervisors and the power of docker-machine.

One of them is OpenStack available at NWS and ready to use. The following examples are from the Icinga production environment and help us on a daily basis to build, test and release Icinga products.

 

Preparations

Install the GitLab Runner on the GitLab instance or in a dedicated VM. Follow along in the docs where this is explained in detail. Install the docker-machine binary and inspect its option for creating a new machine.

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
apt-get install -y gitlab-runner
  
curl -L https://github.com/docker/machine/releases/download/v0.16.2/docker-machine-`uname -s`-`uname -m` -o /usr/local/bin/docker-machine
chmod +x /usr/local/bin/docker-machine
  
docker-machine create --driver openstack --help

Next, register the GitLab CI initially. Note: This is just to ensure that the runner is up and running in the GitLab admin interface. You’ll need to modify the configuration in a bit.

gitlab-runner register \
  --non-interactive \
  --url https://git.icinga.com/ \
  --tag-list docker \
  --registration-token SUPERSECRETKEKSI \
  --name "docker-machine on OpenStack" \
  --executor docker+machine \
  --docker-image alpine

 

Docker Machine with OpenStack Deployment

Edit “/etc/gitlab-runner/config.toml” and add/modify the “[[runners]]” section entry for OpenStack and Docker Machine. Ensure that the MachineDriver, MachineName and MachineOptions match the requirements. Within “MachineOptions”, add the credentials, flavors, network settings just as with other deployment providers. All available options are explained in the documentation.

vim /etc/gitlab-runner/config.toml

  [runners.machine]
    IdleCount = 4
    IdleTime = 3600
    MaxBuilds = 100
    MachineDriver = "openstack"
    MachineName = "customer-%s"
    MachineOptions = [
      "openstack-auth-url=https://cloud.netways.de:5000/v3/",
      "openstack-tenant-name=1234-openstack-customer",
      "openstack-username=customer-login",
      "openstack-password=sup3rS3cr3t4ndsup3rl0ng",
      "openstack-flavor-name=s1.large",
      "openstack-image-name=Debian 10.1",
      "openstack-domain-name=default",
      "openstack-net-name=customer-network",
      "openstack-sec-groups="mine",
      "openstack-ssh-user=debian",
      "openstack-user-data-file=/etc/gitlab-runner/user-data",
      "openstack-private-key-file=/etc/gitlab-runner/id_rsa",
      "openstack-keypair-name=GitLab Runner"
    ]

The runners cache can be put onto S3 granted that you have this service available. NWS luckily provides S3 compatible object storage.

  [runners.cache]
    Type = "s3"
    Shared = true
    [runners.cache.s3]
      ServerAddress = "s3provider.domain.localdomain"
      AccessKey = "supersecretaccesskey"
      SecretKey = "supersecretsecretkey"
      BucketName = "openstack-gitlab-runner"

Bootstrap Docker in the OpenStack VM

Last but not least, these VMs need to be bootstrapped with Docker inside a small script. Check the “–engine-install-url” parameter in the help output:

root@icinga-gitlab:/etc/gitlab-runner# docker-machine create --help
  ...
  --engine-install-url "https://get.docker.com"							Custom URL to use for engine installation 

You can use the official way of doing this, but putting this into a small script also allows customizations like QEMU used for Raspbian builds. Ensure that the script is available via HTTP e.g. from a dedicated GitLab repository 😉

#!/bin/sh
#
# This script helps us to prepare a Docker host for the build system
#
# It is used with Docker Machine to install Docker, plus addons
#
# See --engine-install-url at docker-machine create --help

set -e

run() {
  (set -x; "$@")
}

echo "Installing Docker via get.docker.com"
run curl -LsS https://get.docker.com -o /tmp/get-docker.sh
run sh /tmp/get-docker.sh

echo "Installing QEMU and helpers"
run sudo apt-get update
run sudo apt-get install -y qemu-user-static binfmt-support

Once everything is up and running, the GitLab runners are ready to fire the jobs.

 

Auto-Scaling

Jobs and builds are not run all the time, and especially with cloud resources, this should be a cost-efficient thing. When building Icinga 2 for example, the 20+ different distribution jobs generate a usage peak. With the same resources assigned all the time, this would tremendously slow down the build and release times. In that case, it is desirable to automatically spin up more VMs with Docker and let the GitLab runner take care of distributing the jobs. On the other hand, auto-scaling should also shut down resources in idle times.

By default, one has 4 VMs assigned to the GitLab runner. These builds run non-privileged in Docker, the example below also shows another runner which can run privileged builds. This is needed for Docker-in-Docker to create Docker images and push them to GitLab’s container registry.

root@icinga-gitlab:~# docker-machine ls
NAME                                               ACTIVE   DRIVER      STATE     URL                      SWARM   DOCKER     ERRORS
runner-privileged-icinga-1571900582-bed0b282       -        openstack   Running   tcp://10.10.27.10:2376           v19.03.4
runner-privileged-icinga-1571903235-379e0601       -        openstack   Running   tcp://10.10.27.11:2376           v19.03.4
runner-non-privileged-icinga-1571904408-5bb761b5   -        openstack   Running   tcp://10.10.27.20:2376           v19.03.4
runner-non-privileged-icinga-1571904408-52b9bcc4   -        openstack   Running   tcp://10.10.27.21:2376           v19.03.4
runner-non-privileged-icinga-1571904408-97bf8992   -        openstack   Running   tcp://10.10.27.22:2376           v19.03.4
runner-non-privileged-icinga-1571904408-97bf8992   -        openstack   Running   tcp://10.10.27.22:2376           v19.03.4

Once it detects a peak in the pending job pipeline, the runner is allowed to start additional VMs in OpenStack.

root@icinga-gitlab:~# docker-machine ls
NAME                                               ACTIVE   DRIVER      STATE     URL                      SWARM   DOCKER     ERRORS
runner-privileged-icinga-1571900582-bed0b282       -        openstack   Running   tcp://10.10.27.10:2376           v19.03.4
runner-privileged-icinga-1571903235-379e0601       -        openstack   Running   tcp://10.10.27.11:2376           v19.03.4
runner-non-privileged-icinga-1571904408-5bb761b5   -        openstack   Running   tcp://10.10.27.20:2376           v19.03.4
runner-non-privileged-icinga-1571904408-52b9bcc4   -        openstack   Running   tcp://10.10.27.21:2376           v19.03.4
runner-non-privileged-icinga-1571904408-97bf8992   -        openstack   Running   tcp://10.10.27.22:2376           v19.03.4
runner-non-privileged-icinga-1571904408-97bf8992   -        openstack   Running   tcp://10.10.27.23:2376           v19.03.4

...

runner-non-privileged-icinga-1571904534-0661c396   -        openstack   Running   tcp://10.10.27.24:2376           v19.03.4
runner-non-privileged-icinga-1571904543-6e9622fd   -        openstack   Running   tcp://10.10.27.25:2376           v19.03.4
runner-non-privileged-icinga-1571904549-c456e119   -        openstack   Running   tcp://10.10.27.27:2376           v19.03.4
runner-non-privileged-icinga-1571904750-8f6b08c8   -        openstack   Running   tcp://10.10.27.29:2376           v19.03.4

 

In order to achieve this setting, modify the runner configuration and increase the limit.

vim /etc/gitlab-runner/config.toml

[[runners]]
  name = "docker-machine on OpenStack"
  limit = 24
  output_limit = 20480
  url = "https://git.icinga.com/"
  token = "supersecrettoken"
  executor = "docker+machine"

This would result in 24 OpenStack VMs after a while, and all are idle 24/7. In order to automatically decrease the deployed VMs, use the OffPeak settings. This also ensures that resources are available during workhours while spare time and weekend are considered “off peak” with shutting down unneeded resources automatically.

    OffPeakTimezone = "Europe/Berlin"
    OffPeakIdleCount = 2
    OffPeakIdleTime = 1800
    OffPeakPeriods = [
      "* * 0-8,22-23 * * mon-fri *",
      "* * * * * sat,sun *"
    ]

Pretty neat functionality 🙂

 

Troubleshooting & Monitoring

“docker-machine ls” provides the full overview and tells whenever e.g. a connection to OpenStack did not work, or if the VM is currently unavailable.

root@icinga-gitlab:~# docker-machine ls
NAME                                               ACTIVE   DRIVER      STATE     URL                      SWARM   DOCKER     ERRORS
runner-privileged-icinga-1571900582-bed0b282       -        openstack   Error                                      Unknown    Expected HTTP response code [200 203] when accessing [GET https://cloud.netways.de:8774/v2.1/servers/], but got 404 instead

In case you have deleted the running VMs to start fresh, provisioning might take a while and the above can be a false positive. Check the OpenStack management interface to see whether the VMs booted correctly. You can also remove a VM with “docker-machine rm <id>” and run “gitlab-runner restart” to automatically provision it again.

Whenever the VM provisioning fails, a gentle look into the syslog (or runner log) unveils what’s the problem. Lately we had used a wrong OpenStack flavor configuration which was fixed after investigating in the logs.

Oct 18 07:08:48 3 icinga-gitlab gitlab-runner[30988]:  #033[31;1mERROR: Error creating machine: Error in driver during machine creation: Unable to find flavor named 1234-customer-id-4-8#033[0;m  #033[31;1mdriver#033[0;m=openstack #033[31;1mname#033[0;m=runner-non-privilegued-icinga-1571375325-3f8176c3 #033[31;1moperation#033[0;m=create

Monitoring your GitLab CI runners is key, and with the help of the REST API, this becomes a breeze with Icinga checks. You can inspect the runner state and notify everyone on-call whenever CI pipelines are stuck.

 

Conclusion

Developers depend on fast CI feedback these days, speeding up their workflow – make them move fast again. Admins need to understand their requirements, and everyone needs a deep-dive into GitLab and its possibilities. Join our training sessions for more practical exercises or immediately start playing in NWS!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...