Automatisierung in der Cloud: Alles über Orchestration

Jan Rose, Fotolia

Orchesterprobe

Automatisierung etabliert sich im IT-Umfeld allerorten, auch – oder gerade – in der Cloud. Hier heißt das Schlagwort: Orchestrierung.
ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Wann ist Arbeit eigentlich effizient? Die meisten werden Arbeit dann für effizient halten, wenn sich durch möglichst geringen Einsatz möglichst viel Ertrag erzielen lässt – freilich ohne dass die Qualität des Produktes leidet und man so Kunden (oder Arbeitgeber) vergrault. In der IT gilt seit geraumer Zeit Automatisierung als ein willkommenes Werkzeug, um diesem Ziel ein gutes Stück näher zu kommen. Die Grundidee besteht darin, regelmäßige Aufgaben automatisch zu erledigen, statt einen Mitarbeiter damit zu beschäftigen, damit der sie manuell ausführt. Mittlerweile existiert eine stattliche Anzahl gut funktionierender Werkzeuge für allgemeine Automatisierungsaufgaben: Man denke an Puppet, Chef oder Ansible – sie alle buhlen um die Gunst der Nutzer.

Im IT-Umfeld haben sich gerade Service-Provider die Automatisierung zunutze gemacht, speziell auch solche, die Cloud-Services anbieten. Schließlich können sich Anwender in einer gut geplanten öffentlichen Wolke nach Herzenslust selbst bedienen und brauchen den Service-Provider bloß noch dann persönlich in Anspruch zu nehmen, wenn mal etwas schief läuft. Aus Provider-Sicht sind Clouds insofern ein Segen, denn sie erlauben dem eigenen Personal an sinnvollen Neuerungen statt an den ewig gleichen Routineaufgaben zu arbeiten.

Automatisierung auf Blech

Was für Anbieter paradiesisch klingt, ist für Anwender zunächst nicht ganz so erfreulich. Denn die meisten liebgewonnenen Automatisierungswerkzeuge tun in der Cloud nicht gar so gut ihren Dienst. Das liegt an den verschiedenen Konzepten, die physikalischen und virtuellen Systemen quasi inhärent sind: Ein physischer Server ist ein definiertes Stück Hardware, das in der Regel für einen spezifischen Zweck angeschafft und auch eingesetzt wird. Hat der Server es erstmal ins Rack geschafft, bleibt er in der Regel dort.

Für die Automatisierung ergeben sich hieraus gleich mehrere Konsequenzen. In einem Virtualisierungs-Framework lässt sich ein physischer Server statisch behandeln; anhand der MAC-Adressen seiner Netzwerkkarten lässt er sich über PXE automatisiert installieren, und über Puppet, Chef oder eine der diversen anderen Lösungen verpasst ihm der Anbieter eine spezifische Konfiguration.

Ganz anders sieht es mit virtuellen Maschinen aus, die Cloud-Kunden als Bestandteil ihrer Infrastruktur verwenden. Zunächst sind Cloud-VMs häufig volatil: Einmal aus einem vorgebauten Image gestartet, verschwinden sie unter Umständen schon bald wieder, wenn sie nicht mehr benötigt werden. Fällt eine aus, ist sie leicht zu ersetzen. Reparieren lohnt sich hier in der Regel also nicht.

Hinzu kommt, dass sich VMs kaum sinnvoll mit den üblichen Konfigurationswerkzeugen automatisieren lassen. Auf der einen Seite werden Puppet, Chef & Co. ja immer erst dann aktiv, wenn die VM schon läuft; sie helfen dem Benutzer aber nicht dabei, eine große Menge benötigter VMs zu starten. Denkbar wäre zu Testzwecken eine Webserver-Farm, auf der sich die neue Version einer Website austesten lässt. Und es wäre zwar technisch möglich, jeder manuell gestarteten VM mit Puppet & Co. eine spezifische Aufgabe zuzuteilen, doch ist es eher mühsam, für 20 gestartete VMs jeweils einen Puppet-Eintrag anzulegen und sie dann mittels Puppet-Agent entsprechend zu verarzten.

Automatisierung à la Cloud

Effektive Automatisierung in der Wolke bedingt also ein anderes Vorgehen als fürs Blech. Amazon hat sich als Vorreiter im Cloud-Segment quasi eine eigene Lösung gestrickt, die aus Automatisierung kurzerhand Orchestrierung macht und deutlich besser auf Cloud-Verhältnisse zugeschnitten ist. Über die AWS-CloudFormation managen Admins VMs in ihrer Wolke effizient und schnell. Das Prinzip gefiel selbst den OpenStack-Entwicklern so gut, dass sie eine CloudFormation-Engine auch für ihr Projekt bauten, die mit Amazons Version sogar kompatibel ist ( Abbildung 1 ). Im Folgenden vermittelt dieser Artikel einen Eindruck der Orchestrierungsmöglichkeiten in privaten und öffentlichen Clouds auf Grundlage von AWS-CloudFormation – die AWS-Version und die OpenStack-Komponente sind dabei mit Blick auf grundlegende Funktionen ebenbürtig.

Abbildung 1: In OpenStack zeichnet Heat für die Orchestrierung verantwortlich. Der Dienst besteht aus einer Processing-Engine und verschiedenen APIs, die sowohl Amazons CFN-Format als auch das native Heat-Format HOT verstehen.

Voraussetzung für eine funktionierende Orchestrierung sind im Wesentlichen die Funktionen, die Clouds ohnehin schon zur Verfügung stellen. Denn das sich ein Nutzer am webbasierten Service-Portal einloggen und eine VM starten kann, ist ja durchaus auch ohne Orchestrierung kein Problem. In aller Regel genügt es, den gewünschten VM-Typ im Hinblick auf die virtuelle Hardware sowie das gewünschte Betriebsystem auszuwählen. Nach einem abschließenden Klick und ein paar Sekunden Wartezeit steht das neue System bereits zur Verfügung. Etwaige Sonderwünsche sind auch möglich – so ist es kein Problem, eine VM direkt von persistentem Speicher zu starten oder ihr nach dem Starten eine öffentliche IP zuzuteilen, damit sie aus dem Internet erreichbar ist.

Es soll also keineswegs der Eindruck entstehen, Orchestrierung erfinde all diese Funktionen neu; ganz im Gegenteil: Orchestrierung zielt darauf ab, die vorhandene Funktionalität automatisch nutzbar zu machen. Technisch gelöst ist das sowohl bei Amazon als auch bei OpenStack Heat – der Orchestrierungslösung von OpenStack – über eine sogenannte Template-Engine.

CloudFormation

Benutzer verfüttern an diese Engines Textdateien (Templates), die in einer spezifischen Syntax Befehle enthalten; die Template-Engine setzt die Befehle um und führt über die Cloud-Funktionen die gewünschten Aktionen aus ( Listing 1 enthält ein Beispiel-Template). Spannend ist dabei insbesondere die Frage, wie umfassend die jeweilige Template-Engine die angebotenen Funktionen der Cloud unterstützt, denn nicht jede Funktion lässt sich automatisch auch zum Teil von Orchestrierungs-Templates machen. Nur wenn die Policy es zulässt, ist eine bestimmte Aufgabe in der Cloud auch tatsächlich automatisierbar.

Listing 1

Amazon-CloudFormation-Template (Teil 1)

 

Im AWS-Kontext steht freilich die CloudFormation-Engine von Amazon mitsamt der dazugehörigen Template-Syntax im Fokus der Anwender. Im Web ist häufig nur von CFN-Templates die Rede, wenn es um den Amazon-Dienst geht. De facto ist CloudFormation auch die Engine mit den meisten Features. Gekrönt wird der Dienst von einer ausführlichen Dokumentation, die jede einzelne Funktion im Detail erläutert und in den Kontext anderer Funktionen stellt.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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 /2022