Eine API, viele Clouds

© © Wolfgang Grossmann Wolfgang, 123RF

Anschlussfreudig

Heute bringt jede Cloud-Offerte ihre eigene, proprietäre API mit. Das birgt für den Anwender die Gefahr der Abhängigkeit von einem bestimmten Anbieter, weil eine Migration zur Konkurrenz nahezu unmöglich ist. Apache Deltacloud löst dieses Problem dank einer einheitlichen API für alle IaaS-Clouds, die sich so mit Treibern an öffentliche wie private Angebote anpassen lassen.
Security ist ein stets aktuelles Thema in der IT. Deshalb widmet sich das ADMIN-Magazin 04/2012 speziell Sicherheitsaspekten und gibt Antworten auf die Fragen: ... (mehr)

Zwar wird schon seit geraumer Zeit darüber diskutiert, doch haben sich beim Cloud Computing bislang keine Standards etabliert. Noch immer ist vieles in Bewegung. In den letzten Jahren entstanden eine Reihe öffentlicher Clouds wie Amazon Elastic Compute Cloud (EC2) [1] , Amazon Simple Storage Service (S3) [2] oder Jiffybox [3] . In den USA etwa kommen Anbieter wie Gogrid [4] , Rackspace [5] und Terremark [6] dazu. Clouds sind noch immer eine sehr junge Technologie, um Applikation und Dienste bereitzustellen. Jeder Betreiber und auch sehr viele proprietär ausgerichtete Technologielieferanten folgen ihren eigenen Vorstellungen und steuern die Applikationssicht auf ihre Weise. Dagegen wollen Unternehmen sich natürlich nur ungern an einen einzelnen Cloud-Anbieter binden. Interoperabilität, die einen Wechsel zwischen Cloud-Anbietern ermöglichen würde, ist daher besonders wichtig.

Privatwolken

Während es auf der einen Seite ein durchaus beachtliches Angebot öffentlicher Clouds gibt, haben auf der anderen Seite viele Unternehmen ihre privaten Clouds implementiert, die Applikationen und Computing Services über das eigene LAN/WAN bereitstellen. In den USA betreiben Unternehmen oft bereits Dutzende von Clouds, in Deutschland dagegen befinden sich viele noch im Experimentierstadium und nur wenige haben die ersten privaten Clouds tatsächlich im produktiven Betrieb. Reicht die Leistungsfähigkeit der internen Clouds nicht mehr aus, wäre es wünschenswert, zusätzliche Ressourcen öffentlicher Clouds nutzen zu können. Was dafür allerdings lange Zeit fehlte, war eine Möglichkeit, beide Welten miteinander zu verknüpfen.

Ein weiterer Aspekt des Themas Inter-operabilität besteht darin, dass sich unabhängige Softwarehersteller bei der Entwicklung neuer Anwendungen frühzeitig entscheiden müssen, in welcher der bestehenden Clouds ihre Software laufen soll. Das Erscheinen jeder neuen Cloud mit eigenem API verursacht hier zusätzlichen Aufwand. Es gibt daher gute Gründe, die für eine konsistente, standardisierte Cloud-Computing-API sprechen.

Auch wenn die Amazon-Cloud-Angebote wie EC2 oder S3 für ihre jeweiligen Einsatzgebiete bereits zweckdienliche APIs bereitstellen, sind sie dennoch keine generelle Lösung für andere öffentliche Clouds. Aus diesem Grund entschloss sich Red Hat im Herbst 2009, diese Lücke mit einem Open-Source-Projekt zu schließen, das sowohl ein einheitliches Interface definiert als auch Adapter für die wichtigsten öffentlichen und privaten Clouds implementiert ( Abbildung 1 ). Damit wird der Aufwand, neu erscheinende Clouds zu unterstützen, von den Applikationen zu ebendieser API, der Deltacloud, verschoben.

Abbildung 1: Apache Deltacloud stellt eine auf REST basierende API zur Kommunikation zwischen Clients und dem Deltacloud-Server (Deltacloud Core) zur Verfügung.

War Deltacloud anfangs ein originäres Projekt von Red Hat, wurden die bis dahin fertiggestellte Schnittstelle mit allem dazugehörigen Code im Frühjahr 2010 zur weiteren Bearbeitung an den Incubator der Apache Software Foundation [7] übergeben. Das Projekt wird dort unter der Bezeichnung Apache Deltacloud [8] fortgeführt. Damit ist die Herstellerunabhängigkeit gesichert. Ebenso wie andere Apache-Projekte wird auch Deltacloud von einer Vielzahl von Beteiligten aus unterschiedlichen Unternehmen und Organisation weiterentwickelt, die sich den Prinzipien offener Softwarelizenzen und einer benutzergesteuerten Innovation verpflichtet haben.

Eine REST-basierte Schnittstelle

Die Deltacloud-API ist als servicebasierte REST-Schnittstelle (Representational State Transfer) über HTTP implementiert, die einen Deltacloud-Server mit Daten versorgt. Um die Benutzung der REST-Schnittstelle zu vereinfachen, stellt das Deltacloud-Projekt sowohl ein CLI-Tool (Command Line Tool, Listing 1 ) als auch Client-Bibliotheken in Ruby, Java, C und Python zur Verfügung.

Listing 1

CLI-Beispielsitzung

 

Listing 1 zeigt, wie das CLI-Tool »deltacloudc« benutzt werden kann, um eine neue virtuelle Maschine anzulegen. In Zeile 1 wird die Environment-Variable »API_URL« so gesetzt, dass sie auf einen lokalen Deltacloud-Server zeigt. Die URL enthält auch Benutzernamen und Passwort für die Backend-Cloud – sie lassen sich alternativ aber auch mit den Umgebungsvariablen »API_USER« und »API_PASSWORD« setzen.

In Zeile 2 werden alle vorhandenen Images aufgelistet, deren Details in den Zeilen 3 bis 5 zu sehen sind. Ebenso werden die vorhandenen Hardwareprofile in Zeile 6 angefordert und in den Zeilen 7 bis 9 angezeigt. Zeile 10 schließlich legt eine neue virtuelle Maschine an, die auf dem Image »img1« beruht und deren virtuelle Hardware gemäß dem Hardwareprofil »m1-small« gewählt wird. Diese Operationen sehen für andere Backend-Clouds genau so aus, außer dass Benutzername und Passwort anzupassen sind.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023