JAVA Mag
Java 8: Benutzerdefinierte Stream Sources S. 16
Domain-driven Design: Microservices lieben DDD S. 62
Dropwizard: Eine zauberhafte Lösung
S. 71
magazin
Java | Architektur | Software-Innovation
Security
minfos Program 35! ab Seite
agil verankern
© iStockphoto.com/CemOzoral
Plädoyer für eine Securitykultur
www.javamagazin.de
javamagazin 10 | 2016 Ausgabe 10.2016
Sonderdruck Agile 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 Cluster 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.
von Michael Hausenblas, Mario-Leander Reimer und Andreas Zitzelsberger Die Kernaufgabe von Mesos ist das Scheduling von Containern 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 Ressourcen frei werden. Dann wird die Ausführung eines Containers auf eine andere Ressource verlagert. Mesos abstrahiert dabei die konkrete Infrastruktur hin zu Ressourcen wie Rechenleistung, Netzwerk oder Storage. Der Nutzer von Mesos übergibt lediglich einen Container zur Ausführung. Ob dieser dann in einer lokalen virtuellen 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 Ressourcen möglichst effektiv genutzt werden können.
Teil 1: Der Cloud-Native-Stack Teil 2: Cloud-native Anwendungen bauen mit Spring Cloud und Netflix OSS Teil 3: Cloud-native Anwendungen mit Kubernetes Teil 4: Eine Einführung in Apache Mesos
javamagazin 10 | 2016
Mesos ist ein Cluster-Scheduler. Wie spielt Mesos mit einem Cluster-Orchestrierer zusammen? Das Zusammenspiel (Abb. 1) lässt sich am einfachsten erklären,
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 TopLevel-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
Artikelserie
2
Zusammenspiel mit einem Cluster-Orchestrierer
■■ Ein Package Repository mit diversen vorgefertigten Anwendungs- und Infrastrukturpaketen ■■ Frameworkintegrationen von Marathon und Chronos für langlaufende und zeitgesteuerte Services
© Software & Support Media GmbH
www.JAXenter.de
Sonderdruck Agile Abb. 1: Der Cloud Native Stack: Mesos, Kubernetes, Spring Cloud
wenn wir die Analogie zum klassischen Betriebssystem betrachten. Im klassischen Betriebssystem gibt es Ausführungseinheiten wie Prozesse und Threads und darüber Anwendungen. Eine Anwendung kann aus vielen Ausführungseinheiten bestehen, die alle möglichen Abhängigkeiten, Querbeziehungen und Eigenheiten mitbringen. Der Kernel des Betriebssystems kennt nur Threads und Prozesse und weiß nichts von Anwendungen. Anwendungen 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 Ressourcenmanagement und -Scheduling. Mesos kennt als Ausführungseinheit Tasks, weiß aber nichts von Anwendungen. Ein Task ist die Ausführung eines Docker-Containers oder eines Shell-Kommandos. Anwendungen werden vom Orchestrierer gesteuert.
Abb. 2: Die Architektur von Mesos [4]
Wie funktioniert Mesos? Mesos setzt eine Master-Slave-Architektur um (Abb. 2). Es gibt einen Master, der Agenten verwaltet, die auf jedem Knoten (Worker-Node) im Cluster laufen. MesosFrameworks 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 besteht aus zwei Komponenten: einem Scheduler, der sich am Master anmeldet, um Ressourcenangebote zu erhalten, und einem Executor, der die tatsächliche Ausführung der Tasks übernimmt. Die Frameworkschnittstelle ist auch die Schnittstelle zum Cluster-Orchestrierer. Marathon oder auch Kubernetes laufen als Frameworks im Mesos-Cluster. Mesos implementiert außerdem zweistufiges Scheduling (Two-Level-Scheduling, Abb. 3). Stufe 1: Der Ressourcen-Scheduler kennt alle verfügbaren Ressourcen und darf diese allokieren. Er nimmt Ressourcenanfragen (Specifications) entgegen und unterbreitet entsprechend einer Scheduling Policy Ressourcenangebote (Offers). Dabei nutzt Mesos standardmäßig DRF (Dominant Resource Fairness, [5]) als Algorithmus. Dieser Algorithmus ist auf Fairness ausgelegt 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 Gemeinschaft 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 passende 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 gleichzeitig betrieben werden. Im Kasten „Mesos-Frameworks kurz vorgestellt“ finden Sie eine Übersicht herausragender Frameworks für Mesos. Eine längere Liste von Frameworks findet sich unter [6].
www.JAXenter.de
Abb. 3: Zweistufiges Scheduling in Mesos
Erste Schritte: Hands-on Mesos
Für unsere ersten Schritte mit Mesos wollen wir DC/ OS Vagrant [15] einsetzen. Dies erlaubt uns, einen vorkonfigurierten 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 Communityversion 1.7.0 von DC/OS [17]. Zusätzlich benötigen wir für die Beispiele das DC/OS CLI [18]. Nach der Installation von DC/OS Vagrant erzeugen und starten wir einen Cluster mit einem Management-Node, drei WorkerNodes und einem Bootstrap-Node: $ vagrant up m1 a1 a2 a3 boot
© Software & Support Media GmbH
javamagazin 10 | 2016
3
Sonderdruck Agile Zwitscher auf Mesos und Marathon ausführen Als 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 exemplarisch am Beispiel des ZwitscherEureka-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]. Abb. 4: Laufendes DC/OS In der Konfiguration (Listing 1) sind der Ressourcenbedarf, hier nur CPUs und Speicher, der Programmtyp ("container" mit "type" : "DOCKER") und die Settings für den Health Check definiert. Im Zwitscher GitHub finden sich Konfigurationen für sämtliche Services [20]. Diese Konfiguration enthält eine Besonderheit: Da wir für die Discovery des Eureka-Service Mesos-DNS über die DNS-Schnittstelle einsetzen wollen, können wir keine dynamischen Ports verwenden. Mesos-DNS ist in unserem Abb. 5: Marathon mit laufendem Config-Service DC/OS-Vagrant-Cluster schon vorkonfiguriert. Nachdem die Nodes laufen, lässt sich unter http:// Die Zeile "portMappings" legt daher fest, dass der m1.dcos/ die DC/OS-Management-Oberfläche Marathon-Port aufru1:1 nach außen durchgereicht wird. Mefen. Die DC/OS-Community-Edition verwendet per sos Dekümmert sich selbstständig darum, dass die Confault externe OAuth-Quellen wie G oogle, GitHub tainer odernur auf Nodes ausgeführt werden, die passende Microsoft. Der erste angemeldete Nutzer wird zum freieSuPorts haben. Damit können wir den Eureka-Service peruser und kann weitere Nutzer hinzufügen. einfach über den Hostnamen referenzieren:
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.
4
javamagazin 10 | 2016
■■ 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 Mesos-Jenkins-Plug-in [14] ist Jenkins in der Lage, beliebige Batches und natürlich auch CI-Builds im Cluster zu verteilen und zu steuern.
© Software & Support Media GmbH
www.JAXenter.de
Sonderdruck Agile "dependencies" : [ "zwitscher-eureka" ], "env": { "eureka.host": "zwitscher-eureka.marathon.mesos"}
Listing 1
Lassen Sie uns nun den Config-Service über die Marathon CLI starten: $ dcos marathon app add zwitscher-config/marathon-zwitscher-config.json
Der Status kann entweder über die CLI oder die Marathon-Weboberfläche beobachtet werden: $ dcos marathon app list ID 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 wesentlich schneller, wenn der Container bereits im Cluster 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übersicht in Marathon dann aus wie in Abbildung 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 Marathon-UI (Abb. 7). Unter den Nodes wird jeweils die IP:PORT-Kombination 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 skalieren
{
"tcp", "servicePort":8761}
"id": "zwitscher-eureka",
] } },
"instances": 1, "cpus": 0.1, "mem": 512, "container": { "type": "DOCKER", "docker": { "image": "qaware-oss-dockerregistry.bintray.io/zwitscher/ zwitscher-eureka:1.0.1", "network": "BRIDGE", "portMappings": [ { "hostPort": 8761, "containerPort": 8761, "protocol":
"healthChecks": [ { "protocol": "HTTP", "path": "/admin/health", "intervalSeconds": 10, "portIndex": 0, "timeoutSeconds": 10, "maxConsecutiveFailures": 3 } ] }
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 werden. Prinzipiell ist es möglich, beliebige automatische
Abb. 6: Marathon mit allen Zwitscher-Services
Wir wollen nun unseren ZwitscherService skalieren. Über das DC/OS CLI geht das schnell: $ dcos marathon app update zwitscher-service instances=2 Created deployment ca7e50f0-ad1b-4172-91e050061cf78242
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 Aufrufe der anderen Komponenten werden automatisch per Round-Robin an die
www.JAXenter.de
Abb. 7: Details des Zwitscher-Edge-Service in Marathon
© Software & Support Media GmbH
javamagazin 10 | 2016
5
Sonderdruck Agile Mit Apache Mesos und DC/OS steht ein leistungsfähiges Betriebssystem für die Cloud frei zur Verfügung. Skalierungs-Use-Cases zu bauen, diese müssen aber individuell programmiert werden. Mögliche Beispiele: • Automatisch in Abhängigkeit von den Requests/Sekunde 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
Mario-Leander Reimer ist Cheftechnologe bei der QAware. Er ist Spezialist für den Entwurf und die Umsetzung von komplexen System- und Softwarearchitekturen auf Basis von Open-Source-Technologien. Andreas Zitzelsberger ist Cheftechnologe bei der QAware GmbH, einem IT-Projekthaus mit Schwerpunkt auf Cloud-nativen Anwendungen und Softwaresanierung. Er konzentriert sich auf moderne Big-Data-Architekturen, leichtgewichtige Enterprise-Integration und Diagnose und Stabilisierung von komplexen Systemen.
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
Fehlertoleranz messen
[3] DC/OS Communityseite: https://dcos.io/
Wir 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, welcher Docker-Container den Eureka-Service enthält, und anschließend benutzen wir docker kill, um den Container zu stoppen. Nach einem kurzen Augenblick können wir im Marathon-UI sehen, dass die Instanz als down erkannt 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 Nodes verteilt. Wird der Node anschließend wieder hochgefahren, wird er nach kurzer Zeit von Mesos erkannt und wieder in den Cluster mit aufgenommen.
[4] Mesos-Architekturdokumentation: http://mesos.apache.org/ documentation/latest/architecture/
Mit Apache Mesos und DC/OS steht ein leistungsfähiges Betriebssystem für die Cloud frei zur Verfügung. Der Stand der Dinge ist vergleichbar mit den ersten Linux-Versionen: Noch nicht perfekt und manches wird noch vermisst, 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 beherrschbar 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 seinen Dienst, so wie man es von einem Kernel erwartet.
javamagazin 10 | 2016
[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] K ubernetes-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] M esos-Jenkins-Plugin auf GitHub: https://github.com/jenkinsci/ mesos-plugin [15] DC/OS Vagrant auf GitHub: https://github.com/dcos/dcos-vagrant
Fazit
6
Michael Hausenblas ist Entwickler und Cloud Advocate bei Mesosphere. Er hilft AppOps dabei, verteilte Cloud-native Applikationen 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.
[16] D C/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] M arathon Create and Start and Application REST API Documentation: https://mesosphere.github.io/marathon/docs/rest-api.html#post-v2-apps [20] Z witscher-Showcase auf GitHub: https://github.com/qaware/cloudnative-zwitscher
QAware GmbH
[email protected] Aschauer Straße 32 81549 München Tel.: +49 (0) 89 23 23 15 - 0
© Software & Support Media GmbH
Rheinstraße 4D 55116 Mainz Tel.: +49 (0) 6131 215 69 - 0
www.JAXenter.de
