Programmieren statt Konfigurieren: Infrastruktur als TypeScript-Code

Inhaltsverzeichnis

Infrastructure as Code (IaC) ist eine verbreitete Best Practice, bei der Code – statt manueller Prozesse – die Infrastruktur verwaltet und provisioniert. Dafür kommen bekannte Werkzeuge wie AWS CloudFormation oder Terraform zum Einsatz. Eines haben fast alle Werkzeuge gemeinsam: Sie nutzen eine Konfigurationssprache wie YAML zum Beschreiben der Infrastruktur. Damit gehen einige Herausforderungen einher, denn lückenhafte IDE-Unterstützung und umfangreiche Templates reduzieren die Übersichtlichkeit und Produktivität. In den letzten Jahren ist eine alternative Herangehensweise populär geworden. Eine neue Generation von IaC-Werkzeugen erlaubt es, Infrastruktur mit universellen Programmiersprachen zu beschreiben. Ein praktisches Beispiel stellt einen bekannten Vertreter näher vor: das Cloud Development Kit, kurz CDK. 

Was ist das Cloud Development Kit?

Das CDK ist ein Open-Source-Framework zum Definieren von Infrastruktur mithilfe bekannter Programmiersprachen wie Python, Java, Go, JavaScript und TypeScript. Nachfolgend liegt der Fokus auf dem Verwenden des CDK mit TypeScript. Die 2012 veröffentlichte Programmiersprache ist ein Superset von JavaScript und hebt sich vor allem durch ihre statische Typisierung ab.

Das Beschreiben der Infrastruktur mit Programmcode erlaubt TypeScript-Entwicklerinnen und -Entwicklern, in ihrer bekannten Entwicklungsumgebung zu arbeiten und auf hilfreiche Funktionen wie Autovervollständigung und Inline-Dokumentation zurückzugreifen. Zudem bietet das CDK zusätzliche Abstraktionen, genannt Constructs, zum Aufsetzen der Infrastruktur.

Funktionsweise des CDK

Nun geht es an das Verwenden des Cloud Development Kit, um Infrastruktur auf AWS zu modellieren. Hierzu ist es nötig, eine CDK-Anwendung in der gewünschten Programmiersprache zu schreiben, beispielsweise TypeScript. Eine CDK-Anwendung kann mehrere Stacks, also Gruppierungen von Infrastruktur, enthalten. Innerhalb eines Stacks instanziiert der Entwickler oder die Entwicklerin eine Reihe von Klassen, die die eigentliche Infrastruktur repräsentieren, wie beispielsweise eine virtuelle Maschine mit Amazon EC2 oder einen Objektspeicher wie Amazon S3. Diese Klassen heißen Constructs (siehe Abbildung 1). Sie können die Infrastruktur mit sinnvollen Voreinstellungen aufsetzen und typische Konfigurationen per Funktionsaufruf aktivieren. Das beschleunigt das Definieren der gesamten Infrastruktur und macht es leichter, Best Practices zu befolgen. Constructs können unterschiedlich komplex sein und entweder einzelne Infrastrukturkomponenten enthalten oder sogar ganze Architekturen. 

Danach wird das CDK CLI verwendet, um den Anwendungscode in ein CloudFormation-Template zu übersetzen. AWS CloudFormation ist ein Service, um Infrastruktur auf AWS deklarativ zu beschreiben und auszurollen. Das CDK CLI sendet das Template zum CloudFormation-Dienst, um die eigentliche Infrastruktur zu erstellen (siehe Abbildung 2). Das Interessante bei diesem Prozess ist, dass das CDK auf bestehende IaC-Werkzeuge aufsetzt.

Anwendungsbereiche für das CDK

Das Cloud Development Kit ist Open Source und in großen Teilen treibt eine offene Community seine Entwicklung voran. Heute existiert das CDK in verschiedenen Varianten, die jeweils unterschiedliche Clouds beziehungsweise Plattformen programmieren können. Initial hatte AWS es als AWS CDK ins Leben gerufen. Wie der Name erahnen lässt, liegt hier der Fokus auf der Modellierung von Infrastruktur und der Nutzung von Diensten in der AWS Cloud. Die Kernkomponenten von CDK verwendeten weitere Open-Source-Projekte wieder, um Kubernetes-Anwendungen (cdk8s) und Ressourcen mit Terraform (cdktf) mit dem gleichen Programmiermodell aufsetzen zu können. Damit deckt das CDK-Ökosystem eine sehr breite Auswahl an Plattformen ab. Wie beim AWS CDK generiert das zugehörige CLI die Templates aus dem geschriebenen Programmcode. Diese Templates lassen sich dann mit den nativen Funktionen der jeweiligen Werkzeuge beziehungsweise Plattformen ausführen. cdk8s synthetisiert YAML-Dateien, die das Kubernetes-Kommandozeilenwerkzeug kubectl direkt lesen und anwenden kann. cdktf synthetisiert Terraform-Templates im JSON-Format.

Infrastruktur erstellen in einem Praxisbeispiel

Dass das CDK mehr ist als die Übersetzung von Programmcode in Templates für CloudFormation, Kubernetes oder Terraform, demonstriert ein praktisches Beispiel. Es zeigt, wie die Constructs als Abstraktionen dienen können, um mit wenigen Zeilen Programmcode Architekturen mit sinnvollen Standardkonfigurationen aufzubauen.

Die Beispielarchitektur besteht aus einem Application Load Balancer, der über das Internet erreichbar ist. Er verteilt HTTP-Anfragen an eine Amazon EC2 Auto Scaling Group. Die Definition dieser Architektur mit Berücksichtigung einiger Best Practices schlägt sich – beim Verwenden von CloudFormation – in über 300 Zeilen YAML nieder. Es stellt sich die Frage, warum eine einfache Architektur schon so viele Zeilen Code benötigt. Die Antwort liegt darin, dass das in Abbildung 3 dargestellte Diagramm eine vereinfachte Sicht ist, die eine Menge zusätzlich zu definierender Objekte und Einstellungen unterschlägt (siehe Abbildung 4).

Zum einen ist eine Amazon Virtual Private Cloud (VPC), die private Netzwerkumgebung, zu konfigurieren. Das erfordert viele Entscheidungen: Welcher IP-Adressbereich soll zum Einsatz kommen? Wie viele Subnetze soll es geben? In wie vielen Availability Zones, also diskreten Rechenzentren innerhalb einer AWS-Region, sind Subnetze zu erstellen? Gibt es öffentliche Subnetze, die vom Internet erreichbar sind, und private, die es nicht sind? Auf all diese Fragen gibt es Antworten in Form von Best Practices, die entweder bekannt oder zunächst zu recherchieren sind. Damit aber nicht genug: Zum anderen ist es anschließend nötig, die Einzelkomponenten zu konfigurieren und miteinander zu verbinden. So braucht es für die Kommunikation zwischen Subnetzen und mit dem Internet jeweils Routing-Tabellen. Je nachdem, ob es sich um ein öffentliches oder privates Subnetz handelt, enthalten die Routing-Tabellen eine Route zum Internet oder zum Network-Address-Translation-(NAT)-Gateway. Das NAT-Gateway benötigt noch eine Elastic IP, also eine öffentliche IP-Adresse, mit der es im Internet die privaten Hosts vertritt. 

Für den Application Load Balancer und die Auto-Scaling-Gruppe sind ebenfalls zusätzliche Objekte und Einstellungen anzulegen. Ein Aspekt sind die Security Groups, die als virtuelle Firewalls fungieren und entsprechend mit Regeln für ein- und ausgehenden Datenverkehr zu versehen sind. Die Vielzahl an Konfigurationsmöglichkeiten ist der Grund, warum eine auf den ersten Blick einfache Architektur zu einem über 300 Zeilen langen CloudFormation-Template wird.