Was ist Infrastructure as Code (IaC)?

Bevor wir uns mit Terraform an sich beschäftigen können, sollten wir zunächst einmal klären: Was ist denn Infrastructure as Code überhaupt? Und das Ganze tun wir initial mal von der Definitionsseite her. Es geht bei Infrastructure as Code darum, Infrastruktur mithilfe von Software bereitzustellen. Ziel ist es dabei, eine konsistente Konfiguration und vorhersagbare Umgebungen zu erzeugen. Anders also, als wenn ich manuell in einem Portal etwas zusammenklicke z.B., möchte ich mithilfe dieser Software immer das gleiche Ergebnis sicherstellen und damit eben Konsistenz sicherstellen. Damit das Ganze funktioniert, gibt es einige Grundprinzipien für den Einsatz von Infrastructure as Code. Nämlich, wie der Name es schon sagt, zuallererst mal, dass die Definition unserer Infrastruktur in Code erfolgt. Das heißt also, wir schreiben tatsächlich nieder, wie unsere Infrastruktur aussehen, bereitgestellt werden soll. Wenn wir jetzt schon in Code arbeiten, wollen wir dann auch die Verwaltung dieses Codes in einem Source-Control-System vornehmen, bspw. Git. Wir haben damit dann die Möglichkeit, jederzeit nachzuvollziehen, wer wann was und im besten Fall auch noch warum geändert hat und haben auch die Möglichkeit, schnell zu einem vorherigen Stand unserer Infrastruktur zurückzukehren. Wenn ich Infrastructure as Code einsetze, habe ich in der Regel die Auswahl, ob ich deklarativ, also beschreibend, arbeiten möchte, was die häufigste Form von Infrastructure as Code ist, oder ob ich mit imperativen Mitteln arbeiten möchte, also eine klassische Abarbeitung von nacheinander folgenden Schritten. Das Ganze schauen wir uns aber in einem späteren Video noch mal etwas genauer an. Eine weitere Grundidee von Infrastructure as Code ist, dass wir idempotent arbeiten, das heißt also konsistent. Das bedeutet, dass wir Dinge nur dann anfassen und manipulieren, wenn es auch tatsächlich eine Änderung gibt. Aber auch dazu mehr in einem späteren Video. Ziel ist es also, mithilfe von Infrastructure as Code möglichst Konsistenz in meiner Umgebung herzustellen. Und dabei gibt es je nach Technologie Push- oder Pull-Methoden. Das heißt also, entweder die Konfiguration wird von einem System auf das Zielsystem aufgetragen und dort umgesetzt, oder aber die Zielsysteme fragen an einer zentralen Stelle ab. Sie pullen also ihre Konfiguration und passen sich dann entsprechend an. Um das Ganze ein kleines bisschen greifbarer zu machen, werfen wir mal einen ganz kurzen Blick hier in das Azure-Portal. Wenn ich nämlich hier in meine Resource Group mal reingehe und einen neuen Storage Account z.B. anlege, dann sehe ich hier schon, dass ich unheimlich viele Möglichkeiten habe, hier in diesen Storage Accounts Konfigurationen vorzunehmen. Und das ist ja eigentlich erst mal nur ein ganz simpler Speicher. Das kann ja so schwer gar nicht sein. Und es fängt natürlich auch simpel an. Ich brauche hier einen Namen. Der braucht im besten Fall auch einen einmaligen Namen. Dann wähle ich noch eine Region aus, sage noch, was das für ein Service sein soll, ob Standard oder Premium, georedundant oder vielleicht nur lokal redundant. Dann geht das Ganze aber weiter über Advanced-Funktionen. Also, wollen wir die Secure-Transfer-Konfiguration für die REST-API anmachen. Welche TLS-Version wollen wir denn erzwingen und so weiter und so fort. Da gehören noch Netzwerk-Konfigurationen, Encryption-Konfigurationen dazu. Und all diese Dinge kann ich jetzt jedes Mal, wenn ich diesen Assistenten durchlaufe, anders einstellen. Und nun ist klar, wenn verschiedene Menschen sich durch diesen Assistenten durchklicken, wird sehr wahrscheinlich ein unterschiedliches Ergebnis dabei rauskommen. Und genau da versucht Infrastructure as Code Abhilfe zu schaffen. Indem wir einmalig in Code definieren, was wir konfigurieren wollen. Wollen wir also HTTPS anhaben, wollen wir Encryption anhaben, haben wir immer das gleiche Deployment, immer das gleiche Ergebnis für bspw. hier die Bereitstellung eines Storage Accounts. Und obwohl wir jetzt hier in der Oberfläche von Microsoft Azure etwas zusammengeklickt haben, ist es trotzdem spannend zu wissen, dass im Hintergrund auch hier im Prinzip Infrastructure as Code genutzt wird. Denn wechseln wir hier mal in unsere Resource Group, dann können wir hier unter Deployment sehen, dass dort ein Deployment stattgefunden hat, nämlich mein gerade eben bereitgestellter Storage Account. Und wenn ich hier auf Template gehe, dann sehe ich hier ein JSON-File und das ist ein Azure Resource Manager Template. Also all das, was ich gerade im Portal zusammengeklickt habe, ist im Hintergrund übersetzt worden in dieses JSON-File. Und dieses JSON-File wurde dann an die Azure Resource Manager API übergeben, um tatsächlich umgesetzt zu werden. Das ist doch gut zu wissen, dass selbst wenn wir im Portal etwas zusammenklicken, wir im Hintergrund schon Infrastructure as Code nutzen.