Dieser Blog-Beitrag ist ein Kapitel aus dem eBook Von Admin zu DevOps: Der No-BS-Weg zu DevOps in Azure. Schauen Sie es sich unbedingt an, wenn Sie tiefer in das Thema eintauchen möchten, was es braucht, um mit DevOps in Microsoft Azure erfolgreich zu sein, indem Sie Infrastructure as Code lernen.
Wenn Sie jemals eine Art von Cloud- oder virtueller Infrastruktur manuell lokal erstellt haben, wissen Sie, dass entweder viel geklickt oder viel getippt wird. Infrastructure as Code (IaC) kümmert sich darum.
Um etwas bereitzustellen, muss man sich merken, auf welchen Bildschirm man gehen oder welchen Befehl man ausführen muss. Wenn Sie nur zum Spaß Azure ausprobieren, ist das in Ordnung, aber wenn dieses Spielen zu geschäftskritischen, produktiven Prozessen wird, bei denen Zeit Geld ist, muss sich etwas ändern.
Sobald Ihre Organisation ernsthaft damit beginnt, Infrastruktur bereitzustellen und zu verwalten, werden Sie auf viele neue Herausforderungen stoßen.
Sie werden unnötige Duplizierung von Arbeit, wiederholte Fälle des Fat-Finger-Syndroms, Probleme mit dem Änderungsmanagement, Konfigurationsdrift und mehr erleben. Je größer die Organisation und das Team, desto größer die Probleme. All diese Probleme können mit einem Konzept namens Infrastructure as Code (IaC) beseitigt oder zumindest minimiert werden.
Infrastructure as Code (IaC): Am Beispiel erklärt
IaC ist ein branchenüblicher Begriff, der sich auf die Speicherung aller erforderlichen Dinge zum Aufbau von Infrastrukturkomponenten in Code bezieht. Dieser Code wird normalerweise in JSON- oder YAML-Dateien definiert, die repräsentieren, wie Ihre Infrastruktur aussehen sollte.
Sobald alle Komponenten in einer strukturierten Datei definiert sind, kommt ein weiterer Prozess hinzu, der den Code versteht und sofort damit beginnt, dieses Dokument als Anleitung zum Aufbau der Infrastruktur zu verwenden.
Um ein allgemeines, pseudocode-ähnliches Beispiel zu geben, nehmen wir an, Sie möchten eine virtuelle Maschine (VM) erstellen. Diese VM hat Anforderungen wie Berechnung, Speicherung und Netzwerk. Ein grober Ansatz für Infrastructure as Code (IaC) wäre, die VM und alle ihre Komponenten in einer Vorlage zu beschreiben.
Die Vorlage
Im folgenden Codeausschnitt können Sie ein Beispiel dafür sehen, wie jede Komponente durch eine Hierarchie mit definierten Attributen aufgeschlüsselt wird. Dieses fiktive Beispiel wurde in einer JSON-Datei erstellt, die die meisten Dienste als Vorlage bezeichnen würden.
Diese Vorlage definiert die VM und alle Attribute, die mit dieser VM verbunden sind. Sie hat ein spezifisches Schemata, dem Vorlagenautoren folgen müssen, um zu definieren, wie diese VM aussieht. Angenommen, diese Vorlage wird dann in einer Datei mit dem Namen myvm.json gespeichert.
Quellcodeverwaltung
Sie haben nun alles, was eine VM ausmacht, in einer einzigen Datei gespeichert. Wie jeder gute DevOps-Experte überprüfen Sie diese Datei in der Quellcodeverwaltung. Sie haben jetzt eine Möglichkeit, Änderungen an der Datei nachzuverfolgen.
Das Werkzeug
Jetzt, da die Datei erstellt ist, benötigen Sie ein Werkzeug oder einen Dienst, der diese Datei lesen kann und versteht, was Sie erstellen möchten. Dieses Werkzeug verwendet die Vorlage als Eingabe und erstellt die VM genau nach diesen Spezifikationen, ohne weitere Interaktion.
Toller Deal, oder? Aber das ist noch nicht alles.
Bekämpfung von Konfigurationsabweichungen
Nehmen wir nun an, Sie müssen die statische IP-Adresse ändern, die dem NIC dieser VM zugewiesen ist. Sie könnten per RDP auf die VM zugreifen und die IP-Adresse ändern, aber Sie möchten das nicht tun. Warum?
- Sie führen die Änderung manuell durch, was Zeitverschwendung ist und zu menschlichen Fehlern führen kann.
- Es gibt keine Prüfspur, wer die IP-Adresse geändert hat und wann.
- Es gibt keine automatisierte Möglichkeit, die Änderung rückgängig zu machen, falls Sie sich bei der Eingabe der IP-Adresse vertippen.
Infrastructure as Code (IaC) kann all diese Herausforderungen bewältigen. Mit nur wenigen Tastenschlägen könnten Sie diese Änderung auf eine Weise vornehmen, die Ihr Manager und Ihr Auditor lieben werden.
Öffnen Sie myvm.json, ändern Sie das IPAddress-Attribut, übernehmen Sie die Änderung in der Quellkontrolle und führen Sie das Tool erneut aus. Fertig.
Das Tool weiß genau, was geändert werden muss. Es wird das NIC nicht trennen oder die gesamte VM neu erstellen. Alle IaC-Tools und -Dienste sind clever genug, um zu verstehen, wie die Änderung vorgenommen werden kann. Magisch!
Aber jetzt haben Sie gerade festgestellt, dass Sie die falsche IP-Adresse verwendet haben und zurückkehren müssen. Kein Problem. Machen Sie die Änderung in der Quellkontrolle rückgängig, übernehmen Sie sie, führen Sie das Tool aus und Sie sind wieder im Geschäft.
Aber warten Sie, es gibt noch mehr.
Die Anfänge der kontinuierlichen Bereitstellung
Wenn Sie die Infrastruktur in Vorlagen unter Versionskontrolle haben, haben Sie eine Reihe von Zutaten für den Beginn einer automatisierten Freigabe- oder kontinuierlichen Bereitstellungs-Pipeline.
Erinnern Sie sich daran, dass Sie jedes Mal, wenn Sie die Vorlage geändert haben, dieses Tool ausführen mussten. In einer automatisierten Pipeline/Workflow wird dieses Tool automatisch ausgeführt. Sobald der Prozess zur Erstellung oder Änderung der Umgebung automatisiert ist, stimmt die Infrastruktur mit der Vorlage überein.
Erstellen Sie genügend Vorlagen und letztendlich könnte Ihre gesamte Infrastruktur in Code oder als Code repräsentiert werden.
Schlussfolgerung
IaC ist eine DevOps-Methodik, die es Operations ermöglicht, eine Rolle im Buch des Softwareentwicklers zu spielen. IaC bringt viele Vorteile mit sich, die Softwareentwickler seit Jahren nutzen und gibt sie in die Hände des Systemadministrators.
Source:
https://adamtheautomator.com/infrastructure-as-code-iac/