Was ist Infrastruktur als Code?

  • 10 Minuten

Sie sind damit beauftragt, zu beurteilen, ob der Ansatz „Infrastructure-as-Code“ ein sinnvoller Ansatz für die Bereitstellung von Ressourcen in Ihrem Unternehmen sein könnte. Sie prüfen die verfügbaren Bereitstellungsoptionen, einschließlich:

  • Azure-Portal
  • Azure CLI
  • Azure PowerShell
  • Azure Resource Manager Vorlagen (JSON und Bicep)

Sie sind auf der Suche nach einer wiederholbaren Option und müssen entscheiden, mit welcher Technologie Sie Ihre Azure-Infrastruktur bereitstellen möchten.

In dieser Lerneinheit erfahren Sie, wie und warum Infrastructure-as-Code Ihnen helfen kann, Ihre Azure-Infrastruktur auf automatisierte und wiederholbare Weise bereitzustellen.

Azure CLI-Befehle werden verwendet, um Konzepte zu veranschaulichen. Sie erfahren in anderen Modulen des Bicep-Lernpfads mehr über die Verwendung von Befehlen zum Bereitstellen von Ressourcen.

Definition von Infrastructure-as-Code

Ihr Unternehmen entwirft neue Spielzeuge, die auf den Markt gebracht werden sollen, von denen die meisten nach dem Kauf eine Art Zusammenbau erfordern. Das Designteam des Unternehmens erstellt Gebrauchsanleitungen, die jedem Spielzeug beiliegen. Jede Anleitung enthält Details zum ordnungsgemäßen Zusammenbau des Spielzeugs.

Sie können sich Infrastructure-as-Code als eine Art Gebrauchsanleitung für Ihre Infrastruktur vorstellen. In der Anleitung wird die Endkonfiguration Ihrer Ressourcen beschrieben und wie Sie diesen Konfigurationszustand erreichen.

Infrastructure-as-Code ist der Prozess der Automatisierung Ihrer Infrastrukturbereitstellung. Es verwendet eine beschreibende Programmiersprache und ein Versionsverwaltungssystem, das dem für Quellcode ähnlich ist. Wenn Sie eine Anwendung erstellen, generiert Ihr Quellcode jedes Mal das gleiche Ergebnis, wenn Sie ihn kompilieren. In ähnlicher Weise sind „Infrastructure-as-Code“-Bereitstellungen automatisiert, konsistent und wiederholbar. Infrastructure-as-Code kann die Bereitstellung Ihrer Infrastrukturressourcen, wie z. B. virtuelle Netzwerke, virtuelle Computer, Anwendungen und Speicher, automatisieren.

Diagramm, das den Infrastructure as Code-Prozess unter Verwendung eines Quellcode-Repositorys mit einer Vorlage für die Bereitstellung von Azure-Ressourcen zeigt.

Wenn Sie an die Gebrauchsanleitung für das neue Spielzeug zurückdenken, gibt es mehrere Möglichkeiten, die Gebrauchsanleitung zu schreiben. Eine Möglichkeit ist, jeden Schritt des Zusammenbauprozesses detailliert zu beschreiben. Eine andere Möglichkeit ist, eine Explosionsansicht der Teile zu zeigen, aus denen sich das Spielzeug zusammensetzt. Später in dieser Lerneinheit erfahren Sie mehr über die Unterschiede zwischen imperativem und deklarativem Code und deren Beziehung zu den Gebrauchsanleitungen Ihres Unternehmens.

Gründe für Infrastructure-as-Code

Die Umsetzung eines Infrastructure-as-Code-Ansatzes bietet für die Ressourcenbereitstellung viele Vorteile. Infrastructure-as-Code ermöglicht Folgendes:

  • Erhöhen des Vertrauens in Ihre Bereitstellungen
  • Verwalten mehrerer Umgebungen
  • Besseres Verständnis Ihrer Cloudressourcen

Mehr Vertrauen

Einer der Vorteile von Infrastructure-as-Code ist das Maß an Vertrauen, das Sie durch Verbesserungen bei Konsistenz und Sicherheit Ihrer Bereitstellungen gewinnen.

  • Integration in aktuelle Prozesse: Wenn Ihre Organisation bereits Standardmethoden für die Softwareentwicklung verwendet, können Sie dieselben Prozesse für Ihre Infrastrukturbereitstellungen übernehmen. Zum Beispiel können Peer-Reviews dabei helfen, Probleme in Konfigurationen zu erkennen, die bei manuellen Änderungen möglicherweise nur schwierig zu entdecken sind.

  • Konsistenz: Die Umsetzung eines Infrastructure-as-Code-Ansatzes hilft Ihrem Team, etablierte Prozesse zur Bereitstellung von Infrastruktur zu befolgen. Durch Befolgen dieser Prozesse wird die Verantwortung von einer kleinen Gruppe von Personen auf Ihren Automatisierungsprozess und Ihre Tools verlagert. Infrastructure-as-Code trägt dazu bei, menschliche Fehler bei der Ressourcenbereitstellung zu reduzieren und konsistente Bereitstellungen sicherzustellen.

  • Automatisierte Überprüfung: Sie können Infrastruktur-as-Code-Konfigurationen mit automatisierten Tools scannen, die nach Fehler im Code suchen können. Automatisierte Tools können auch vorgeschlagene Änderungen überprüfen, um sicherzustellen, dass die Sicherheits- und Leistungspraktiken eingehalten werden.

  • Geheimnisverwaltung: Viele Lösungen erfordern Geheimnisse, wie z. B. Verbindungszeichenfolgen, Verschlüsselungsschlüssel, Clientgeheimnisse und Zertifikate. In Azure ist Azure Key Vault der Dienst zum sicheren Speichern dieser Geheimnisse. Viele „Infrastructure-as-Code“-Tools können in Key Vault integriert werden, um bei der Bereitstellung sicher auf diese Geheimnisse zuzugreifen.

  • Zugriffssteuerung: Bei „Infrastructure-as-Code“-Bereitstellungen haben Sie die Möglichkeit, verwaltete Identitäten oder Dienstkonten zu verwenden, um die Ressourcenbereitstellung zu automatisieren. Dieser Prozess stellt sicher, dass nur diese Identitäten Ihre Cloudressourcen ändern können. Außerdem wird so verhindert, dass falsche Konfigurationen in der Produktion bereitgestellt werden. Bei Bedarf können Sie diesen Vorgang durch ein Konto für den Notfallzugriff (oft als Break Glass-Konto bezeichnet) oder das Feature „Microsoft Entra ID Privileged Identity Management“ außer Kraft setzen.

  • Vermeiden von Konfigurationsabweichungen: Idempotenz ist ein Begriff, der häufig mit Infrastructure-as-Code in Verbindung gebracht wird. Wenn ein Vorgang idempotent ist, bedeutet dies, dass er jedes Mal das gleiche Ergebnis liefert, wenn Sie ihn ausführen. Wenn Sie Tools mit idempotenten Vorgängen wählen, können Sie Konfigurationsabweichungen vermeiden.

Als Beispiel für idempotenz sollten Sie den folgenden Azure CLI-Befehl berücksichtigen. Mit dem Befehl wird eine Azure-Ressourcengruppe namens storage-resource-group in der Region USA, Osten erstellt.

az group create \
  --name storage-resource-group \
  --location eastus

Wenn Sie diesen Befehl ein zweites Mal ausführen, erhalten Sie genau dieselbe Ausgabe, da dieser Azure CLI-Befehl als idempotent konzipiert wurde. Sie erhalten keinen Fehler und keine doppelte Ressourcengruppe.

Wenn Sie Infrastructure-as-Code einsetzen, können Sie Ihre Umgebung mit jedem Release Ihrer Lösung neu bereitstellen. Diese Releases können kleine Konfigurationsänderungen oder sogar wichtige Updates enthalten. Dieser Prozess hilft, Konfigurationsabweichungen zu vermeiden. Wenn eine versehentliche Änderung an einer Ressource erfolgt, kann diese durch erneutes Bereitstellen der Konfiguration korrigiert werden. Bei Befolgung dieses Ansatzes dokumentieren Sie Ihre Umgebung mithilfe von Code.

Verwalten mehrerer Umgebungen

Viele Organisationen haben mehrere Anwendungsumgebungen. Die Entwickler bei Ihrem Spielzeugunternehmen verfügen möglicherweise über mehrere Versionen des Anwendungscodes in einem Repository zur Freigabe für verschiedene Umgebungen. Zu diesen Umgebungen gehören die Entwicklungs-, Test- und Produktionsumgebung. Einige Organisationen haben mehrere Produktionsumgebungen für Anwendungen, die global verteilt sind. Andere Organisationen wie unabhängige Softwarehersteller (Independent Software Vendors, ISVs) verwalten für ihre Kunden mehrinstanzenfähige Umgebungen.

Im Folgenden finden Sie einige der wichtigsten Möglichkeiten, wie Infrastructure-as-Code Sie bei der Verwaltung Ihrer Umgebungen unterstützen kann:

  • Bereitstellen neuer Umgebungen: Einer der Hauptvorteile von Cloud Computing ist Skalierbarkeit. Infrastructure-as-Code kann Sie bei der Skalierung auf mehrere Instanzen Ihrer Anwendung unterstützen. Diese Instanzen können in Zeiten erhöhter Last helfen oder für Benutzer in anderen Regionen der Welt bereitgestellt werden. Diese Agilität kann auch von Vorteil sein, wenn Sie Ihre Anwendung testen, z. B. bei Penetrations-, Auslastungs- und Fehlertests. Mit einer klar definierten Codebasis können Sie diese neuen Umgebungen dynamisch konsistent bereitstellen.

  • Nichtproduktionsumgebungen: Ein häufiges Problem für Organisationen ist die Unterscheidung zwischen Produktions- und Nichtproduktionsumgebungen. Wenn Sie manuell Ressourcen in getrennten Umgebungen bereitstellen, stimmen die Endkonfigurationen möglicherweise nicht überein. Ein Beispiel ist die Bereitstellung eines neuen Features in einer Nichtproduktionsumgebung, die sich von der Produktionsumgebung unterscheidet. Es ist möglich, dass dieses Feature in der Produktionsumgebung aufgrund der Unterschiede zwischen den beiden Umgebungen nicht wie erwartet funktioniert. Infrastructure-as-Code kann dazu beitragen, diese Probleme zu minimieren. Sie können für jede Umgebung die gleichen Konfigurationsdateien verwenden, aber unterschiedliche Eingabeparameter angeben, um für Eindeutigkeit zu sorgen.

  • Notfallwiederherstellung: In bestimmten Situationen kann Infrastructure-as-Code als Teil des Notfallwiederherstellungsplans einer Organisation zum Einsatz kommen. So kann es z. B. vorkommen, dass Sie Ihre Umgebung in einer anderen Region neu erstellen müssen, weil ein Dienst ausgefallen ist. Dank Infrastructure-as-Code können Sie schnell eine neue Instanz bereitstellen, auf die das Failover erfolgt, anstatt alles manuell bereitstellen und neu konfigurieren zu müssen.

Besseres Verständnis Ihrer Cloudressourcen

Infrastructure-as-Code kann Ihnen helfen, den Zustand Ihrer Cloudressourcen besser zu verstehen:

  • Überwachungsprotokoll: Änderungen an Ihren Infrastructure-as-Code-Konfigurationen unterliegen der gleichen Versionsverwaltung wie der Quellcode Ihrer Anwendung. Diese Änderungen werden in Ihrem Tool ähnlich dem Git-Versionsverlauf nachverfolgt. Dieses Überwachungsprotokoll bedeutet, dass Sie detailliert überprüfen können, wer wann welche Änderung vorgenommen hat.

  • Dokumentation: Sie können viele „Infrastructure-as-Code“-Konfigurationen nutzen, um Metadaten wie Kommentare hinzuzufügen, die den Zweck des Codes in Ihrer Konfiguration beschreiben. Wenn Ihre Organisation bereits einen Prozess zur Codedokumentation verfolgt, sollten Sie eventuell erwägen, diese Verfahren auch für Ihren Infrastrukturcode zu übernehmen.

  • Vereinheitlichtes System: Wenn ein Entwickler an einem neuen Feature arbeitet, muss er oft Änderungen am Anwendungs- und Infrastrukturcode vornehmen. Durch den Einsatz eines gemeinsamen Systems kann Ihre Organisation die Beziehung zwischen Ihren Anwendungen und Ihrer Infrastruktur besser verstehen.

  • Besseres Verständnis der Cloudinfrastruktur: Wenn Sie Ressourcen über das Azure-Portal bereitstellen, sind viele der Prozesse abstrahiert, d. h. nicht einsehbar. Infrastructure-as-Code kann dabei helfen, ein besseres Verständnis der Funktionsweise von Azure und der Problembehandlung bei eventuell auftretenden Problemen zu erlangen. Wenn Sie z. B. einen virtuellen Computer im Azure-Portal erstellen, werden einige erstellte Ressourcen abstrahiert. Das bedeutet, dass verwaltete Datenträger und Netzwerkschnittstellenkarten im Hintergrund bereitgestellt werden. Wenn Sie denselben virtuellen Computer mithilfe von Infrastructure-as-Code bereitstellen, haben Sie die vollständige Kontrolle über alle erstellten Ressourcen.

Imperativer und deklarativer Code

Sie können eine Gebrauchsanleitung für den Zusammenbau eines neuen Spielzeugs auf unterschiedliche Weisen erstellen. Wenn Sie die Bereitstellung von Diensten und Infrastruktur automatisieren, können Sie zwei Ansätze wählen: imperativ und deklarativ.

  • Bei imperativem Code führen Sie eine Folge von Befehlen in einer bestimmten Reihenfolge aus, um eine Endkonfiguration zu erreichen. Dieser Prozess legt fest, was der Code erreichen und wie die Aufgabe erfüllt werden soll. Der imperative Ansatz ist wie eine Schritt-für-Schritt-Gebrauchsanleitung.

  • Bei deklarativem Code geben Sie nur die Endkonfiguration an. Der Code legt nicht fest, wie die Aufgabe erledigt werden soll. Der deklarative Ansatz ist wie eine Gebrauchsanleitung in Form einer Explosionsansicht.

Wenn Sie sich zur Ressourcenbereitstellung für einen imperativen oder deklarativen Ansatz entscheiden, sollten Sie die Tools berücksichtigen, die in Ihrer Organisation möglicherweise bereits im Einsatz sind. Prüfen Sie auch, welcher Ansatz besser Ihren eigenen Fähigkeiten entspricht.

Imperativer Code

In Azure wird ein Ansatz mit imperativem Code programmgesteuert mit einer Skriptsprache wie Bash oder Azure PowerShell umgesetzt. Die Skripts führen eine Reihe von Schritten aus, um Ihre Ressourcen zu erstellen, zu ändern und zu entfernen.

In diesem Beispiel werden zwei Azure CLI-Befehle gezeigt, die eine Ressourcengruppe und ein Speicherkonto erstellen.

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

Mit dem ersten Befehl wird eine Ressourcengruppe namens storage-resource-group in der Region „USA, Osten“ erstellt. Der zweite Befehl erstellt ein Speicherkonto mit dem Namen mystorageaccount in der Ressourcengruppe storage-resource-group, die mit dem ersten Befehl angelegt wurde. Mit dem zweiten Befehl werden auch einige Eigenschaften für das Speicherkonto konfiguriert, einschließlich der Art des Speicherkontos und dessen Zugriffsebene.

Mithilfe eines imperativen Ansatzes können Sie die Ressourcenbereitstellung vollständig automatisieren, was jedoch einige Nachteile mit sich bringt. Mit zunehmender Reife Ihrer Architektur kann die Verwaltung von Skripts komplexer werden. Befehle können aktualisiert oder veraltet werden, was Überprüfungen vorhandener Skripts erfordert.

Deklarativer Code

In Azure wird ein Ansatz mit deklarativem Code mithilfe von Vorlagen umgesetzt. Es stehen viele Arten von Vorlagen zur Verfügung, so z. B.:

  • JSON
  • Bicep
  • Ansible von RedHat
  • Terraform von HashiCorp

Hinweis

In diesem Modul liegt der Fokus auf Bicep-Vorlagen.

Sehen Sie sich das folgende Beispiel einer Bicep-Vorlage an, mit der ein Speicherkonto konfiguriert wird. Die Konfiguration des Speicherkontos entspricht dem Azure CLI-Beispiel.

resource storageAccount 'Microsoft.Storage/storageAccounts@2203-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

Im Abschnitt „resources“ wird die Konfiguration des Speicherkontos festgelegt. Dieser Abschnitt enthält den Namen, Speicherort und die Eigenschaften des Speicherkontos, einschließlich SKU und Art des Kontos.

Möglicherweise bemerken Sie, dass in der Bicep-Vorlage nicht angegeben ist, wie das Speicherkonto bereitgestellt werden soll. Sie gibt nur an, wie das Speicherkonto aussehen muss. Die tatsächlichen Schritte, die hinter den Kulissen zum Anlegen oder Aktualisieren dieses Speicherkontos gemäß der Spezifikation erfolgen, bleiben Azure überlassen.