Infrastructure as Code (IaC)
Infrastructure as Code (IaC) ist ein IT-Setup, bei dem Entwickler oder Betriebsteams den Technologie-Stack für eine Anwendung automatisch über Software verwalten und bereitstellen, anstatt einen manuellen Prozess zur Konfiguration diskreter Hardwaregeräte und Betriebssysteme zu verwenden. Infrastructure as Code wird manchmal auch als programmierbare oder softwaredefinierte Infrastruktur bezeichnet.
Das Konzept von Infrastructure as Code ähnelt den Programmierskripten, die zur Automatisierung von IT-Prozessen verwendet werden. Skripte werden jedoch in erster Linie dazu verwendet, eine Reihe statischer Schritte zu automatisieren, die auf mehreren Servern mehrfach wiederholt werden müssen. Infrastructure as Code verwendet eine übergeordnete oder beschreibende Sprache, um vielseitigere und anpassungsfähigere Bereitstellungsprozesse zu codieren.
Zum Beispiel können die Infrastructure-as-Code-Fähigkeiten, die in Ansible, einem IT-Verwaltungs- und Konfigurationswerkzeug, enthalten sind, einen MySQL-Server installieren, überprüfen, ob MySQL ordnungsgemäß läuft, ein Benutzerkonto und ein Kennwort erstellen, eine neue Datenbank einrichten und nicht benötigte Datenbanken entfernen.
Der Prozess der codebasierten Infrastrukturautomatisierung ähnelt der Softwaredesignpraxis, bei der Entwickler die Codeversionen sorgfältig kontrollieren, Iterationen testen und den Einsatz einschränken, bis die Software erprobt und für die Produktion freigegeben ist.
Vorteile von Infrastructure as Code
Softwareentwickler können Code für die Bereitstellung und den Einsatz von Servern und Anwendungen verwenden, anstatt sich in einer DevOps-Umgebung auf Systemadministratoren verlassen zu müssen. Ein Entwickler kann einen Infrastructure-as-Code-Prozess schreiben, um eine neue Anwendung zur Qualitätssicherung oder zum experimentellen Einsatz bereitzustellen und zu implementieren, bevor der Betrieb für den Live-Einsatz in der Produktion übernommen wird.
Wenn das Infrastruktur-Setup als Code geschrieben ist, kann es die gleiche Versionskontrolle, automatisiertes Testen und andere Schritte einer Pipeline für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) durchlaufen, die Entwickler für Anwendungscode verwenden.
Eine Organisation kann sich dafür entscheiden, Infrastructure as Code mit Containern zu kombinieren, die die Anwendung von der Infrastruktur auf Betriebssystemebene abstrahieren. Da das Betriebssystem und die Hardwareinfrastruktur automatisch bereitgestellt und die Anwendung darauf gekapselt wird, erweisen sich diese Technologien als komplementär für verschiedene Bereitstellungsziele wie Test, Staging und Produktion.
Trotz ihrer Vorteile birgt Infrastructure as Code potenzielle Nachteile. Es erfordert zusätzliche Tools, wie zum Beispiel ein Konfigurationsmanagementsystem, das Lernkurven und Raum für Fehler bieten könnte. Jegliche Fehler können sich schnell über Server ausbreiten, daher ist es unerlässlich, die Versionskontrolle zu überwachen und umfassende Vorabtests durchzuführen.
Wenn Administratoren Serverkonfigurationen außerhalb der festgelegten Infrastructure-as-Code-Templates ändern, kann es zu einem Konfigurationsdrift kommen. Es ist wichtig, Infrastructure as Code vollständig in die Systemadministration, den IT-Betrieb und die DevOps-Praktiken mit gut dokumentierten Richtlinien und Verfahren zu integrieren.
Ansätze und Methoden
Infrastructure-as-Code-Tool können deklarativ und imperativ sein.
Ein deklarativer Programmierungsansatz umreißt den gewünschten, beabsichtigten Zustand der Infrastruktur, nennt aber nicht explizit die Schritte zum Erreichen dieses Zustands. SQL ist eine allgemein bekannte deklarative Programmiersprache. AWS CloudFormation Templates werden zum Beispiel im deklarativen Stil von Infrastructure as Code geschrieben.
Im Gegensatz dazu definiert ein imperativer Ansatz Befehle, die es der Infrastruktur ermöglichen, den gewünschten Zustand zu erreichen. Objektorientierte Sprachen, wie C++ und Java, können für die imperative Programmierung verwendet werden. Ein Tool wie Chef kann deklarativ, bei Bedarf aber auch imperativ verwendet werden.
Bei beiden Ansätzen wird Infrastructure as Code auf einem Template konfiguriert, wobei der Benutzer die für jeden Server in der Infrastruktur benötigten Ressourcen angibt. Das Template wird verwendet, um entweder zu verifizieren, dass ein System richtig konfiguriert ist, oder um es in die entsprechende Konfiguration zu bringen. Templates können als ein Satz von Ressourcenschichten konstruiert werden, wie zum Beispiel in AWS CloudFormation.
Infrastructure as Code Tools
Infrastructure as Code Tools konfigurieren und automatisieren die Bereitstellung der Infrastruktur. Diese Tools können die Bereitstellung von Infrastruktur, wie zum Beispiel Servern, mit Orchestrierungsfunktionalität automatisch ausführen. Sie können auch zuvor bereitgestellte Systeme konfigurieren und überwachen.
Infrastructure as Code Tools erzwingen das Setup aus dem Template über Push- oder Pull-Methoden. Bei der Push-Methode sendet ein zentralisierter Server die gewünschte Konfiguration an ein bestimmtes System oder bestimmte Systeme. Die Pull-Methode wird durch eine Anfrage an einen zentralisierten Server von einem System oder mehreren Systemen in der Infrastruktur initiiert.
Die Tools sind in der Regel standardmäßig für die Push- oder Pull-Bereitstellung von Code ausgelegt, können aber für bestimmte Instanzen eingerichtet werden, um das jeweils andere zu tun. Diese Tools sollten auch in der Lage sein, Änderungen am Code rückgängig zu machen, wie im Falle unerwarteter Probleme bei einer Aktualisierung.
Beispiele für Infrastructure as Code Tools sind AWS CloudFormation, Red Hat Ansible, Chef, Puppet, SaltStack und HashiCorp Terraform. Einige Tools basieren auf einer domänenspezifischen Sprache (DSL), während andere ein Standard-Template-Format verwenden, wie zum Beispiel YAML und JSON.
Bei der Auswahl eines Tools sollten Organisationen das Zielsystem berücksichtigen. Beispielsweise ist AWS CloudFormation für die Bereitstellung und Verwaltung der Infrastruktur auf AWS konzipiert und arbeitet mit anderen AWS-Angeboten zusammen. Alternativ arbeitet Chef mit lokalen Servern und Infrastructure-as-Code-Angeboten mehrerer Cloud-Provider.
