MANUELL WAR GESTERN – WIE IHR BESTEHENDE AWS-RESSOURCEN IN TERRAGRUNT IMPORTIERT

Ihr wolltet schon immer Provider eurer eigenen Datenplattform werden und euch auf die Nutzung datengetriebener Produkte sowie auf die Künstliche Intelligenz fokussieren? Wir von Fluxraum erklären euch wie ihr Schritt für Schritt die richtigen Prozesse etabliert, Tools sorgfältig auswählt und alle beteiligten Personen in die Produktentwicklung mit einbezieht. So besteht letztendlich die Möglichkeit, den Betrieb und die Weiterentwicklung eurer Datenplattform selbst zu verantworten. 

Zur erfolgreichen Umsetzung einer selbstbetriebenen Datenplattform vermitteln wir u.a. den Automate First Approach. Das bedeutet, wir versuchen Plattformen möglichst früh vollständig zu automatisieren, zu testen und den Plattform-Code so zu entwickeln, dass immer das gleiche Ergebnis erwartet werden kann. Durch die immer größer werdende Komplexität des Betriebs und der Entwicklung von Plattformen ist es erforderlich, diese reproduzierbar und nachhaltig abzubilden. Erfahrungsgemäß werden die ersten Schritte in Richtung Cloud via Lift and Shift-Strategie umgesetzt. Dieses Verfahren stellt im Kern zunächst kein Problem dar, da On-Prem-Applikationen durch hervorragende Dokumentation und vielerlei Hilfestellungen der Cloud Provider relativ schnell in die Cloud übertragen werden kann. Langfristig hat dieser Ansatz allerdings signifikante Nachteile, da die Gesamtarchitektur der Systeme von Grund auf neu gedacht werden muss, um hohe Folgekosten zu vermeiden. Ebenso muss ein Unternehmen die eigenen Arbeitsweisen, Prozesse und Methoden so an die Gegebenheiten anpassen, dass ein Cloud Native-Ansatz langfristig und nachhaltig funktionieren kann (vgl. Cloud Native Computing Foundation, 2021).

Mit der Zeit kommen auch Methoden wie DevOps ins Spiel, um Entwicklung und Betrieb enger miteinander zu verzahnen. Dabei muss das Unternehmen ein Bewusstsein dafür entwickeln, dass es nicht nur einen verantwortlichen DevOps Engineer gibt, sondern sich das gesamte Team nach den DevOps-Methoden richten muss. Eine der Kernelemente von DevOps ist die Automatisierung von (Cloud-) Infrastrukturen (vgl. Google Cloud, o.J.) Hierbei werden in modernen Umgebungen u.a. Infrastructure as Code Frameworks wie Terraform, Pulumi oder (AWS) CloudFormation verwendet, um die bereitgestellten APIs der Cloud Provider über eine Domain Specific Language (DSL) anzusteuern, die es erlaubt, Ressourcen in der Cloud via Code zu provisionieren. Hieraus ergibt sich gegenüber dem manuellen Erstellen von Cloud-Ressourcen eine Liste signifikanter Vorteile: Die gesamte Cloud-Landschaft ist dokumentiert, weniger fehleranfällig und immer wieder reproduzierbar, da der Code durch ein einfaches Ändern von Eingabeparametern für alle Umgebungen genutzt werden kann. Bei einem manuellen Prozess müsste jede Umgebung eins zu eins per Hand nachgestellt werden. Dies führt in den seltensten Fällen zum Erfolg und erzeugt darüber hinaus einen enormen Aufwand (vgl. Cloud Native Computing Foundation, 2021). Damit dieser Aufwand vermieden wird, haben wir uns bei Fluxraum aufgrund der hervorragenden Community, der Dokumentation und des mittlerweile hohen Reifegrades auf den Einsatz von Terraform spezialisiert. Da der Einsatz von Terraform allerdings Entwickler dazu zu zwingt Code mehrfach zu duplizieren und wir aber grundsätzlich den “Don’t Repeat Yourself”-Ansatz verfolgen, um die Komplexität von großen Code-Strukturen zu verringern, nutzen wir zudem Terragrunt als Wrapper für Terraform. Wir werden zukünftig – in einem weiteren Impuls – noch detaillierter auf Terragrunt eingehen und dort ausgiebig erläutern, warum Terragrunt sinnvoll ist und wie es dabei hilft, euren Code möglichst DRY zu halten, um eine saubere Code-Struktur zu etablieren.

Wie zuvor angeschnitten, sind wir davon überzeugt, dass es notwendig ist, schon möglichst früh damit zu beginnen, Cloud-Ressourcen in Code abzubilden, um zu vermeiden, dass nach einigen Monaten der Prozess des Imports von manuell erstellten Cloud-Ressourcen zu einer unlösbaren Aufgabe wird. Damit wir dieses Risiko trotzdem auffangen, möchten wir anhand des Beispiels einer manuell erstellten VPC (Virtual Private Cloud) in AWS (Amazon Web Services) zeigen, wie ihr diese mit den Bordmitteln von Terraform und Terragrunt einfach in eure Codebasis überführen könnt.

Disclaimer

Wir weisen ausdrücklich darauf hin für die folgenden Schritte eine Umgebung zu verwenden, die nicht als Produktivumgebung genutzt wird. Erstellt euch am besten in einem Test-Account Dummies, die im besten Fall vom Produktivsystem getrennt sind. Damit seid ihr auf der sicheren Seite!

Vorbereitung

Wir gehen davon aus, dass ihr das AWS Command Line Interface (CLI), Terraform und Terragrunt bereits installiert habt und die entsprechende Konfiguration der AWS Credentials vorgenommen habt, um über das Terminal mit der AWS API interagieren zu können. Solltet ihr diesen Schritt noch nicht erledigt haben, findet ihr Anleitungen zu den Installationsroutinen auf der jeweiligen Website der Hersteller. Alternativ könnt ihr auch auf ein Docker Image zurückgreifen, welches alle folgenden Tools bereits mitbringt. Dafür können wir euch dieses Docker Image empfehlen: 

Ansonsten folgt einfach den Installationsroutinen der folgenden Links:

Analyse der vorhanden VPC

Damit wir die vorhandene VPC nun in unseren Terragrunt Code importieren können, benötigen wir zunächst alle relevanten Informationen, die für den Import benötigt werden. Für den Import werdet ihr die VPC ID brauchen, welche ihr in der AWS Konsole unter VPC → VPCs findet. In unserem Beispiel lautet die VPC ID: vpc-0ec5eafbd3fa5fdee

Erstellen des Terragrunt Codes

Ordnerstruktur

Bevor wir beginnen, erstellen wir eine rudimentäre Projektstruktur, in welcher die Konfigurationen der nachfolgenden Abschnitte zu finden sind. Damit ihr die Projektstruktur nicht händisch anlegen müsst, haben wir euch ein Repository bereitgestellt, welches für den nachfolgenden Verlauf genutzt werden kann: 

Die Projektstruktur orientiert sich an einem bereits bestehenden GitHub Projekt und wurde für diese Demo leicht abgewandelt. Der Link dazu befindet sich im README des Repositories. 

Backend- und Provider-Konfiguration

Damit wir später die vorhandene VPC importieren können, benötigen wir zunächst den Terragrunt Code. Wir nehmen an dieser Stelle eine Minimalkonfiguration vor, bestehend aus Backend- und Provider-Konfiguration. Diese Konfigurationen beschreiben, wo der Terraform State abgelegt wird und welcher Cloud Provider verwendet wird. In unserem Fall nutzen wir S3 als Backend für das Terraform State File und AWS als Provider, da dies aus unserer Sicht die gängigste Kombination darstellt. Für die Backend- und Provider-Konfiguration verweisen wir an dieser Stelle auf die offizielle Terragrunt-Dokumentation. Ihr könnt die Informationen aber auch einfach aus diesem Repository entnehmen:

Die Backend- und Provider-Konfiguration befindet sich in der Datei terragrunt.hcl direkt unterhalb von terraform/

VPC-Modul und Modul-Referenz

Bevor wir mit dem Import von bestehenden AWS-Ressourcen beginnen können, ist es wichtig zu erwähnen, dass durch Terraform und Terragrunt keine Config Files erstellt werden. Es ist also Voraussetzung, dass wir bereits Code geschrieben haben, welcher die zu importierenden Ressourcen präsentieren soll. In diesem Fall benötigen wir also Code, welcher eine VPC in AWS erstellt. Da wir das Rad nicht neu erfinden müssen, bedienen wir uns an dieser Stelle an dem bereits bestehenden Terraform VPC-Modul in GitHub.

Jetzt müssen wir nur noch auf das Modul referenzieren und die vom Modul erforderlichen Eingabeparameter übergeben, indem wir unterhalb von terraform/environments/demo/eu-central-1/networking/vpc eine weitere terragrunt.hcl erstellen und den folgenden Codeschnipsel einfügen:

Plan ausführen

Damit wir ermitteln können, in welche Ressource des VPC-Moduls die VPC ID verknüpft und importiert werden kann, müssen wir initial “terragrunt plan” ausführen. Dadurch werden uns alle Ressourcen ausgegeben, die durch das VPC-Modul erstellt werden. Wir navigieren dazu in folgendes Verzeichnis “terraform/environments/demo/eu-central-1/networking/vpc” und führen den Befehl “terragrunt run-all plan” aus. Wir sollten nun neben vielen anderen Ressourcen im Output die VPC-Ressource finden, welche wir gleich für den Import verwenden können:

Wir notieren neben der VPC ID aus dem ersten Schritt den Ressourcenname aus dem Terragrunt Output: aws_vpc.this[0]

Terragrunt Import
Wir haben nun sowohl die VPC ID als auch den Ressourcennamen ermittelt, welcher durch das VPC-Modul kreiert wird. Um nun mit dem Import fortzufahren, kombinieren wir beide Werte und Importieren die bestehende VPC via:

Wenn der Import erfolgreich war, sollte euer Terminal folgendes ausgeben:

Terragrunt Import mit „Plan“ prüfen

Um nun zu prüfen, ob der Import auch wirklich erfolgreich war, führen wir erneut “terragrunt run-all plan” aus. Sollte der Import erfolgreich gewesen sein, wird die VPC im Terragrunt Output nicht mehr angezeigt, da sie nun der Kontrolle des Terraform States unterliegt und als Teil des Codes fungiert.

Und was ist mit den restlichen Ressourcen des Outputs?

Diese Ressourcen müssten ebenfalls importiert werden, sofern diese (und davon ist normalerweise auszugehen) bereits in AWS bereitgestellt wurden. Unsere Empfehlung ist an dieser Stelle, dass ihr eure Test-VPC ggf. weiter manuell ausbaut und weitere Ressourcen nach dem beschriebenen Vorgehen importiert. Dann bekommt ihr auf jeden Fall ein Gefühl für den Prozess und werdet feststellen, dass ihr immer sicherer werdet.

It’s a wrap!

Wir hoffen wir konnten euch einen kurzen, übersichtlichen Eindruck vermitteln, wie ihr mit modernen Methoden eure Cloud-Infrastrukturen in wenigen Schritten analysieren, importieren und schlussendlich in eure Codebasis überführen könnt. Falls ihr Fragen habt, Anregungen geben möchtet oder sogar Unterstützung bei der Modernisierung und Digitalisierung eurer (Daten-)Plattform benötigt, dann lasst es uns gerne wissen. Wir freuen uns auf euer Feedback!

Verweise

Cloud Native Computing Foundation (28.07.2021). Cloud Native Computing Foundation (“CNCF”) Charter. Abgerufen am 26. Juli 2022, von https://github.com/cncf/foundation/blob/main/charter.md 

Google Cloud (o.J.). DevOps Ressourcen. Abgerufen am 26. Juli 2022, von https://cloud.google.com/architecture/devops