Terraform Changes

Hallo!

Was vielen von unseren Lesern entgeht, ist das wir auch in unserem Alltag zwischen der ganzen Softwareschreiber- und Kompilier- Tätigkeiten auch ganz viele virtuelle Maschinen und Container zum testen selbiger Software rauf und runter installieren müssen, und das Tag für Tag.

Deshalb versuchen wir uns das Leben mit dafür erstellter Software und deren arbeitserleichternden Funktionen leichter zu machen. Wie mein Kollege schon in seinem Blogpost im März mir vorgegriffen hat, benutzen wir bei der Netways Terraform. Achim wird in weiteren Artikeln darauf eingehen wie man Openstack per Terraform nach seiner Pfeife tanzen lassen kann und Ich möchte mich heute auf ein anderes Terraform Thema beziehen, nämlich dem nahen Release von Terraform 0.12.

Zu dem Zeitpunkt wo ich diese Zeilen niederschreibe, ist auf der aktuellen Website von Hashicorp noch die Aktuelle Version 0.11.13 zu finden.

Aber Terraform hat uns schon vielversprechendes gezeigt mit dem 0.12.0-beta1 pre-release.

Damit kann man schon die vielen Erleichterungen, welche der neue Terraform Release mit sich bringt erahnen und auch schon antesten. Ich versuche die Änderungen Anhand eines kleinen Beispiels zu erläutern.
Vielleicht kann ich den einen oder anderen IaaS Codeschreiber, welcher sich hierfür interessiert, etwas auf den Geschmack zu bringen schon etwas zu testen mit der neuen Version.

Hier der Unterschied zwischen einer (aktuell 0.11.13) alten Terraform Version und einer neuen Version in Terraform 0.12 durch eine Gegenüberstellung.

main.tf (Random Tiernamen Beispiel)

variable "count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "zoo_enabled" { default = "0" } variable "prefix_liste" { default = [] } resource "random_pet" "my_pet" { count = "${var.count}" prefix = "${var.zoo_enabled == "0" ? var.default_prefix : element(concat(var.prefix_liste, list (""), count.index)}" }

main.tf HCL2 Version(Random Tiernamen Beispiel)

variable "pet_count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "prefix_list" { default = [] } resource "random_pet" "my_pet" { count = var.pet_count prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix }

Die Unterschiede fallen zuerst etwas weniger ins Auge, sind aber dafür meines Erachtens tiefgreifender für Leute, die IaaS Code schreiben müssen und dienen der Lesbarkeit des Codes.

Vorteil Nummer 1:
Im alten Beispiel musste noch mit “${var.count}” von einem String zu einer Number evaluiert werden. Mit der neuen HCL2 Schreibweise entfällt das, und es kann mit var.pet_count direkt der korrekte String oder Number Wert adressiert werden.

Vorteil Nummer 2:
Auch die Evaluierung der Liste prefix = “${var.zoo_enabled == “0” ? var.default_prefix : element(concat(var.prefix_liste, list (“”), count.index)}”  wird mit der neuen Notation der HCL2 wesentlich eingängiger. prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix ist prägnanter. Es entfällt auch die element(concat(x), list(“”), x ) Hack-Situation, um aus einer leeren Liste auch eine Liste mit einem NULL Element zum machen.

Weitere Vorteile: es gibt viel mehr was geändert worden ist, if you want to know more, klick here.

Ich hoffe ich habe euch nicht zu sehr gelangweilt mit C.O.D.E. kurz vor dem Wochenende.

Gruß David

 

David Okon
David Okon
Senior Consultant

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...
Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Wer in GitLab die CI/CD-Features nutzen möchte und nicht zufällig einen ungenutzten Kubernetes-Cluster übrig hat, mit dem man GitLab’s Auto DevOps Funktion einrichten kann, der benötigt zumindest einen GitLab Runner, um Build-Jobs und Tests zum Laufen zu bekommen.
Der GitLab Runner ist eine zusätzliche Anwendung, welche sich ausschließlich darum kümmert, bei einer GitLab-CE/-EE Instanz die CI/CD-Aufträge abzuholen und diese abzuarbeiten. Der Runner muss dabei nicht zwingend auf dem selben System wie das GitLab installiert sein und kann somit auch extern auf einem anderen Host laufen. Der Hintergrund, weshalb man das auch so umsetzen sollte, ist eigentlich recht klar: ein GitLab Runner steht bei einer aktiven CI/CD-Pipeline oftmals unter hoher Last und würde er auf dem gleichen Host wie das GitLab selbst laufen, so könnte er dessen Performance stark beeinträchtigen. Deshalb macht es Sinn, den GitLab Runner z.B. auf eine VM in OpenStack auszulagern.
In diesem Blogpost werde ich kurz darauf eingehen, wie man schnell und einfach eine GitLab Runner VM per CLI in OpenStack aufsetzen kann. Da ich den Runner als Docker-Container starten möchte, bietet sich CoreOS an. CoreOS kommt mit Docker vorinstalliert und es bietet die Möglichkeit per Ignition Config nach dem Start des Betriebssystems Container, oder auch andere Prozesse, automatisch starten zu lassen.

Sobald man sich bei seinem OpenStack-Anbieter in sein Projekt eingeloggt hat, kann man sich dort unter “API Zugriff” die OpenStack-RC-Datei herunterladen. Damit kann man sich dann recht einfach per CLI bei OpenStack authentifizieren. Voraussetzung für die Nutzung der CLI ist, dass man bei sich den OpenStack Command-Line Client installiert hat.
Sobald man beides hat, kann es auch schon losgehen:

    1. Runner Registration Token abholen
      Dazu loggt man sich als Admin in sein GitLab-CE/-EE ein und navigiert zu “Admin Area” -> “Overview” -> “Runners”. Hier findet man den aktuellen Registration Token.
    2. CoreOS Ignition Config
      Die Konfigurationsdatei für CoreOS nennt man z.B. config.ign. Diese legt man sich ebenfalls auf dem Rechner ab.
      Der Inhalt muss im nächsten Schritt geringfügig angepasst werden.

      config.ign

      { "ignition": { "version": "2.2.0", "config": {} }, "storage": { "filesystems": [{ "mount": { "device": "/dev/disk/by-label/ROOT", "format": "btrfs", "wipeFilesystem": true, "label": "ROOT" } }] }, "storage": { "files": [{ "filesystem": "root", "path": "/etc/hostname", "mode": 420, "contents": { "source": "data:,core1" } }, { "filesystem": "root", "path": "/home/core/config.toml", "mode": 644, "contents": { "source": "data:,concurrent=4" } } ] }, "systemd": { "units": [ { "name": "gitlab-runner.service", "enable": true, "contents": "[Service]\nType=simple\nRestart=always\nRestartSec=10\nExecStartPre=/sbin/rngd -r /dev/urandom\nExecStart=/usr/bin/docker run --rm --name gitlab-runner -e 'GIT_SSL_NO_VERIFY=true' -v /home/core:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:v11.8.0 \n\n[Install]\nWantedBy=multi-user.target" }, { "name": "gitlab-runner-register.service", "enable": true, "contents": "[Unit]\nRequires=gitlab-runner.service\n[Service]\nType=simple\nRestart=on-failure\nRestartSec=20\nExecStart=/usr/bin/docker exec gitlab-runner gitlab-runner register -n --env 'GIT_SSL_NO_VERIFY=true' --url https://$URL -r $TOKEN --description myOpenStackRunner--locked=false --executor docker --docker-volumes /var/run/docker.sock:/var/run/docker.sock --docker-image ruby:2.5 \n\n[Install]\nWantedBy=multi-user.target" } ] }, "networkd": {}, "passwd": { "users": [ { "name": "core", "sshAuthorizedKeys": [ "$your-ssh-pub-key" ] } ] } }
    3. Ignition Config anpassen
      Beim Systemd-Unit “gitlab-runner-register.service” setzt man im Content bei den Variablen “$URL” den FQDN der eigenen GitLab-Instanz und bei “$TOKEN” den in Schritt 1 kopierten Registration Token ein.
      Außerdem kann man gleich noch seinen SSH-Key mitgeben, damit man später auch per SSH auf die VM zugreifen kann. Diesen hinterlegt man unter dem Abschnitt “passwd” im Platzhalter “$your-ssh-pub-key”.
    4. CLI Commands
      Nun kann man sich auch schon das Kommando zum anlegen der VM zusammenbauen.
      Als erstes muss man sich bei OpenStack authentifizieren, indem man die Datei sourced, die man sich eingangs aus seinem OpenStack Projekt geladen hat und dabei sein OpenStack Passwort angibt:

      source projectname-openrc.sh

      Man sollte außerdem sicherstellen, dass in dem Projekt ein CoreOS Image zur Verfügung steht.
      Anschließend kann man nach folgendem Schema die Runner-VM anlegen:

      openstack server create --network 1826-openstack-7f8d2 --user-data config.ign --flavor s1.medium --image CoreOS_Live "GitLab Runner"

      Network, Flavor und Image sollten aber individuell noch angepasst werden.

    Nach ca. zwei Minuten sollte dann der Runner auch schon zur Verfügung stehen. Überprüfen lässt sich das, indem man sich als Admin in seine GitLab-Instanz einloggt und im Bereich unter “Admin Area” -> “Overview” -> “Runners” nach einem Runner mit dem Namen “myOpenStackRunner” nachsieht.

    Wer noch auf der Suche nach einem OpenStack-Provider ist, der wird bei den NETWAYS Web Services fündig. Mit nur wenigen Clicks hat man sein eigenes OpenStack-Projekt und kann sofort loslegen.

Gabriel Hartmann
Gabriel Hartmann
Systems Engineer

Gabriel hat 2016 als Auszubildender Fachinformatiker für Systemintegrator bei NETWAYS angefangen und 2019 die Ausbildung abgeschlossen. Als Mitglied des Web Services Teams kümmert er sich seither um viele technische Themen, die mit den NETWAYS Web Services und der Weiterentwicklung der Plattform zu tun haben. Aber auch im Support engagiert er sich, um den Kunden von NWS bei Fragen und Problemen zur Seite zu stehen.

GitLab CI + Docker + Traefik = ❤️

So wie vermutlich einige, bin auch ich zur Zeit sehr von GitLab und dessen CI/CD Features angetan. Vor einigen Monaten habe ich angefangen, für meine privaten Webprojekte eine Template .gitlab-ci.yml zu erstellen, welche für jeden Commit, auf jedem Branch, automatisch Docker Images baut und diese in meiner Docker-Umgebung mit zum Branch/Projekt passender Subdomain und SSL-Zertifikat bereitstellt.

Um zu funktionieren benötigt das ganze eine erreichbare Docker-API, ein darauf laufendes Traefik, ein Docker-Netzwerk namens Proxy (Traefik muss dieses auch nutzen) und einen Account + Repository auf hub.docker.com. Das ganze kann aber recht einfach umgeschrieben werden, falls man seine eigene Registry verwenden möchte.

Ablauf beim Commit:

  1. Bauen und Pushes des Images (Tag => Branch + Commit-Hash)
  2. Umbenennen des alten Containers, falls vorhanden (Suffix ‘-old’ wird angehangen)
  3. Erstellen des neuen Containers (Name => Deployment Domain bsp. master.dev.domain.tld)
  4. Löschen des alten Containers
  5. (Optional) Löschen & neu erstellen des Produktionscontainers, falls der Commit auf dem Masterbranch stattgefunden hat (Muss durch Button ausgelöst werden und läuft wie Schritte 2 bis 4 ab)
  6. Neue Container stehen unter den Deployment-Domains zur Verfügung

Pipeline eines Commits auf Master/andere Branches (Deploy auf Produktion kann durch “Play”-Button ausgelöst werden):

Pipeline eines Commits auf andere Branches:

Für jeden Branch wird auch ein Environment erstellt, welches über Operations/Environments in GitLab verwaltet werden kann.
Hier können Deployments angesehen, gelöscht, in Produktion ausgerollt und auf einen früheren Stand zurückgesetzt werden:

Zur Nutzung des Templates in einem Projekt wird ein Dockerfile im Repository, ein paar CI/CD-Variablen, und das Template selber benötigt.

Benötigte CI/CD-Variablen:

CI_DEV_URL_SUFFIX (Domain-Suffix der Development-Umgebungen): dev.domain.tld
CI_PRODUCTION_URL (Domain der Produktionsumgeben): domain.tld
CI_DOCKER_HOST (Adresse & Port der Docker-API): docker.domain.tld
CI_REGISTRY_IMAGE (Image-Name auf hub.docker.com): supertolleruser/supertollesoftware
CI_REGISTRY_USER (Docker-Hub Benutzer): supertolleruser
CI_REGISTRY_PASSWORD (Passwort des Docker-Hub Benutzers): supertollespasswort
CI_TRAEFIK_PORT (Port der Webanwendung im Container): 8080

Da das ganze Projekt bis jetzt nur Images baut und Container bereitstellt, könnten hier natürlich noch Tests eingebaut werden um das ganze abzurunden.

Zur Zeit arbeite ich an einer Umstellung auf Kubernetes und werde, sobald abgeschlossen, auch davon berichten.

Noah Hilverling
Noah Hilverling
Junior Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

Portainer

Übersicht für Docker

Docker ist eine Open Source Lösung, welche eine sehr effiziente und einfache Möglichkeit bietet, deine App als Container problemlos zum Laufen zu bringen bei verschiedenen Umgebungen. Wer mehr über Docker erfahren will, kann den vorherigen Artikel durchlesen. Wir als Netways GmbH arbeiten seit langem mit Docker und bieten Hostings für Ihre gewünschte Umgebung. Als erfolgreiches Beispiel für Docker sind die Apps, die wir durch NWS anbieten.

Eine kleine Wissensrunde über Portainer

Portainer ist ein Container von Docker-Hub, welcher eine Web-Management-Schnittstelle darstellt, die es uns ermöglicht, Docker grafisch zu betreiben.
docker run -d -p 9000:9000 --name=portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer

Was kann man mit Portainer zaubern ?

  • Container starten, stoppen, killen, neustarten, löschen, addieren etc…
  • Images aufbauen, löschen, an eigens Konto auf Docker Hub oder an selber konfigurierte Registry exportieren und importieren.
  • Services auf einem Cluster “Swarm” als Hochverfügbarkeit hinzufügen oder löschen. Wir werden mehr über Swarm im nächsten Abschnitt erfahren!
  • Stacks addieren und löschen. Stacks sind Gruppen von Services, die mit einander kommunizieren und am Ende eine App liefern wie zum Beispiel wordpress mit Datenbank.
  •  Administrator oder normale User hinzufügen und zu einem bereitgestelltem Team zuweisen.
  • Zugreifen und managen von Docker-Endpoints. Dazu gibt es zwei Möglichkeiten, entweder erstellen Sie eine Gruppe, weisen Docker-Endpoint/s zu ihr zu und geben Zugriffsrechte für Benutzer oder Team/s auf diese Gruppe, oder Sie geben Rechte direkt im Endpoint-Menü für Benutzer oder Team/s für jeden einzigen Docker-Endpoint .
  •  Eigne Registry anbinden und Zugriffe nach Benutzer oder Team vergeben. Allerdings können Sie Ihre Images nicht durchsuchen. Das heißt der Name des Images muss bekannt sein, bevor ein Container gestartet werden kann.
  • Authentifizierung lokal konfigurieren oder vom LDAP Server ziehen.
  • Einen Überblick über die Swarm “Cluster” Umgebung verschaffen z.B wie viel Leistung bietet das Cluster und welche Container laufen auf welcher Docker Engine. Außerdem können Sie die Availability von einer Docker-Instance auf active, pause oder drain setzen. Dies ist sehr hilfreich bei einem Update oder Backup. Bei active ist Docker immer bereit Tasks von einem Service anzunehmen. Bei Pause akzeptiert Docker keine Tasks mehr. Bei drain werden alle Tasks gestoppt und von anderen Nodes im Swarm übernommen.
Portainer kann auch Infos von einem Swarm visualisieren.

Was ist Swarm ?

Swarm oder Cluster entstehen einfach aus Manager/n und Worker/n, auf denen Docker läuft. Das Hauptziel von Swarm ist die Hochverfügbarkeit und Lastverteilung. Manager können alles konfigurieren und  managen, allerdings sind Worker nur dafür da, die Last zu vermindern und Tasks zum laufen zu bringen. Wenn ein Service bei Default auf dem ganzen Swarm verteilt wird,  können Sie entweder im docker-compose.yml einen Key definieren auf welchen Nodes die Services laufen sollen, oder den Service auf dem ganzen Swarm verteilt lassen. Von einem Swarm dürfen maximal (N-1)/2 Manager ausfallen, ansonsten funktioniert kein Swarm-Befehl bis die fehlenden Manager wieder up sind oder ein neuer Cluster erzwungen wird.
docker swarm init --force-new-cluster --advertise-addr "IP-Adresse von manager"
Trotz des neuen Cluster-Aufbaus synchronisieren sich die wieder up Server mit dem Swarm ganz normal. Ich würde gerne ein Beispiel von einer Swarm-Konfiguration von zwei Managern und einem Worker vorstellen.




Wie kann portainer swarm managen ?

Portainer kann andere Manger in Swarm als Endpoint betreiben, wenn ein overlay Network eingerichtet ist, auf dem portainer_agent als Service läuft.
docker network create --driver overlay --attachable portainer_agent_network
docker service create \
--name portainer_agent \
--network portainer_agent_network \
--publish mode=host,target=9001,published=9001 \
-e AGENT_CLUSTER_ADDR=192.168.56.150 \
--mode global \
--mount type=bind,src=//var/run/docker.sock,dst=/var/run/docker.sock \
--mount type=bind,src=//var/lib/docker/volumes,dst=/var/lib/docker/volumes \
portainer/agent

Für jeden neuen Agent muss ein neuer Service auf dem Overlay Netwok zum laufen gebracht werden mit neuem Namen, veröffentlichen Port und Adresse. Ansonsten bekommt man einen Duplikatfehler.


Für Leser, die sich für Portainer begeistert haben, gibt es eine Demo auf http://demo.portainer.io
Benutzername : admin
Passwort : tryportainer
Hinweis: Das Cluster wird alle 15 Minuten zurückgesetzt.
Ich hoffe der Artikel hat Ihnen weiter geholfen 🙂

Afeef Ghannam
Afeef Ghannam
Junior Consultant

Afeef macht seit September 2017 eine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS. Nachdem der gebürtige Syrer erfolgreich Deutsch gelernt hat, stellt er sich jetzt der Herausforderung Programmiersprache. Neben der IT schätzt er vielfältiges Essen. Sein Motto lautet يد واحدة لا تصفق لوحدها , was so viel bedeutet wie „Eine Hand wird nie allein klatschen“.

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

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
Marius Hein
Head of Development

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.