CFN-Templates im Detail

Welche Möglichkeiten haben Autoren, um eigene CFN-Templates zu entwickeln und so das Starten spezifischer Stacks zu vereinfachen? Jedes CFN-Template folgt einer gewissen Grundstruktur. Das Beispiel in Listing 1 macht deutlich, dass zunächst die Version des CFN-Standards anzugeben ist, der das Template folgt (ähnlich wie bei anderen Dokumenttypen gibt es auch von CFN mehrere Releases, sodass die Versionsangabe dazu dient, die Kompatibilität mit der konkreten Version einer Template-Engine sicherzustellen). Danach folgt eine kurze Beschreibung des Templates. Die Beschreibung besteht aus frei wählbarem Text und wird später auch bei den Eigenschaften des Stacks angezeigt, sobald mit dem Template ein solcher gestartet worden ist.

Dann folgen die Parameter, über die sich spezifische Eigenschaften eines Stacks steuern lassen ( Abbildung 3 ). Parameter gibt es in unterschiedlichen Varianten, den spezifischen Typ legt das gleichnamige Feld ("Type") fest. Strings geben Cloud-Nutzern die Option, beliebige Zeichenketten an das Template zu liefern; sie sind die am häufigsten benutzten Parameter. Das Listing 1 zeigt, wie sich Parameter einsetzen lassen: Über sie bestimmt das Template beispielsweise die Hardware-Konfiguration der VM ("InstanceType") und den Namen des SSL-Schlüssels, den die neuen VMs mit auf den Weg bekommen ("KeyPairName"). Zudem lassen sich auch spezifische Parameter für Images bestimmen, die dann direkt an die VMs weitergegeben werden und dort zu entsprechenden Effekten führen.

Abbildung 3: Auch im Dashboard ist die Heat-Integration bereits vorhanden; der Stack erlaubt beim Starten die detaillierte Angabe vieler Parameter.

Mappings definieren benutzerspezifische Daten unter allgemeinen Labels. Beim Starten von VMs in Amazon ist es beispielsweise üblich, die Region, in der die VM laufen soll, mit anzugeben – genauso wie den Kernel, den das System verwendet. Durch die Mappings der standardisierten Ortsbeschreibungen wie "eu-west-1" auf eine Architektur und einen Kernel ("64" : "ami-534a2d52") legen Admins bereits im Template fest, welches Image und welcher Kern für welche Region zum Einsatz kommt. Unbedingt festlegen muss der Admin das aber im Template nicht; stattdessen kann er Nutzern auch die Wahl lassen, selbst ein geeignetes Image beim Starten eines Stacks auszuwählen.

Ressoucenbedarf

Der wichtigste Abschnitt im ganzen Template ist zweifellos der Abschnitt, der mit »Resources« betitelt ist.

Denn der legt fest, welche Dienste die Engine beim Starten eines Stacks in OpenStack aufruft. Von zentraler Bedeutung ist an dieser Stelle insbesondere »AWS:EC2:Instance« , das eine neue virtuelle Maschine startet. Anwender können bei diesem Vorgang Metadaten angeben, welche die VMs per HTTP-Request anschließend vom Cloud-Metadaten-Server abfragen. Metadaten sind im Cloud-Kontext ein sehr wichtiges Werkzeug – interpretiert die VM sie wie gewünscht, dann lässt sich über Metadaten das Verhalten von VMs noch steuern, nachdem sie gebootet wurden.

Am Ende des Templates findet sich der »Outputs« -Absatz; dieser legt fest, welche Eigenschaften des Stacks die Template-Engine für die einzelnen VMs exponiert, also gesondert anzeigt und beispielsweise auch abfragbar macht. Im vorliegenden Beispiel lassen sich alle Features, die der Admin den VMs beim Start mit auf den Weg gegeben hat, zu jedem späteren Zeitpunkt über die Engine auch wieder in Erfahrung bringen.

Das dargestellte Template würde schließlich Windows-Instanzen starten; es handelt sich allerdings nur um ein generisches Beispiel und nahezu jede andere Kombination wäre denkbar. Auch geht das Beispiel nicht auf die Möglichkeiten ein, die sowohl Amazon als auch OpenStack Heat sonst noch so bieten: Wer in VMs mit Linux spezifische Pakete nach dem Booten installieren möchte, kann über einen entsprechenden Absatz im Template beliebige Shell-Befehle ausführen. Das ist nicht selten deutlich komfortabler als die Arbeit mit dem Metadaten-Server.

Auch die zuvor bereits erwähnten Skalierbarkeitsparameter wertet das Beispiel nicht aus – für die wäre im Template ebenfalls ein eigener Absatz fällig. Auch im »Resources« -Absatz sind Erweiterungen fast beliebig denkbar; CFN stellt viele Funktionen zur Verfügung, darunter eine, die einer neu gestarteten VM direkt eine öffentliche IP-Adresse umhängt – oder die festlegt, welches Tenant-Netz ein zu startender Stack verwenden soll. Eine umfassende Übersicht über die in CFN vorgesehenen Funktionen und Parameter bietet die AWS-CFN-Dokumentation auf [2] . Die meisten der dort vorgestellten Befehle funktionieren auch in Heat, das eine eigene Dokumentation unter [3] anbietet.