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

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Let’s Encrypt HTTP Proxy: Another approach

Yes, we all know that providing microservices with Docker is a very wicked thing. Easy to use and of course there is a Docker image available for almost every application you need. The next step to master is how we can expose this service to the public. It seems that this is where most people struggle. Browsing the web (generally GitHub) for HTTP proxies you’ll find an incredible number of images, people build to fit into their environments. Especially when it comes to implement a Let’s Encrypt / SNI encryption service. Because it raises the same questions every time: Is this really the definitely right way to do this? Wrap custom API’s around conventional products like web servers and proxies, inject megabytes of JSON (or YAML or TOML) through environment variables and build scrips to convert this into the product specific configuration language? Always my bad conscience tapped on the door while I did every time.

Some weeks ago, I stumble upon Træfik which is obviously not a new Tool album but a HTTP proxy server which has everything a highly dynamic Docker platform needs to expose its services and includes Let’s Encrypt silently – Such a thing doesn’t exist you say?

A brief summary:

Træfik is a single binary daemon, written in Go, lightweight and can be used in virtually any modern environment. Configuration is done by choosing a backend you have. This could be an orchestrator like Swarm or Kubernetes but you can also use a more “open” approach, like etcd, REST API’s or file backend (backends can be mixed of course). For example, if you are using plain Docker, or Docker Compose, Træfik uses Docker object labels to configures services. A simple configuration looks like this:

[docker]
endpoint = "unix:///var/run/docker.sock"
# endpoint = "tcp://127.0.0.1:2375"
domain = "docker.localhost"
watch = true

Træfik constantly watch for changes in your running Docker container and automatically adds backends to its configuration. Docker container itself only needs labels like this (configured as Docker Compose in this example):

whoami:
image: emilevauge/whoami # A container that exposes an API to show its IP address
labels:
- "traefik.frontend.rule=Host:whoami.docker.localhost"

The clue is, that you can configure everything you’ll need that is often pretty complex in conventional products. This is for Example multiple domains, headers for API’s, redirects, permissions, container which exposes multiple ports and interfaces and so on.

How you succeed with the configuration can be validated in a frontend which is included in Træfik.

However, the best thing everybody was waiting is the seamless Let’s Encrypt integration which can be achieved with this snippet:

[acme]
email = "test@traefik.io"
storage = "acme.json"
entryPoint = "https"
[acme.httpChallenge]
entryPoint = "http"
# [[acme.domains]]
# main = "local1.com"
# sans = ["test1.local1.com", "test2.local1.com"]
# [[acme.domains]]
# main = "local2.com"
# [[acme.domains]]
# main = "*.local3.com"
# sans = ["local3.com", "test1.test1.local3.com"]

Træfik will create the certificates automatically. Of course, you have a lot of conveniences here too, like wildcard certificates with DNS verification though different DNS API providers and stuff like that.

To conclude that above statements, it exists a thing which can meet the demands for a simple, apified reverse proxy we need in a dockerized world. Just give it a try and see how easy microservices – especially TLS-encrypted – can be.

Marius Hein

Autor: Marius Hein

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Running Icinga in NWS with Slack notifications

Slack notifications through Icinga2. This is what we activated last week for our Icinga2 Master apps on our NWS platform! The feature came highly recommended, so we decided to give it a try. And we did. It really is awesome!!

First of all, I want to show you how it will look like on your side, so have a look at the small demo-video!

 

To work with this feature, all you need is a Slack workspace and a chatroom for your alerts. once you are done with configuration part, just follow the 7 steps below.

  1. Go to Configuration/Commands in your Icinga2 app
  2. Open command-slack-host/command-slack-service and open the drop-down Custom properties
  3. Fill in the slack_channel you want to use
  4. Fill in the slack_webhook_url (You can get your webhook url from your Slack-account settings)
  5. Create a new user in Configuration/User and add user to the two groups for Slack-Message on critical hosts/services. Also give user the user template user-template in Imports
  6. Add the states you want to receive as a notifications for to the Configuration / User/Contacts / User-template / modify / State and transition type filtersfield
  7. Deploy your changes in the Configuration/Deployments

If you have ideas for more features for our apps, just contact us via email, twitter, facebook or our NWS chat!

 

This slideshow requires JavaScript.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

NETWAYS Web Services: WordPress now up and running!

This entry is part of 1 in the series NWS

We are proud to announce a new app hosted in our NWS platform! WordPress is now available!

“Simply for everyone – Perfect for everyone who wants to create individual content. Simple and safe.”

Just as our slogan for this app tells you, we decided to create an app for our users, which can be used by anybody. An app, which is ready to use, easy to configure and practically for almost everyone, without writing code or configuring credentials etc.

We built up an automated migration program, so you can migrate your existing WordPress instance to our platform, no matter which version you are running. We also decided to give the users the opportunity to restore their website by their self and to manage their website without the need of one of our WordPress experts.

The WordPress app includes our S3 compatible replication-based and distributed storage.

All in all it will bring you the following enhanced functions to your cloud:

  • Automated Updates
  • Easy migration
  • Super fast assests delivery via S3
  • Full domain freedom / No domain needed
  • Free CNAME
  • It is available immediately
  • Automated Backups, which are stored for 24 hours
  • Preinstalled plugins and themes
  • Access to DocRoot / Backup via WebDAV

Give it a try! If you are new to our platform, you can use it 30 days for free. The app is of course monthly callable but we think you will like it!

 

This slideshow requires JavaScript.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Gitlab now supports Let’s Encrypt

Since last week our Gitlab-ce and Gitlab-ee instances are able to use Let’s Encrypt for SSL encryption. As an owner of one of our instances, you are able to use Let’s Encrypt simply by activating it in your product view on our NWS platform.

With this, you can now use your own domain, without the need of an existing SSL-certificate. If you already have a SSL-certificate active and want to test Let’s Encrypt, you can do so. Your active certificate will be stored and will be activated again, as soon as you deactivate the SSL encryption with Let’s Encrypt.

In the screenshot below, you can see an example of how it looks in the product view. Activation and deactivation will always require a restart of your instances, since these are major configurations changes to your container.

If you are interested in one of our instances, just have a look on nws.netways.de! We have many more open-source apps available, such as Rocket.Chat, RT or Nextcloud and are currently working on some new features/apps.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Obstacles when setting up Mesos/Marathon

Obstacles when setting up Mesos/Marathon

Sebastian has already mentioned Mesos some time ago, now it’s time to have a more practical look into this framework.

We’re currently running our NWS Platform under Mesos/Marathon and are quite happy with it. Sebastians talk at last years OSDC can give you a deeper insight into our setup. We started migrating our internal coreos/etcd/fleetctl setup to Mesos with Docker and also could provide some of our customers with a new setup.

Before I will give you a short description about snares I ran into during the migration, let’s have a quick overview on how Mesos works. We will have a look at Zookeeper, Mesos, Marathon and Docker.

Zookeeper acts as centralized key-value store for the Mesos cluster and as such has to be installed on both the Mesos-Master and -Slaves

Mesos is a distributed system kernel and runs on the Mesos-Masters and Slaves. The Masters distribute jobs and workload to the slaves and therefore need to know about their available ressources, e.g. RAM and CPU

Marathon is used for orchestration of docker containers and can access on information provided by Mesos.

Docker is one way to run containerized applications and used in our setup.

As we can see, there are several programs running simultaneously which creates needs for seamless integration.

What are obstacles you might run into when setting up your own cluster?

1. Connectivity:

When you set up e.g. different VMs to run your cluster, please make sure they are connected to each other. Which might look simple, can become frustrating when the Zookeeper nodes can’t find each other due to “wrong” etc/hosts settings, such as

127.0.1.1  localhost

This should be altered to

127.0.1.1 $hostname, e.g. mesos-slave1

2. Configuration

Whenever you make changes to your configuration, it has to be communicated through your complete cluster. Sometimes it doesn’t even a need a service restart. Sometimes you may need to reboot. In desperate times you might want to purge packages and reinstall them. In the end it will work and you will happily run into

by TRISTAR MEDIA

3. Bugs

While Marathon provides you with an easy to use Web-UI to interact with your containers, it has one great flaw in the current version. As the behaviour is so random, you could tend to search for issues in your setup.  You might or might not be able to make live changes to your configured containers. Worry not, the “solution” may be simply using an older version of Marathon.

Version 1.4.8 may help.

by TRISTAR MEDIA

Have fun setting up your own cluster and avoiding annoying obstacles!

Edit 20180131 TA: fixed minor typo

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!