Mehrschichtbereitstellung

Azure Developer CLI (azd) unterstützt die mehrschichtige Bereitstellung, mit der Sie mehrere Bereitstellungsebenen in Ihrer azure.yaml Datei definieren können. Jede Ebene verweist auf einen eigenen Satz von Infrastructure as Code (IaC)-Vorlagen. Die CLI stellt die Ebenen jeweils einzeln bereit, entsprechend den Abhängigkeiten zwischen ihnen. Sie können einzelne Ebenen auch unabhängig bereitstellen oder abbauen.

Dieses Feature löst komplexe Abhängigkeitsszenarien, in denen Ressourcen in einer Ebene von Ressourcen von einer anderen Ebene abhängen. Anstatt IaC mit imperativen Hook-Skripten zu mischen, bleibt durch schichtweise Bereitstellung alles deklarativ.

Wann sollte mehrschichtige Bereitstellung verwendet werden?

Verwenden Sie die Mehrschichtbereitstellung, wenn eine einzelne azd provision Bereitstellung nicht alle Infrastrukturanforderungen in einem Schritt verarbeiten kann. Erwägen Sie die Verwendung der mehrschichtigen Bereitstellung in folgenden Fällen:

• Zirkelabhängigkeiten: Einige Ressourcen müssen zuerst auf andere Ressourcen verweisen, z. B. ein virtuelles Netzwerk, das vorhanden sein muss, bevor ein privater Endpunkt konfiguriert werden kann.
• Grundlegende Infrastruktur unterscheidet sich von der Anwendungsinfrastruktur: Sie verwalten gemeinsam genutzte Netzwerke, Sicherheit oder Identitätsressourcen getrennt von Anwendungsressourcen.
• Eine unabhängige Lebenszyklusverwaltung ist erforderlich: Sie aktualisieren und zerreißen unterschiedliche Infrastrukturkomponenten zu unterschiedlichen Zeiten. Beispielsweise kann eine Netzwerkebene langlebig sein, während eine Anwendungsschicht häufig erneut bereitgestellt wird.
• Monorepo-Projekte mit unterschiedlichen Infrastrukturgruppen: Ein einzelnes Repository enthält mehrere unabhängige Dienste (z. B. einen Event Hub, eine Container-App und eine Funktions-App) mit jeweils eigenen Infrastrukturvorlagen.

Konfigurieren von Ebenen in azure.yaml

Definieren Sie Ebenen unter dem infra Abschnitt Ihrer azure.yaml Datei. Für jede Ebene ist ein name und ein path Zeiger auf das Verzeichnis erforderlich, das die IaC-Vorlagen für diese Ebene enthält.

name: my-app
infra:
  layers:
    - name: networking
      path: ./infra/networking
    - name: application
      path: ./infra/application
services:
  api:
    project: ./src/api
    language: js
    host: containerapp

Layereigenschaften

Jede Ebene unterstützt die folgenden Eigenschaften:

Verzeichnisstruktur

Ein typisches Projekt mit layered provisioning kann die folgende Verzeichnisstruktur aufweisen:

my-app/
├── azure.yaml
├── infra/
│   ├── networking/
│   │   └── main.bicep
│   └── application/
│       └── main.bicep
└── src/
    └── api/
        └── ...

Jedes Layerverzeichnis enthält einen eigenen vollständigen Satz von IaC-Vorlagen, genau wie das Verzeichnis eines Standardprojektsazdinfra.

Bereitstellen und Verwalten von Ebenen

Sie können alle Ebenen auf einmal bereitstellen oder auf eine bestimmte Ebene nach Namen abzielen. In den folgenden Abschnitten werden allgemeine Befehle zum Bereitstellen, Abbauen und Aktualisieren des Layer-Zustands beschrieben.

Bereitstellen aller Ebenen

Ohne Argumente ausführen azd provision , um alle Ebenen bereitzustellen:

azd provision

azd verarbeitet jede Ebene einzeln, um sicherzustellen, dass eine Ebene abgeschlossen wird, bevor eine Ebene beginnt, die von ihr abhängt. Bei Bicep-Layern und benutzerdefinierten oder Erweiterungsanbietern leitet azd Abhängigkeiten aus Umgebungsvariablen und Verweisen auf Layerausgaben in den Dateien *.bicepparam und *.parameters.json ab, sodass sich die Ausführungsreihenfolge von der in azure.yaml aufgeführten Reihenfolge unterscheiden kann. Ebenen ohne abgeleitete oder deklarierte Abhängigkeiten werden in der aufgeführten Reihenfolge ausgeführt. Dieser Prozess garantiert, dass abhängige Ressourcen vorhanden sind, bevor Ebenen bereitgestellt werden, die darauf verweisen.

Bereitstellen einer bestimmten Ebene

Um nur eine bestimmte Ebene bereitzustellen, übergeben Sie den Layernamen als Argument:

azd provision networking

Mit diesem Befehl werden nur die in der networking Ebene definierten Ressourcen bereitgestellt. Die Bereitstellung einer bestimmten Ebene ist nützlich, wenn:

• Während der Entwicklung iterieren Sie auf einer einzigen Schicht.
• Sie müssen eine Ebene aktualisieren, ohne andere erneut bereitzustellen.
• Sie richten eine neue Ebene über der vorhandenen Infrastruktur ein.

Alle Schichten abreißen

Führen Sie azd down ohne Argumente aus, um Ressourcen aus allen Ebenen zu zerreißen. Wenn mehrere Ebenen vorhanden sind, azd verarbeitet sie in umgekehrter Bereitstellungsreihenfolge, sodass abhängige Ressourcen vor den grundlegenden Ressourcen entfernt werden, von denen sie abhängig sind:

azd down

Zerreißen einer bestimmten Schicht

Um nur eine bestimmte Ebene einzureißen, übergeben Sie den Layernamen als Argument:

azd down application

Mit diesem Befehl werden nur die von der application Ebene bereitgestellten Ressourcen entfernt, sodass die anderen Ebenen erhalten bleiben.

Aktualisieren des Umgebungszustands

Sie können den Umgebungszustand von einer bestimmten Ebene erneuern, indem Sie das --layer-Flag mit azd env refresh verwenden.

azd env refresh --layer networking

Mit diesem Befehl werden die Umgebungsvariablen und Ausgaben basierend auf der neuesten Bereitstellung der angegebenen Ebene aktualisiert.

Beispiel: Monorepo mit mehreren Diensten

Im folgenden Beispiel wird die mehrschichtige Bereitstellung für ein Monorepo veranschaulicht, das einen Event Hub, eine Container-App mit mehreren Containern und eine Azure Function App enthält:

name: logging-app
infra:
  layers:
    - name: eventhub
      path: ./infra/eventhub
    - name: aca
      path: ./infra/aca
    - name: functionapp
      path: ./infra/functionapp
services:
  functionapp:
    resourceName: ${site_name}
    language: dotnet
    project: ./src/function/functionapp.csproj
    host: appservice
    resourceGroup: ${rg_name}

Die entsprechende Verzeichnisstruktur:

logging-app/
├── azure.yaml
├── infra/
│   ├── eventhub/
│   │   └── main.bicep
│   ├── aca/
│   │   └── main.bicep
│   └── functionapp/
│       └── main.bicep
└── src/
    └── function/
        └── functionapp.csproj

Mit dieser Konfiguration können Sie:

1. Bereitstellen nur der Event Hub-Infrastruktur: azd provision eventhub
2. Nur die Container-App-Infrastruktur bereitstellen: azd provision aca
3. Stellen Sie alles in der Reihenfolge bereit: azd provision
4. Zerreißen Sie nur die Funktions-App-Ebene: azd down functionapp

Beispiel: Basis- und Anwendungsebenen

Ein gängiges Muster trennt die gemeinsam genutzte oder grundlegende Infrastruktur von der Infrastruktur pro Anwendung:

name: my-app
infra:
  layers:
    - name: base
      path: ./infra/base
    - name: app
      path: ./infra/app
services:
  web:
    project: ./src/web
    language: js
    host: containerapp

Die base Ebene erstellt freigegebene Ressourcen wie Netzwerk, Identität und Überwachung. Die app Ebene erstellt die anwendungsspezifischen Ressourcen (z. B. eine Container-App-Umgebung und Container-Apps), die auf die Basisressourcen verweisen.

Während der Entwicklung können Sie die Basisebene einmal bereitstellen und über die Anwendungsebene iterieren.

azd provision base
azd provision app
azd provision app  # re-provision only the app layer after changes

Beispiel: Gemischte IaC-Anbieter

Jede Ebene kann einen anderen IaC-Anbieter verwenden. Beispielsweise können Sie Bicep für Netzwerke und Terraform für die Anwendungsschicht verwenden:

name: my-app
infra:
  layers:
    - name: networking
      path: ./infra/networking
      provider: bicep
    - name: application
      path: ./infra/application
      provider: terraform

Die integrierten Nicht-Bicep-Anbieter (Terraform, Pulumi, ARM und der Testanbieter) sind für die Abhängigkeitsableitung nicht transparent, da azd ihre Eingaben nicht auf Verweise auf andere Ebenen analysieren kann. Verwenden Sie die explizite Eigenschaft dependsOn, wenn die Reihenfolge zwischen diesen Ebenen oder zwischen diesen Ebenen und anderen Ebenen wichtig ist:

name: my-app
infra:
  layers:
    - name: networking
      path: ./infra/networking
      provider: bicep
    - name: application
      path: ./infra/application
      provider: terraform
      dependsOn:
        - networking

Überlegungen und Einschränkungen

• Wenn Sie alle Ebenen bereitstellen, azd verarbeitet sie jeweils einzeln basierend auf ihren Abhängigkeiten. Für Bicep-Layer und benutzerdefinierte oder Erweiterungsanbieter leitet azd Abhängigkeiten aus Umgebungsvariablen und Verweisen auf Layerausgaben in *.bicepparam- und *.parameters.json-Dateien ab. Ebenen ohne abgeleitete oder deklarierte Abhängigkeiten werden in der von Ihnen definierten Reihenfolge ausgeführt.
• Die integrierten Nicht-Bicep-Anbieter (Terraform, Pulumi, ARM und der Testanbieter) sind für die Abhängigkeitsinferenz undurchsichtig. Verwenden Sie eine explizite dependsOn-Eigenschaft, wenn die Reihenfolge dieser Ebenen wichtig ist.
• Explizit dependsOn ist auch erforderlich, wenn die Reihenfolge wichtig ist, azd die Abhängigkeit jedoch nicht aus Parameterreferenzen ableiten kann. Verwenden Sie dependsOn beispielsweise, wenn der Hook einer Ebene postprovision einen Wert erzeugt, den eine andere Ebene verbraucht, da hook-erzeugte Werte nicht als Ausgabeverweise in *.bicepparam oder *.parameters.json Dateien angezeigt werden.
• Wenn Sie alle Ebenen entfernen, bearbeitet azd sie in umgekehrter Bereitstellungsreihenfolge.
  • Wenn mehrere Ebenen Ressourcen in derselben Azure-Ressourcengruppe bereitstellen und Sie das standardmäßige, ressourcengruppenbasierte Löschverhalten verwenden, werden freigegebene Ressourcen möglicherweise gelöscht, wenn Sie azd down ausführen.
  • Um die unabhängige Nachverfolgung und Löschung von mehrschichtiger Infrastruktur zu ermöglichen, aktivieren Sie Bereitstellungsstapel, indem Sie den Befehl azd config set alpha.deployment.stacks on ausführen.
• Sie können das --preview Kennzeichen nicht verwenden, wenn Sie mehrere Ebenen gleichzeitig bereitstellen. Geben Sie einen <layer> Namen an, der den Vorschaumodus verwenden soll.
• Ebenen funktionieren unabhängig in Bezug auf IaC. Verwenden Sie Umgebungsvariablen, die azd nach der Bereitstellung jeder Ebene festgelegt werden, um auf Ausgaben von einer Ebene in einer anderen Ebene zu verweisen. Der Verweis auf diese Umgebungsvariablen in einer *.bicepparam- oder *.parameters.json-Datei ermöglicht es azd außerdem, die Reihenfolge zwischen den Ebenen zu erschließen.
• Alle Standardbereitstellungsfeatures azd (Bereitstellungsstatuszwischenspeicherung, Hooks, Parameter, Bicep oder Terraform) funktionieren innerhalb jeder einzelnen Ebene.
  • Hooks auf Befehlsebene (z. B. preprovision, postprovision) werden einmal pro Ebene aufgerufen. Wenn mehrere Ebenen definiert sind, werden Hooks für jede Ebene in der Reihenfolge ausgeführt, in der die Ebenen verarbeitet werden.

Nächste Schritte

• Featureversionierung und Releasemanagement-Strategie
• Verwalten von Umgebungsvariablen
• Anpassen von Workflows mithilfe von Befehls- und Ereignishaken