Infrastructure as Code: Was steckt dahinter und warum lohnt es sich?

Was ist Infrastructure as Code?

In unserem Beitrag zur Teleport-Demoumgebung verweisen wir auf Infrastructure as Code – doch was verbirgt sich dahinter? Warum ist das Konzept interessant, warum sollte es Sie kümmern, und wie funktioniert es überhaupt?

Die Grundidee von IaC besteht darin, Infrastrukturbedarf und -konfiguration in Codeform zu erfassen. Dieser Code lässt sich in einer Versionsverwaltung ablegen, bei Bedarf abrufen und referenzieren – und vor allem lässt er sich mit wenig oder, bei richtiger Konfiguration, gar keinem manuellen Aufwand deployen.

Was heißt Deployment im IaC-Kontext? Das hängt von Tool und Domäne ab, lässt sich aber grob in zwei Kategorien einteilen. Auf der einen Seite steht imperatives IaC – etwa Ansible oder Puppet –, bei dem der Code eine Abfolge von Aktionen beschreibt, die nacheinander ausgeführt werden. Bei deklarativem IaC wie Terraform oder CloudFormation beschreibt der Code hingegen lediglich, was Sie haben möchten, und das Tool sorgt selbst dafür, dass dieser Sollzustand hergestellt wird.

Auf den ersten Blick mag der deklarative Ansatz überlegen oder zumindest einfacher zu schreiben klingen; in der Praxis werden beide Varianten jedoch in unterschiedlichen Kontexten eingesetzt. Deklarativer Code eignet sich hervorragend für Ressourcen, die sich jederzeit erzeugen und wieder verwerfen lassen, während der imperative Stil besser zu Kontexten wie dem Aufsetzen einer Maschine passt, bei denen die Interaktion mit dem Zielsystem – etwa über bash-Befehle – ohnehin sequenziell ist.

Und selbstverständlich lassen sich beide Ansätze kombinieren. Continuous-Integration- und Continuous-Deployment-Tools (CI/CD) wie GitHub Actions oder CircleCI sind zwar streng genommen kein „echtes” IaC, da sie weit mehr leisten als reines Infrastruktur-Provisioning, sie können jedoch sequenzielle Befehle ausführen, um deklarative Tools wie Terraform aufzusetzen und zu betreiben. So wird das Infrastruktur-Deployment zu einem vollständig menschenfreien Prozess.

Eine ähnlich vollständige Automatisierung lässt sich auch erreichen, wenn man konsequent auf den deklarativen Ansatz setzt. GitOps-Tools überwachen dabei sowohl den Code als auch die Infrastruktur und sorgen dafür, dass beide zu jeder Zeit übereinstimmen. Aber das ist ein Thema für einen eigenen Beitrag!

Warum sollte mich das interessieren?

Infrastructure as Code ist ein mächtiges Werkzeug, das Unternehmen an vielen Stellen weiterbringt: bei Effizienz, Zuverlässigkeit, Skalierbarkeit und Sicherheit. Sehen wir uns einige dieser Aspekte im Detail an.

Traue niemals einem Menschen

Zunächst einmal macht IaC menschliche Eingriffe überflüssig. Das hat mehrere Folgeeffekte; der unmittelbarste ist die Vermeidung von menschlichen Fehlern. Nehmen wir an, Sie müssen die Software Ihres Unternehmens auf eigenen Servern bei einem Public-Cloud-Anbieter wie AWS betreiben. Das lässt sich über „ClickOps” erledigen, indem sich ein Engineer durch die Cloud-Konsole klickt, Server anlegt und sich anschließend per SSH auf die Maschinen verbindet, um sie einzurichten.

Natürlich kostet das alles Zeit – vielleicht haben Sie diese Zeit auch eingeplant und sind bereit, sie zu investieren. Auf diesen Punkt kommen wir gleich noch zurück. Doch was passiert, wenn Sie sich mitten in der Arbeit verklicken? Sie könnten einen falsch dimensionierten Server anlegen und damit Ihre geschäftskritische Software ausbremsen – oder umgekehrt Geld verschwenden. Sie könnten den Server in der falschen Region, im falschen Subnetz, in der falschen Security Group oder VPC platzieren und ihn dadurch für die falschen Komponenten unerreichbar machen – oder ihn ausgerechnet für die falschen Komponenten zu erreichbar machen. Die möglichen Szenarien reichen von „ärgerlich” über „darüber müssen wir dringend mit dem Controlling sprechen” bis zu „wir sind gerade aus dem Markt geklagt worden”.

Nehmen wir aber an, Ihre Engineers wären brillant und machten nie Fehler. Selbst dann ist ihr Gedächtnis nicht perfekt. Angenommen, Sie haben eine Änderung an Ihrem System vorgenommen, die nun wieder zurückgedreht werden muss: Der Anwendungsfall ist weggefallen, eine Regulierung hat sich geändert, oder Sie versuchen, einer subtilen Störung auf die Spur zu kommen. Mit IaC genügt ein Blick in die Commit-Historie, um zu sehen, was genau wann geändert wurde – mit Commit-Messages, Blame-Informationen und weiteren Hinweisen, die dabei helfen, den Zusammenhang zu rekonstruieren. Sicher, bei rein manueller Arbeit lassen sich Notizen führen; nur werden diese schnell unübersichtlich, veralten, gehen verloren oder erleiden andere unschöne Schicksale. Klar strukturierte Commits sind da unbezahlbar.

Ein oft übersehener Nebeneffekt des Zeitaufwands und der Fehleranfälligkeit manueller Deployments: Wenn Sie manuell deployen, tun Sie es seltener. Warum sollte ich den Server neu aufsetzen, er läuft doch? Die neue Codeänderung deploye ich nächste Woche, ich habe gestern schon eine Stunde in das letzte Deployment gesteckt. Diesen Bug will ich jetzt nicht mehr anfassen, es ist Freitagnachmittag – lieber ein leicht kaputter Code über das Wochenende, als am Freitagabend alles komplett zu zerlegen. Und im Extremfall: Ich weiß, dass alles kaputt ist, aber es muss warten, weil der Kollege, der das deployen kann, krank ist.

Kennen Sie den Spruch „Have you tried turning it off and on again?”? Der ist nicht ohne Grund ein Klassiker: Es gibt unzählige Wege, auf denen Software aus einem stabilen Zustand geraten kann, und ein sauberes Zurücksetzen ist oft die zuverlässigste und effizienteste Rückkehr in gewohnte Bahnen.

Die Vorteile von Geschwindigkeit

Automatisierung liefert nicht nur Zuverlässigkeit, sondern auch Tempo. Verglichen mit Menschen, die sich manuell durch Konfigurationen hangeln oder Bash-Skripte ad hoc zusammenbasteln, beschleunigen Tools wie Terraform zwei Dinge. Erstens erlaubt IaC eine schnelle Definition dessen, was benötigt wird: Da das eingesetzte Tool konsistent bleibt und sich die (meist umfangreiche) Dokumentation zurate ziehen lässt, ist es eine Kleinigkeit, einen neuen Server zu definieren oder eine weitere Datenbank in das bestehende Netzwerk einzubinden.

Wichtiger noch: IaC ermöglicht ein schnelles Deployment des Codes. Das bedeutet weniger Wartezeit, bis etwas nutzbar ist – sei es für Tester, die Feedback geben, für Endanwender, die eine neue Funktion bekommen sollen, für Demonstratoren, die kurz vor der Präsentation noch ein Feature justiert haben, oder für viele andere Beteiligte. Selbst ein fehlgeschlagenes Deployment liefert schnelle Signale: Sie erfahren umgehend, dass ein Problem vorliegt und im Idealfall auch, wo – und können ohne Verzögerung in die Fehlerbehebung einsteigen.

Darüber hinaus bringen schnelle Deployments eine Reihe positiver Nebenwirkungen mit sich. Untersuchungen zu Hochleistungsteams haben die Four Key Metrics identifiziert, die auf eine hohe Produktivität von Teams hindeuten. Zwei davon sind die Deployment-Frequenz und die Mean Time to Restore nach einem Ausfall. Die Deployment-Frequenz hängt unmittelbar mit dem Aufwand (und, in geringerem Maße, der Zeit) eines Deployments zusammen, wie oben beschrieben; die Wiederherstellungszeit wird stark von vielen der bereits genannten Faktoren beeinflusst. Wer sich näher damit beschäftigen möchte, dem seien die Four Key Metrics ausdrücklich empfohlen.

Rauf skalieren, runter skalieren

Ein klar definierter Codestand mit automatisiertem Deployment bringt noch einen weiteren Vorteil mit sich: Skalierbarkeit. In einer manuellen Welt bedeutet mehr Ressourcen bereitzustellen häufig, den vollständigen Aufbauprozess für jede neue Maschine erneut zu durchlaufen. Ebenso müssen beim Herunterskalieren einzelne Maschinen gezielt zur Löschung ausgewählt werden.

Damit IaC beim Skalieren hilft, lassen sich Konfigurationen definieren – etwa Spezifikationen für virtuelle Maschinen oder Cloud Functions –, die es anschließend erlauben, per einfacher Anweisung mehr oder weniger Ressourcen abzurufen. Automatisierte Prozesse übernehmen den Rest, häufig ganz ohne zusätzliche Deployment-Schritte. Noch besser: Selbst diese einfachen Anweisungen lassen sich automatisieren, sodass die aktuelle Last überwacht und Ressourcen bedarfsgerecht erzeugt oder abgebaut werden – vollständig ohne menschliches Zutun. Damit werden auch heftige Lastspitzen – etwa beim Launch eines neuen Produkts – ohne dauerhafte Kostenbelastung beherrschbar.

Sicherheit durch Sichtbarkeit

Es gibt weitere Vorteile von IaC, doch der letzte, auf den wir hier eingehen, betrifft die Sicherheit. Der Zusammenhang ist etwas subtiler, aber im Kern gilt: Je mehr Personen Berechtigungen haben, Code zu deployen oder Infrastruktur zu ändern, desto mehr Wege gibt es, über die ein Angreifer diese Berechtigungen erlangen kann. Ihre Entwickler mögen schlicht unachtsam sein und Zugangsdaten in ein öffentliches Repository committen oder ihr Notebook kurz einer betriebsfremden Person überlassen. Oder der Angreifer geht proaktiv vor, greift per Phishing Zugangsdaten ab oder platziert eine Backdoor auf einem Entwickler-Rechner. Solche Risiken lassen sich mildern, doch im ständigen Wettlauf zwischen Angreifern und Verteidigern bleiben derartige Angriffe immer möglich.

Wie also reduziert IaC dieses Risiko? (Beachten Sie: reduzieren, nicht eliminieren.) IaC unterstützt CI/CD, wie oben erwähnt; in einem gut orchestrierten CI/CD-Setup sollte der Zugriff – oder überhaupt jeder Zugang – zum Produktionssystem strikt eingeschränkt sein. Deployments sollten zunächst in niedrigere Umgebungen erfolgen, bevor sie die Produktion erreichen (ein Vorgehen, das manuellen Aufwand und Risiko vervielfachen würde, mit IaC aber problemlos umsetzbar ist). Möchten Entwickler zu Testzwecken auf Datenbanken zugreifen, dann bitte ausschließlich in solchen Entwicklungsumgebungen. Damit bleibt das einzige System, das im Normalbetrieb überhaupt Einfluss auf die Produktion nehmen darf, Ihr CI-System – das wiederum Ihre IaC ausführt.

Doch was, so werden Sie einwenden, hindert einen Angreifer daran, einfach den Rechner eines Entwicklers zu übernehmen, eine bösartige Änderung einzuschleusen und diese über die automatisierten Prozesse in die Produktion zu pushen? Die Antwort: Genau das könnte ein Angreifer tatsächlich tun – doch jeder Schritt des Vorgangs wäre nachvollziehbar protokolliert. Der ursprüngliche Commit enthält die genaue Änderung und hilft dabei, den Schaden zu beheben; er lässt sich zudem meist dem Account des kompromittierten Entwicklers zuordnen, sodass Gegenmaßnahmen wie Passwortwechsel unmittelbar möglich sind. Sie wüssten präzise, wann der Angriff stattfand, und würden vermutlich sogar automatisch über das Deployment informiert.

Ein schwerwiegenderes Szenario wäre, dass ein Angreifer direkten Zugriff (etwa per SSH) auf die Maschine erhält, auf der Ihre CI-Pipelines laufen. Er könnte dort ungehindert Änderungen einbringen, ohne einen entsprechenden Papierpfad zu hinterlassen. Das wäre kritisch, lässt sich aber eindämmen, indem niemand – nicht einmal Ihre Administratoren – direkten Zugriff auf die CI-Maschinen erhält. Umsetzen lässt sich das über gehärtete Images und ephemere Runner, sodass sich Probleme durch schlichtes Verwerfen der Deployment-Maschine lösen lassen, statt manuell debuggen zu müssen.

Ohne IaC träten diese Probleme so nicht auf. Aber Vorsicht: Das liegt daran, dass in der Alternative jeder oder zumindest ein Teil der Entwickler direkten Deployment-Zugriff auf alle Umgebungen hätte. Die genannten Risiken bestünden also weiterhin – nur mit menschlichen Akteuren, die weniger vorhersehbar, schlechter nachvollziehbar und träger sind als jeder automatisierte Prozess.

Der Paradigmenwechsel durch IaC

Infrastructure as Code ist ein starkes Konzept. Es nimmt einen erheblichen Teil des Risikos, Aufwands, Zeitverlusts und der Unwägbarkeiten aus der Bereitstellung (und Nachverfolgung) von Infrastruktur heraus. Wir haben einige der Vorteile beleuchtet – fast noch spannender ist jedoch das breite Spektrum an Innovationen, die dieser Ansatz erst ermöglicht. Wir haben Continuous Deployment und dessen Bezug zu den Four Key Metrics gestreift, ebenso Werkzeuge wie GitOps, die adaptives Skalieren in großem Umfang mit minimalem manuellem Aufwand realisieren. Zentral ist dabei Kubernetes, ein Deployment-System, das sich weltweit ausbreitet und in mehreren seiner Kernbestandteile stark auf IaC aufbaut.

Mit Infrastructure as Code sind die Möglichkeiten praktisch unbegrenzt.