Freigeben über

Bereitstellen eines Aspire-Projekts auf Azure Container Apps unter Verwendung des Azure Developer CLI (ausführlicher Leitfaden)

Azure Developer CLI(azd) wurde erweitert, um die Bereitstellung von Aspire-Projekten zu unterstützen. Verwenden Sie dieses Handbuch, um den Prozess des Erstellens und Bereitstellens eines Aspire-Projekts auf Azure Container Apps mithilfe des Azure Developer CLI zu durchlaufen. In diesem Lernprogramm lernen Sie die folgenden Konzepte kennen:

  • Erfahren Sie, wie azd die Integration mit Aspire Projekten funktioniert
  • Bereitstellen und Implementieren von Ressourcen auf Azure für ein Aspire Projekt mit azd
  • Generieren von Bicep-Infrastruktur und anderen Vorlagendateien mithilfe von azd

Voraussetzungen

Um mit Aspireihnen zu arbeiten, benötigen Sie folgendes lokal installiert:

Weitere Informationen finden Sie unter Aspire Setup und Tooling und Aspire SDK.

Außerdem müssen Sie die Azure Developer CLIinstallation lokal ausführen. Zu den allgemeinen Installationsoptionen gehören die folgenden:

winget install microsoft.azd

Wie Azure Developer CLI Integration funktioniert

Der azd init Workflow bietet angepasste Unterstützung für Aspire Projekte. Das folgende Diagramm veranschaulicht, wie dieser Fluss konzeptionell funktioniert und wie azd und Aspire integriert wird:

Darstellung des internen Verarbeitungsprozesses von

  1. Wenn azd ein Aspire Projekt anvisiert, startet es den AppHost mit einem speziellen Befehl (dotnet run --project AppHost.csproj --output-path manifest.json --publisher manifest), der die AspireManifestdatei erzeugt.
  2. Die Manifestdatei wird von der azd provision Unterbefehlslogik abgefragt, um nur Bicep-Dateien im Arbeitsspeicher zu generieren (standardmäßig).
  3. Nach dem Generieren der Bicep-Dateien wird eine Bereitstellung mithilfe der ARM-APIs von Azure für das zuvor angegebene Abonnement und die Ressourcengruppe ausgelöst.
  4. Nachdem die zugrunde liegenden Azure Ressourcen konfiguriert wurden, wird die azd deploy Unterbefehlslogik ausgeführt, die dieselbe Aspire Manifestdatei verwendet.
  5. Im Zuge der Bereitstellung ruft azd eine integrierte Unterstützung für die Containerveröffentlichung von dotnet publish auf, um Container-Images zu generieren.
  6. Nachdem azd die Containerimages erstellt hat, überträgt es sie an das ACR-Registry, das während der Bereitstellungsphase erstellt wurde.
  7. Nachdem sich das Containerimage in ACR befindet, aktualisiert azd die Ressource mit ARM, um mit der Nutzung der neuen Version des Containerimages zu beginnen.

Hinweis

azd ermöglicht Ihnen auch, die generierte Bicep in einen infra Ordner Ihres Projekts zu exportieren, über den Sie mehr im Abschnitt Generieren von Bicep aus dem Aspire App-Modell lesen können.

Einrichten und Bereitstellen einer Aspire Starter-App

Die Schritte in diesem Abschnitt veranschaulichen, wie Sie eine Aspire Startanwendung erstellen und die Bereitstellung und Implementierung der App-Ressourcen für Azure mithilfe von azd bearbeiten.

Erstellen der Aspire Start-App

Erstellen Sie ein neues Aspire Projekt mit dem dotnet new Befehl. Sie können das Projekt auch mithilfe von Visual Studio.

dotnet new aspire-starter --use-redis-cache -o AspireSample
cd AspireSample
dotnet run --project AspireSample.AppHost\AspireSample.AppHost.csproj

Die vorherigen Befehle erstellen ein neues Aspire Projekt basierend auf der aspire-starter Vorlage, die eine Abhängigkeit vom Redis Cache enthält. Es führt das Aspire Projekt aus, das überprüft, ob alles ordnungsgemäß funktioniert.

Initialisieren der Vorlage

  1. Öffnen Sie ein neues Terminalfenster und cd in das Verzeichnis Ihrer Aspire Lösung.

  2. Führen Sie den befehl azd init aus, um Ihr Projekt mit azdzu initialisieren, wodurch die lokale Verzeichnisstruktur überprüft und der App-Typ bestimmt wird.

    azd init

    Weitere Informationen zum azd init-Befehl finden Sie unter azd init.

  3. Wählen Sie "Code im aktuellen Verzeichnis verwenden" aus, wenn azd Ihnen drei Optionen zur App-Initialisierung angeboten werden.

    ? How do you want to initialize your app?  [Use arrows to move, type to filter]
> Use code in the current directory
  Select a template
  Create a minimal project

  4. Nach dem Scannen des Verzeichnisses werden Sie aufgefordert, zu bestätigen, azd dass es das richtige AspireAppHost-Projekt gefunden hat. Wählen Sie die Option Bestätigen und mit der Initialisierung meiner App fortfahren.

    Detected services:

  .NET (Aspire)
  Detected in: D:\source\repos\AspireSample\AspireSample.AppHost\AspireSample.AppHost.csproj

azd will generate the files necessary to host your app on Azure using Azure Container Apps.

? Select an option  [Use arrows to move, type to filter]
> Confirm and continue initializing my app
  Cancel and exit

  5. Geben Sie einen Umgebungsnamen ein, der verwendet wird, um bereitgestellte Ressourcen in Azure zu benennen und verschiedene Umgebungen wie dev und prodzu verwalten.

    Generating files to run your app on Azure:

  (✓) Done: Generating ./azure.yaml
  (✓) Done: Generating ./next-steps.md

SUCCESS: Your app is ready for the cloud!
You can provision and deploy your app to Azure by running the azd up command in this directory. For more information on configuring your app, see ./next-steps.md

azd generiert eine Reihe von Dateien und platziert sie in das Arbeitsverzeichnis. Diese Dateien sind:

  • azure.yaml: Beschreibt die Dienste der App, z. B. Aspire AppHost-Projekt, und ordnet sie Azure Ressourcen zu.
  • .azure/config.json: Konfigurationsdatei, die azd informiert, was die aktuelle aktive Umgebung ist.
  • .azure/aspireazddev/.env: Enthält umgebungsspezifische Überschreibungen.

Die Datei "azure.yaml " hat den folgenden Inhalt:

# yaml-language-server: $schema=https://raw.githubusercontent.com/Azure/azure-dev/main/schemas/v1.0/azure.yaml.json

name: AspireSample
services:
  app:
    language: dotnet
    project: .\AspireSample.AppHost\AspireSample.AppHost.csproj
    host: containerapp

Ressourcen-Namensgebung

Wenn Sie neue Azure Ressourcen erstellen, ist es wichtig, die Benennungsanforderungen zu erfüllen. Für Azure Container Apps muss der Name zwischen 2 und 32 Zeichen lang sein und aus Kleinbuchstaben, Zahlen und Bindestrichen bestehen. Der Name muss mit einem Buchstaben beginnen und mit einem alphanumerischen Zeichen enden.

Weitere Informationen finden Sie unter Benennungsregeln und Einschränkungen für Azure Ressourcen.

Erste Bereitstellung

  1. Um das Aspire Projekt bereitzustellen, authentifizieren Sie sich bei Azure AD, um die Ressourcenverwaltungs-APIs Azure aufzurufen.

    azd auth login

    Der vorherige Befehl startet einen Browser, um die Befehlszeilensitzung zu authentifizieren.

  2. Führen Sie nach der Authentifizierung den folgenden Befehl aus dem AppHost-Projektverzeichnis aus, um die Anwendung bereitzustellen und bereitzufügen.

    azd up

    Von Bedeutung

    Um Container-Images an die Azure Containerregistrierung (Container Registry, ACR) zu übertragen, müssen Sie Microsoft.Authorization/roleAssignments/write Zugriff haben. Dies kann erreicht werden, indem ein Administratorbenutzer in der Registrierung aktiviert wird. Öffnen Sie das Azure Portal, navigieren Sie zu der ACR-Ressource /Einstellungen/Zugriffstasten, und aktivieren Sie dann das Kontrollkästchen "Administratorbenutzer ". Weitere Informationen finden Sie unter "Administratorbenutzer aktivieren".

  3. Wenn Sie dazu aufgefordert werden, wählen Sie das Abonnement und den Speicherort aus, in dem die Ressourcen bereitgestellt werden sollen. Sobald diese Optionen ausgewählt sind, wird das Aspire Projekt bereitgestellt.

    By default, a service can only be reached from inside the Azure Container Apps environment it is running in. Selecting a service here will also allow it to be reached from the Internet.
? Select which services to expose to the Internet webfrontend
? Select an Azure Subscription to use:  1. <YOUR SUBSCRIPTION>
? Select an Azure location to use: 1. <YOUR LOCATION>

Packaging services (azd package)


Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Subscription: <YOUR SUBSCRIPTION>
Location: <YOUR LOCATION>

  You can view detailed progress in the Azure Portal:
  <LINK TO DEPLOYMENT>

  (✓) Done: Resource group: <YOUR RESOURCE GROUP>
  (✓) Done: Container Registry: <ID>
  (✓) Done: Log Analytics workspace: <ID>
  (✓) Done: Container Apps Environment: <ID>

SUCCESS: Your application was provisioned in Azure in 1 minute 13 seconds.
You can view the resources created under the resource group <YOUR RESOURCE GROUP> in Azure Portal:
<LINK TO RESOURCE GROUP OVERVIEW>

Deploying services (azd deploy)

  (✓) Done: Deploying service apiservice
  - Endpoint: <YOUR UNIQUE apiservice APP>.azurecontainerapps.io/

  (✓) Done: Deploying service webfrontend
  - Endpoint: <YOUR UNIQUE webfrontend APP>.azurecontainerapps.io/

Aspire Dashboard: <LINK TO DEPLOYED Aspire DASHBOARD>

SUCCESS: Your up workflow to provision and deploy to Azure completed in 3 minutes 50 seconds.

    Die letzte Ausgabezeile des azd Befehls ist ein Link zum Azure Portal, der alle Azure bereitgestellten Ressourcen anzeigt:

    Screenshot des Azure Portals mit bereitgestellten Ressourcen.

In dieser Anwendung werden drei Container bereitgestellt:

  • webfrontend: Enthält Code aus dem Webprojekt in der Startvorlage.
  • apiservice: Enthält Code aus dem API-Dienstprojekt in der Startvorlage.
  • cache: Ein Redis Containerimage zum Bereitstellen eines Caches an das Front-End.

Genau wie bei der lokalen Entwicklung wurde die Konfiguration von Verbindungszeichenfolgen automatisch behandelt. In diesem Fall azd war verantwortlich für die Interpretation des Anwendungsmodells und die Übersetzung in die entsprechenden Bereitstellungsschritte. Betrachten Sie beispielsweise die Verbindungszeichenfolgen und Dienstermittlungsvariablen, die in den webfrontend Container eingefügt werden, damit er weiß, wie er eine Verbindung mit dem Redis Cache und apiservice herstellen kann.

Screenshot von Umgebungsvariablen in der Webfrontend-Container-App.

Weitere Informationen dazu, wie Aspire Projekte Verbindungszeichenfolgen und Dienstermittlung behandeln, finden Sie in Aspire der Übersicht über die Orchestrierung.

Bereitstellen von Anwendungsupdates

Wenn der azd up Befehl ausgeführt wird, werden die zugrunde liegenden Azure Ressourcen bereitgestellt , und ein Containerimage wird erstellt und in den Container-Apps bereitgestellt , die das Aspire Projekt hosten. Normalerweise wird, sobald die Entwicklung im Gange ist und Azure Ressourcen bereitgestellt sind, es nicht erforderlich sein, bei jeder Aktualisierung des Codes Azure Ressourcen bereitzustellen. Dies gilt insbesondere für die interne Schleife des Entwicklers.

Um die Bereitstellung von Codeänderungen zu beschleunigen, azd unterstützt die Bereitstellung von Codeupdates im Containerimage. Dazu wird der azd deploy Befehl verwendet:

azd deploy

Deploying services (azd deploy)

  (✓) Done: Deploying service apiservice
  - Endpoint: <YOUR UNIQUE apiservice APP>.azurecontainerapps.io/

  (✓) Done: Deploying service webfrontend
  - Endpoint: <YOUR UNIQUE webfrontend APP>.azurecontainerapps.io/

Aspire Dashboard: <LINK TO DEPLOYED Aspire DASHBOARD>

Es ist nicht erforderlich, alle Dienste jedes Mal bereitzustellen. azd versteht das Aspire Projektmodell, es ist möglich, nur einen der mit dem folgenden Befehl angegebenen Dienste bereitzustellen:

azd deploy webfrontend

Weitere Informationen finden Sie unter Azure Developer CLI Referenz: azd deploy.

Bereitstellen von Infrastrukturupdates

Wenn sich die Abhängigkeitsstruktur innerhalb eines Aspire Projekts ändert, azd müssen die zugrunde liegenden Azure Ressourcen erneut bereitgestellt werden. Der azd provision Befehl wird verwendet, um diese Änderungen auf die Infrastruktur anzuwenden.

Um dies in Aktion zu sehen, aktualisieren Sie die AppHost.cs Datei im AppHost-Projekt wie folgt:

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

// Add the locations database.
var locationsdb = builder.AddPostgres("db").AddDatabase("locations");

// Add the locations database reference to the API service.
var apiservice = builder.AddProject<Projects.AspireSample_ApiService>("apiservice")
    .WithReference(locationsdb);

builder.AddProject<Projects.AspireSample_Web>("webfrontend")
    .WithReference(cache)
    .WithReference(apiservice);

builder.Build().Run();

Speichern Sie die Datei, und stellen Sie den folgenden Befehl aus:

azd provision

Der azd provision Befehl aktualisiert die Infrastruktur, indem eine Container-App zum Hosten der Postgres Datenbank erstellt wird. Der azd provision Befehl hat die Verbindungszeichenfolgen für den apiservice Container nicht aktualisiert. Damit Verbindungszeichenfolgen so aktualisiert werden, dass sie auf die neu bereitgestellte Postgres Datenbank verweisen, muss der azd deploy Befehl erneut aufgerufen werden. Verwenden Sie im Zweifelsfall azd up, um sowohl die Bereitstellung als auch den Einsatz durchzuführen.

Bereinigen von Ressourcen

Denken Sie daran, die Azure Ressourcen zu bereinigen, die Sie während dieser Schritt-für-Schritt-Anleitung erstellt haben. Da azd die Ressourcengruppe kennt, in der es die Ressourcen erstellt hat, kann es zum Herunterfahren der Umgebung mit dem folgenden Befehl verwendet werden:

azd down

Der vorherige Befehl kann einige Zeit in Anspruch nehmen, aber sobald er abgeschlossen ist, sollten die Ressourcengruppe und alle zugehörigen Ressourcen gelöscht werden.

Deleting all resources and deployed code on Azure (azd down)
Local application code is not deleted when running 'azd down'.

  Resource group(s) to be deleted:

    • <YOUR RESOURCE GROUP>: <LINK TO RESOURCE GROUP OVERVIEW>

? Total resources to delete: 7, are you sure you want to continue? Yes
Deleting your resources can take some time.

  (✓) Done: Deleting resource group: <YOUR RESOURCE GROUP>

SUCCESS: Your application was removed from Azure in 9 minutes 59 seconds.

Generieren von Bicep aus dem Aspire Projektmodell

Obwohl Entwicklungsteams die Befehle azd up (oder azd provision und azd deploy) sowohl für Entwicklungs- als auch für Produktionszwecke frei verwenden können, entscheiden sich einige Teams dafür, Bicep-Dateien zu erstellen, die sie im Rahmen der Versionssteuerung überprüfen und verwalten können (dies ermöglicht auch, dass auf diese Bicep-Dateien als Teil einer größeren, komplexeren Azure Bereitstellung verwiesen wird).

Umfassende Anleitungen zum Anpassen der generierten Infrastruktur für Produktionsszenarien finden Sie unter Anpassen von AspireAzure Bereitstellungen.

azd umfasst die Möglichkeit, den Bicep-Code auszugeben, der für die Bereitstellung mittels des folgenden Befehls verwendet wird:

azd config set alpha.infraSynth on
azd infra gen

Nachdem dieser Befehl im Beispiel der Startvorlage in diesem Leitfaden ausgeführt wurde, werden die folgenden Dateien im AppHost-Projektverzeichnis erstellt:

  • infra/main.bicep: Stellt den Haupteinstiegspunkt für die Bereitstellung dar.
  • infra/main.parameters.json: Wird als Parameter für die Haupt-Bicep verwendet (ordnet Umgebungsvariablen zu, die im Azure-Ordner definiert sind).
  • infra/resources.bicep: Definiert die ressourcen, die Azure für die Unterstützung des Aspire Projektmodells erforderlich sind.
  • AspireSample.Web/manifests/containerApp.tmpl.yaml: Die Container-App-Definition für webfrontend.
  • AspireSample.ApiService/manifests/containerApp.tmpl.yaml: Die Container-App-Definition für apiservice.

Die Datei "infra\resources.bicep " enthält keine Definition der Container-Apps selbst (mit Ausnahme von Container-Apps, die als Abhängigkeiten fungieren, wie Redis und Postgres):

@description('The location used for all deployed resources')
param location string = resourceGroup().location

@description('Tags that will be applied to all resources')
param tags object = {}

var resourceToken = uniqueString(resourceGroup().id)

resource managedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: 'mi-${resourceToken}'
  location: location
  tags: tags
}

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2023-07-01' = {
  name: replace('acr-${resourceToken}', '-', '')
  location: location
  sku: {
    name: 'Basic'
  }
  tags: tags
}

resource caeMiRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(containerRegistry.id, managedIdentity.id, subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d'))
  scope: containerRegistry
  properties: {
    principalId: managedIdentity.properties.principalId
    principalType: 'ServicePrincipal'
    roleDefinitionId:  subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d')
  }
}

resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: 'law-${resourceToken}'
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
  tags: tags
}

resource containerAppEnvironment 'Microsoft.App/managedEnvironments@2023-05-01' = {
  name: 'cae-${resourceToken}'
  location: location
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalyticsWorkspace.properties.customerId
        sharedKey: logAnalyticsWorkspace.listKeys().primarySharedKey
      }
    }
  }
  tags: tags
}

resource cache 'Microsoft.App/containerApps@2023-05-02-preview' = {
  name: 'cache'
  location: location
  properties: {
    environmentId: containerAppEnvironment.id
    configuration: {
      service: {
        type: 'redis'
      }
    }
    template: {
      containers: [
        {
          image: 'redis'
          name: 'redis'
        }
      ]
    }
  }
  tags: union(tags, {'aspire-resource-name': 'cache'})
}

resource locations 'Microsoft.App/containerApps@2023-05-02-preview' = {
  name: 'locations'
  location: location
  properties: {
    environmentId: containerAppEnvironment.id
    configuration: {
      service: {
        type: 'postgres'
      }
    }
    template: {
      containers: [
        {
          image: 'postgres'
          name: 'postgres'
        }
      ]
    }
  }
  tags: union(tags, {'aspire-resource-name': 'locations'})
}
output MANAGED_IDENTITY_CLIENT_ID string = managedIdentity.properties.clientId
output AZURE_CONTAINER_REGISTRY_ENDPOINT string = containerRegistry.properties.loginServer
output AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID string = managedIdentity.id
output AZURE_CONTAINER_APPS_ENVIRONMENT_ID string = containerAppEnvironment.id
output AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN string = containerAppEnvironment.properties.defaultDomain

Weitere Informationen zur Verwendung von Bicep zur Automatisierung von Bereitstellungen finden Sie unter Azure, „Was ist Bicep?“

Die Definition der Container-Apps aus den .NET Dienstprojekten ist in den containerApp/tmpl.yaml-Dateien im manifests Verzeichnis in jedem Projekt enthalten. Hier ist ein Beispiel aus dem webfrontend Projekt:

location: {{ .Env.AZURE_LOCATION }}
identity:
  type: UserAssigned
  userAssignedIdentities:
    ? "{{ .Env.AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID }}"
    : {}
properties:
  environmentId: {{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_ID }}
  configuration:
    activeRevisionsMode: single
    ingress:
      external: true
      targetPort: 8080
      transport: http
      allowInsecure: false
    registries:
    - server: {{ .Env.AZURE_CONTAINER_REGISTRY_ENDPOINT }}
      identity: {{ .Env.AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID }}
  template:
    containers:
    - image: {{ .Env.SERVICE_WEBFRONTEND_IMAGE_NAME }}
      name: webfrontend
      env:
      - name: AZURE_CLIENT_ID
        value: {{ .Env.MANAGED_IDENTITY_CLIENT_ID }}
      - name: ConnectionStrings__cache
        value: {{ connectionString "cache" }}
      - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES
        value: "true"
      - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES
        value: "true"
      - name: APISERVICE_HTTP
        value: http://apiservice.internal.{{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN }}
      - name: APISERVICE_HTTPS
        value: https://apiservice.internal.{{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN }}
      - name: services__apiservice__http__0
        value: http://apiservice.internal.{{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN }}
      - name: services__apiservice__https__0
        value: https://apiservice.internal.{{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN }}
tags:
  azd-service-name: webfrontend
  aspire-resource-name: webfrontend

Nachdem der azd infra gen Befehl ausgeführt wurde, verwenden azd provision und azd deploy die Bicep- und unterstützenden generierten Dateien, wenn sie aufgerufen werden.

Von Bedeutung

Wenn azd infra gen erneut aufgerufen wird, ersetzt es alle geänderten Dateien durch neu generierte und fordert eine Bestätigung an, bevor es dies tut.

Isolierte Umgebungen für das Debuggen

Da azd es einfacher ist, neue Umgebungen bereitzustellen, ist es für jedes Teammitglied möglich, eine isolierte cloudgehostete Umgebung für das Debuggen von Code in einer Einstellung zu haben, die eng mit der Produktion übereinstimmt. Wenn Sie dies tun, sollte jedes Teammitglied eine eigene Umgebung mit dem folgenden Befehl erstellen:

azd env new

Dadurch wird der Benutzer erneut aufgefordert, Abonnement- und Informationen zur Ressourcengruppe einzugeben. Nachfolgende azd up, azd provision und azd deploy Aufrufe verwenden diese neue Umgebung standardmäßig. Der --environment Schalter kann auf diese Befehle angewendet werden, um zwischen Umgebungen zu wechseln.

Bereinigen von Ressourcen

Führen Sie den folgenden Azure CLI-Befehl aus, um die Ressourcengruppe zu löschen, wenn Sie die von Ihnen erstellten Azure Ressourcen nicht mehr benötigen. Durch das Löschen der Ressourcengruppe werden auch die darin enthaltenen Ressourcen gelöscht.

az group delete --name <your-resource-group-name>

Weitere Informationen finden Sie unter Ressourcen bereinigen in Azure.

  • Last updated on