Delen via


Instellen van testomgevingen in Azure App Service

Notitie

Vanaf 1 juni 2024 kunnen nieuw gemaakte App Service-apps een unieke standaardhostnaam genereren die gebruikmaakt van de naamconventie <app-name>-<random-hash>.<region>.azurewebsites.net. Voorbeeld: myapp-ds27dh7271aah175.westus-01.azurewebsites.net. Bestaande app-namen blijven ongewijzigd.

Zie het blogbericht over het maken van een web-app met een unieke standaardhostnaamvoor meer informatie.

Wanneer u uw web-app, web-app op Linux, mobiele back-end of API-app implementeert in Azure-app Service, kunt u een afzonderlijke implementatiesite gebruiken in plaats van de standaard productiesite. Deze methode is beschikbaar als u de Standard-, Premium- of Geïsoleerde laag van een App Service-plan uitvoert. Deployment slots are live apps with their own host names. App-inhoud en configuratie-elementen kunnen worden gewisseld tussen twee implementatiesites, inclusief de productiesite.

Het implementeren van uw toepassing in een niet-productiesite heeft de volgende voordelen:

  • You can validate app changes before you swap the slot into production.

  • You can make sure that all instances of the slot are warmed up before you swap it into production. Deze aanpak elimineert downtime wanneer u uw app implementeert. The traffic redirection is seamless. Er worden geen aanvragen verwijderd vanwege wisselbewerkingen.

    You can automate this entire workflow by configuring auto swap when pre-swap validation isn't needed.

  • After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot aren't as you expect, you can perform the same swap immediately to get your last known good site back.

Er worden geen extra kosten in rekening gebracht voor het gebruik van implementatieslots. Elke App Service-planklasse ondersteunt een ander aantal implementatieslots. Zie App Service-limieten om te ontdekken hoeveel slots door de tier van uw app worden ondersteund.

Als u uw app wilt schalen naar een andere laag, moet u ervoor zorgen dat de doellaag het aantal sites ondersteunt dat uw app al gebruikt. Als uw app bijvoorbeeld meer dan vijf slots heeft, kunt u deze niet afschalen naar de Standard-laag. De Standaard-laag ondersteunt slechts vijf implementatieslots.

De volgende video vormt een aanvulling op de stappen in dit artikel door te laten zien hoe u faseringsomgevingen instelt in Azure App Service.

Prerequisites

  • Permissions to perform the slot operation that you want. Zie Bewerkingen van de resourceprovider voor meer informatie over de vereiste machtigingen. Search for slot, for example.

Een sleuf toevoegen

For you to enable multiple deployment slots, the app must be running in the Standard, Premium, or Isolated tier.

  1. Ga in Azure Portal naar de beheerpagina van uw app.

  2. Selecteer Implementatie> en vervolgens Implementatieslots in het linkermenu. Selecteer vervolgens Toevoegen.

    Notitie

    Als de app zich nog niet in de laag Standard, Premium of Isolated bevindt, selecteert u Upgraden. Ga naar het tabblad Schaal van uw app voordat u doorgaat.

  3. Geef in het dialoogvenster Site toevoegen een naam op voor de site en geef aan of u een app-configuratie van een andere implementatiesite wilt klonen. Selecteer Toevoegen om door te gaan.

    Schermopname van selecties voor het configureren van een nieuwe implementatiesite met de naam Staging in de portal.

    You can clone a configuration from any existing slot. Instellingen die kunnen worden gekloond, zijn app-instellingen, verbindingsreeksen, taalframeworkversies, websockets, HTTP-versie en platformbitsheid.

    Notitie

    Momenteel wordt een privé-eindpunt niet gekloond tussen slots.

  4. Nadat u de instellingen hebt ingevoerd, selecteert u Sluiten om het dialoogvenster te sluiten. The new slot now appears on the Deployment slots page. By default, Traffic % is set to 0 for the new slot, with all customer traffic routed to the production slot.

  5. Select the new deployment slot to open its resource page.

    Schermopname die laat zien hoe je de beheerpagina van een implementatieslot in het portaal opent.

    The staging slot has a management page just like any other App Service app. You can change the slot's configuration. Om u eraan te herinneren dat u de implementatiesite bekijkt, wordt de naam van de app weergegeven als <app-naam>/<sitenaam>. Het app-type is App Service (Slot). U kunt het slot ook zien als een afzonderlijke app in uw resourcegroep, met dezelfde aanduidingen.

  6. On the slot's resource page, select the app URL. Het deploymentslot heeft een eigen hostnaam en is tevens een live-applicatie. Zie Toegangsbeperkingen voor Azure App Service instellen om openbare toegang tot de implementatiesite te beperken.

De nieuwe implementatieslot heeft geen inhoud, zelfs als u de instellingen van een ander slot kloont. For example, you can publish to this slot with Git. You can deploy to the slot from a different repository branch or a different repository. The article Get a publish profile from Azure App Service can provide the required information for deploying to the slot. Visual Studio can import the profile to deploy contents to the slot.

De URL van de slot heeft de indeling http://sitename-slotname.azurewebsites.net. Als u de URL-lengte binnen de vereiste DNS-limieten wilt houden, wordt de sitenaam afgekapt met 40 tekens. De gecombineerde sitenaam en slotnaam mogen niet langer zijn dan 59 tekens.

Begrijpen wat er gebeurt tijdens een wissel

Stappen voor wisselbewerking

Wanneer u twee sites wisselt, doet App Service het volgende om ervoor te zorgen dat de doelsite geen downtime ondervindt:

  1. Pas de volgende instellingen van de doelsite (bijvoorbeeld de productiesite) toe op alle exemplaren van de bronsite:

    Wanneer een van de instellingen wordt toegepast op de bronslot, veroorzaakt de wijziging dat alle exemplaren in de bronslot opnieuw starten. Tijdens een wissel met preview markeert deze actie het einde van de eerste fase. De wisselbewerking is onderbroken. U kunt controleren of het bronvak goed werkt met de instellingen van het doelvak.

  2. Wait for every instance in the source slot to complete its restart. If any instance fails to restart, the swap operation reverts all changes to the source slot and stops the operation.

  3. Als lokale cache is ingeschakeld, activeert u initialisatie van lokale cache door een HTTP-aanvraag in te dienen bij de hoofdmap van de toepassing (/) op elk exemplaar van de bronsite. Wacht totdat elk exemplaar een HTTP-antwoord retourneert. Initialisatie van lokale cache zorgt ervoor dat elke instantie opnieuw wordt opgestart.

  4. If auto swap is enabled with custom warm-up, trigger the custom application initialization on each instance of the source slot.

    If applicationInitialization isn't specified, trigger an HTTP request to the application root of the source slot on each instance.

    If an instance returns any HTTP response, it's considered to be warmed up.

  5. If all instances on the source slot are warmed up successfully, swap the two slots by switching their routing rules. After this step, the target slot (for example, the production slot) has the app that's previously warmed up in the source slot.

  6. Now that the source slot has the pre-swap app that was previously in the target slot, perform the same operation by applying all settings and restarting the instances.

Op elk moment in de wisselbewerking vindt alle werkzaamheden voor het initialiseren van de gewisselde apps plaats op de bronsite. De doelsite blijft online terwijl de bronsite wordt voorbereid en opgewarmd, ongeacht of de wissel slaagt of mislukt. Als u een staging-site wilt wisselen met de productiesite, moet u ervoor zorgen dat de productiesite altijd de doelsite is. Op deze manier heeft de wisselbewerking geen invloed op uw productie-app.

Notitie

Your former production instances are swapped into staging after this swap operation. Deze gevallen worden gerecycled in de laatste stap van het ruilproces. If you have any long-running operations in your application, they're abandoned when the workers recycle. Dit feit is ook van toepassing op functie-apps. Zorg ervoor dat uw toepassingscode op een fouttolerante manier is geschreven.

Stappen voor het ontoepasbaar maken van een sleuf

Wanneer u een configuratie van een andere implementatiesite kloont, kan de gekloonde configuratie worden bewerkt. Sommige configuratie-elementen volgen de inhoud bij een wisseling (ze zijn niet slot specifiek). Andere configuratie-elementen blijven na een wissel in dezelfde sleuf staan (ze zijn sleufspecifiek).

Wanneer u slots verwisselt, worden deze instellingen uitgewisseld:

  • Taalstack en -versie, 32-bits en 64-bits
  • App settings (can be configured to stick to a slot)
  • Verbindingsreeksen (kunnen worden geconfigureerd om vast te houden aan een sleuf)
  • Mounted storage accounts (can be configured to stick to a slot)
  • Handler mappings
  • Openbare certificaten
  • WebJobs-inhoud
  • Hybride verbindingen (momenteel)
  • Service-eindpunten (momenteel)
  • Azure Content Delivery Network (momenteel)
  • Path mappings

Wanneer u slots wisselt, worden deze instellingen niet omgewisseld:

  • Algemene instellingen die niet worden vermeld in de vorige lijst
  • Publishing endpoints
  • Aangepaste domeinnamen
  • Niet-openbare certificaten en TLS/SSL-instellingen
  • Schaalinstellingen
  • WebJobs schedulers
  • IP-beperkingen
  • Altijd ingeschakeld
  • Diagnostic settings
  • Cross-origin resource sharing (CORS)
  • Integratie van virtueel netwerk
  • Beheerde identiteiten en gerelateerde instellingen
  • Instellingen die eindigen op het achtervoegsel _EXTENSION_VERSION
  • Instellingen die serviceconnector heeft gemaakt

Notitie

Als u instellingen wilt verwisselen, voegt u de app-instelling WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS toe in elke slot van de app. Stel de waarde ervan in op 0 of false. Deze instellingen zijn allemaal wisselbaar of allemaal niet wisselbaar. U kunt niet alleen bepaalde instellingen wisselbaar maken en niet de overige. Beheerde identiteiten worden nooit gewisseld. This override app setting doesn't affect them.

Bepaalde app-instellingen die van toepassing zijn op niet-gewisselde instellingen, worden ook niet gewijzigd. Omdat diagnostische instellingen bijvoorbeeld niet worden gewisseld, worden gerelateerde app-instellingen zoals WEBSITE_HTTPLOGGING_RETENTION_DAYS en DIAGNOSTICS_AZUREBLOBRETENTIONDAYS ook niet gewisseld, zelfs als ze niet worden weergegeven als slotinstellingen.

Een app-instelling of verbindingsreeks configureren om vast te houden aan een specifiek slot die niet wordt verwisseld:

  1. Go to Settings>Environment Variable for that slot.

  2. Voeg een instelling toe of bewerk deze en selecteer vervolgens Implementatieslotinstelling. Als u dit selectievakje inschakelt, wordt in App Service aangegeven dat de instelling niet kan worden gewisseld.

  3. Selecteer de optie Toepassen.

Schermopname van het selectievakje voor het configureren van een app-instelling als een slotinstelling in de Azure-portal.

Implementatiesites wisselen

U kunt implementatiesites wisselen op de pagina Implementatiesites van uw app en op de pagina Overzicht .

Voordat u een app van een implementatiesite in productie wisselt, moet u ervoor zorgen dat productie uw doelsite is en dat alle instellingen in de bronsite precies zijn geconfigureerd zoals u ze in productie wilt hebben.

  1. Ga naar de Implementatieslots pagina van uw app en selecteer Wisselen.

    Schermopname van selecties voor het initiëren van een wisselbewerking in de portal.

    The Swap dialog shows settings in the selected source and target slots to be changed.

  2. Select the desired Source and Target slots. Meestal is het doel het productietijdslot. Selecteer ook de tabbladen Bron slotwijzigingen en Doelslotwijzigingen en controleer of de configuratiewijzigingen naar verwachting zijn. Wanneer u klaar bent, kunt u de slots direct wisselen door Wisselen starten te selecteren.

    Schermopname van selecties voor het configureren en voltooien van een wissel in de portal.

    Als u wilt zien hoe uw doelslot werkt met de nieuwe instellingen voordat de wissel plaatsvindt, selecteer dan niet Wisselen starten. Follow the instructions in Swap with preview later in this article.

  3. Selecteer en klik op om het dialoogvenster te sluiten.

Raadpleeg Swaps oplossen verderop in dit artikel als u problemen ondervindt.

Wisselen met preview (wisselen in meerdere fasen)

Before you swap into production as the target slot, validate that the app runs with the swapped settings. The source slot is also warmed up before the swap completion, which is desirable for mission-critical applications.

Wanneer u een wissel met preview uitvoert, voert App Service dezelfde wisselbewerking uit, maar wordt na de eerste stap onderbroken. You can then verify the result on the staging slot before completing the swap.

Als u de wisseling annuleert, past App Service configuratie-elementen opnieuw toe op het bronvak.

Notitie

You can't use swap with preview when site authentication is enabled in one of the slots.

  1. Follow the steps in the Swap deployment slots section, but select Perform swap with preview.

    The dialog shows you how the configuration in the source slot changes in the first phase, and how the source and target slot change in the second phase.

  2. Wanneer u klaar bent om te beginnen met wisselen, selecteert u Wisselen starten.

    Wanneer de eerste fase is voltooid, krijgt u een melding in het dialoogvenster. Preview the swap in the source slot by going to https://<app_name>-<source-slot-name>.azurewebsites.net.

  3. When you're ready to complete the pending swap, select Complete Swap in Swap action, and then select the Complete Swap button.

    Screenshot that shows how to configure a swap with preview in the portal.

    To cancel a pending swap, select Cancel Swap instead, and then select the Cancel Swap button.

  4. Wanneer u klaar bent, selecteert u Sluiten om het dialoogvenster te sluiten.

Raadpleeg Swaps oplossen verderop in dit artikel als u problemen ondervindt.

Een swap terugdraaien

Als er fouten optreden in het doelslot (bijvoorbeeld het productieslot) na een wisseling van slots, herstelt u de slots naar hun status van vóór de wissel door onmiddellijk dezelfde twee slots te verwisselen.

Automatisch wisselen configureren

Automatisch wisselen stroomlijnt Azure DevOps-scenario's waarbij u uw app continu wilt implementeren met nul koude start en nul downtime voor klanten van de app. When auto swap is enabled from a slot into production, every time you push your code changes to that slot, App Service automatically swaps the app into production after it's warmed up in the source slot.

Notitie

Automatisch wisselen wordt niet ondersteund in web-apps in Linux en in Web App for Containers.

Before you configure auto swap for the production slot, consider testing it on a nonproduction target slot.

  1. Ga naar de resourcepagina van uw app. Select Deployment>Deployment slots, and then select the desired source slot.

  2. Selecteer inhet linkermenu>>algemene instellingen.

  3. Als Automatisch wisselen is ingeschakeld, selecteert u Aan. For Auto swap deployment slot, select the target slot. Selecteer Vervolgens Opslaan op de opdrachtbalk.

    Schermopname van selecties voor het configureren van automatisch overzetten naar de productieslot in de portal.

  4. Run a code push to the source slot. Automatisch wisselen vindt plaats na korte tijd. The update is reflected at your target slot's URL.

Raadpleeg Swaps oplossen verderop in dit artikel als u problemen ondervindt.

Specify custom warm-up

Voor sommige apps zijn mogelijk aangepaste opwarmacties vereist voordat de wissel wordt uitgevoerd. U kunt deze aangepaste acties opgeven met behulp van het applicationInitialization configuratie-element in Web.config. The swap operation waits for this custom warm-up to finish before swapping with the target slot. Hier volgt een voorbeeldfragment Web.config :

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

Zie voor meer informatie over het aanpassen van het applicationInitialization element het blogbericht Meest voorkomende fouten bij het wisselen van implementatiesites en hoe u deze kunt oplossen.

U kunt het opwarmgedrag ook aanpassen met behulp van de volgende app-instellingen:

  • WEBSITE_SWAP_WARMUP_PING_PATH: het pad om via HTTP te pingen om uw site op te warmen. Voeg deze app-instelling toe door een aangepast pad op te geven dat begint met een slash als waarde. Een voorbeeld is /statuscheck. De standaardwaarde is /.
  • WEBSITE_SWAP_WARMUP_PING_STATUSES: Geldige HTTP-antwoordcodes voor de opwarmbewerking. Voeg deze app-instelling toe met een door komma's gescheiden lijst met HTTP-codes. Een voorbeeld is 200,202. Als de geretourneerde statuscode zich niet in de lijst bevindt, worden de opwarm- en wisselbewerkingen gestopt. Standaard zijn alle antwoordcodes geldig.
  • WEBSITE_WARMUP_PATH: A relative path on the site that should be pinged whenever the site restarts (not only during slot swaps). Voorbeelden van waarden zijn /statuscheck of het hoofdpad. /

Het <applicationInitialization> configuratie-element maakt deel uit van het opstarten van elke app, terwijl de app-instellingen voor opwarmgedrag alleen van toepassing zijn op slotwisselingen.

Raadpleeg Swaps oplossen verderop in dit artikel als u problemen ondervindt.

Een swap bewaken

Als het lang duurt voordat de wisselbewerking is voltooid, kunt u informatie krijgen over de wisselbewerking in het activiteitenlogboek.

  1. Selecteer activiteitenlogboek in het linkermenu op de resourcepagina van uw app in de portal.

  2. Een wisselbewerking wordt in de logboekquery weergegeven als Swap Web App Slots. Als u de details wilt bekijken, kunt u deze uitvouwen en een van de suboperations of fouten selecteren.

Productieverkeer automatisch routeren

Standaard worden alle clientaanvragen naar de productie-URL (http://<app_name>.azurewebsites.net) van de app doorgestuurd naar de productiesite. U kunt een deel van het verkeer naar een andere slot routeren. Deze functie is handig als u feedback van gebruikers nodig hebt voor een nieuwe update, maar u niet klaar bent om deze beschikbaar te maken voor productie.

  1. Ga naar de resourcepagina van uw web-app en selecteer Implementatie>Implementatieslots.

  2. Geef in de kolom Verkeer % van de site waarnaar u wilt routeren een percentage (tussen 0 en 100) op om het totale verkeer weer te geven dat u wilt routeren. Selecteer vervolgens Opslaan.

    Schermopname van portalselecties voor het routeren van een percentage aanvraagverkeer naar een implementatieslot.

After you save the setting, the specified percentage of clients is randomly routed to the nonproduction slot.

Nadat een client automatisch naar een specifieke slot wordt gerouteerd, blijft hij gehecht aan die slot gedurende één uur of totdat de cookies worden verwijderd. In de clientbrowser kunt u zien aan welke sleuf uw sessie is vastgemaakt door de x-ms-routing-name cookie in uw HTTP-headers te bekijken. A request that's routed to the staging slot has the cookie x-ms-routing-name=staging. Een aanvraag die naar de productiesite wordt doorgestuurd, heeft de cookie x-ms-routing-name=self.

Productieverkeer handmatig routeren

Naast automatische verkeersroutering kan App Service verzoeken routeren naar een specifieke slot. Deze optie is handig als u wilt dat uw gebruikers zich kunnen aanmelden of zich kunnen afmelden voor uw bèta-app. Als u productieverkeer handmatig wilt routeren, gebruikt u de x-ms-routing-name queryparameter.

Als u wilt dat gebruikers zich afmelden voor uw bèta-app, kunt u deze koppeling bijvoorbeeld op uw webpagina plaatsen:

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

The string x-ms-routing-name=self specifies the production slot. Nadat de clientbrowser toegang heeft tot de koppeling, wordt deze omgeleid naar de productiesite. Every subsequent request has the x-ms-routing-name=self cookie that pins the session to the production slot.

To let users opt in to your beta app, set the same query parameter to the name of the nonproduction slot. Hier volgt een voorbeeld:

<webappname>.azurewebsites.net/?x-ms-routing-name=staging

Nieuwe slots hebben standaard een routeringsregel van 0%, weergegeven in grijs. Wanneer u deze waarde expliciet instelt op 0% (weergegeven in zwarte tekst), kunnen uw gebruikers handmatig toegang krijgen tot de staging slot door gebruik te maken van de x-ms-routing-name queryparameter. Ze worden niet automatisch naar de slot gerouteerd omdat het routeringspercentage is ingesteld op 0. This configuration is an advanced scenario where you can hide your staging slot from the public while allowing internal teams to test changes on the slot.

Een slot verwijderen

  1. Zoek en selecteer uw app.

  2. Select Deployment>Deployment slots>slot to delete>Overview. Het app-type wordt weergegeven als App Service (Slot) om u eraan te herinneren dat u een implementatieslot bekijkt.

  3. Stop het slot en stel het verkeer in het slot in op nul.

  4. Selecteer Verwijderen op de opdrachtbalk.

Schermopname van selecties voor het verwijderen van een implementatieslot in de portal.

Automatiseren met Resource Manager-sjablonen

Azure Resource Manager-sjablonen zijn declaratieve JSON-bestanden voor het automatiseren van de implementatie en configuratie van Azure-resources. Als u slots wilt wisselen via Resource Manager-sjablonen, stelt u twee eigenschappen in op de Microsoft.Web/sites/slots- en Microsoft.Web/sites-resources.

  • buildVersion: A string property that represents the current version of the app deployed in the slot. Bijvoorbeeld: v1, 1.0.0.1of 2019-09-20T11:53:25.2887393-07:00.
  • targetBuildVersion: Een stringeigenschap die aangeeft welke waarde de slot moet hebben. Als de targetBuildVersion waarde niet gelijk is aan de huidige buildVersion waarde, wordt de wisselbewerking geactiveerd door de slot met de opgegeven buildVersion waarde te vinden.

Voorbeeld van Een Resource Manager-sjabloon

De volgende Resource Manager-sjabloon wisselt twee slots door de buildVersion waarde van de staging slot bij te werken en de targetBuildVersion waarde op de productieslot in te stellen. U moet een sleuf hebben met de naam staging.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "my_site_name": {
            "defaultValue": "SwapAPIDemo",
            "type": "String"
        },
        "sites_buildVersion": {
            "defaultValue": "v1",
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Web/sites/slots",
            "apiVersion": "2018-02-01",
            "name": "[concat(parameters('my_site_name'), '/staging')]",
            "location": "East US",
            "kind": "app",
            "properties": {
                "buildVersion": "[parameters('sites_buildVersion')]"
            }
        },
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('my_site_name')]",
            "location": "East US",
            "kind": "app",
            "dependsOn": [
                "[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
            ],
            "properties": {
                "targetBuildVersion": "[parameters('sites_buildVersion')]"
            }
        }        
    ]
}

This Resource Manager template is idempotent. You can run it repeatedly and produce the same state of the slots. Zonder enige wijziging in de sjabloon activeren volgende uitvoeringen van dezelfde sjabloon geen wisseling van sites omdat de sites al de gewenste status hebben.

Troubleshoot swaps

Als er een fout optreedt tijdens een slotwissel, wordt de fout weergegeven in D:\home\LogFiles\eventlog.xml. Het wordt ook geregistreerd in het toepassingsspecifieke foutenlogboek.

Hier volgen enkele veelvoorkomende wisselfouten:

  • An HTTP request to the application root is timed. De wisselbewerking wacht 90 seconden voor elke HTTP-aanvraag en probeert maximaal vijf keer opnieuw. If all retries are timed out, the swap operation is stopped.

  • Initialisatie van lokale cache kan mislukken wanneer de app-inhoud het quotum voor de lokale schijf overschrijdt dat is opgegeven voor de lokale cache. Zie het overzicht van de lokale cache van Azure App Service voor meer informatie.

  • During a site update operation, the following error can occur: "The slot cannot be changed because its configuration settings have been prepared for swap." This error can occur if the first phase in a multiple-phase swap finishes but the second phase hasn't happened. Dit kan ook gebeuren als een wissel is mislukt. Er zijn twee manieren om dit probleem op te lossen:

    • Annuleer de wisselbewerking, waardoor de site opnieuw wordt ingesteld op de oude status.
    • Voltooi de wisselbewerking, waarmee de site wordt bijgewerkt naar de gewenste nieuwe status.

    Zie Wisselen met preview (meervoudige swap) eerder in dit artikel voor meer informatie over het annuleren of voltooien van de wisselbewerking.

  • Tijdens het opwarmen worden de HTTP-aanvragen intern uitgevoerd zonder de externe URL te doorlopen. Ze kunnen mislukken met bepaalde regels voor het herschrijven van URL's in Web.config. Regels voor het omleiden van domeinnamen of het afdwingen van HTTPS kunnen bijvoorbeeld verhinderen dat opwarmaanvragen de app-code bereiken. Als u dit probleem wilt omzeilen, wijzigt u de herschrijfregels door de volgende twee voorwaarden toe te voegen:

    <conditions>
      <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
      ...
    </conditions>
    
  • Zonder een aangepaste opwarmbewerking kunnen de REGELS voor het herschrijven van url's nog steeds HTTP-aanvragen blokkeren. Als u dit probleem wilt omzeilen, wijzigt u de herschrijfregels door de volgende voorwaarde toe te voegen:

    <conditions>
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
      ...
    </conditions>
    
  • Na slotwisselingen kan de app onverwacht herstarten. De herstarts gebeuren omdat de configuratie van de hostnaambinding na een wisseling niet meer wordt gesynchroniseerd. Deze situatie veroorzaakt zelf geen herstarts. Bepaalde onderliggende opslagevenementen, zoals failovers van opslagvolumes, kunnen deze verschillen detecteren en ervoor zorgen dat alle werkprocessen opnieuw worden opgestart.

    Als u deze typen herstarts wilt minimaliseren, stelt u de app-instelling WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 in op alle slots. Deze app-instelling werkt echter niet met WCF-apps (Windows Communication Foundation).

Volgende stap