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 Ebenen sequenziell in der Reihenfolge fest, in der Sie sie definieren. 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

Führen Sie azd provision ohne Argumente aus, um alle Ebenen sequenziell in der Reihenfolge bereitzustellen, in azure.yamlder sie definiert sind:

azd provision

azd verarbeitet jede Ebene einzeln, um sicherzustellen, dass die erste Ebene abgeschlossen ist, bevor die zweite Ebene beginnt. 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 werden sie in umgekehrter Reihenfolge verarbeitet, 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

Überlegungen und Einschränkungen

• Bei der Bereitstellung aller Ebenen verarbeitet azd sie in der von Ihnen definierten Reihenfolge nacheinander. Planen Sie die Schichtreihenfolge so, dass grundlegende Ressourcen zuerst bereitgestellt werden.
• Beim Abreißen aller Schichten werden azd sie in umgekehrter Reihenfolge verarbeitet.
  • 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 geschichteter Infrastruktur zu ermöglichen, aktivieren Sie Bereitstellungsstapel mithilfe des Befehls azd config set alpha.deployment.stacks on, sodass azd Ressourcen pro Ebene nachverfolgen kann, anstatt sich allein auf die Löschung von Ressourcengruppen zu stützen.
• 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.
• 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