Freigeben über

Infrastruktur als Code

Infrastructure as Code (IaC) ist eine wichtige DevOps-Praxis, die die Verwaltung der Infrastruktur umfasst, z. B. Netzwerke, Computedienste, Datenbanken, Speicher und Verbindungstopologie, in einem beschreibenden Modell. IaC ermöglicht Es Teams, Änderungen schneller und mit größerem Vertrauen zu entwickeln und freizugeben. Zu den Vorteilen von IaC gehören:

  • Mehr Vertrauen in Implementierungen
  • Möglichkeit zum Verwalten mehrerer Umgebungen
  • Verbessertes Verständnis des Zustands der Infrastruktur

Weitere Informationen zu den Vorteilen der Verwendung von Infrastruktur als Code finden Sie unter Wiederholbare Infrastruktur.

Werkzeugbau

Es gibt zwei Ansätze, die Sie bei der Implementierung von Infrastruktur als Code ausführen können.

  • Imperative Infrastruktur als Code umfasst das Schreiben von Skripts in Sprachen wie Bash oder PowerShell. Sie geben explizit Befehle an, die ausgeführt werden, um ein gewünschtes Ergebnis zu erzielen. Wenn Sie imperative Bereitstellungen verwenden, müssen Sie die Abfolge von Abhängigkeiten, Fehlersteuerung und Ressourcenaktualisierungen verwalten.
  • Die deklarative Infrastruktur als Code umfasst das Schreiben einer Definition, die definiert, wie Ihre Umgebung aussehen soll. In dieser Definition geben Sie ein gewünschtes Ergebnis anstelle dessen an, wie sie erreicht werden soll. Die Werkzeuge ermitteln, wie das Ergebnis erzielt werden kann, indem sie Ihren aktuellen Zustand überprüfen, mit dem Zielzustand vergleichen und dann die Unterschiede umsetzen.

ARM-Vorlagen

Überprüfen Sie Informationen zu Azure Resource Manager-Vorlagen (ARM-Vorlagen).

Bizeps

Bicep ist eine domänenspezifische Sprache (Domain-Specific Language, DSL), die eine deklarative Syntax zur Bereitstellung von Azure-Ressourcen verwendet. In Bicep-Dateien definieren Sie die Infrastruktur, die Sie bereitstellen möchten, und deren Eigenschaften. Im Vergleich zu ARM-Vorlagen sind Bicep-Dateien für ein nicht-entwickler Publikum einfacher zu lesen und zu schreiben, da sie eine knappe Syntax verwenden.

Dieser Bicep-Beispielcode stellt ein Azure Storage-Konto in der Region der Ressourcengruppe bereit. Sie wendet Standard_LRS Redundanz und die StorageV2-Art an. Die Zugriffsebene ist für häufigen Datenzugriff auf "Hot" festgelegt.

param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Terraformierung

Überprüfen Sie Die Informationen zu Terraform.

Azure-Befehlszeilenschnittstelle (Azure CLI)

Überprüfen Sie Informationen zu Azure CLI.

Infrastruktur als Codemodule

Eines der Ziele der Verwendung von Code zur Bereitstellung der Infrastruktur ist die Vermeidung von Duplizieren von Arbeiten oder Erstellen mehrerer Vorlagen für dieselben oder ähnliche Zwecke. Infrastrukturmodule sollten wiederverwendbar und flexibel sein und einen klaren Zweck haben.

Module sind unabhängige Dateien, die in der Regel eine Gruppe von Ressourcen enthalten, die zusammen bereitgestellt werden sollen. Mithilfe von Modulen können Sie komplexe Vorlagen in kleinere, verwaltbare Codegruppen unterteilen. Sie können sicherstellen, dass sich jedes Modul auf eine bestimmte Aufgabe konzentriert und dass alle Module für mehrere Bereitstellungen und Workloads wiederverwendbar sind.

Bicep-Module

Mit Bicep können Sie Module erstellen und aufrufen. Sobald Module erstellt worden sind, können sie aus jeder anderen Bicep-Vorlage verwendet werden. Ein hochwertiges Bicep-Modul sollte mehrere verwandte Ressourcen definieren. Wenn Sie beispielsweise eine Azure-Funktion definieren, stellen Sie in der Regel eine bestimmte Anwendung, einen Hostingplan für diese Anwendung und ein Speicherkonto für die Metadaten dieser Anwendung bereit. Diese Komponenten werden separat definiert, bilden aber eine logische Gruppierung von Ressourcen, sodass Sie sie als Modul definieren sollten.

Bicep-Module verwenden häufig:

  • Parameter , die Werte aus einem aufrufenden Modul akzeptieren sollen.
  • Ausgabewerte , um Ergebnisse an ein aufrufende Modul zurückzugeben.
  • Ressourcen zum Definieren eines oder mehrerer Infrastrukturobjekte für ein zu verwaltenes Modul.

Bicep-Module veröffentlichen

Sie haben mehrere Optionen zum Veröffentlichen und Freigeben von Bicep-Modulen.

  • Öffentliche Registrierung: Die Registrierung des öffentlichen Moduls wird in einer Microsoft-Containerregistrierung (MCR) gehostet. Der Quellcode und die darin enthaltenen Module werden in GitHub gespeichert.
  • Private Registrierung: Sie können die Azure-Containerregistrierung verwenden, um Module in einer privaten Registrierung zu veröffentlichen. Informationen zum Veröffentlichen von Modulen in einer Registrierung in einer CI/CD-Pipeline finden Sie unter Bicep- und GitHub-Aktionen oder bei Bedarf Bicep und Azure Pipelines.
  • Vorlagenspezifikation: Sie können Vorlagenspezifikationen verwenden, um Bicep-Module zu veröffentlichen. Vorlagenspezifikationen sollen vollständige Vorlagen sein, aber Bicep ermöglicht es Ihnen, Vorlagenspezifikationen zum Bereitstellen von Modulen zu verwenden.
  • Versionssteuerungssystem: Sie können Module direkt über Versionssteuerungstools wie GitHub oder Azure DevOps laden.

Terraform-Module

Terraform ermöglicht es Ihnen, Module zu erstellen und aufzurufen. Jede Terraform-Konfiguration verfügt über mindestens ein Modul, das als Stammmodul bezeichnet wird und aus Ressourcen besteht, die in .tf Dateien in Ihrem Hauptarbeitsverzeichnis definiert sind. Jedes Modul kann andere Module aufrufen, mit denen Sie untergeordnete Module in die Hauptkonfigurationsdatei aufnehmen können. Module können auch mehrmals innerhalb derselben Konfiguration oder aus verschiedenen Konfigurationen aufgerufen werden.

Module werden mit allen gleichen Konfigurationssprachenkonzepten definiert. Sie verwenden am häufigsten:

  • Eingabevariablen , um Werte aus einem aufrufenden Modul zu akzeptieren.
  • Ausgabewerte , um Ergebnisse an ein aufrufende Modul zurückzugeben.
  • Ressourcen zum Definieren eines oder mehrerer Infrastrukturobjekte für ein zu verwaltenes Modul.

Veröffentlichen von Terraform-Modulen

Sie haben mehrere Möglichkeiten zum Veröffentlichen und Freigeben von Terraform-Modulen:

  • Öffentliche Registrierung: HashiCorp verfügt über eine eigene Terraform Module Registry, mit der Benutzer sharable Terraform Module generieren können. Es gibt derzeit mehrere Azure-Module , die in der Terraform Module Registry veröffentlicht werden.
  • Private Registrierung: Sie können Terraform-Module nahtlos in einem privaten Repository wie Terraform Cloud Private Registry oder Azure Container Registry veröffentlichen.
  • Versionssteuerungssystem: Sie können private Module direkt über Versionssteuerungstools wie GitHub laden. Informationen zu unterstützten Quellen finden Sie unter Terraform-Modulquellen.

Entwurfsüberlegungen

  • Erwägen Sie die Verwendung von IaC beim Bereitstellen von Landungszonenressourcen in Azure. IaC realisiert die Bereitstellungsoptimierung vollständig, reduziert den Konfigurationsaufwand und automatisiert die Bereitstellungen der gesamten Umgebung.

  • Bestimmen Sie, ob Sie einen imperativen oder deklarativen IaC-Ansatz verwenden sollten.

    • Wenn Sie einen imperativen Ansatz wählen, geben Sie explizite Befehle an, die Ihr gewünschtes Ergebnis erzeugen.

    • Wenn Sie einen deklarativen Ansatz ergreifen, geben Sie Ihr gewünschtes Ergebnis anstelle der gewünschten Vorgehensweise an.

  • Erwägen Sie Bereitstellungsbereiche. Verfügen Sie über ein gutes Verständnis der Azure-Verwaltungsebenen und -hierarchie. Jede IaC-Bereitstellung muss den Umfang kennen, in dem Azure-Ressourcen bereitgestellt werden.

  • Ermitteln Sie, ob Sie ein systemeigenes Azure- oder Azure-Nicht-natives IaC-Tool verwenden sollten. Zu berücksichtigende Punkte:

    • Native Azure-Tools wie Azure CLI, ARM-Vorlagen und Bicep werden von Microsoft vollständig unterstützt, wodurch ihre neuen Features schneller integriert werden können.

    • Nicht native Tools wie Terraform ermöglichen es Ihnen, Infrastruktur als Code für mehrere Cloudanbieter wie AWS oder GCP zu verwalten. Neue Azure-Funktionen können jedoch einige Zeit in Anspruch nehmen, bis sie in nicht-nativen Umgebungen verfügbar sind. Wenn Ihre Organisation Multi-Cloud ist oder Ihre Organisation bereits Terraform verwendet und gut mit Terraform vertraut ist, sollten Sie Terraform verwenden, um Azure-Landezonen zu implementieren.

  • Da Module es Ihnen ermöglichen, komplexe Vorlagen in kleinere Codegruppen zu unterteilen, sollten Sie IaC-Module für Ressourcen verwenden, die häufig zusammen bereitgestellt werden. Sie können sicherstellen, dass sich jedes Modul auf eine bestimmte Aufgabe konzentriert und für mehrere Bereitstellungen und Workloads wiederverwendbar ist.

  • Erwägen Sie die Einführung einer Veröffentlichungsstrategie für IaC-Module, indem Sie zwischen öffentlichen Registern, privaten Registrierungen oder einem Versionskontrollsystem wie einem Git-Repository wählen.

  • Erwägen Sie die Verwendung einer CI/CD-Pipeline für IaC-Bereitstellungen. Eine Pipeline erzwingt den von Ihnen festgelegten wiederverwendbaren Prozess, um die Qualität Ihrer Bereitstellungen und Azure-Umgebung sicherzustellen.

Designempfehlungen

  • Übernehmen Sie einen IaC-Ansatz zum Bereitstellen, Verwalten, Steuern und Unterstützen von Azure Landing Zone-Implementierungen.

  • Verwenden Sie native Azure-Tools für IaC in den folgenden Szenarien:

    • Sie möchten nur systemeigene Azure-Tools verwenden. Ihre Organisation hat möglicherweise Erfahrung mit der früheren Bereitstellung von ARM- oder Bicep-Vorlagen.

    • Ihre Organisation möchte sofortige Unterstützung für alle Vorschau- und GA-Versionen von Azure-Diensten haben.

  • Verwenden Sie nicht systemeigene Tools für IaC in den folgenden Szenarien:

    • Ihre Organisation verwendet derzeit Terraform, um Infrastruktur für andere Clouds wie AWS oder GCP bereitzustellen.

    • Ihre Organisation muss keine sofortige Unterstützung für alle Vorschau- und GA-Versionen von Azure-Diensten haben.

  • Verwenden Sie wiederverwendbare IaC-Module, um sich wiederholende Arbeiten zu vermeiden. Sie können Module in Ihrer Organisation freigeben, um mehrere Projekte oder Workloads bereitzustellen und weniger komplexen Code zu verwalten.

  • Veröffentlichen und Verwenden von IaC-Modulen aus öffentlichen Registrierungen in den folgenden Szenarien:

    • Sie möchten Module für Azure Landing Zone verwenden, die bereits in öffentlichen Registern veröffentlicht wurden. Weitere Informationen finden Sie im Terraform-Modul für Azure-Landezonen.

    • Sie möchten Module verwenden, die von Microsoft, Terraform oder anderen Modulanbietern verwaltet, aktualisiert und unterstützt werden.

      • Stellen Sie sicher, dass Sie die Support-Anweisung von einem beliebigen Modulanbieter überprüfen, den Sie bewerten.

  • Veröffentlichen und Verwenden von IaC-Modulen aus privaten Registrierungen oder Versionskontrollsystemen in den folgenden Szenarien:

    • Sie möchten ihre eigenen Module basierend auf Ihren Organisationsanforderungen erstellen.

    • Sie möchten die vollständige Kontrolle über alle Features haben und neue Versionen von Modulen verwalten, aktualisieren und veröffentlichen.

  • Verwenden Sie eine CI/CD-Pipeline, um IaC-Artefakte bereitzustellen und die Qualität Ihrer Bereitstellungs- und Azure-Umgebungen sicherzustellen.