Sicher verstaut - Deduplizierung spart Platz, Cloud-Backup für Windows, Areca sichert kostenlos. ADMIN 01/14 stellt Backups für Profis mit und ohne Cloud ... (mehr)

Modularer Aufbau

De facto besteht Cloudify also aus mehreren Teilen, und die Modularität der Lösung setzt sich wiederum auch bei den einzelnen Teilen fort, die gleichfalls aus mehreren Komponenten bestehen. Die Haupt-Engine ist zum Beispiel in der Lage, die Kommunikation mit einer spezifischen Public Cloud abzuwickeln, indem sie dafür einen eigenen "Cloud-Treiber" verwendet (Abbildung 3). Das richtet sich besonders an diejenigen Anwender, die Cloudify tatsächlich nutzen möchten, um damit die Orchestrierung von VMs in Public Clouds durchzuführen – vermutlich die große Mehrheit der Cloudify-Anwender. Die Zahl der unterstützten Clouds deckt dabei alle wichtigen Player ab: Amazon, Rackspace, Microsoft Azure, alles, was mit OpenStack kompatibel ist, HPs Cloud. Mit der gleichen Instanz von Cloudify ist es übrigens auch möglich, mehrere Public-Cloud-Zugänge zeitgleich zu verwalten, sogar Multi-Tier-Clouds sind möglich, also Installationen, die mehrere Public Clouds überspannen.

Abbildung 3: Ebenso kann die Cloudify-Shell eine echte Appliance im Rahmen einer Public Cloud deployen; die entsprechenden Treiber machen das möglich.

In der Cloudify-Engine verborgen existiert allerdings noch deutlich mehr Logik, welche die Benutzung des Werkzeugs sehr angenehm macht. Da wäre unter anderem die Tatsache, dass sich für einzelne PaaS-Anwendungen Lastgrenzen definieren lassen. Im laufenden Betrieb findet die Master-Instanz von Cloudify über eine eigene Logik heraus, welche Last auf den VMs mit der PaaS-Anwendung gerade anliegt. Übersteigt die vorhandene Last vom Admin festgesetzte Limits, kümmert sich Cloudify automatisch darum, dass mehr Instanzen der Applikation gestartet werden. So bleibt die Ladezeit für Benutzer der App auf einem erträglichen und akzeptablen Level, und dennoch ist das System automatisiert, erfordert also seitens des Admins kein Eingreifen.

Recipes

Technisch ist damit klar, wie eine Cloudify-Installation auszusehen hat, doch eine Frage ist unbeantwortet: Wie definiert der Admin die Eigenschaften einer PaaS-Plattform, sodass er darin nach dem Start seine Anwendung auch sicher betreiben kann? An dieser Stelle kommen bei Cloudify die Recipes ins Spiel, denn die legen genau jene Parameter fest.

Intern unterscheiden die Cloudify-Recipes zwischen mehreren Typen. Auf der einen Seite gibt es die Application-Recipes; eine Application in Cloudify ist quasi der Oberbegriff für alle Dienste, die zum Betrieb der Applikation notwendig sind. Soll beispielsweise eine Webplattform betrieben werden, die phpBB enthält, so könnte die Applikation »phpBB« heißen.

Ein Application-Recipe besteht aus den Definitionen mehrerer Services. Ein Service in Cloudify ist ein konkreter Dienst, beispielsweise »MySQL« , das im Beispiel notwendig sein könnte, um »phpBB« sinnvoll zu nutzen. Damit ein Dienst in Cloudify im Rahmen von PaaS verwaltbar ist, bedarf es also eines entsprechenden Service-Recipes, ein Füllhorn an Recipes für die meisten alltäglichen Anwendungen findet sich unter [1] (Abbildung 4). Wer seinen Kunden die Möglichkeit bieten möchte, einen Webserver zum Beispiel für das eigene Blog zu betreiben, wird mit diesen fertigen Recipes bereits glücklich werden – sollen allerdings spezifische Dienste in der Cloud ebenfalls automatisiert zu deployen sein, dann ist an dieser Stelle die Entwicklung eines Service-Recipes angesagt.

Abbildung 4: Über das Web-Interface lassen sich Recipes auswählen, die sich dann unmittelbar als Applikation starten lassen.

Service-Recipes haben eine verhältnismäßig komplexe Anatomie, so unterstützen sie sogenannte Lifecycle-Events, die wichtiger sind, als sie im ersten Augenblick wirken. Letztlich erledigen Lifecycle-Events das, was für das Deployment einer PaaS-Anwendung elementar ist: Sie sorgen dafür, dass – ausgehend von bestimmten Events (zum Beispiel Start/Stopp) einer Applikation – deren Service-Recipes die entsprechenden Befehle befolgen. Ein Recipe müsste also zum Beispiel beim Lifecycle-Event "Start" dafür sorgen, dass das Programm installiert ist und gestartet wird.

Auch auf die Begrifflichkeiten kommt es an: Die Cloudify-Entwickler trennen im Application-Kontext zwischen "Services" und "Service Instances". Letzeres ist eine konkrete Inkarnation eines Dienstes, während der Begriff "Service" die clusterweit verfügbaren Instanzen desselben Dienstes bezeichnet. "MySQL" als Service bezieht sich also auf alle Instanzen von MySQL, die zu einer Cloudify-Applikation gehören; eine "Service-Instanz" hingegen würde sich auf eine spezifische Instanz des Dienstes beziehen, die eindeutig identifizierbar ist.

Insgesamt ist das Prinzip der Recipes in Cloudify sehr umfassend und am Anfang zweifellos auch komplex; hilfreich zur Seite steht dann allerdings die Cloudify-Dokumentation [2], die neben ausführlichen Erklärungen auch konkrete Beispiele für die wichtigsten Themen enthält. Detailliert beschreibt Gigaspaces darin beispielsweise, wie sich über Recipes ein Tomcat- oder auch ein MongoDB-System als PaaS etablieren lässt.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite