CoreMedia

Das Design und die Frontend Entwicklung für eine Webseite wo nicht technische Nutzer den Inhalt editieren birgt einige Fallstricke. Es ist ein Unterschied, ob man die volle Kontrolle über den Output Markup hat oder nicht. Leider kommt bei CoreMedia Projekten häufig vor, dass Designer die nicht in den Tiefen eines Enterprise Content Managements stecken Dateien abliefern, die in Photoshop gut aussehen, aber nach der Überführung in CMS Templates und Befüllung mit echtem Content grausig aussehen. Ebenfalls ist es ein sehr großer Unterschied, ob Webdesigner oder Printdesigner ans Werk gehen. Es sind nun mal unterschiedliche Welten. Das Zauberwort heißt: Dynamik.

Alles was wir bis jetzt aufgesetz haben diente einem einzigen Zweck: Dem Continuous Delivery Paradigma – der Königs Diziplin. Continuous Integration ist vielen ein Begriff. Darin geht es darum, dass Code in einem Versionierungs System mit einem sogenannten CI Tools wie Jenkins gebaut und in einer Testumgebung gestartet wird. Das dient dem Zweck kontinuerlich zu prüfen, ob Code, repsektive die Features, die man gebaut hat im Gesamtsystem funktioniert, ob alle Komponenten zusammen noch funktionieren. Dieser Workflow soll helfen das Vertrauen aller Beteiligten in das System zu erhöhen und dadurch Releases schneller durchführen zu können. In der Software Entwicklung gibt es viele Abhängigkeiten von Libraries, Entwickler Code, Betriebssystem, Umgebung, Patches, Drittsystemen, etc. Mit CI soll die Integration all dieser Komponenten sicher gestellt werden.

In dem Film Terminator gibt es diese Super Humanoiden, die einfach nicht kaputt zu kriegen sind. Egal was man auf sie abfeuert, man kann zusehen wie das „Ding“ sich selbst heilt und dem Protagonisten weiter nachstellt. In dem Falle würde man sich natürlich wünschen, dass der Humanoid irgendwann kaputt geht, aber im Falle unserer CoreMedia Dienste wünscht man sich eher Terminator Fähigkeiten. Genau das wollen wir hier im Artikel an hand unseres Clusters zeigen.

In den vorherigen Artikeln haben wir gezeigt wie wir den Cluster aufgesetzt haben. In diesem Artikel werde ich demonstrieren wie ich einen Dienst manuell „kille“ und das Cluster selbständig für die Heilung des Dienstes sorgt. Am Anfang sieht der Dienst noch gut aus und der Health Status ist auf grün.

Führen wir uns noch einmal das Endziel vor Augen: Eine Umgebung, in der das Deployment von Features in CoreMedia schnell und unkompliziert von statten gehen kann. Eine Grundvoraussetzung hierfür ist ein Cluster, welches Docker Container orchestrieren kann. Es gibt auf dem Markt einige  Lösungen:

• Apache Mesos, bzw. DC/OS (eine erweiterte Produkt Variante von der Firma Mesosphere)
• Kubernetes (ursprünglich von Google entwickelt, jetzt Open Source)
• Docker Swarm
• Rancher
• Nomad (von HashiCorp, dem Hersteller von Terraform)
• Mantl
• etc.

Los geht es mit der Provisionierung der Infrastruktur von „0“ an. D.h. wir haben noch keine Server auf denen wir irgend etwas installieren können. Für unseren ShowCase nutzen wir das Tool Terraform, um Server in der Cloud zu starten. Als Cloud Provider nutzen wir Digital Ocean. Selbstverständlich können aber viele andere Provider genutzt werden wie Amazon Web Services, Google cloud Engine, Microsoft Azure, Redhat Openshift u.v.m.

Man unterscheidet Infrastruktur Provisonierung und Software Provisionierung. Für beide Kategorien gibt es Tools und meist beherrschen die Tools einer Kategorie ein paar Funktionen der anderen Kategorie. Terraform ist ein Tool aus der Kategorie Infrastruktur Provisionierung, es kann aber auch Software Provisonieren.

Der normale Start eines solchen Projektes bestand meist darin diese Fragen zu beantworten:

• Welche Dienste brauchen wir?
• Wieviele Redakteure werden das System nutzen?
• Wieviele User erwarten wir auf den CAEs?
• Brauchen wir Ausfallsicherheit und wenn ja in welchem Ausmaß?
• Wieviele Artikel, Bilder und sonstige Assets soll das System aufbnehmen können?
• etc.

All diese Metriken dienen dazu die entsprechende Hardware zu planen und zu bestellen. Dann vergehen meist mehrere Tage, wenn nicht Wochen bis die Hardware eintrifft oder im Rechenzentrum bereitgestellt werden kann. Dann machen sich die Admins, meist mit der Hilfe von Kollegen aus der Entwicklung, daran einen CoreMedia Strang (Dev) aufzuzetzen, damit die Entwickler loslegen können.

In einer früheren Artikel Serie haben wir die Vorteile einer Container basierten Infrastruktur für CoreMedia beleuchtet. In der Zwischenzeit haben wir eine ShowCase Umgebung aufgebaut, in der wir all diese Features Live und in Farbe dem interessierten Kunden vorführen können. Selbst für uns, die tagtäglich mit dieser Technologie zu tun haben, ist es jedes mal erstaunlich, wenn EIN Kommandozeilen Befehl eine Kaskade an Servern und Diensten (sprich: einen kompletten CoreMedia Serverstrang aus dem Nichts) in der Cloud hochfährt. Das dauert ganze 6 Minuten, oder ein Git Commit 10 Minuten später eine CAE Instanz mit dem neuen Code in der Cloud instanziiert, selbst verständlich ohne Downtime.

Jede Webanwendung besteht aus mehreren Komponenten, die im Zusammenspiel eine HTML Seite zur Anzeige bringen. Hier ein mögliches Beispiel:

• Apache Webserver
• Tomcat Applikationsserver
• Datenbank
• Caching layer
• Messaging Broker
• Suchmachine
• Etc.

All diese Komponenten müssen effizient miteinander kommunizieren. Meistens hat man aber einen solchen Stack nicht nur in einfacher Ausfertigung, sondern mehrfach vorliegen: Entwicklungsumgebung, Abnahmeumgebung (Staging) und Produktionsumgebung. In der Produktionsumgebung ist es darüber hinaus üblich von einigen Komponenten wiederum mehrere Instanzen zu besitzen zum Zwecke der Lastverteilung oder Ausfallsicherheit.