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.
Coremedia Blueprint
Unter dem Coremedia Enterprise Content Management System finden wir ebenfalls einen Stack mit vielen Komponenten:
- Contentserver
- Studio
- Preview CAE
- Delivery CAE
- Master Live Server
- Replication Live Server
- Solr Suchmaschine
- CAE Feeder
- MongoDB
- Workflowserver
Das sind 10 Dienste für eine Umgebung, wenn man noch Staging und Produktionsumgebung hinzurechnet kommt man leicht auf über 30 Dienste, die es zu verwalten gibt. Nicht eingerechnet, dass in der Produktion leicht 10 CAEs, mehrere Solrs und RLS Server laufen können. Ein Sammelsurium an Servern, Ports und Netzwerkdiensten, deren Verwaltung einiges den Administratoren abverlangt.
Im Blueprint von Coremedia befinden sich über 120 Maven Module. Hat man die richtigen Maven Befehle abgesetzt entstehen für die oben genannten Server zip oder rpm Artefakte, die dann manuell auf einen Server kopiert und installiert werden müssen. Das entsprechende Verfahren des Deployments ist von Coremedia nicht vorgegeben. Die Unterstützung hört an dieser Stelle auf und jedes Unternehmen muss seine eigene Deployment Pipeline erfinden.
Microservices
Microservices sind aktuell in der Softwareentwicklung und Softwareinfrastruktur sehr beliebt. Der Begriff beschreibt im Grunde die Aufteilung von einer Anwendung in kleinere Einheiten die im Zusammenspiel ein Ergebnis erzeugen. Dabei sind die einzelnen Dienste möglichst selbständig und erfüllen eine konkrete Aufgabe. Ursprünglich im Umfeld von OSGi entstanden nutzen inzwischen auch andere Infrastruktur Konzepte den Begriff. Unter Coremedia Blueprint sind die einzelnen Dienste nicht so „klein“ geschnitten wie bei OSGi, jedoch ist es hilfreich die Dienste als Microservices zu betrachten. Microservices alleine sind ziemlich unnütz, erst im Zusammenspiel mit anderen Diensten erfüllen Sie ihren Zweck.
Microservices müssen orchestriert werden, damit sie ein Ganzes ergeben. D.h. Man muss die Möglichkeit haben zu beschreiben welche Dienste zusammen gehören und wie miteinander kommunizieren müssen. Idealerweise beschreibt man diese Zusammengehörigkeit in einer Datei, die dann von einem Framework als Infrastruktur automatisiert aufgebaut wird.
Bevor wir die einzelnen Komponenten in diesem Framework beschreiben müssen wir einen anderen Begriff erklären:
Infrastructure as Code
Wie wir schon erklärt haben wird hier die Server Infrastruktur in einer formalen Sprache in einer Datei beschrieben. Das Framework liest diese Datei und baut die Infrastruktur auf. Dabei spielt die Servervirtualisierung eine entscheidende Rolle worauf wir im nächsten Abschnitt näher eingehen. Die Verantwortung geht dabei mehr von den Administratoren zu den Entwicklern, da nun Infrastruktur eben als Code vorliegt. Es entsteht die neue Rolle des DevOps.
Docker
Docker ist eine Virtualisierungstechnologie die keinen Hypervisor nutzt wie z.B. VMWare. Sie ist eine Betriebssystem Virtualisierung speziell für Linux Systeme und basiert auf LXC. Diese sogenannten Linux Container isolieren auf Betriebssystem Ebene Prozesse und Prozessgruppen und nutzen den Kernel gemeinsam. Das Ergebnis sind sehr leichtgewichtige Container, ganz ähnlich zu dem chroot Konzept, welches eine Art „Jail“ für Prozesse darstellt. Anwendungen können dadurch sehr einfach auf dem selben Host in eigenen Containern gestartet werden und sind dabei völlig unabhängig voneinander.
Zentrale Konzepte sind bei Docker das Docker Image und der Docker Container. Das Image wird mit Hilfe einer Datei (Dockerfile) beschrieben. Diese Dockerdatei ist deklarativ und man beschreibt die Dienste und Programme die in einem Container zu Ausführung gebracht werden sollen. In unserem Fall befindet sich in einem Docker Image z.B. Ein Contentserver oder eine Solr. Dieses Image kann jetzt in eine Art Repository geladen werden und steht für andere Dienste zur Ausführung als Container bereit. Z.B. kann maven ein Modul im Blueprint bauen, das Docker Image erstellen und in ein Repository (im Docker Jargon Registry) laden. Auch kann man in der Dockerdatei festlegen, welche Ports die Anwendung nach aussen freigeben oder wie der Hostname lauten soll.
Images können voneinander erben. In dem Coremedia Beispiel haben wir z.B. Ein Image festgelegt, welches auf dem CentOS Betriebssystem basiert und die Tomcat7 Basisinstallation beinhaltet. Alle anderen Images erben von diesem Image und brauchen somit selbst kein Betriebssystem und Tomcat mehr installieren. Folgende Dienste sind als Docker Images beschrieben:
- Contentserver
- MLS
- RLS
- Workflowserver
- Preview cae
- Delivery cae
- Studio
- Solr
- Caefeeder
- MongoDB
Für jede dieser Dienste existiert im Rootverzeichnis im Blueprint ein Dockerfile. Per maven bauen wir umgebungsabhängig (dev, stage, live) den entsprechenden Dienst und erstellen gleichzeitig das Docker Image, welches dann noch in die Docker Registry gepushed wird.
Mesos
Mesos ist eine Clustersoftware, sie sorgt für die Verteilung von Diensten auf einer beliebigen Menge von Hardwarenodes. Mesos verwaltet dabei Betriebssystem Ressourcen und ist als verteiltes Linux Kernel anzusehen, der über beliebig viele Hardware Nodes Betriebssystem Ressourcen abstrahiert. Auf jedem Node läuft dabei ein Mesos Agent, der Betriebssystem Ressourcen auf jedem Node verwaltet/überwacht und dem Master Node meldet. Mesos ist hoch ausfallsicher mit zookeeper, der Ausfälle bemerkt und meldet. Dabei werden Ressourcen umallokiert. Mesos selbst bietet low level APIs zum steuern und allokieren von Betriebssystem Ressourcen.
Marathon
Eine etwas höhere Abstarktionsschicht bieten sogenannte Frameworks an, die in mesos installiert werden. Ein solches Framework ist Marathon. Marathon kann Applikationen auf verschiedene Nodes verteilen, Ausfälle registrieren und Applikationen auf einen anderen Node umallokieren. Dafür bietet es eine json API an, die per HTTP angesprochen werden kann. Die Json Dateien bieten eine deklarative Beschreibung der Ressourcen. D.h. man kann z.b. festlegen wieviel CPU, RAM, etc. die Applikation auf dem Host erhalten soll. Ein HTTP Aufruf sorgt dann dafür, dass die Applikation auf irgend einem Node im Cluster gestartet wird. Zusammen mit Docker eine ideale Kombination. In der Json Datei beschreibt man z.B. welche Docker Container für die Applikation wichtig sind und welche Ressourcen notwendig sind. Marathon/Mesos sorgen dafür, dass die entsprechenden Images aus der Docker Registry gepulled, auf einen Hardware Node kopiert und gestartet werden. Fällt der Dienst aus, sorgt Marathon dafür, dass Der Dienst auf einem anderen Node gestartet wird.
Weave Netzwerk
Das Konfigurieren eines Netzwerkes unter verschiedenen Docker Containern über verschiedene Hosts gestaltet sich relativ aufwendig. Hier hilft das Weave Projekt : Es produziert ein virtuelles Netzwerk zwischen Docker Containern auf verschiedenen Hosts. Das funktioniert sogar wenn gewünscht über das Internet und Firewall Grenzen hinweg, so als ob die Docker Container am selben physikalischen Switch hängen würden.
HAProxy
HAProxy fungiert als loadbalancer zwischen den Diensten: z.B. zu mehreren CAEs. Die Konfiguration des HAProxy erfolgt dabei automatisch durch Bamboo. Bamboo fragt die Marathon API nach Hosts und Ports für einen entsprechenden Dienst und generiert die HAProxy.cfg Datei, um HAProxy automatisch zu konfigurieren.
Elastic Search, Logstash, Kibana
Zum Auswerten von Logfiles benutzen wir den sogenannten ELK Stack bestehend aus Elastic Search, Logstash/Kibana. Hierbei werden z.B. Tomcat/Blueprint Logfiles per Logstash gelesen und in Elastic Search indiziert. Kibana nutzen wir als Dashboard zur Visualisierung.
Ziele
Folgende Ziele können mit der neuen Infrastruktur erreicht werden:
- Erhöhung der Entwickler Produktivität (Video)
- Continous Delivery von Features, damit mehr und schneller Features ausprobiert werden können
- Agilere Releases, Zero Downtime Releases (Video)
- Erhöhung der Qualität von Releases
- Stabilere Umgebungen
- Ausfallsicherheit
- Schnellere Fixes für Fehler
Auf Wunsch stellen wir Ihnen Referenzen bereit, um aus erster Hand zu erfahren wie andere die Produktivität in ihrem Coremedia Entwicklungsprozess mit Hilfe agiler Infrastrukturen erheblich steigern konnten.
