Hackathon “Q.wiki Saas running on Kubernetes” oder „Docker/Container based Perl Legacy Code“

Posted by admin |18 Jun 18 |

Mission der Hackathons:

Wir wollen mit einem Proof-of-Concept beweisen, dass das Q.wiki der Modell Aachen GmbH auf einem Kubernetes-Cluster betrieben werden kann.

Warum überhaupt?

Das Cloud-Wachstum der Modell Aachen GmbH hat uns dazu gezwungen, mehr Fokus auf die Architektur des Cloud-Produktes „Q.wiki Now“ zu legen. In unserem internen Projekt „Q.wiki Cloud“ haben wir auf der technischen Seite zunächst damit begonnen das Deployment mit Ansible abzubilden. Auch vorher konnten wir Wikis automatisiert bereitstellen, jedoch mit einer self-made Lösung.

In mehreren Workshops haben wir an einer Umstellung des Deployments auf Ansible gearbeitet, um insbesondere

  • weniger „Eigenbau“-Lösungen im Haus zu betreiben
  • schnellere Einarbeitung in das Deployment durch eine bekannte Technologie zu ermöglichen
  • eine gemeinsame Schnittstelle zwischen Dev und Ops zu etablieren

 

Die Durchführung:

Bislang ist die Erfahrung ausgesprochen positiv. Unser Deployment-Tooling konnten wir innerhalb von 5 Tagen in einem Team von 4 Personen auf Basis von Ansible abbilden.

Nach einem ersten Workshop in Münster konnten wir alle Skripte so umstellen, dass wir unser Standard-Produkt mit Ansible vollständig bereitstellen konnten. Auch Updates konnten wir mit Hilfe von Ansible Skripten im Nachgang weitgehend automatisieren.

Die reine Bereitstellung der Enterprise-Wikis ist jedoch deutlich weniger komplex als die Bereitstellung und das regelmäßige Deployment unserer Cloud-Infrastruktur.

Unser 2. Hackathon in Münster hatte daher das Ziel, einen Proof-of-Concept für eine zukunftsfähige, skalierbare Cloud-Infrastruktur zu erarbeiten

Nach einer ersten Analysephase haben wir entschieden einen containerbasierten Ansatz zu wählen.

Folgende Vorteile sehen wir in einem containerbasierten Ansatz auf Basis von Docker:

  • Ein Container-Ansatz zwingt uns das Gesamtsystem Service-orientiert zu denken
  • Richtig umgesetzt, kann das Gesamtsystem sehr einfach horizontal skaliert werden
  • Mit Kubernetes / Docker Swarm / Rancher und Co gibt es mittlerweile Umgebungen die einen professionellen Betrieb einer containerbasierten Infrastruktur ermöglichen
  • Docker ist etabliert und macht es dadurch einfach mit externen Partnern zusammenzuarbeiten

 

Vor dem Hackathon konnten wir schon mit Ansible einen (virtuellen) Cluster aufbauen und einzelne Komponenten wie Solr und PostgreSQL als externe Services betreiben. Außerdem wurde mit GlusterFS ein verteiltes Dateisystem eingebunden, sowie ein Hochverfügbarkeits-Proxy (HAProxy) vor mehrere Q.wiki Instanzen geschaltet. Der Proof-of-Concept war erreicht, als Anfragen im Round-Robin-Verfahren an die einzelnen Instanzen durchgeleitet und auf dem gleichen Datenbestand gearbeitet wurde.

Wir wussten somit, dass die geplante Architektur im Groben funktioniert. Mit dem Einsatz von Containern veränderten sich jedoch die Anforderungen:

  1. In einem Container sollte immer nur ein Prozess ausgeführt werden. Wenn dieser Prozess stirbt oder endet, kann durch ein Container-Managementsystemen, wie z.B. Kubernetes, der Container einfach neu instanziiert werden.
  2. Container sind immutable, d.h. Änderungen der Konfiguration zur Laufzeit sind zu unterbinden

 

Das Deployment mit Containern hat aus den 3 genannten Punkten einerseits neue Anforderung an die Basis-Software gestellt, aber auch dazu geführt, dass wir uns der Architektur und der Verbindung zwischen den Komponenten viel mehr bewusst geworden sind.

Abschließend konnten wir nach 5 Tagen intensiver Arbeit einen Prototypen auf der Basis von OpenShift bereitstellen, der das Q.wiki in die Breite skalieren lässt. Auch wenn wir teilweise einen recht langen Atem brauchten, bin ich nach den Workshops davon überzeugt, dass das Denken in Containern hilft, eine bessere Software-Architektur zu erreichen.

Also, Mission accomplished – naja fast 🙂

Fazit:

Ein Container-Ansatz für Q.wiki ist möglich und hilft mehr Struktur in den gesamten Software-Aufbau zu bringen. Da die und Skalierungs-Anforderungen bei Q.wiki aus IT-Sicht nicht sehr groß sind, muss jedoch geprüft werden, ob es sinnvoll ist eine „Container-Management“ Ebene wie Kubernetes zu integrieren. Die Erfarung der Hackathons zeigt, dass Kubernes und Openshift zwar sehr viele Möglichkeiten bietet, aber auch zusätzliche Komplexität in einem Projekt entsteht.

Hier muss nun abgewogen werden, ob die Vorteile größer als die Nachteile der Komplexität sind oder ob es nicht reicht einen etwas „abgespeckten“ Ansatz – zumindest für die ersten Schritte – zu wählen.

@Modac Team DevOps: Now it´s your turn – Viel Erfolg!!!