Freigeben über

Infrastructure-as-Code

  • Artikel

Infrastructure-as-Code (IaC) ist eine wichtige DevOps-Methode, die die Verwaltung der Infrastruktur (z. B. Netzwerke, Computedienste, Datenbanken, Speicher und Verbindungstopologie) in einem beschreibenden Modell umfasst. IaC ermöglicht Teams, Änderungen schneller und sicherer zu entwickeln und freizugeben. Vorteile von IaC:

  • Höheres Vertrauen in Bereitstellungen
  • Möglichkeit zur Verwaltung mehrerer Umgebungen
  • Verbessertes Verständnis des Zustands der Infrastruktur

Weitere Informationen zu den Vorteilen der Verwendung von Infrastructure-as-Code finden Sie unter Wiederholbare Infrastruktur.

Tools

Es gibt zwei Ansätze, die Sie beim Implementieren von Infrastructure-as-Code verfolgen können.

  • Imperative Infrastructure-as-Code umfasst das Schreiben von Skripts in Sprachen wie Bash oder PowerShell. Sie geben explizit Befehle an, die ausgeführt werden sollen, um ein gewünschtes Ergebnis zu erzielen. Wenn Sie imperative Bereitstellungen verwenden, müssen Sie die Abfolge von Abhängigkeiten, Fehlerkontrolle und Ressourcenupdates einhalten.
  • Deklarative Infrastructure-as-Code umfasst das Schreiben einer Definition, wie Ihre Umgebung aussehen soll. In dieser Definition geben Sie anstelle von Verfahren das gewünschte Ergebnis an. Das Tool ermittelt dann, wie das Ergebnis erreicht werden kann, indem es den aktuellen Zustand überprüft, mit dem gewünschten Zielzustand vergleicht und dann die Unterschiede anwendet.

ARM-Vorlagen

Lesen Sie die Informationen zu Azure Resource Manager-Vorlagen (ARM-Vorlagen).

Bicep

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, zusammen mit ihren Eigenschaften. Im Vergleich zu ARM-Vorlagen sind Bicep-Dateien für Zielgruppen ohne Entwicklungserfahrung einfacher zu lesen und zu schreiben, da darin eine präzise Syntax verwendet wird.

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'
  }
}

Terraform

Lesen Sie die Informationen zu Terraform.

Azure CLI

Lesen Sie die Informationen zur Azure-Befehlszeilenschnittstelle.

IaC-Module (Infrastructure-as-Code)

Eines der Ziele der Verwendung von Code zur Bereitstellung von Infrastruktur besteht darin, doppelte Arbeit oder das Erstellen mehrerer Vorlagen für dieselben oder ähnliche Zwecke zu vermeiden. Infrastrukturmodule sollten wiederverwendbar und flexibel sein und einen klaren Zweck haben.

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

Bicep-Module

Mit Bicep können Sie Module erstellen und aufrufen. Nachdem ein Modul erstellt wurde, kann es von jeder anderen Bicep-Vorlage genutzt werden. In einem hochwertigen Bicep-Modul sollten mehrere verwandte Ressourcen definiert sein. 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 Ressourcengruppe, sodass Sie sie als Modul definieren sollten.

Folgendes wird in Bicep-Modulen häufig verwendet:

  • Parameter zum Akzeptieren von Werten aus einem aufrufenden Modul
  • Ausgabewerte zum Zurückgeben von Ergebnissen an ein aufrufende Modul
  • Ressourcen zum Definieren mindestens eines Infrastrukturobjekts, das von einem Modul verwaltet wird

Veröffentlichen von Bicep-Modulen

Sie haben mehrere Möglichkeiten, Bicep-Module zu veröffentlichen und freizugeben:

  • Öffentliche Registrierung: Die öffentliche Modulregistrierung wird in einer Microsoft-Containerregistrierung (MCR) gehostet. Der Quellcode und die enthaltenen Module werden auf GitHub gespeichert.
  • Private Registrierung: Sie können Azure Container Registry verwenden, um Module in einer privaten Registrierung zu veröffentlichen. Informationen zum Veröffentlichen von Modulen in einer Registrierung einer CI/CD-Pipeline finden Sie unter Bicep und GitHub Actions oder unter Bicep und Azure Pipelines.
  • Vorlagenspezifikation: Sie können Vorlagenspezifikationen verwenden, um Bicep-Module zu veröffentlichen. Vorlagenspezifikationen sind als vollständige Vorlagen konzipiert, Bicep ermöglicht Ihnen aber, Vorlagenspezifikationen auch zum Bereitstellen von Modulen zu verwenden.
  • Versionskontrollsystem: Sie können Module direkt über Tools zur Versionskontrolle wie GitHub oder Azure DevOps laden.

Terraform-Module

Mit Terraform können Sie Module erstellen und aufrufen. Jede Terraform-Konfiguration umfasst mindestens ein Modul, das als Stammmodul bezeichnet wird und aus Ressourcen besteht, die in .tf-Dateien im Hauptarbeitsverzeichnis definiert sind. Jedes Modul kann andere Module aufrufen, sodass Sie untergeordnete Module in Ihre Hauptkonfigurationsdatei einschließen können. Module können auch mehrmals innerhalb derselben Konfiguration oder aus unterschiedlichen Konfigurationen aufgerufen werden.

Module werden mit allen Konfigurationskonzepten derselben Sprache definiert. Folgendes wird darin am häufigsten verwendet:

  • Eingabevariablen zum Akzeptieren von Werten aus einem aufrufenden Modul
  • Ausgabewerte zum Zurückgeben von Ergebnissen an ein aufrufende Modul
  • Ressourcen zum Definieren mindestens eines Infrastrukturobjekts, das von einem Modul verwaltet wird

Veröffentlichen von Terraform-Modulen

Sie haben mehrere Möglichkeiten, Terraform-Module zu veröffentlichen und freizugeben:

  • Öffentliche Registrierung: HashiCorp verfügt über eine eigene Terraform-Modulregistrierung, mit der Benutzer*innen Terraform-Module für die Freigabe generieren können. Derzeit sind mehrere Azure-Module in der Terraform-Modulregistrierung veröffentlicht.
  • Private Registrierung: Sie können Terraform-Module nahtlos in einem privaten Repository wie Terraform Cloud Private Registry oder Azure Container Registry veröffentlichen.
  • Versionskontrollsystem: Sie können private Module direkt über Tools zur Versionskontrolle wie GitHub laden. Informationen zu den unterstützten Quellen finden Sie unter Terraform-Modulquellen.

Überlegungen zum Entwurf

  • Erwägen Sie die Verwendung von IaC beim Bereitstellen von Zielzonenressourcen in Azure. Mit IaC realisieren Sie die gesamte Bereitstellungsoptimierung, reduzieren den Konfigurationsaufwand und automatisieren die Bereitstellungen in der gesamten Umgebung.

  • Bestimmen Sie, ob Sie einen imperativen oder deklarativen IaC-Ansatz anwenden möchten.

    • Wenn Sie einen imperativen Ansatz verfolgen, geben Sie explizit die Befehle an, die zum Erreichen Ihres gewünschten Ergebnisses ausgeführt werden müssen.

    • Bei einem deklarativen Ansatz geben Sie Ihr gewünschtes Ergebnis und nicht die Vorgehensweise an.

  • Erwägen Sie die Anwendung von Bereitstellungsbereichen. Sie sollten mit den Azure-Verwaltungsebenen und -hierarchien tiefgehend vertraut sein. Für jede IaC-Bereitstellung muss der Bereich bekannt sein, in dem Azure-Ressourcen bereitgestellt werden.

  • Bestimmen Sie, ob Sie ein natives Azure-IaC-Tool oder ein externes Tool verwenden möchten. Zu berücksichtigende Punkte:

    • Native Azure-Tools wie die Azure-Befehlszeilenschnittstelle, ARM-Vorlagen und Bicep werden vollständig von Microsoft unterstützt, sodass neue Features schneller integriert werden können.

    • Nicht native Tools wie Terraform ermöglichen Ihnen, Infrastructure-as-Code bei mehreren Cloudanbietern wie AWS oder GCP zu verwalten. Die Übernahme neuer Azure-Features kann bei nicht nativen Systemen jedoch einige Zeit in Anspruch nehmen. Wenn Ihre Organisation mehrere Clouds oder bereits Terraform verwendet und damit vertraut ist, sollten Sie Terraform verwenden, um Azure-Zielzonen bereitzustellen.

  • Da Sie mit Modulen komplexe Vorlagen in kleinere Codeabschnitte unterteilen können, sollten Sie für Ressourcen, die gemeinsam bereitgestellt werden, IaC-Module verwenden. So können Sie sicherstellen, dass jedes Modul sich auf eine bestimmte Aufgabe bezieht und für mehrere Bereitstellungen und Workloads wiederverwendbar ist.

  • Legen Sie auch eine Veröffentlichungsstrategie für IaC-Module fest, und entscheiden Sie sich dabei zwischen öffentlichen Registrierungen, privaten Registrierungen oder einem Versionskontrollsystem wie einem Git-Repository.

  • Ziehen Sie auch die Verwendung einer CI/CD-Pipeline für IaC-Bereitstellungen in Betracht. Eine Pipeline erzwingt den von Ihnen festgelegten, wiederverwendbaren Prozess, sodass Sie damit die Qualität Ihrer Bereitstellungen und Ihrer Azure-Umgebung sicherstellen können.

Entwurfsempfehlungen

  • Verfolgen Sie bei Bereitstellung, Verwaltung, Steuerung und Support von Azure-Zielzonen einen IaC-Ansatz.

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

    • Sie möchten nur native Azure-Tools verwenden. Ihre Organisation verfügt möglicherweise über Erfahrungen aus früheren ARM- oder Bicep-Vorlagenbereitstellungen.

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

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

    • Ihre Organisation verwendet derzeit Terraform, um Infrastruktur in anderen Clouds wie AWS oder GCP bereitzustellen.

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

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

  • In den folgenden Szenarien können Sie IaC-Module aus öffentlichen Registrierungen veröffentlichen und verwenden:

    • Sie möchten Module für Azure-Zielzonen verwenden, die bereits in öffentlichen Registrierungen veröffentlicht wurden. Weitere Informationen finden Sie unter Terraform-Modul für Azure-Zielzonen.

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

      • Stellen Sie sicher, dass Sie die Supporthinweise von jedem Modulanbieter überprüfen, den Sie auswerten.

  • In den folgenden Szenarien können Sie IaC-Module aus privaten Registrierungen oder Versionskontrollsystemen veröffentlichen und verwenden:

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

    • Sie benötigen volle Kontrolle über alle Features und möchten neue Versionen von Modulen selbst verwalten, aktualisieren und veröffentlichen.

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