Weshalb Infrastruktur-Code nicht nur Konfiguration ist

Bei Infrastruktur-Code gestalten sich derartige Vorgehensweisen etwas anders und auch der Fokus von vielen Unit-Tests zu Integrationstests.

Wir beschreiben unser Zielsystem mit Code und diese Beschreibung wird dann mit dem Ist-Zustand abgeglichen. Weichen diese voneinander ab, müssen Aktionen ausgeführt werden, welche die Integrität wieder herstellen.

Beim Programmieren von Infrastruktur-Code werden verschiedene Ressourcen, Services und Komponenten miteinander verknüpft. Der Fokus liegt also primär auf der Integrationsebene, da je nach Konfigurations-Parametern und Abhängigkeiten das Gesamtsystem funktioniert oder nicht. Besteht das Beispielsystem aus einer App, welche Daten aus einer Datenbank liest und diese bereitstellt, so hilft es wenig, die Komponenten einzeln zu testen. Unit-Tests helfen zwar, Fehlkonfigurationen der Komponente oder Verstöße gegen die Compliance (zum Beispiel: eine Datenbank darf nicht in einem öffentlichen Netz stehen) zu finden. Das System funktioniert aber nur, wenn auch weitere Aspekte wie Firewalls, Netzwerke etc. korrekt konfiguriert sind. Wirklich aussagekräftige Ergebnisse über das System können also erst nach den Integrationstests getroffen werden.

Da Infrastruktur-Code deklarativer Natur ist, macht es oft keinen Sinn, ihn nur in Isolation zu testen. Dennoch gibt es eine Reihe an sinnvollen Tests, die auf Unit-Ebene durchgeführt werden sollten. Tools wie Terraform, CDK, Pulumi oder Cloudfront bieten Möglichkeiten der Interpolation, Schleifenkonstrukten und Schalter, welche den deklarativen Code dynamisch und dadurch weniger vorhersagbar machen. Das kann beispielsweise dazu führen, dass bestimmte Ressourcen, Einstellungen oder Komponenten abhängig von Variablen provisioniert werden oder nicht. Ein typischer Fall ist, wenn z. B. eine Web-Applikation-Firewall nur in der Produktion deployt und an den Loadbalancer gehängt werden soll. Durch einen umgebungsspezifischen Schalter wird hier also nicht nur zusätzliche Infrastruktur gebaut, sondern hat auch signifikanten Einfluss auf das Verhalten des Datenflusses. Gerade um unerwünschte Seiteneffekte bei Änderungen zu verhindern, ergibt es durchaus Sinn, Validierungen und Tests einzuführen, die solche dynamischen Deklarationen testen. Aber auch die semantische Bedeutung von Infrastruktur-Konfiguration kann von essenzieller Wichtigkeit sein und sollte durch Tests abgesichert sein. Benötigt ein System zwei separate Objektspeicher, so werden diese als Code zu großen Teilen identisch sein.

Listing 1: Flüchtiger Objektspeicher

resource "aws_s3_bucket" "bucket" {
 bucket = local.name
 acl    = "private"

 lifecycle {
   prevent_destroy = false
 }
}

Listing 2: Archiv Objektspeicher

resource "aws_s3_bucket" "bucket" {
 bucket = local.name
 acl    = "private"

 lifecycle {
   prevent_destroy = true
 }
}

Wird der eine Objektspeicher lediglich als flüchtiger Speicher zur Zwischenspeicherung von Daten genutzt und der andere aber als Langzeitarchiv, so sind die Anforderungen an die Sicherheit und Verfügbarkeit immens unterschiedlich. In so einem Fall würde es durchaus Sinn ergeben, den Archivspeicher so zu konfigurieren, dass er nicht unbeabsichtigt gelöscht werden kann. Mit einem Test kann gewährleistet werden, dass im Archiv entsprechende Konfigurations-Parameter gesetzt werden.

Ein weiterer Anwendungsfall, in dem Unit-Tests sinnvoll sind, sind Komponenten, die zur Infrastruktur gehören, aber eigene Erweiterungen der Zielplattform darstellen. Das könnte zum Beispiel eine Funktion sein, die auf bestimmte Events oder Ereignisse reagiert und weitere Prozesse, z. B. einen Alert in das firmenweite Messenger-System triggert. Es handelt sich hier um kleine Softwarekomponenten innerhalb der Infrastruktur-Definition, deren korrekten Funktionsweise essenziell für das Gesamtsystem ist und deren Funktionalität sich einfach mit Tests sicherstellen lässt.

Zur Integration von Systemen gehört es auch, Firewallregeln und ACLs zu definieren, damit Systeme über das Netzwerk miteinander kommunizieren können. Fehler oder zu offene Einstellungen können leicht zum Einfallstor für Angreifer werden und stellen ein hohes Risiko im System dar. Für viele Infrastruktur-Code-Tools gibt es Linter, die den Code analysieren und gegen Richtlinien prüfen können. Auf diese Weise lassen sich Compliance und Sicherheitsvorschriften automatisiert und schnell auf der Codebasis überprüfen. Mit Hilfe von Unit-Tests und Linting erhält man schnell und automatisiert ein erstes Feedback über Auswirkungen einer Änderung.

Im nächsten Schritt gilt es, die Infrastruktur und die Codebasis integrativ zu testen, hier sollte auch der Hauptfokus liegen, denn erst, wenn die Komponenten unserer definierten Infrastruktur auch im Zusammenspiel wie gewünscht funktioniert, kann die Anwendung darauf laufen. Der Webserver muss beispielsweise in der Lage sein, mit der Datenbank zu kommunizieren (vgl. Abb. 2). Dies lässt sich nur testen, indem wir die Infrastruktur irgendwo hin deployen. Hier gibt es verschiedene Möglichkeiten, zum einen bieten sich Test/Stage-Systeme an, die ein Abbild der Produktion darstellen. Wenden wir gegen ein solches System den Infrastruktur-Code an, lässt sich schnell feststellen, welche Änderungen vollzogen werden und in welcher Weise – also ob eine Downtime erforderlich ist oder nicht. Der Vorteil von Tests gegen existierende Umgebungen ist, dass solche Tests recht schnell durchgeführt werden können, da sich in der Regel nicht die gesamte Infrastruktur ändert, sondern lediglich ein Teil davon. Ein Nachteil ist, dass man nicht sicher sagen kann, wie sich Änderungen auf das Bootstrapping von Umgebungen auswirkt, also dem Neuaufsetzen von Grund auf. Ein weiterer Nachteil liegt bei den Kosten durch den permanenten Betrieb der Test/Stage-Systeme, aber dieser relativiert sich, wenn solche Systeme auch von den Entwicklungsteams mitgenutzt werden.

Es kommt bei der Wahl einer geeigneten Architektur stark auf den Kontext des Projektes an.

Es kann durchaus gewünscht sein, Systeme von Grund auf zu testen, etwa um Metriken wie Mean-Time-To-Restore permanent zu erheben oder die Disaster Recovery zu testen. Dabei werden alle Infrastruktur-Komponenten auf leeren Umgebungen neu erstellt und nach dem Test wieder entfernt. Tools wie Terratest für Terraform bieten solche Funktionalität und sorgen am Ende des Tests wieder dafür, dass die Ressourcen gelöscht werden. Durch das gesamte Bootstrapping des Systems ergeben sich deutlich längere Testdurchlaufzeiten im Vergleich zum inkrementellen Testen. Zusätzlich sollte man einen Mechanismus bzw. Prozess bereitstellen, der dafür sorgt, verwaiste Testinfrastruktur periodisch zu entfernen, um Kosten zu sparen. Zum ganzheitlichen Test des Systems können zusätzlich E2E- und Smoke-Tests unterstützen. Ziel ist es, das Zusammenspiel von Infrastruktur und Applikation unter möglichst realen Bedingungen zu testen.

In einer monolithischen Infrastruktur-Code-Basis kann das Gesamtsystem verwaltet werden, dazu zählt auch Basis-Infrastruktur wie etwa Netzwerksegmente, ACLs und Firewallregeln.

Der Vorteil hier liegt vor allem darin, dass sämtliche Ressourcen eines Systems an einer Stelle gepflegt und verwaltet werden. Dies erfordert allerdings in der Wartung und Entwicklung eine hohe Kompetenz und Wissen über ein breites Aufgabenfeld des verantwortlichen Teams. Es muss sowohl tiefes Wissen über die Anwendung selber, aber auch über die Gesamtinfrastruktur, in die diese eingebettet ist, vorhanden sein. Das kann schnell zur Gefahr werden und zu einer kognitiven Überlastung des Teams führen. Gerade bei größeren Projekten kann eine verteilte Architektur sinnvoll sein. Viele Tools für Infrastruktur-Code ermöglichen eine Trennung auf Artefaktebene: Das bedeutet insbesondere, dass Querschnittsthemen oder Ressourcen, die nicht zwingend direkt zur Anwendung gehören, wie zum Beispiel das Definieren von Netzwerksegmenten, als wiederverwendbare Artefakte bereitgestellt werden können. Der Vorteil hier ist eine einfache Abstraktion, die einen Großteil der Komplexität in der Verwendung verschleiert, außerdem können so einfach Compliance-Regeln und Strukturen vorgegeben werden.