Web-App benötigt eine Staging-Umgebung? Deployment Slot erstellen

CloudTrips möchte ein Release unter einer echten Azure-URL testen, bevor es Benutzer erreicht. Ein App-Service-Deployment Slot ist eine getrennt laufende Version der Web-App mit eigenem Hostnamen. Ein Swap wärmt die bereitgestellte Version auf und verschiebt sie ohne erneute Bereitstellung in den Production-Slot.

Slots teilen die Rechenressourcen des App Service Plans und sind keine getrennten Sicherheits- oder Infrastrukturgrenzen. Erforderlich ist Standard, Premium oder Isolated. Der in diesem Labor angezeigte Tarif Premium v3 P0V3 unterstützt Deployment Slots.

Erstelle den App Service

Dieser Trip ist eigenständig. Suche nach App Services, wähle Create > Web App und trage ein:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-slots-test-weu
Name: app-cloudtrips-slots-dmytro-test-weu
Publish: Code
Runtime stack: Node 24 LTS
Operating System: Linux
Region: West Europe
Linux Plan: Create new
Plan name: asp-cloudtrips-slots-test-weu
Pricing plan: Premium v3 P0V3
Zone redundancy: Disabled

Der Web-App-Name muss global eindeutig sein. Ergänzt Azure den Standardhostnamen um ein Suffix, verwende den von Azure zurückgegebenen Hostnamen und konstruiere ihn nicht aus dem App-Namen. P0V3 bleibt bis zur Löschung der Ressourcengruppe kostenpflichtig. Schließe das Labor ab und räume zeitnah auf.

Wähle Review + create > Create.

Stelle die Production-Version bereit

Erstelle diese lokale Struktur:

cloudtrips-slots/
└── production/
    ├── package.json
    └── server.js

Verwende diese package.json:

{
  "name": "cloudtrips-slots-production",
  "version": "1.0.0",
  "scripts": {
    "start": "node server.js"
  }
}

Verwende diese server.js:

const http = require('http');
const port = process.env.PORT || 8080;

http.createServer((request, response) => {
  response.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
  response.end('<h1>CloudTrips Production</h1><p>Version 1</p>');
}).listen(port);

Packe und veröffentliche die Dateien aus cloudtrips-slots im Production-Standardslot:

(cd production && zip ../production.zip package.json server.js)

az webapp deploy \
  --resource-group rg-cloudtrips-slots-test-weu \
  --name app-cloudtrips-slots-dmytro-test-weu \
  --src-path production.zip \
  --type zip

Erstelle den Staging-Slot

Öffne die Web-App und wähle Deployment > Deployment slots > Add:

Name: staging
Clone settings from: app-cloudtrips-slots-dmytro-test-weu

Wähle Add, warte auf die Erstellung und öffne den Slot. Das Klonen kopiert Konfigurationen wie Laufzeitstack und App-Einstellungen, erstellt aber keinen zweiten App Service Plan. Der App-Name in dieser Auswahlliste steht für den Production-Slot. Do not clone settings würde Staging erstellen, ohne diese Production-Konfiguration zu kopieren.

Stelle die Staging-Version bereit und teste sie

Erstelle staging/package.json mit derselben Struktur wie Production, aber verwende cloudtrips-slots-staging als Namen. Erstelle staging/server.js:

const http = require('http');
const port = process.env.PORT || 8080;

http.createServer((request, response) => {
  response.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
  response.end('<h1>CloudTrips Staging</h1><p>Version 2 ready</p>');
}).listen(port);

Packe die Dateien und stelle sie nur in staging bereit:

(cd staging && zip ../staging.zip package.json server.js)

az webapp deploy \
  --resource-group rg-cloudtrips-slots-test-weu \
  --name app-cloudtrips-slots-dmytro-test-weu \
  --slot staging \
  --src-path staging.zip \
  --type zip

Rufe beide generierten Hostnamen ab und teste sie:

PROD_HOST=$(az webapp show \
  --resource-group rg-cloudtrips-slots-test-weu \
  --name app-cloudtrips-slots-dmytro-test-weu \
  --query defaultHostName --output tsv)

STAGING_HOST=$(az webapp show \
  --resource-group rg-cloudtrips-slots-test-weu \
  --name app-cloudtrips-slots-dmytro-test-weu \
  --slot staging \
  --query defaultHostName --output tsv)

curl --fail "https://${PROD_HOST}"
curl --fail "https://${STAGING_HOST}"

Production sollte Version 1 und Staging Version 2 anzeigen.

Tausche Staging nach Production

Kehre zu Deployment slots zurück und wähle Swap:

Source: staging
Target: production

Prüfe die Änderungen und wähle Swap. App Service wendet die Production-Konfiguration auf Staging an, wärmt den Quellslot auf, wechselt das Routing und verschiebt die bisherige Production-Version nach Staging. Langlaufende Prozesse können beim Neustart der Worker unterbrochen werden; Anwendungen müssen Neustarts daher sicher behandeln.

Führe dieselben Tests erneut aus:

curl --fail "https://${PROD_HOST}"
curl --fail "https://${STAGING_HOST}"

Production sollte nun Version 2 zeigen, während Staging die vorherige Version 1 enthält. Die Hostnamen wurden nicht verschoben, sondern der Anwendungsinhalt. Schlägt die Prüfung von Version 2 fehl, stellt ein erneuter Swap Version 1 wieder her.

Einstellungen mit Deployment slot setting bleiben bei einem Swap an ihren Slot gebunden. Verwende dies für umgebungsspezifische Werte wie Staging-API- Endpunkte oder Verbindungszeichenfolgen. Geheimnisse gehören in Key Vault oder einen anderen geeigneten Secretspeicher.

Aufräumen

Lösche die isolierte Ressourcengruppe zeitnah, um P0V3-Gebühren zu beenden:

az group delete --name rg-cloudtrips-slots-test-weu --yes

Bestätige, dass az group exists --name rg-cloudtrips-slots-test-weu den Wert false zurückgibt.