Bereitstellen von Orleans auf Azure App Service

In diesem Lernprogramm erfahren Sie, wie Sie eine Orleans Einkaufswagen-App für Azure App Service bereitstellen. Dieses Handbuch führt Sie durch eine Beispielanwendung, die die folgenden Features unterstützt:

• Einkaufswagen: Eine einfache Einkaufswagenanwendung mit Orleans plattformübergreifender Unterstützung und skalierbaren verteilten Anwendungsfunktionen.

  • Bestandsverwaltung: Bearbeiten und/oder Erstellen des Produktbestands.
  • Shopinventar: Durchstöbern Sie kaufbare Produkte und fügen Sie sie zum Warenkorb hinzu.
  • Warenkorb: Zeigen Sie eine Zusammenfassung aller Artikel im Warenkorb an, und verwalten Sie diese Artikel, indem Sie die Menge der einzelnen Artikel entfernen oder ändern.

Mit einem Verständnis der App und ihrer Features erfahren Sie, wie Sie die App mit GitHub-Aktionen, den .NET- und Azure-CLIs und Azure Bicep auf Azure App Service bereitstellen. Erfahren Sie außerdem, wie Sie das virtuelle Netzwerk für die App in Azure konfigurieren.

In diesem Tutorial lernen Sie Folgendes:

Voraussetzungen

• Ein GitHub-Konto
• Lesen Sie eine Einführung in Orleans
• Das .NET 8 SDK
• Die Azure CLI
• Eine integrierte .NET-Entwicklungsumgebung (IDE)
  • Sie können Visual Studio oder Visual Studio Code verwenden.

Lokales Ausführen der App

Um die App lokal auszuführen, forken Sie das Azure Samples: Orleans Cluster im Repository von Azure App Service und klonen Sie es auf Ihren lokalen Computer. Öffnen Sie die Lösung nach dem Klonen in einer IDE Ihrer Wahl. Wenn Sie Visual Studio verwenden, klicken Sie mit der rechten Maustaste auf das OrleansShoppingCart.Silo-Projekt, wählen Sie "Als Startprojekt festlegen" aus und führen Sie dann die App aus. Führen Sie andernfalls die App mit dem folgenden .NET CLI-Befehl aus:

dotnet run --project Silo\Orleans.ShoppingCart.Silo.csproj

Weitere Informationen finden Sie unter dotnet run. Navigieren Sie, während die App läuft, und testen Sie ihre Funktionen. Alle App-Funktionen bei der lokalen Ausführung basieren auf speicherinterner Persistenz und lokalem Clustering. Es verwendet auch das Bogus NuGet-Paket , um gefälschte Produkte zu generieren. Beenden Sie die App, indem Sie entweder die Option "Debugging beenden " in Visual Studio auswählen oder STRG+C in der .NET CLI drücken.

Innerhalb der Einkaufswagen-App

Orleans ist ein zuverlässiges und skalierbares Framework zum Erstellen verteilter Anwendungen. Stellen Sie für dieses Lernprogramm eine einfache Einkaufswagen-App bereit, die mit Orleans erstellt wurde und auf Azure App Service bereitgestellt wird. Die App bietet die Möglichkeit, Lagerbestände zu verwalten, Artikel in einem Einkaufswagen hinzuzufügen und zu entfernen und verfügbare Produkte zu kaufen. Der Client wird mit Blazor mit einem Serverhostingmodell erstellt. Die App wird wie folgt entwickelt:

Das vorherige Diagramm zeigt, dass der Client die serverseitige Blazor-App ist. Es besteht aus mehreren Diensten, die ein entsprechendes Orleans Getreide verbrauchen. Jeder Dienst wird mit einem Orleans Korn wie folgt zugeordnet:

• InventoryService: Verbraucht das IInventoryGrain, wo der Bestand nach Produktkategorie partitioniert wird.
• ProductService: Verbraucht an der Stelle, wo IProductGrain ein einzelnes Produkt mit einer einzelnen Korninstanz verbunden ist.IdAttribute
• ShoppingCartService: Nutzt den IShoppingCartGrain, wo ein einzelner Benutzer nur eine einzelne Einkaufswageninstanz hat, unabhängig von den benutzenden Clients.

Die Lösung enthält drei Projekte:

• Orleans.ShoppingCart.Abstractions: Eine Klassenbibliothek, die die Modelle und Schnittstellen für die App definiert.
• Orleans.ShoppingCart.Grains: Eine Klassenbibliothek, die die Körner definiert, die die Geschäftslogik der App implementieren.
• Orleans.ShoppingCart.Silos: Eine serverseitige Blazor-App, die das Orleans-Silo verwaltet.

Die Client-Benutzeroberfläche

Die Einkaufswagen-Client-App verfügt über mehrere Seiten, die jeweils eine andere Benutzeroberfläche darstellen. Die Benutzeroberfläche der App wird mithilfe des MudBlazor NuGet-Pakets erstellt.

Homepage

Einige einfache Ausdrücke helfen dabei, den Zweck der App zu verstehen und jedem Navigationsmenüelement Kontext hinzuzufügen.

Shopinventarseite

Eine Seite, auf der alle produkte angezeigt werden, die zum Kauf verfügbar sind. Artikel können dem Warenkorb von dieser Seite hinzugefügt werden.

Leere Einkaufswagenseite

Wenn dem Warenkorb nichts hinzugefügt wurde, wird auf der Seite eine Meldung gerendert, die angibt, dass sich keine Artikel im Warenkorb befinden.

Artikel, die dem Warenkorb hinzugefügt wurden, während sie sich auf der Lagerbestandsseite befinden

Wenn Artikel auf der Inventarseite des Shops dem Warenkorb hinzugefügt werden, zeigt die App eine Meldung an, die angibt, dass der Artikel hinzugefügt wurde.

Produktverwaltungsseite

Verwalten des Inventars von dieser Seite aus. Produkte können hinzugefügt, bearbeitet und aus dem Bestand entfernt werden.

Seite "Produktverwaltung" zum Erstellen eines neuen Dialogfelds

Wenn Sie auf die Schaltfläche " Neues Produkt erstellen" klicken, wird ein Dialogfeld angezeigt, in dem das Erstellen eines neuen Produkts ermöglicht wird.

Artikel auf der Einkaufswagenseite

Wenn sich die Artikel im Warenkorb befinden, können Sie diese ansehen, die Menge ändern und sie sogar entfernen. Eine Zusammenfassung der Artikel im Warenkorb und die Vortax-Gesamtkosten werden angezeigt.

Übersicht über die Bereitstellung

Orleans Anwendungen sind so konzipiert, dass sie effizient hochskaliert und erweitert werden können. Dazu kommunizieren Anwendungsinstanzen direkt über TCP-Sockets. Erfordert daher netzwerkkonnektivität Orleans zwischen Silos. Azure App Service unterstützt diese Anforderung über die Integration des virtuellen Netzwerks und zusätzliche Konfiguration, die App Service anweist, private Netzwerkports für App-Instanzen zuzuweisen.

Führen Sie bei der Orleans Bereitstellung in Azure App Service die folgenden Aktionen aus, um sicherzustellen, dass Hosts kommunizieren können:

• Aktivieren Sie die Integration virtueller Netzwerke, indem Sie den Leitfaden zum Aktivieren der Integration in ein virtuelles Azure-Netzwerk ausführen.
• Konfigurieren Sie die App mit privaten Ports mithilfe der Azure CLI, wie im Abschnitt "Konfigurieren der Anzahl privater Ports mithilfe von Azure CLI " beschrieben. Die Vorlage "Bicep" im Abschnitt " Bicep-Vorlagen erkunden " unten zeigt, wie Sie diese Einstellung über Bicep konfigurieren.
• Stellen Sie bei der Bereitstellung auf Linux sicher, dass Hosts auf allen IP-Adressen lauschen, wie im Abschnitt "Hostnetzwerk konfigurieren " beschrieben.

Konfigurieren der Anzahl privater Ports mit Azure CLI

az webapp config set -g '<resource-group-name>' --subscription '<subscription-id>' -n '<app-service-app-name>' --generic-configurations '{\"vnetPrivatePortsCount\": "2"}'

Konfigurieren des Hostnetzwerks

Nachdem Sie Azure App Service mit VNet-Integration (Virtual Network) konfiguriert und festgelegt haben, um Anwendungsinstanzen mit mindestens zwei privaten Ports bereitzustellen, werden zwei zusätzliche Umgebungsvariablen für Ihre App-Prozesse bereitgestellt: WEBSITE_PRIVATE_IP und WEBSITE_PRIVATE_PORTS. Diese Variablen stellen zwei wichtige Informationen bereit:

• Welche IP-Adresse andere Hosts in Ihrem virtuellen Netzwerk verwenden kann, um eine bestimmte App-Instanz zu kontaktieren; und
• Welche Ports für diese IP-Adresse an diese App-Instanz weitergeleitet werden

Die WEBSITE_PRIVATE_IP Variable gibt eine IP-Adresse an, die vom VNet aus erreichbar ist, aber nicht unbedingt eine IP-Adresse, an die die App-Instanz direkt gebunden werden kann. Weisen Sie daher den Host an, durch Übergabe von listenOnAnyHostAddress: true an den Methodenaufruf ConfigureEndpoints, eine Bindung an alle internen Adressen vorzunehmen. Im folgenden Beispiel wird eine ISiloBuilder Instanz so konfiguriert, dass die eingefügten Umgebungsvariablen verwendet und die richtigen Schnittstellen überwacht werden:

var endpointAddress = IPAddress.Parse(builder.Configuration["WEBSITE_PRIVATE_IP"]!);
var strPorts = builder.Configuration["WEBSITE_PRIVATE_PORTS"]!.Split(',');
if (strPorts.Length < 2)
{
    throw new Exception("Insufficient private ports configured.");
}

var (siloPort, gatewayPort) = (int.Parse(strPorts[0]), int.Parse(strPorts[1]));

siloBuilder
    .ConfigureEndpoints(endpointAddress, siloPort, gatewayPort, listenOnAnyHostAddress: true)

Der obige Code ist auch im Azure Samples: Orleans Cluster im Azure App Service-Repository vorhanden, sodass er im Kontext der restlichen Hostkonfiguration angezeigt wird.

Bereitstellung auf Azure App Service

Eine typische Orleans Anwendung besteht aus einem Cluster von Serverprozessen (Silos), in denen Grains leben, und einem Satz von Clientprozessen (in der Regel Webserver), die externe Anforderungen empfangen, sie in Grain-Methodenaufrufe umwandeln und Ergebnisse zurückgeben. Daher besteht der erste Schritt zum Ausführen einer Orleans-Anwendung darin, einen Cluster von Silos zu starten. Zu Testzwecken kann ein Cluster aus einem einzigen Silo bestehen.

Erstellen Sie vor der Bereitstellung der App eine Azure-Ressourcengruppe (oder Sie können eine vorhandene verwenden). Verwenden Sie einen der folgenden Artikel, um eine neue Azure-Ressourcengruppe zu erstellen:

• Azure-Portal
• Azure CLI
• Azure PowerShell

Notieren Sie sich den ausgewählten Ressourcengruppennamen; Sie benötigen sie später, um die App bereitzustellen.

Erstellen eines Diensthauptkontos

Um die Bereitstellung der Anwendung zu automatisieren, müssen Sie einen Dienstprinzipal erstellen. Dies ist ein Microsoft-Konto, das über die Berechtigung zum Verwalten von Azure-Ressourcen in Ihrem Auftrag verfügt.

az ad sp create-for-rbac --sdk-auth --role Contributor \
  --name "<display-name>"  --scopes /subscriptions/<your-subscription-id>

Die erstellten JSON-Anmeldeinformationen ähneln den folgenden, jedoch mit konkreten Werten für Ihren Client, Ihr Abonnement und Ihren Mandanten.

{
  "clientId": "<your client id>",
  "clientSecret": "<your client secret>",
  "subscriptionId": "<your subscription id>",
  "tenantId": "<your tenant id>",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com/",
  "resourceManagerEndpointUrl": "https://brazilus.management.azure.com",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com",
  "managementEndpointUrl": "https://management.core.windows.net"
}

Kopieren Sie die Ausgabe des Befehls in die Zwischenablage und gehen Sie zum nächsten Schritt über.

Erstellen eines GitHub-Geheimschlüssels

GitHub bietet einen Mechanismus zum Erstellen verschlüsselter Geheimschlüssel. Die geheimen Schlüssel, die Sie erstellen, stehen für die Verwendung in GitHub-Aktionen-Workflows zur Verfügung. Sie erfahren, wie Sie GitHub-Aktionen verwenden, um die Bereitstellung der App in Verbindung mit Azure Bicep zu automatisieren. Bicep ist eine domänenspezifische Sprache (DSL), die deklarative Syntax zum Bereitstellen von Azure-Ressourcen verwendet. Weitere Informationen finden Sie unter Was ist Bicep?. Mithilfe der Ausgabe aus dem Schritt "Dienstprinzipal erstellen" müssen Sie ein GitHub-Secret AZURE_CREDENTIALS mit den JSON-formatierten Anmeldeinformationen erstellen.

Wählen Sie in Ihrem GitHub-Repository "Einstellungen>geheime Schlüssel>erstellen" aus. Geben Sie den Namen AZURE_CREDENTIALS ein, und fügen Sie die JSON-Anmeldeinformationen aus dem vorherigen Schritt in das Feld "Wert " ein.

Weitere Informationen finden Sie unter GitHub: Encrypted Secrets.

Vorbereiten der Azure-Bereitstellung

Verpacken Sie die App für die Bereitstellung. Orleans.ShoppingCart.Silos Im Projekt wird ein Target Element definiert, das nach dem Publish Schritt ausgeführt wird. Dieses Ziel komprimiert das Veröffentlichungsverzeichnis in eine silo.zip Datei.

<Target Name="ZipPublishOutput" AfterTargets="Publish">
    <Delete Files="$(ProjectDir)\..\silo.zip" />
    <ZipDirectory SourceDirectory="$(PublishDir)" DestinationFile="$(ProjectDir)\..\silo.zip" />
</Target>

Es gibt viele Möglichkeiten, eine .NET-App für Azure App Service bereitzustellen. Verwenden Sie in diesem Lernprogramm GitHub-Aktionen, Azure Bicep und die .NET- und Azure-CLIs. Berücksichtigen Sie die DATEI ./github/workflows/deploy.yml im Stammverzeichnis des GitHub-Repositorys:

name: Deploy to Azure App Service

on:
  push:
    branches:
    - main

env:
  UNIQUE_APP_NAME: cartify
  AZURE_RESOURCE_GROUP_NAME: orleans-resourcegroup
  AZURE_RESOURCE_GROUP_LOCATION: centralus

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Setup .NET 8.0
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: 8.0.x

    - name: .NET publish shopping cart app
      run: dotnet publish ./Silo/Orleans.ShoppingCart.Silo.csproj --configuration Release

    - name: Login to Azure
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Flex bicep
      run: |
        az deployment group create \
          --resource-group ${{ env.AZURE_RESOURCE_GROUP_NAME }} \
          --template-file '.github/workflows/flex/main.bicep' \
          --parameters location=${{ env.AZURE_RESOURCE_GROUP_LOCATION }} \
            appName=${{ env.UNIQUE_APP_NAME }} \
          --debug

    - name: Webapp deploy
      run: |
        az webapp deploy --name ${{ env.UNIQUE_APP_NAME }} \
          --resource-group ${{ env.AZURE_RESOURCE_GROUP_NAME  }} \
          --clean true --restart true \
          --type zip --src-path silo.zip --debug

    - name: Staging deploy
      run: |
        az webapp deploy --name ${{ env.UNIQUE_APP_NAME }} \
          --slot ${{ env.UNIQUE_APP_NAME }}stg \
          --resource-group ${{ env.AZURE_RESOURCE_GROUP_NAME  }} \
          --clean true --restart true \
          --type zip --src-path silo.zip --debug

Der vorherige GitHub-Workflow führt folgende Aktionen aus:

• Veröffentlicht die Einkaufswagen-App als ZIP-Datei mithilfe des Dotnet-Veröffentlichungsbefehls .
• Meldet sich bei Azure mithilfe von Anmeldeinformationen aus dem Schritt " Dienstprinzipal erstellen " an.
• Wertet die Datei "main.bicep" aus und startet eine Bereitstellungsgruppe mithilfe von az deployment group create.
• Stellt die silo.zip-Datei mit az webapp deploy in Azure App Service bereit.
  • Eine zusätzliche Bereitstellung zum Staging ist ebenfalls konfiguriert.

Der Workflow wird bei einem Push auf den main Branch ausgelöst. Weitere Informationen finden Sie unter GitHub Actions und .NET.

Azure erzwingt Benennungseinschränkungen und Konventionen für Ressourcen. Aktualisieren Sie die Werte in der datei deploy.yml für die folgenden Umgebungsvariablen:

• UNIQUE_APP_NAME
• AZURE_RESOURCE_GROUP_NAME
• AZURE_RESOURCE_GROUP_LOCATION

Legen Sie diese Werte auf Ihren eindeutigen App-Namen sowie Ihren Azure-Ressourcengruppennamen und -standort fest.

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

Erkunden Sie die Bicep-Vorlagen

Wenn der az deployment group create Befehl ausgeführt wird, wertet er die Datei "main.bicep " aus. Diese Datei enthält die azure-Ressourcen, die bereitgestellt werden sollen. Stellen Sie sich diesen Schritt als Bereitstellung aller Ressourcen für die Bereitstellung vor.

Es gibt viele Bicep-Dateien, die jeweils Ressourcen oder Module (Sammlungen von Ressourcen) enthalten. Die datei main.bicep ist der Einstiegspunkt und besteht hauptsächlich module aus Definitionen:

param appName string
param location string = resourceGroup().location

module storageModule 'storage.bicep' = {
  name: 'orleansStorageModule'
  params: {
    name: '${appName}storage'
    location: location
  }
}

module logsModule 'logs-and-insights.bicep' = {
  name: 'orleansLogModule'
  params: {
    operationalInsightsName: '${appName}-logs'
    appInsightsName: '${appName}-insights'
    location: location
  }
}

resource vnet 'Microsoft.Network/virtualNetworks@2021-05-01' = {
  name: '${appName}-vnet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '172.17.0.0/16',
        '192.168.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'default'
        properties: {
          addressPrefix: '172.17.0.0/24'
          delegations: [
            {
              name: 'delegation'
              properties: {
                serviceName: 'Microsoft.Web/serverFarms'
              }
            }
          ]
        }
      }
      {
        name: 'staging'
        properties: {
          addressPrefix: '192.168.0.0/24'
          delegations: [
            {
              name: 'delegation'
              properties: {
                serviceName: 'Microsoft.Web/serverFarms'
              }
            }
          ]
        }
      }
    ]
  }
}

module siloModule 'app-service.bicep' = {
  name: 'orleansSiloModule'
  params: {
    appName: appName
    location: location
    vnetSubnetId: vnet.properties.subnets[0].id
    stagingSubnetId: vnet.properties.subnets[1].id
    appInsightsConnectionString: logsModule.outputs.appInsightsConnectionString
    appInsightsInstrumentationKey: logsModule.outputs.appInsightsInstrumentationKey
    storageConnectionString: storageModule.outputs.connectionString
  }
}

Die vorangehende Bicep-Datei definiert Folgendes:

• Zwei Parameter für den Ressourcengruppennamen und den App-Namen.
• Die storageModule Definition, die das Speicherkonto definiert.
• Die logsModule Definition, die Azure Log Analytics- und Application Insights-Ressourcen definiert.
• Die vnet Ressource, die das virtuelle Netzwerk definiert.
• Die siloModule Definition, die den Azure App Service definiert.

Ein sehr wichtiger Aspekt resource ist das virtuelle Netzwerk. Die vnet Ressource ermöglicht Azure App Service die Kommunikation mit dem Orleans Cluster.

Wenn in der Bicep-Datei ein module Fehler auftritt, wird sie über eine andere Bicep-Datei ausgewertet, die die Ressourcendefinitionen enthält. Das erste gefundene Modul ist storageModulein der Datei "storage.bicep " definiert:

param name string
param location string

resource storage 'Microsoft.Storage/storageAccounts@2021-08-01' = {
  name: name
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

var key = listKeys(storage.name, storage.apiVersion).keys[0].value
var protocol = 'DefaultEndpointsProtocol=https'
var accountBits = 'AccountName=${storage.name};AccountKey=${key}'
var endpointSuffix = 'EndpointSuffix=${environment().suffixes.storage}'

output connectionString string = '${protocol};${accountBits};${endpointSuffix}'

Bicep-Dateien akzeptieren Parameter, die mit dem param Schlüsselwort deklariert werden. Ebenso können sie Ausgaben mithilfe des output Schlüsselworts deklarieren. Der Speicher resource basiert auf dem Typ und der Microsoft.Storage/storageAccounts@2021-08-01 Version. Sie wird am Standort der Ressourcengruppe als StorageV2 und Standard_LRS-SKU bereitgestellt. Die Speicher-Bicep-Datei definiert ihre Verbindungszeichenfolge als eine output. Dies connectionString wird später von der Silo-Bicep-Datei verwendet, um eine Verbindung mit dem Speicherkonto herzustellen.

Als Nächstes definiert die Datei "logs-and-insights.bicep " die Ressourcen "Azure Log Analytics" und "Application Insights":

param operationalInsightsName string
param appInsightsName string
param location string

resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: appInsightsName
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: logs.id
  }
}

resource logs 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: operationalInsightsName
  location: location
  properties: {
    retentionInDays: 30
    features: {
      searchVersion: 1
    }
    sku: {
      name: 'PerGB2018'
    }
  }
}

output appInsightsInstrumentationKey string = appInsights.properties.InstrumentationKey
output appInsightsConnectionString string = appInsights.properties.ConnectionString

Diese Bicep-Datei definiert die Azure Log Analytics- und Application Insights-Ressourcen. Die appInsights Ressource ist ein web Typ, und die logs Ressource ist ein PerGB2018 Typ. Sowohl appInsights- als auch logs-Ressourcen werden am Standort der Ressourcengruppe bereitgestellt. Die appInsights Ressource verknüpft sich mit der logs Ressource über die WorkspaceResourceId Eigenschaft. Diese Bicep-Datei definiert zwei Ausgaben, die später vom App-Service module verwendet werden.

Schließlich definiert die Datei "app-service.bicep " die Azure App Service-Ressource:

param appName string
param location string
param vnetSubnetId string
param stagingSubnetId string
param appInsightsInstrumentationKey string
param appInsightsConnectionString string
param storageConnectionString string

resource appServicePlan 'Microsoft.Web/serverfarms@2021-03-01' = {
  name: '${appName}-plan'
  location: location
  kind: 'app'
  sku: {
    name: 'S1'
    capacity: 1
  }
}

resource appService 'Microsoft.Web/sites@2021-03-01' = {
  name: appName
  location: location
  kind: 'app'
  properties: {
    serverFarmId: appServicePlan.id
    virtualNetworkSubnetId: vnetSubnetId
    httpsOnly: true
    siteConfig: {
      vnetPrivatePortsCount: 2
      webSocketsEnabled: true
      netFrameworkVersion: 'v8.0'
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: appInsightsInstrumentationKey
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsightsConnectionString
        }
        {
          name: 'ORLEANS_AZURE_STORAGE_CONNECTION_STRING'
          value: storageConnectionString
        }
        {
          name: 'ORLEANS_CLUSTER_ID'
          value: 'Default'
        }
      ]
      alwaysOn: true
    }
  }
}

resource stagingSlot 'Microsoft.Web/sites/slots@2022-03-01' = {
  name: '${appName}stg'
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    virtualNetworkSubnetId: stagingSubnetId
    siteConfig: {
      http20Enabled: true
      vnetPrivatePortsCount: 2
      webSocketsEnabled: true
      netFrameworkVersion: 'v8.0'
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: appInsightsInstrumentationKey
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsightsConnectionString
        }
        {
          name: 'ORLEANS_AZURE_STORAGE_CONNECTION_STRING'
          value: storageConnectionString
        }
        {
          name: 'ORLEANS_CLUSTER_ID'
          value: 'Staging'
        }
      ]
      alwaysOn: true
    }
  }
}

resource slotConfig 'Microsoft.Web/sites/config@2021-03-01' = {
  name: 'slotConfigNames'
  parent: appService
  properties: {
    appSettingNames: [
      'ORLEANS_CLUSTER_ID'
    ]
  }
}

resource appServiceConfig 'Microsoft.Web/sites/config@2021-03-01' = {
  parent: appService
  name: 'metadata'
  properties: {
    CURRENT_STACK: 'dotnet'
  }
}

Diese Bicep-Datei konfiguriert Azure App Service als .NET 8-Anwendung. Sowohl appServicePlan- als auch appService-Ressourcen werden am Standort der Ressourcengruppe bereitgestellt. Die appService Ressource ist konfiguriert, um die S1 SKU mit einer Kapazität von 1 zu verwenden. Darüber hinaus ist die Ressource für die Verwendung des vnetSubnetId Subnetzes und HTTPS konfiguriert. Außerdem werden der appInsightsInstrumentationKey Instrumentierungsschlüssel, die appInsightsConnectionString Verbindungszeichenfolge und die storageConnectionString Verbindungszeichenfolge konfiguriert. Die Einkaufswagen-App verwendet diese Werte.

Die oben erwähnte Visual Studio Code-Erweiterung für Bicep enthält eine Visualisierung. Alle diese Bicep-Dateien werden wie folgt visualisiert:

Stagingumgebungen

Die Bereitstellungsinfrastruktur kann in Stagingumgebungen bereitgestellt werden. Dies sind kurzlebige, testorientierte, unveränderliche Throwaway-Umgebungen, die sehr hilfreich für Tests von Bereitstellungen sind, bevor sie in die Produktion gefördert werden.

Zusammenfassung

Wenn der Quellcode aktualisiert wird und Änderungen an der push Verzweigung des Repositorys vorgenommen werdenmain, wird der deploy.yml-Workflow ausgeführt. Sie stellt die in den Bicep-Dateien definierten Ressourcen bereit und stellt die Anwendung bereit. Die Anwendung kann um neue Features erweitert werden, z. B. Authentifizierung oder um mehrere Instanzen zu unterstützen. Das Hauptziel dieses Workflows besteht darin, die Fähigkeit zu demonstrieren, Ressourcen in einem einzigen Schritt bereitzustellen und zu implementieren.

Zusätzlich zu dem Visualisierungstool aus der Bicep-Erweiterung sieht die Seite der Ressourcengruppe im Azure-Portal nach der Bereitstellung und Implementierung der Anwendung ähnlich wie im folgenden Beispiel aus.

Siehe auch

• Orleans Übersicht über die Bereitstellung
• GitHub-Aktionen und .NET
• Schnellstart: Bereitstellen einer ASP.NET-Web-App
• Integrieren Ihrer App in ein Azure Virtual Network
• Aktivieren der Integration virtueller Netzwerke in Azure App Service