Bereitstellen für Azure App Service-Bereitstellungsplätze mit Azure Developer CLI

Azure Developer CLI (azd) unterstützt Azure App Service-Bereitstellungsplätze für Apps, die auf App Service gehostet werden. Sie können Slots in Ihrer Infrastruktur definieren, Code für einen bestimmten Steckplatz bereitstellen und Slots austauschen, wenn Sie bereit sind, eine Version zu bewerben.

Verwenden Sie diesen Ansatz für das Staging, Blue-Green-Bereitstellungen, Rauchtests und Rollbacks, ohne benutzerdefinierte Bereitstellungsskripte hinzuzufügen.

Voraussetzungen

  • Ein azd Projekt, das einen Dienst für Azure App Service bereitstellt.
  • Infrastruktur-als-Code, die Ihre App Service-Ressourcen in Bicep definiert.
  • Ein App Service-Plan auf der Standardebene (S1) oder höher. Die Stufen "Kostenlos", "Geteilt" und "Basis" unterstützen keine Bereitstellungsplätze.

Definieren eines Bereitstellungsplatzes in Bicep

Definieren Sie Ihre Produktionsseite wie gewohnt, und fügen Sie dann eine Microsoft.Web/sites/slots Ressource für jeden Slot hinzu, auf den Sie azd abzielen möchten.

resource appServicePlan 'Microsoft.Web/serverfarms@2021-03-01' = {
  name: 'my-appservice-plan'
  location: resourceGroup().location
  sku: {
    name: 'S1'
    tier: 'Standard'
  }
}

resource webApp 'Microsoft.Web/sites@2021-03-01' = {
  name: 'my-appservice'
  location: resourceGroup().location
  kind: 'app'
  properties: {
    serverFarmId: appServicePlan.id
  }
}

resource stagingSlot 'Microsoft.Web/sites/slots@2021-03-01' = {
  name: '${webApp.name}/staging'
  location: webApp.location
  properties: {}
}

Wenn Sie Azure Verified Modules (AVM) verwenden, definieren Sie die Web-App- und Bereitstellungsplatzmodule in derselben Bereitstellung, und übergeben Sie den App-Namen an das Slotmodul.

Bereitstellen auf einem Steckplatz mit azd

Führen Sie azd up oder azd provision und azd deploy wie gewohnt aus.

azd up

Bei der ersten Bereitstellung wird azd auf der Produktionssite und in alle in Ihrer Infrastruktur definierten Slots bereitgestellt. Diese erste Bereitstellung etabliert dieselbe Ausgangsbasis für die Haupt-App und jeden Slot.

Nach der ersten Bereitstellung ändert azd deploy die Methode zur Auswahl des Bereitstellungsziels, wenn Slots vorhanden sind. azd setzt die Bereitstellung nicht direkt in der Produktions-App fort, wenn Slots verfügbar sind. Stattdessen stellen Sie auf einem Slot bereit, validieren die Version und tauschen diese dann in die Produktion aus.

Wie azd das Bereitstellungsziel auswählt

Wenn azd deploy sie für einen App-Dienst mit Bereitstellungsplätzen ausgeführt wird, wählt er das Ziel aus, indem er den Bereitstellungsverlauf in der Haupt-App überprüft und dann die verfügbaren Slots auswertet.

Das Verhalten funktioniert wie folgt:

  • Wenn keine vorherigen Bereitstellungen vorhanden sind, wird azd zur Haupt-App und allen Slots bereitgestellt.
  • Wenn frühere Bereitstellungen existieren und keine Slots verfügbar sind, wird azd nur für die Haupt-App bereitgestellt.
  • Wenn es frühere Bereitstellungen gibt und genau ein Steckplatz vorhanden ist, wird azd nur in diesem Steckplatz bereitgestellt.
  • Wenn frühere Bereitstellungen vorhanden sind und zwei oder mehr Steckplätze vorhanden sind, azd wird der durch eine Umgebungsvariable angegebene Steckplatz verwendet oder Sie aufgefordert, eins auszuwählen.

Von Bedeutung

Nach der ersten Bereitstellung wird nicht direkt zur Haupt-App des App Service bereitgestellt, azd wenn Slots vorhanden sind. Dieses Verhalten ist beabsichtigt und verhindert versehentliche Direct-to-Production-Bereitstellungen. Um die Produktion zu aktualisieren, stellen Sie die Bereitstellung auf einem Slot bereit und tauschen Sie dann den Slot in die Produktion aus (@main).

Einen Slot mit einer Umgebungsvariable auswählen

Wenn Ihr Dienst nach der ersten Bereitstellung über mindestens zwei Slots verfügt, können Sie die interaktive Eingabeaufforderung überspringen, indem Sie eine Umgebungsvariable für den Dienst festlegen, den Sie bereitstellen möchten.

Verwenden Sie das folgende Format:

AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME

Erstellen Sie den Variablennamen aus dem Dienstnamen azure.yaml in Großbuchstaben, und ersetzen Sie Bindestriche durch Unterstriche.

Wenn Ihr Dienst beispielsweise benannt my-apiist, verwenden Sie AZD_DEPLOY_MY_API_SLOT_NAME.

azd env set AZD_DEPLOY_MY_API_SLOT_NAME staging
azd deploy my-api

Sie können diesen Wert in Ihrer azd Umgebung speichern, indem Sie azd env set verwenden oder direkt in Ihrem CI-System definieren, bevor Sie azd deploy ausführen.

Wenn Ihr Dienst genau einen Steckplatz aufweist, wird die Umgebungsvariable ignoriert, azd da nur ein mögliches Bereitstellungsziel vorhanden ist.

Wenn Ihr Dienst über mindestens zwei Steckplätze verfügt und die Umgebungsvariable nicht festgelegt ist, werden Sie aufgefordert, azd einen Steckplatz auszuwählen.

Sloterkennung umgehen und für die Haupt-App bereitstellen

In einigen Szenarien müssen Sie azd auch dann direkt in der Haupt-App von App Service bereitstellen, wenn Slots vorhanden sind. Beispiel:

  • Ihre CI-Pipeline muss die Haupt-App aktualisieren, ohne dabei vorhandene Slots zu verändern.
  • Sie beheben gerade einen fehlerhaften Zustand des Slots und möchten die Produktionssite direkt erneut bereitstellen.
  • Sie erstellen eine Basis für die Haupt-App, bevor Sie neue Slots konfigurieren.

Um die Steckplatzerkennung zu umgehen, legen Sie die folgende Umgebungsvariable für den Dienst fest:

AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS

Erstellen Sie den Variablennamen aus dem Dienstnamen azure.yaml in Großbuchstaben, und ersetzen Sie Bindestriche durch Unterstriche. Legen Sie den Wert auf true fest, um die Sloterkennung zu überspringen und in der Haupt-App bereitzustellen.

Wenn Ihr Dienst beispielsweise benannt my-apiist, verwenden Sie AZD_DEPLOY_MY_API_IGNORE_SLOTS.

azd env set AZD_DEPLOY_MY_API_IGNORE_SLOTS true
azd deploy my-api

Wenn AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS auf true festgelegt ist, wird azd für die Haupt-App bereitgestellt und jeder AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME-Wert für denselben Dienst ignoriert. Setzen Sie die Variable zurück, oder setzen Sie sie auf false, um zum standardmäßigen slotbewussten Verhalten zurückzukehren.

CI und nicht-interaktives Verhalten

Wenn Sie azd deploy --no-prompt innerhalb von CI ausführen oder deployen, verhält sich die Slot-Auswahl je nachdem, wie viele Steckplätze verfügbar sind:

Steckplätze Verhalten von Umgebungsvariablen Ergebnis
0 Nicht zutreffend. azd wird auf die Hauptanwendung bereitgestellt.
1 Wird ignoriert, es sei denn, AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS ist true. azd wird im einzigen Slot oder in der Haupt-App bereitgestellt, wenn Slots ignoriert werden.
2+ AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME ist erforderlich, um eine Aufforderung zu vermeiden, es sei denn, AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS ist true. azd wird im angegebenen Slot bereitgestellt, in der Haupt-App bereitgestellt, wenn Slots ignoriert werden, oder schlägt fehl, wenn kein Ziel ausgewählt werden kann.

Wenn Sie Bereitstellungen für einen App Service mit mindestens zwei Slots automatisieren, setzen Sie AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME in der Pipeline-Umgebung, bevor Sie azd deploy ausführen. Um bei vorhandenen Slots eine direkte Bereitstellung im Hauptslot aus CI zu erzwingen, setzen Sie AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS stattdessen auf true.

Austauschen von Azure App Service-Bereitstellungsplätzen

Verwenden Sie die Erweiterung, um Steckplätze nach der azure.appservice Überprüfung zu tauschen. Wenn die Erweiterung noch nicht installiert ist, werden Sie aufgefordert, azd sie beim ersten Ausführen des Befehls zu installieren.

Führen Sie die interaktive Oberfläche aus:

azd appservice swap

Wenn nur ein Nichtproduktionsplatz vorhanden ist, azd überspringt die Eingabeaufforderungen und wechselt direkt mit der Produktion.

Geben Sie für die Automatisierung die Quell- und Zielplätze explizit an. Wird @main verwendet, um auf den Produktionsplatz zu verweisen.

azd appservice swap --src staging --dst @main
azd appservice swap --src @main --dst staging
azd appservice swap --service myapi --src staging --dst @main

Verwenden Sie diese Muster, um gängige Veröffentlichungsabläufe zu unterstützen.

  • Fördern Sie eine validierte Staging-Bereitstellung für die Produktion mit --src staging --dst @main.
  • Rückgängig machen, indem Sie die Produktion mit --src @main --dst staging wieder in den Staging-Slot verschieben.
  • Zielen Sie auf einen bestimmten, App Service-gesicherten Dienst in einem Multiservice-Projekt azd mit --service.

Swapping ist der vorgesehene Prozess zur Aktualisierung der Produktionsumgebung, nachdem die Slots konfiguriert wurden. Verwenden Sie azd deploy, um einen Slot zu aktualisieren, und azd appservice swap, um diesen Slot in die Produktion zu überführen.

  1. Definieren Sie einen oder mehrere App Service-Bereitstellungsplätze in Ihren Bicep-Vorlagen.
  2. Stellen Sie die App Service-Ressourcen mithilfe von azd provision oder azd up bereit.
  3. Lassen Sie die erste Bereitstellung eine Grundlinie für die Haupt-App und jeden Slot etablieren.
  4. Stellen Sie spätere Anwendungsupdates für einen Staging-Slot bereit, indem Sie AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME festlegen, wenn Sie zwei oder mehr Slots haben, oder indem Sie den Slot auswählen, wenn Sie dazu aufgefordert werden, einen auszuwählen. Um bei vorhandenen Slots eine direkte Bereitstellung in der Hauptumgebung aus der CI zu erzwingen, setzen Sie AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS stattdessen auf true.
  5. Überprüfen Sie die mehrstufige Bereitstellung.
  6. Führen Sie azd appservice swap --src <slot> --dst @main aus, um die Veröffentlichung zu fördern.
  7. Führen Sie bei Bedarf den Reverse-Swap aus, um ein Rollback durchzuführen.