Cachet now available at NETWAYS Web Services

We think communication is crucial. Especially during downtimes. That’s why we release a new app today. An app, which allows you to share all necessary information about your services and servers with your users. Cachet is software that improves downtime.

Cachet is a status page, which is very simple to use, yet it offers many opportunities, to better communicate downtime and system outages to customers, teams and shareholders. You can display the status of your services, websites and servers. You can create and show metrics, plan maintenances or inform your users about current issues.

 

 

Cachet comes with a powerfull API. In the detailed documentation you can generate your calls for whatever you want to create or change. All information which can be created and edited in the admin panel, can also be created and changed with an API call. The interesting part about Cachet is that administrators have the opportunity to automate the updates. For example with data of your monitoring or some scripts on your hosts which check some services.

In the following command, you would create a new incident with the name “Down” and the message “A server went down“.

  • It will be in the state “1“, which means “investigating
  • The component which is affected by this incident has the id 2, which is in this case “My Login
  • The component will be in state “4“, which means “Major Outage
  • Notify: true – so your user would receive an email with about this incident.

mgebert@MacBook-Pro ~ $ curl --request POST --url https://cachet-demo.nws.netways.de/api/v1/incidents -H "Content-Type: application/json;" -H "X-Cachet-Token: j5t0mNvvh57ubO84TxJq" --data '{"name":"Down","message":"A server went down.","status":1,"visible":1,"component_id":2,"component_status":4,"notify":"true"}'

If you want to notify your users as soon as an incident was reported, you will have to configure the credentials for your mailserver and enable the “Subscribe” button, which can be done in the settings quite simple.

But if you don’t want to use the API, you can create and manage your information just by changing the states of your components and incidents, as you can see in the screenshots below.

 

You can start your own Cachet app at the NWS platform now on our platform. First 30 days are for free and the app will be ready within 5 minutes – so what are you waiting for?

Last but not least, I want to share with you the link to a temporary available demo installation, so you can have a look at it right now. Check it out!

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 – because web services don’t have to be complicated

NWS – because web services don’t have to be complicated

Web services platforms are a common way nowadays, to run your services without the need of your own infrastructure. No matter if you need a safe place for your data, an app to communicate with people or just a place to run your own services. But what do you know about the platform of your choice?

  • Do you know how your data is stored?
  • Do you know where the servers are located in detail?
  • Do you know the people which are giving you support?
  • Do you know what happens in case of a critical issue?

I bet, most of you, or at least some of you, don’t. But that’s the point where we start. We want to be different. We want to be transparent and uncomplicated.

Our servers are located in Nuremberg – Germany. We are running them in two different datacenters to ensure high security.

Working with our apps is pretty simple. Just start them! There is no complicated registration process, just fill in the form and you are good to go. The best thing is: you don’t even need a domain or some know how of SSL. It’s already configured for you! Of course you can use your own domain and certificates if you want, but you don’t have to.
If you are curious about how our apps are working in detail or what features are available in our apps, just have a look at our FAQs
Still can’t find what you are looking for? Contact us via live chat! If there is no live chat agent available, an automated ticket will be created, so we can get in touch with you.

But whats so special about our support? Well, it’s quick, it’s professional, it’s individual and most important of all: Our developers and administrators are your support team.

We also want to create our bills as transparent as possible. In case of our OpenStack cloud, you won’t just get a bill with an amount. You will get a detailed report of all resources you used in the past month. Which IP was used how long? How many CPUs were used how long and which VM did use them? But thats still not all. We want to give you the possibility to check at a various day of the month, how much money you spent on our cloud so far and how much you will spent till the end of the month.

Keep track of whats going on! And even if you have your applications running on a different platform – we will help you migrating your data with almost no downtime. Because we take care.

Most features we released for our apps and the platform itself, were not features “we wanted” to release. Don’t get me wrong here, we also wanted to release them, but most of them were features our customers requested and needed.

And we got one more thing. If you don’t know if you can trust us, you can just give it a try. Ask us anything or just try our services – 30 days for free (OpenStack is excluded here – but just get in touch with us. We will find a solution that fit your needs.).

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 Cloud and Terraform – does this work?

NWS Cloud and Terraform – does this work?

A few months ago we launched our OpenStack project within our NWS platform. The NWS Cloud was born.
Since then we are trying to increase the performance and the possibilities of the cloud. And nowadays there is no way around Terraform.

So i had a look at the possibilities and had to try them out. One of my first runs should create a virtual machine, create some security rules, attach a public IP to the virtual machine and install a webserver with a customized index.html

And how this works, i want to show now.

 

But first of all, i have to save my credentials in my config file

variables.tf

variable "openstack_user_name" { description = "The username for the Tenant." default = "my-nws-user" } variable "openstack_tenant_name" { description = "The name of the Tenant." default = "my-nws-project" } variable "openstack_password" { description = "The password for the Tenant." default = "my-password" } variable "openstack_auth_url" { description = "The endpoint url to connect to OpenStack." default = "nws-cloud" } variable "openstack_keypair" { description = "The keypair to be used." default = "mgebert" } variable "tenant_network" { description = "The network to be used." default = "my-nws-project" }

With this variables i can now start writing the rest of my files. I had to configure the provider

provider.tf

provider "openstack" { user_name = "${var.openstack_user_name}" tenant_name = "${var.openstack_tenant_name}" password = "${var.openstack_password}" auth_url = "${var.openstack_auth_url}" }

And the “script” which should run on the new virtual machine

bootstrapweb.sh

#!/bin/bash apt update apt install -y apache2 cat <<EOF > /var/www/html/index.html <html> <body> <p>hostname is: $(hostname)</p> </body> </html> EOF chown -R www-data:www-data /var/www/html systemctl apache2 start

But there is still no server right? So i have to write my deploy file.

deploy.tf

resource "openstack_networking_secgroup_v2" "secgroup1" { name = "ALLOW SSH AND HTTP" } resource "openstack_networking_secgroup_rule_v2" "secgroup_rule_1" { direction = "ingress" ethertype = "IPv4" protocol = "tcp" port_range_min = 22 port_range_max = 22 remote_ip_prefix = "0.0.0.0/0" security_group_id = "${openstack_networking_secgroup_v2.secgroup1.id}" } resource "openstack_networking_secgroup_rule_v2" "secgroup_rule_2" { direction = "ingress" ethertype = "IPv4" protocol = "tcp" port_range_min = 80 port_range_max = 80 remote_ip_prefix = "0.0.0.0/0" security_group_id = "${openstack_networking_secgroup_v2.secgroup1.id}" } resource "openstack_networking_secgroup_rule_v2" "secgroup_rule_3" { direction = "ingress" ethertype = "IPv4" protocol = "icmp" remote_ip_prefix = "0.0.0.0/0" security_group_id = "${openstack_networking_secgroup_v2.secgroup1.id}" } resource "openstack_compute_instance_v2" "web" { name = "web01" image_name = "Ubuntu Xenial" availability_zone = "HetznerNBG4" flavor_name = "s2.small" key_pair = "${var.openstack_keypair}" security_groups = ["default","ALLOW SSH AND HTTP"] network { name = "${var.tenant_network}" } user_data = "${file("bootstrapweb.sh")}" } resource "openstack_networking_floatingip_v2" "floating" { pool = "public-network" } resource "openstack_compute_floatingip_associate_v2" "floating" { floating_ip = "${openstack_networking_floatingip_v2.floating.address}" instance_id = "${openstack_compute_instance_v2.web.id}" }

 

In this file i configure first of all the new security group and afterwards 3 rules to allow ICMP, HTTP and SSH. Then we can start the virtual machine with a name, image_name, a flavor_name, security_groups and so on. I could configure more, like a loop which creates me 10 web-servers with the name web-01 to web-10 . But for now, thats fine. When the server is up and running, the deploy will attach a floating IP to it, so i can access it without a VPN.

And thats it, basically. When it is installed, the bootstrapweb.sh will install the apache2 webserver and replace the default index.html with my custom one.

There is almost no setup which can’t be build up with terraform in combination with the NWS Cloud – so just try it yourself

If you want to see the code above in action, have a look at this video!

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...
NETWAYS Web Services Raffle

NETWAYS Web Services Raffle

We wanted to do a big raffle. A very special one. You can win 3 amazing prices and how this works will be described below. But first of all, what are the prices?

  • First place: Our incredible @gethash for one day at your office*
  • Second place: One NWS app for free. A whole year! **
  • Third place: One big box of Dragee Keksi

The requirements will be explained in detail in the tweet of the NWS Twitter Account. Basically you have to follow the NWS Twitter account and retweet the tweet, where this blogpost is published. It will be pinned to the account till the end of May. We will draw 3 winners from all participants.

The great colleagues of Netways are excluded from this raffle cause Bernd is afraid of their crazy ideas.

The winners will be announced on May 31st 2019 and will be published on the NWS Twitter account.

We wish good luck to all of you!

*Restriction: it has to be within Germany!
**You decide which app. OpenStack is excluded here

 

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...
FM Empfänger mit dem Raspberry Pi 3

FM Empfänger mit dem Raspberry Pi 3

Es gibt viele Projekte für Einsteiger, um mit einem Raspberry Pi kleineres zu realisieren. Unter anderem ein FM Empfänger, wofür die folgende Anleitung genutzt werden kann.

Materialien: 

  1. Raspberry Pi 3
  2. Female Female Jumper
  3. Tea5767 Modul
  4. Lautsprecher (Beispiel)
  5. AUX Kabel

Vorgehen: 

1) Die mitgelieferte SD Karte enthält bereits ein Noob OS, womit Raspian installiert werden kann. Sollte ein anderes Kit ohne Karte bestellt werden, braucht man natürlich auch eine SD Karte. Noob OS dann einfach herunterladen, entpacken und auf die Karte kopieren

2) I2C aktivieren via: sudo raspi-config
-> Interfacing Options
-> I2C
-> YES

3) Der Raspberry Pi muss natürlich auch mit dem Modul verbunden werden. Hierzu werden die Female-Female Jumper benutzt.
Raspberry Pi    Tea5767
5V              5V
SDA.1           SDA
SCL.1           SCL
GND             GND

Auf welche Pins nun genau gesteckt werden muss, kann mittels gpio readall herausgefunden werden. Falls SDA.1 und SCL.1 bereits in Verwendung sind, kann auch auf 0 oder 2 ausgewichen werden.

4) Ob das Modul auch erkannt wurde, wird folgendermaßen überprüft:
i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Die “1” steht hier für SCl.1 und SDA.1 – sollte SDA.0 und SCL.0 verwendet worden sein, muss der Command entsprechend angepasst werden.  Wenn in der angezeigten Tabelle keine Zahl erscheint, wird das Modul nicht erkannt. Dies liegt meist an einer falschen Verkabelung oder einem defekten Modul.

5) Aus einer anderen Anleitung haben wir uns eines Links zum Code bedient, das den Tea5767 steuert. Es kann hier natürlich selbst auch ein Skript geschrieben werden, wenn tiefere Einblicke gewünscht sind. Hierfür wird python3 benötigt sowie verschiedene Module. Beim ersten Aufruf des Skriptes wird aber mitgeteilt, ob etwas nachinstalliert werden muss, oder nicht. Falls das der Fall ist, kann mit pip3 install $modul entsprechend nachjustiert werden.
Unter /home/pi ein neues Verzeichnis (z.B.: PiFM) erstellen und das Skript dort ablegen.

6) Mit python3 radio.py kann nun der eigentliche Radio gestartet werden. Es empfiehlt sich, das Skript kurz durchzulesen, da der Radio über Tasten gesteuert wird. So wird mit “W” die Frequenz um +1 verändert, mit “E” um +0.1

Alles in allem ist das ein schönes Projekt um erste Eindrücke in die Funktionsweise eines Raspberry Pis zu bekommen und wie bestimmte Module funktionieren, verbunden und genutzt werden. Interessant wird das auch, wenn man parallel dazu mit einem 2. Pi einen FM Transmitter aufbaut. Hierzu gibt es in einem späteren Blogpost aber mehr.

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 OpenStack – automatisierte Snapshots

Unser Ziel war und ist es, eine Plattform zu schaffen, die sehr hohe Flexibilität, Sicherheit und Komfort bietet. Unsere Kunden sollen in eigenen, isolierten Projekten ihrer Kreativität freien Lauf lassen und nahezu uneingeschränkt sein, ohne sich um essenzielle Dinge Gedanken machen zu müssen.

In genau diesem Zuge, haben wir diese Woche ein neues Feature für unsere OpenStack Cloud veröffentlicht – automatisierte Snapshots für virtuelle Maschinen und Volumes! Mit diesem neuen Feature können sich unsere “IaaS” (Infrastructure as a Service) Kunden zurücklehnen, entspannen und die Verantwortung der zuverlässigen Sicherung an uns abgeben. Wir stellen sicher, dass ausgewählte Instanzen ordnungsgemäß gesichert werden und dieser Prozess überwacht wird.

Doch wie genau funktioniert das nun? Wir haben in unserer Plattform einen Menüpunkt eingebaut, der als Schaltzentrale fungiert. Eingesehen werden kann dieser von jedem Nutzer in der Übersicht seiner OpenStack Instanz. Es werden hier alle VMs sowie Volumes aufgelistet und gegebenenfalls mit Notizen versehen. Beispielsweise in welcher VM ein Volume unter welchem Pfad eingehängt ist.

In dieser Liste kann nach belieben, durch setzen eines Hakens, der Sicherungsprozess aktiviert oder deaktiviert werden.
Neben dem Erstellen von Backups werden nach einer gewissen Retention, Snapshots natürlich auch vollkommen automatisch wieder gelöscht. Per Default alle Sicherungen, welche älter als 7 Tage sind.

Eine Übersicht über die aktuellen Sicherungen gibt es im OpenStack selbst:
Compute -> Images / Volumes -> Snapshots 

Erweiterungen zu dieser Sicht sind geplant. Ebenso weitere neue spannende Features, welche aktuell noch in der Entwicklung sind.
Wir haben zum Snapshot/Backup Release auf unserem Twitter Account ein kurzes Video mit einer Live Demo dazu für euch vorbereitet. Lasst uns auf Twitter gerne wissen, was ihr davon haltet!

Noch kein NWS IaaS Kunde? – Hier geht’s zu unserer Platform

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

Bursting und Throtteling in OpenStack

Wir haben die vergangenen Monate genutzt, um eine neue Cloud mit OpenStack aufzubauen. Im Zuge dessen, mussten wir eine Möglichkeit finden, die IOPS sowie die Bandbreite, die VMs zur Verfügung haben, zu limitieren.
Das Limitieren der Bandbreite sowie der IOPS erfolgt in OpenStack in sogenannten Flavors. In einem deutschsprachigen Interface von OpenStack werden diese “Varianten” genannt. Flavors werden hier als VM-Templates genutzt, mit denen sich VMs starten lassen. Es werden hier Ressourcen geregelt wie RAM, CPU und Firewallregeln aber eben auch die Limitierungen. Gesetzte Werte können nicht in laufenden VMs überschrieben werden. Möchte man diese ändern, muss die VM gelöscht und neu gebaut werden, nachdem die neuen Werte im Flavor angepasst wurden. Ein Rebuild reicht hier nicht aus.
Hier gibt es jedoch eine Ausnahme. Durch den Einsatz von beispielsweise libvirtd, können jene Beschränkungen mittels “virsh” angepasst werden.

Was sind IOPS und Bandbreite?

Bandbreite und IOPS geben an, wieviel Datendurchsatz sowie Lese und Schreiboperationen einer VM zugeteilt sind. Per Default sind diese unlimitiert, was unter gewissen Umständen zu Problemen führen kann.

Wieso sind Limitierungen sinnvoll?

In einer Cloud mit mehreren Virt-Systemen laufen mehrere VMs. Sind keine Limitierungen gesetzt, kann jede VM soviel Traffic und IOPS erzeugen, wie sie gerade braucht. Das ist natürlich für die Performance entsprechend gut, jedoch verhält es sich dadurch so, dass andere VMs auf dem gleichen Virt entsprechend unperformanter werden. Limitierungen werden daher dazu genutzt ein gleiches Niveau für alle VMs zu schaffen.

Bandbreite

Average

  1. quota:vif_inbound_average
  2. quota:vif_outbound_average

Wie der Name schon sagt, beschränkt man hier inbound (eingehenden) sowie outbound (ausgehenden) Traffic durch einen durchschnittlichen Wert, den diese beiden nicht überschreiten dürfen.

Peak

  1. quota:vif_inbound_peak
  2. quota:vif_outbound_peak

Die Bandbreite kann man auch mit Peak sowie Burst begrenzen. Peak gibt hierbei an, bis zu welchem Limit die Bandbreite genutzt werden darf, als absolutes Maximum. Dieser Wert funktioniert aber nur in Zusammenarbeit mit “Burst”.

Burst

  1. quota:vif_inbound_burst
  2. quota:vif_outbound_burst

Burst gibt nämlich an, wie lange die Bandbreite im Wert “Average” überschritten werden darf. Gemessen wird hier in KB. Setzt man also den Burst auf 1.048.576 KB, darf der Peak Wert solange genutzt werden, bis 1GB (1.048.576 KB) an Daten übertragen wurden. Zu Beachten ist aber, dass dieser Wert für jeden Zugriff neu gilt. Führt man also 3 Kommandos hintereinander aus (3x wget mit && verknüpft) greift der Burst für alle 3 gleichermaßen. Führt man die gleichen Kommandos ebenfalls hintereinander aus, aber verknüpft diese mit einem Sleep, greift der Burst für jedes Kommando neu.
 

IOPS

Throttle

  1. quota:disk_read_iops_sec
  2. quota:disk_total_iops_sec
  3. quota:disk_write_iops_sec

Die lesenden und schreibenden Prozesse der VMs können natürlich auch begrenzt werden. Hier gibt es zwei Möglichkeiten:

  • Limitierung von lesenden sowie schreibenden Prozessen separat
  • Limitierung auf absoluten Wert

Beides in Kombination geht nicht. Es nicht möglich zu konfigurieren, dass es 300 lesende, 300 schreibende und 700 insgesamte IOPS geben soll, würde aber auch keinen Sinn machen. Zu beachten ist, wenn alle 3 Werte gesetzt werden, können diese in einen Konflikt geraten und gegebenenfalls gar nicht greifen.

Burst

  1. quota:disk_write_iops_sec_max
  2. quota:disk_write_iops_sec_max_length

Durch das Bursting auf den Festplatten direkt, kann angegeben werden, mit welcher maximalen Anzahl an IOPS (quota:disk_write_iops_sec_max)eine VM die oben gesetzten Werte, für wie lange (quota:disk_write_iops_sec_max_length) überschreiten darf. Sinnvoll wäre dies, wenn bekannt ist, dass gewisse Prozesse kurzzeitig mehr IOPS benötigen, als freigegeben ist.

Beispiele

Um Limitierungen zu setzen, wird zunächst ein Flavor benötigt. Im Anschluss können die Werte gesetzt werden. Die Dokumentation zum Anlegen von Flavors gibts hier
openstack flavor set {$flavor} --property quota:{$param}={$value}
quota:disk_read_iops_sec='200'
(quota:disk_total_iops_sec='1000')
quota:disk_write_iops_sec='200'
quota:vif_inbound_average='10240'
quota:vif_inbound_burst='20480'
quota:vif_inbound_peak='15360'
quota:vif_outbound_average='10240'
quota:vif_outbound_burst='20480'
quota:vif_outbound_peak='15360'
quota:disk_write_iops_sec_max_length='10'
quota:disk_write_iops_sec_max='1000'
In diesem Beispiel würde man zum Beispiel die lesenden Prozesse auf 200 (quota:disk_read_iops_sec='200') beschränken, ebenso die schreibenden, bei einer eingehenden Brandbreite von 10MB(quota:vif_inbound_average='10240'). Peak liegt bei 20MB und darf für 15MB erreicht werden. Das ist natürlich ein sehr unrealistisch minimalistisches Begrenzungsbeispiel, jedoch sollte die Art und Weise wie es funktioniert verdeutlich worden sein.

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

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

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