Effizienter arbeiten mit AWS CloudFormation (2/3)
AWS-Trainer Rinon Belegu zeigt im zweiten Teil dieses Artikels, wie Sie mit AWS CloudFormation eine Definition aufbauen können.
Im letzten Blogbeitrag habe ich euch einen kleinen Einblick in AWS CloudFormation gegeben. In diesem zweiten Teil schauen wir uns den Aufbau einer Definition in AWS CloudFormation an.
Wie bereits erwähnt, handelt es sich hierbei nicht um eine Programmiersprache, sondern um eine beschreibende Sprache, die in verschiedene «Abteilungen» aufgeteilt ist.
Als Editor kann ich euch Visual Studio Code empfehlen. Er ist komplett Open Source und für verschiedenste Betriebssysteme verfügbar. Durch die Extensions könnt Ihr den Code mit verschiedensten Sprachen, wie z.B. JSON erweitern.
AWSTemplateFormatVersion
Die Section «AWSTemplateFormatVersion» ist optional, sie identifiziert jedoch die Version und «Möglichkeiten» des Templates. Im Moment ist nur die Version «2010-09-09» möglich und gültig. Diese Version ist losgelöst von der API-Version. Somit kann die Version unabhängig von der API angepasst werden.
Description
In der Description kann, wie es der Name schon sagt, eine Beschreibung zum Template angegeben werden. Die Sektion ist optional, muss jedoch, falls definiert, auf die Sektion «AWSTemplateFormatVersion» folgen.
Für die Description stehen uns bis zu 1024 Bytes zur Verfügung. Wenn ihr euch an den ersten Blogbeitrag zurückerinnert, wird uns die Description z.B. vor dem Ausführen des Templates angezeigt.
Metadata
In der Metadata Section kann ich zusätzliche Informationen zum Template zur Verfügung stellen, auf welche ich referenzieren kann.
Die Sektion ist optional, kann jedoch mit bestimmten Keywords auch dazu genutzt werden, cloud-init zu manipulieren.
Parameters
Jetzt wird es langsam spannend ?
In der Parameters Section kann ich Werte definieren oder einschränken, auf die ich beim Erstellen von Ressourcen referenzieren kann. Hierbei kann ich Sachen wie z.B. Default Werte und mögliche Werte definieren.
Wenn bei der Erstellung der Ressourcen auf diesen Parameter verwiesen und kein spezifischer Wert mitgegeben wird, so wird der in der Parameters Section definierte Default Wert verwendet.
Schauen wir uns ein paar Beispiele an:
Ich habe hier «InstanzType» als Parameter definiert. Dieser hat den Default-Wert von «t2.small» welches bei AWS eine Grössenbezeichnung für EC2 Instanzen ist.
Weiter habe ich die «AllowedValues» definiert. Dies bedeutet, dass es beim Deployen des Templates eine Restriktion gibt, die definiert, welche Instanz-Typen verwendet werden können. In unserem Beispiel sind das die EC2 Instanz Typen: t1.micro, t2.nano, t2.micro, t2.small, t2.medium, t2.large, m1.small, m1.medium.
Auf diesen Parameter kann ich später in der Definition von Ressourcen, welche erstellt werden, referenzieren und muss somit diese Parameter im Script nur einmal definieren. Falls eine Anpassung stattfindet, kann ich diese hier zentral verwalten. Die Parameters Section ist auch optional, hilft aber dabei, gewisse Definitionen nur einmal machen zu müssen.
Hier nochmal ein Beispiel zur Definition einer Datenbankklasse:
Mappings
Mit der Mappings Section, werdet ihr vermutlich sehr schnell in Kontakt kommen. Spätestens wenn ihr z.B. ein Script, welches EC2 Instanzen in verschiedenen Regionen erstellt, laufen lassen wollt. Jedes AMI-Image, auch wenn es das Selbe wie aus den von Amazon zur Verfügung gestellten ist, hat pro Region eine eigene «Registrierungs-ID». Das heisst, wenn ich beim Erstellen einer EC2 Ressource eine fixe ID für das Basisimage eintrage und das CloudFormation Template in einer anderen Region laufen lasse, so wird diese fehlschlagen.
Ich kann dem mit einer RegionMap entgegenwirken. So kann ich z.B. auf der linken Seite die AWS Region definieren und auf der rechten Seite welche Architektur und Image ID für die spezifische Region verwendet werden sollen.
Beim Erstellen der Ressourcen greife ich dann mit «Fn::FindInMap» auf diese Definition zu. Da CloudFormation weiss, in welcher Region es gerade das Template ausführt, nimmt es so den «definierten» Wert aus der Map.
Resources
Hier spielt die Musik. In dieser Sektion erstellen wir eine Wunschliste dazu, was und wie viel von einer Ressource CloudFormation erstellen soll.
Hier kann ich jetzt meine Parameter und Mappings zum Einsatz bringen.
Hier noch ein Beispiel der Erstellung einer Datenbankinstanz, mittels des vorher definierten «DBInstaceClass»-Parameters.
Ich hoffe, ich konnte euch einen besseren Einblick in die Thematik geben. Im letzten Beitrag werden wir uns noch die Bedingungen, Outputs und einige Spezialitäten anschauen.