javamagazin 10 | 2016

© iS

tock

phot

o.co

m/C

emO

zora

l

magazinJAVA

Mag

www.javamagazin.de

Dropwizard: Eine zauberhafte Lösung S. 71

Domain-driven Design: Micro - services lieben DDD S. 62

Java 8: Benutzer definierte Stream Sources S. 16

Ausgabe 10.2016

Programminfos

ab Seite 35!

Java | Architektur | Software-Innovation

Security agil verankernPlädoyer für eine Securitykultur

javamagazin 10 | 20162 www.JAXenter.de

AgileSonderdruck

© Software & Support Media GmbH

von Michael Hausenblas, Mario-Leander Reimer und Andreas Zitzelsberger

Die Kernaufgabe von Mesos ist das Scheduling von Con-tainern im Cluster. Mesos führt die Container dabei auf den Cloud-Knoten zuverlässig und ressourcenschonend aus. Rescheduling erfolgt bei Bedarf, z. B. beim Ausfall einer Ressource oder wenn alternative, passendere Res-sourcen frei werden. Dann wird die Ausführung eines Containers auf eine andere Ressource verlagert. Mesos abstrahiert dabei die konkrete Infrastruktur hin zu Res-sourcen wie Rechenleistung, Netzwerk oder Storage. Der Nutzer von Mesos übergibt lediglich einen Contai-ner zur Ausführung. Ob dieser dann in einer lokalen vir-tuellen Maschine, einer privaten oder öffentlichen IaaS Cloud oder auf klassischen Server Racks ausgeführt wird, verbirgt Mesos. Ebenso vermittelt Mesos je nach Bedarf Netzwerkverbindungen und Storage Mounts. Ziel ist, mehrere Mandanten und Anwendungen im Cluster genauso einfach und effektiv zu betreiben wie auf einem lokalen Rechner, damit die verfügbaren Res-sourcen möglichst effektiv genutzt werden können.

Zusammenspiel mit einem Cluster-OrchestriererMesos ist ein Cluster-Scheduler. Wie spielt Mesos mit einem Cluster-Orchestrierer zusammen? Das Zusam-menspiel (Abb. 1) lässt sich am einfachsten erklären,

Teil 4: Eine Einführung in Apache Mesos

Das Betriebssystem der Cloud Apache Mesos ist der Kernel für verteilte Systeme. Es bietet Anwendungen analog zum klassischen Betriebssystemkernel einheitliche Schnittstellen, um Ressourcen im Clus-ter zu verwalten und an Anwendungen zu vermitteln. Mesos ist der Kernbestandteil von DC/OS, einem Betriebssystem für die Cloud. Im Rahmen dieses Artikels geben wir eine Einführung in Mesos und zeigen, wie man die beispielhafte Spring-Cloud-Anwendung Zwitscher auf DC/OS zum Laufen bringt.

Artikelserie

Teil 1: Der Cloud-Native-StackTeil 2: Cloud-native Anwendungen bauen mit Spring Cloud und Netflix OSSTeil 3: Cloud-native Anwendungen mit KubernetesTeil 4: Eine Einführung in Apache Mesos

Hintergrundinformationen zu Mesos und DC/OS

Mesos wurde vom RAD Lab der University of California entwickelt und das erste Mal 2009 veröffentlicht [1]. 2011 war Mesos bereits deutlich fortgeschritten [2] und wurde von Twitter adaptiert. Mittlerweile setzen auch Airbnb, Apple und viele weitere auf Mesos und betreiben damit Cluster mit zehntausenden Rechnern. Seit 2013 ist Mesos ein Top-Level-Projekt der Apache Software Foundation.DC/OS steht für Data Center Operating System [3]. DC/OS erweitert Mesos als Kernel um zusätzliche Funktionalität mit dem Ziel, ein vollwertiges, integriertes Betriebssystem für die Cloud zu bieten. Das System wurde im April 2016 von Mesosphere unter der Apache-2.0-Lizenz freigegeben und bietet unter anderem:

■ Einen DNS-Service für Service Naming und Discovery

■ Ein Command Line Interface sowie ein webbasiertes Administrations-UI

■ Ein Package Repository mit diversen vorgefertigten An-wendungs- und Infrastrukturpaketen

■ Frameworkintegrationen von Marathon und Chronos für langlaufende und zeitgesteuerte Services

javamagazin 10 | 2016 3www.JAXenter.de

AgileSonderdruck

© Software & Support Media GmbH

wenn wir die Analogie zum klassischen Betriebssystem betrachten. Im klassischen Betriebssystem gibt es Aus-führungseinheiten wie Prozesse und Threads und dar-über Anwendungen. Eine Anwendung kann aus vielen Ausführungseinheiten bestehen, die alle möglichen Ab-hängigkeiten, Querbeziehungen und Eigenheiten mit-bringen.

Der Kernel des Betriebssystems kennt nur Threads und Prozesse und weiß nichts von Anwendungen. An-wendungen werden von zusätzlichen Komponenten wie einem init-System für Services (sytemd oder initd) oder einem Applikationsserver gesteuert. Im Cluster erfüllt Mesos die Rolle des Kernels und bietet Ressourcenma-nagement und -Scheduling. Mesos kennt als Ausfüh-rungseinheit Tasks, weiß aber nichts von Anwendungen. Ein Task ist die Ausführung eines Docker-Containers oder eines Shell-Kommandos. Anwendungen werden vom Orchestrierer gesteuert.

Wie funktioniert Mesos?Mesos setzt eine Master-Slave-Architektur um (Abb. 2). Es gibt einen Master, der Agenten verwaltet, die auf je-dem Knoten (Worker-Node) im Cluster laufen. Mesos-Frameworks führen Tasks auf diesen Agenten aus. In Abbildung 2 sind zwei Frameworks in weiß dargestellt: Eines für Hadoop und eines für MPI. Ein Framework be-steht aus zwei Komponenten: einem Scheduler, der sich am Master anmeldet, um Ressourcenangebote zu erhal-ten, und einem Executor, der die tatsächliche Ausfüh-rung der Tasks übernimmt. Die Frameworkschnittstelle ist auch die Schnittstelle zum Cluster-Orchestrierer. Ma-rathon oder auch Kubernetes laufen als Frameworks im Mesos-Cluster. Mesos implementiert außerdem zwei-stufiges Scheduling (Two-Level-Scheduling, Abb. 3).

Stufe 1: Der Ressourcen-Scheduler kennt alle ver-fügbaren Ressourcen und darf diese allokieren. Er nimmt Ressourcenanfragen (Specifications) entgegen und unterbreitet entsprechend einer Scheduling Policy Ressourcenangebote (Offers). Dabei nutzt Mesos stan-dardmäßig DRF (Dominant Resource Fairness, [5]) als Algorithmus. Dieser Algorithmus ist auf Fairness ausge-legt und verhindert, dass sich Tasks mehr als die ihnen fairerweise zustehenden Ressourcen erschleichen. Somit können auf einem Mesos-Cluster viele unterschiedliche Anwendungen und Mandanten in friedlicher Gemein-schaft betrieben werden. In Mesos hat der Master die Rolle des Ressourcen-Schedulers inne.

Stufe 2: Der App-Scheduler nimmt Tasks entgegen, übersetzt diese in Ressourcenanfragen und nimmt pas-sende Ressourcenangebote an. Der App-Scheduler ist nicht Bestandteil von Mesos und wird als Teil eines Frameworks anwendungsspezifisch ergänzt. Auf einem Mesos-Cluster können mehrere Frameworks gleichzei-tig betrieben werden.

Im Kasten „Mesos-Frameworks kurz vorgestellt“ fin-den Sie eine Übersicht herausragender Frameworks für Mesos. Eine längere Liste von Frameworks findet sich unter [6].

Erste Schritte: Hands-on MesosFür unsere ersten Schritte mit Mesos wollen wir DC/OS Vagrant [15] einsetzen. Dies erlaubt uns, einen vor-konfigurierten kompletten DC/OS-Cluster auf einer Maschine hochzufahren (Abb. 4). Alternativ ist es z. B. auch möglich, den Showcase mit DC/OS auf Amazon AWS oder einem anderen Provider auszuführen. Das Set-up und die Systemvoraussetzungen findet man in der DC/OS-Vagrant-Deployment-Anleitung  [16]. Für den Showcase sollte das Zielsystem mindestens 16 GB Speicher besitzen. Wir verwenden die Communityversi-on 1.7.0 von DC/OS [17]. Zusätzlich benötigen wir für die Beispiele das DC/OS CLI [18]. Nach der Installati-on von DC/OS Vagrant erzeugen und starten wir einen Cluster mit einem Management-Node, drei Worker-Nodes und einem Bootstrap-Node:

$ vagrant up m1 a1 a2 a3 boot

Abb. 1: Der Cloud Native Stack: Mesos, Kubernetes, Spring Cloud

Abb. 2: Die Architektur von Mesos [4]

Abb. 3: Zweistufiges Scheduling in Mesos

javamagazin 10 | 20164 www.JAXenter.de

AgileSonderdruck

© Software & Support Media GmbH

Nachdem die Nodes laufen, lässt sich unter http://m1.dcos/ die DC/OS-Management-Oberfläche aufru-fen. Die DC/OS-Community-Edition verwendet per De-fault externe OAuth-Quellen wie Google, GitHub oder Microsoft. Der erste angemeldete Nutzer wird zum Su-peruser und kann weitere Nutzer hinzufügen.

Zwitscher auf Mesos und Marathon ausführenAls nächsten Schritt packen wir unseren Zwitscher-Showcase auf Mesos. Wir setzen als Framework Marathon ein. Netterweise bringt unser fertiger Cluster schon ein vorkonfiguriertes und integriertes Marathon mit. Wir tun dies exem-plarisch am Beispiel des Zwitscher-Eureka-Service. Als Erstes benötigen wir eine Marathon-Konfiguration für den Service. Die Konfiguration ist ein JSON, das über das DC/OS CLI oder das Marathon-REST-API an Marathon geschickt wird. Für die Marathon-Konfiguration gibt es eine ausführliche Dokumentation unter [19].

In der Konfiguration (Listing 1) sind der Ressourcenbedarf, hier nur CPUs und Speicher, der Pro-grammtyp ("container" mit "type" : "DOCKER") und die Settings für den Health Check definiert. Im Zwitscher GitHub finden sich Konfigurationen für sämtliche Ser-vices [20]. Diese Konfiguration ent-hält eine Besonderheit: Da wir für die Discovery des Eureka-Service Mesos-DNS über die DNS-Schnitt-stelle einsetzen wollen, können wir keine dynamischen Ports verwen-den. Mesos-DNS ist in unserem DC/OS-Vagrant-Cluster schon vor-konfiguriert.

Die Zeile "portMappings" legt daher fest, dass der Marathon-Port 1:1 nach außen durchgereicht wird. Me-sos kümmert sich selbstständig darum, dass die Con-tainer nur auf Nodes ausgeführt werden, die passende freie Ports haben. Damit können wir den Eureka-Service einfach über den Hostnamen referenzieren:

Abb. 4: Laufendes DC/OS

Abb. 5: Marathon mit laufendem Config-Service

Mesos-Frameworks kurz vorgestellt

■ Marathon [7] eignet sich speziell zur Steuerung langlaufender Prozesse. Marathon ist einfach zu benutzen und in DC/OS fertig integriert. Es ist als Metaframework konzipiert, kann also andere Frameworks wie Chronos steuern.

■ Kubernetes [8] ist der Cluster-Orchestrierer, obwohl es noch neu ist. Kubernetes wurde im letzten Java Magazin vorgestellt [9]. Leider gibt es zum Zeitpunkt der Erstellung dieses Artikels kein fertiges Paket des Kubernetes-Frameworks für Apache Mesos [10].

■ Chronos [11] ist ein Scheduler zur Steuerung zeitgetriebener Tasks und damit das Cluster-Äquivalent zu cron in Unix.

■ Apache Aurora [12] ist ein Framework, das sowohl langlaufende als auch zeitgesteuerte Tasks unterstützt und damit eine vollwertige Alternative zu Marathon und Chronos ist. Aurora kommt von Twitter und zielt auf sehr große Installationen ab, ist aber auch deutlich komplexer zu benutzen als Marathon und Chronos.

■ Jenkins [13] verdient eine spezielle Erwähnung. Jenkins wird meist als Continuous-Integration-Server bezeichnet, ist aber tatsächlich ein sehr leistungsfähiger Orchestrierer für Batch-Jobs. Mit dem Me-sos-Jenkins-Plug-in [14] ist Jenkins in der Lage, beliebige Batches und natürlich auch CI-Builds im Cluster zu verteilen und zu steuern.

javamagazin 10 | 2016 5www.JAXenter.de

AgileSonderdruck

© Software & Support Media GmbH

"dependencies" : [ "zwitscher-eureka" ], "env": { "eureka.host": "zwitscher-eureka.marathon.mesos"}

Lassen Sie uns nun den Config-Service über die Mara-thon CLI starten:

$ dcos marathon app add zwitscher-config/marathon-zwitscher-config.json

Der Status kann entweder über die CLI oder die Mara-thon-Weboberfläche beobachtet werden:

$ dcos marathon app listID MEM CPUS TASKS HEALTH DEPLOYMENT CONTAINER CMD/zwitscher-config 512 0.1 0/1 0/0 scale DOCKER None

Nun ist es Zeit für einen Kaffee, da Mesos/Marathon/Docker den Container erst herunterladen, instanziieren und den Microservice starten muss. Das Ganze geht we-sentlich schneller, wenn der Container bereits im Clus-ter verfügbar ist. Nach einiger Zeit springt die Anzeige auf den Status Running, und der Health Bar wird grün (Abb. 5).

Die anderen Services können analog deployt werden, alternativ findet sich im Zwischter GitHub ein kleines Skript namens marathon-deploy-all.sh, das sämtliche Services auf einen Rutsch deployt. Marathon unterstützt auch das Anlegen von Applikationen über das Web-UI. Nach ein paar Minuten schaut die Applikationsüber-sicht in Marathon dann aus wie in Ab-bildung 6.

Der Zwitscher-Cluster läuft nun. Als Test können wir das Zwitscher-Board über den Edge-Service aufrufen. Dazu öffnen wir den Edge-Service im Ma-rathon-UI (Abb. 7). Unter den Nodes wird jeweils die IP:PORT-Kombinati-on des Node angezeigt. Diese können wir einfach im Browser aufrufen. In Produktion würden wir einen Load Bal-ancer vorschalten, der die Nodes der Edge-Services anspricht.

Zwitscher-Service skalierenWir wollen nun unseren Zwitscher-Service skalieren. Über das DC/OS CLI geht das schnell:

$ dcos marathon app update zwitscher-service instances=2Created deployment ca7e50f0-ad1b-4172-91e0- 50061cf78242

Ressourcennutzung in DC/OS und die Auslastung des Nodes, den Mesos für die Instanz auswählt, steigen. Dank Eureka war es das dann auch. Die Auf-rufe der anderen Komponenten werden automatisch per Round-Robin an die

Serviceinstanzen verteilt. In der Eureka-Weboberfläche tauchen beide Instanzen des Zwitscher-Service auf. Bei den anderen Services funktioniert das ganze analog, nur die Discovery von Eureka selbst läuft über Mesos-DNS. Auch über das Marathon-REST-API kann skaliert wer-den. Prinzipiell ist es möglich, beliebige automatische

Abb. 6: Marathon mit allen Zwitscher-Services

Abb. 7: Details des Zwitscher-Edge-Service in Marathon

Listing 1

{ "id": "zwitscher-eureka",

"instances": 1, "cpus": 0.1, "mem": 512,

"container": { "type": "DOCKER", "docker": { "image": "qaware-oss-docker- registry.bintray.io/zwitscher/ zwitscher-eureka:1.0.1", "network": "BRIDGE", "portMappings": [ { "hostPort": 8761, "containerPort": 8761, "protocol":

"tcp", "servicePort":8761} ] } },

"healthChecks": [ { "protocol": "HTTP", "path": "/admin/health", "intervalSeconds": 10, "portIndex": 0, "timeoutSeconds": 10, "maxConsecutiveFailures": 3 } ]

}

javamagazin 10 | 20166 www.JAXenter.de

AgileSonderdruck

© Software & Support Media GmbH

Skalierungs-Use-Cases zu bauen, diese müssen aber in-dividuell programmiert werden. Mögliche Beispiele:

• Automatisch in Abhängigkeit von den Requests/Se-kunde skalieren

• Niedrig priorisierte Batch-Jobs starten, wenn der Cluster wenig ausgelastet ist

• Dynamische AWS-Instanzen bestellen, provisonieren und Anwendungen mit niedrigen Datenschutzbedarf erlauben, diese über Mesos zu nutzen

Fehlertoleranz messenWir simulieren nun einen Ausfall eines unserer Service. Dazu verbinden wir uns per vagrant ssh mit dem Node, auf dem eine der Eureka-Instanzen läuft. Das Passwort ist vagrant. Dann finden wir mit docker ps heraus, wel-cher Docker-Container den Eureka-Service enthält, und anschließend benutzen wir docker kill, um den Contai-ner zu stoppen. Nach einem kurzen Augenblick können wir im Marathon-UI sehen, dass die Instanz als down er-kannt wird und eine neue Instanz gestartet wird, um das Soll wieder zu erreichen. Danach stoppen wir den Node a2 oder a3. Dazu nutzen wir vagrant halt a3. Der Node wird in dem DC/OS-UI zunächst als N/A markiert. DC/OS wartet darauf, dass der Node wieder erreichbar wird. Nach Ablauf einer Grace Period wird der Node entfernt, und die Tasks auf dem Node werden auf die anderen No-des verteilt. Wird der Node anschließend wieder hochge-fahren, wird er nach kurzer Zeit von Mesos erkannt und wieder in den Cluster mit aufgenommen.

FazitMit Apache Mesos und DC/OS steht ein leistungsfähi-ges Betriebssystem für die Cloud frei zur Verfügung. Der Stand der Dinge ist vergleichbar mit den ersten Linux-Ver-sionen: Noch nicht perfekt und manches wird noch ver-misst, aber ein deutlicher Schritt vorwärts. Zum Beispiel wären ausgereifte Cluster-Diagnosefunktionen hilfreich. Dafür stehen aber völlig neue Möglichkeiten bereit, auch sehr große und verteilte Anwendungslandschaften be-herrschbar zu machen. Anhand des Zwitscher-Showcase konnten Sie sehen, wie eine Microservice-Anwendung auf Mesos deployt werden kann. Dabei spielt Mesos elegant mit dem bestehenden Stack aus Docker und Spring Cloud zusammen. Die Anwendung kann unverändert bleiben, sie muss nichts davon wissen, dass sie auf Mesos läuft, und Mesos selbst verrichtet geräuschlos und effektiv sei-nen Dienst, so wie man es von einem Kernel erwartet.

Michael Hausenblas ist Entwickler und Cloud Advocate bei Me-sosphere. Er hilft AppOps dabei, verteilte Cloud-native Applikatio-nen zu entwickeln und zu betreiben. Mesosphere ist ein weltweit tätiges Softwareunternehmen, welches DC/OS entwickelt und maßgeblichen Anteil an der Entwicklung von Apache Mesos hat.

Mario-Leander Reimer ist Cheftechnologe bei der QAware. Er ist Spezialist für den Entwurf und die Umsetzung von komplexen Sys-tem- und Softwarearchitekturen auf Basis von Open-Source-Techno-logien.

Andreas Zitzelsberger ist Cheftechnologe bei der QAware GmbH, einem IT-Projekthaus mit Schwerpunkt auf Cloud-nativen Anwen-dungen und Softwaresanierung. Er konzentriert sich auf moderne Big-Data-Architekturen, leichtgewichtige Enterprise-Integration und Diagnose und Stabilisierung von komplexen Systemen.

Mit Apache Mesos und DC/OS steht ein leistungsfähiges

Betriebssystem für die Cloud frei zur Verfügung.

Links & Literatur

[1] A Common Substrate for Cluster Computing: http://usenix.org/legacy/event/hotcloud09/tech/full_papers/hindman.pdf

[2] Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center: http://people.csail.mit.edu/matei/papers/2011/nsdi_mesos.pdf

[3] DC/OS Communityseite: https://dcos.io/

[4] Mesos-Architekturdokumentation: http://mesos.apache.org/documentation/latest/architecture/

[5] Dominant resource fairness: https://www.usenix.org/legacy/events/nsdi11/tech/full_papers/Ghodsi.pdf

[6] Übersicht über auf Mesos aufsetzende Software: http://mesos.apache.org/documentation/latest/frameworks/

[7] Marathon Communityseite: https://mesosphere.github.io/marathon/

[8] Kubernetes Communityseite: http://kubernetes.io/

[9] Adersberger, Josef; Reimer Mario-Leander: „Frühlingswolken“, in: Java Magazin 6.2016

[10] Kubernetes-Mesos-Framework: https://github.com/mesosphere/kubernetes-mesos

[11] Chronos Communityseite: https://mesos.github.io/chronos/

[12] Apache-Aurora-Seite: http://aurora.apache.org/

[13] Jenkins-Homepage: https://jenkins.io/

[14] Mesos-Jenkins-Plugin auf GitHub: https://github.com/jenkinsci/ mesos-plugin

[15] DC/OS Vagrant auf GitHub: https://github.com/dcos/dcos-vagrant

[16] DC/OS Vagrant Deployment-Anleitung: https://github.com/dcos/ dcos-vagrant/blob/master/docs/deploy.md

[17] DC/OS Community Releases: https://dcos.io/releases/

[18] DC/OS-CLI-Installation: https://docs.mesosphere.com/1.7/usage/cli/install/

[19] Marathon Create and Start and Application REST API Documentation: https://mesosphere.github.io/marathon/docs/rest-api.html#post-v2-apps

[20] Zwitscher-Showcase auf GitHub: https://github.com/qaware/cloud-native-zwitscher

QAware GmbHinfo@qaware.de

Aschauer Straße 3281549 MünchenTel.: +49 (0) 89 23 23 15 - 0

Rheinstraße 4D55116 MainzTel.: +49 (0) 6131 215 69 - 0