Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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. Deploymentslots zijn live-apps met hun eigen hostnamen. 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:
U kunt app-wijzigingen valideren voordat u de slot naar de productieomgeving verplaatst.
U kunt ervoor zorgen dat alle exemplaren van de slot zijn opgewarmd voordat u deze in productie overzet. Deze aanpak elimineert downtime wanneer u uw app implementeert. De verkeersomleiding is naadloos. Er worden geen aanvragen verwijderd vanwege wisselbewerkingen.
U kunt deze volledige werkstroom automatiseren door het automatisch wisselen te configureren wanneer validatie vóór het wisselen niet nodig is.
Na een wisseling heeft de site met eerder gefaseerde app nu de vorige productie-app. Als de wijzigingen die naar het productieslot zijn gewisseld niet zijn zoals u verwacht, kunt u direct dezelfde wissel uitvoeren om uw laatst bekende werkende site terug te krijgen.
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.
Vereiste voorwaarden
- Machtigingen om de gewenste slotoperatie uit te voeren. Zie Bewerkingen van de resourceprovider voor meer informatie over de vereiste machtigingen. Zoek bijvoorbeeld naar slot.
Een sleuf toevoegen
Als u meerdere implementatiesleuven wilt inschakelen, moet de app draaien in de Standard-, Premium- of Isolated-laag.
Ga in Azure Portal naar de beheerpagina van uw app.
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.
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.
U kunt een configuratie klonen vanuit elke bestaande 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.
Nadat u de instellingen hebt ingevoerd, selecteert u Sluiten om het dialoogvenster te sluiten. De nieuwe slot wordt nu weergegeven op de pagina Implementatieslots. Verkeer % is standaard ingesteld op 0 voor de nieuwe slot, waarbij al het klantverkeer naar het productieslot wordt gerouteerd.
Selecteer de nieuwe implementatiesleuf om de resourcepagina te openen.
De staging-site heeft, zoals elke andere App Service-app, een beheerpagina. U kunt de configuratie van de slot wijzigen. Om u eraan te herinneren dat u de aanzetplek bekijkt, worden de naam van de app en de slotnaam weergegeven in de URL. Het app-type is App Service (Slot). U kunt het slot ook zien als een afzonderlijke app in uw resourcegroep, met dezelfde aanduidingen.
Selecteer op de resourcepagina van de site de 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. U kunt bijvoorbeeld naar deze slot publiceren met Git. U kunt implementeren naar de slot vanuit een andere vertakking of een andere opslagplaats. Het artikel Een publicatieprofiel ophalen uit Azure App Service kan de vereiste informatie bieden voor het implementeren naar de site. Visual Studio kan het profiel importeren om inhoud naar de site te implementeren.
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:
Pas de volgende instellingen van de doelsite (bijvoorbeeld de productiesite) toe op alle exemplaren van de bronsite:
- Sitespecifieke app-instellingen en verbindingsreeksen, indien van toepassing
- Instellingen voor continue implementatie , indien ingeschakeld
- App Service-verificatie-instellingen , indien ingeschakeld
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.
Wacht tot elke instantie in het bronvak zijn herstart heeft afgerond. Als een exemplaar niet opnieuw kan worden opgestart, worden alle wijzigingen in de bronplek ongedaan gemaakt en wordt de bewerking gestopt.
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.Als automatisch wisselen is ingeschakeld met aangepaste opwarming, activeert u de initialisatie van de aangepaste toepassing op elk exemplaar van de bronsite.
Als
applicationInitializationniet is opgegeven, wordt een HTTP-verzoek uitgevoerd naar de hoofdmap van de broninstantie op elke instance.Als een exemplaar een HTTP-antwoord retourneert, wordt het beschouwd als opgewarmd.
Als alle exemplaren op de bron-slot met succes worden opgewarmd, wisselt u de twee slots door hun routeringsregels om te schakelen. Na deze stap heeft de doelsite (bijvoorbeeld de productiesite) de app die eerder is opgewarmd in de bronsite.
Nu de app die eerder in het doelslot zat, zich in het bronslot bevindt, voert u dezelfde bewerking uit door alle instellingen toe te passen en de instanties opnieuw op te starten.
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
Uw voormalige productie-exemplaren worden na deze wisselbewerking overgewisseld in fasering. Deze gevallen worden gerecycled in de laatste stap van het ruilproces. Als u langlopende bewerkingen in uw toepassing hebt, worden ze afgelaten wanneer de werknemers recyclen. 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-instellingen (kan worden geconfigureerd om aan een slot te blijven)
- Verbindingsreeksen (kunnen worden geconfigureerd om vast te houden aan een sleuf)
- Gekoppelde opslagaccounts (kunnen worden geconfigureerd om aan een slot te blijven)
- Handlertoewijzingen
- Openbare certificaten
- WebJobs-inhoud
- Hybride verbindingen (momenteel)
- Service-eindpunten (momenteel)
- Azure Content Delivery Network (momenteel)
- Padtoewijzingen
Wanneer u slots wisselt, worden deze instellingen niet omgewisseld:
- Algemene instellingen die niet worden vermeld in de vorige lijst
- Eindpunten publiceren
- Aangepaste domeinnamen
- Niet-openbare certificaten en TLS/SSL-instellingen
- Schaalinstellingen
- WebJobs-schedulers
- IP-beperkingen
- Altijd ingeschakeld
- Instellingen voor diagnostiek
- Delen van bronnen tussen verschillende herkomst (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. Deze instelling voor het overschrijven van apps heeft geen invloed op deze instellingen.
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:
Ga naar Instellingen>Omgevingsvariabele voor die slot.
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.
Selecteer de optie Toepassen.
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.
Ga naar de Implementatieslots pagina van uw app en selecteer Wisselen.
In het dialoogvenster Wisselen worden instellingen weergegeven in de geselecteerde bron- en doelsites die moeten worden gewijzigd.
Selecteer de gewenste bron - en doelsites . 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.
Als u wilt zien hoe uw doelslot werkt met de nieuwe instellingen voordat de wissel plaatsvindt, selecteer dan niet Wisselen starten. Volg de instructies in Wisselen met voorbeeld later in de tekst.
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)
Voordat u naar de productieomgeving overgaat als doelomgeving, controleert u of de app correct werkt met de gewisselde instellingen. De bronsite wordt ook opgewarmd voordat de swap is voltooid, wat wenselijk is voor bedrijfskritieke toepassingen.
Wanneer u een wissel met preview uitvoert, voert App Service dezelfde wisselbewerking uit, maar wordt na de eerste stap onderbroken. Daarna kunt u het resultaat op de staging-slot controleren voordat u de wissel voltooit.
Als u de wisseling annuleert, past App Service configuratie-elementen opnieuw toe op het bronvak.
Notitie
U kunt swappen met preview niet gebruiken wanneer authenticatie is ingeschakeld in een van de slots.
Volg de stappen in de sectie Implementatieslots wisselen, maar selecteer Wisselen met preview.
In het dialoogvenster ziet u hoe de configuratie in de bron-vak in de eerste fase verandert, en hoe de bron- en doelvak in de tweede fase veranderen.
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.
Wanneer u klaar bent om de wisseling in behandeling te voltooien, selecteert u Wisseling voltooien in wisselactie en selecteert u vervolgens de knop Wisseling voltooien.
Om een in behandeling zijnde wissel te annuleren, selecteert u Wissel annuleren in plaats daarvan, en selecteer daarna de knop Wissel annuleren.
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. Wanneer automatisch wisselen is ingeschakeld vanuit een slot naar productie, wordt de app elke keer dat u uw codewijzigingen naar dat slot pusht, automatisch na opwarming in de bronslot naar productie gewisseld.
Notitie
Automatisch wisselen wordt niet ondersteund in web-apps in Linux en in Web App for Containers.
Voordat u autoswap configureert voor de productieslot, kunt u overwegen deze te testen op een niet-productiedoelslot.
Ga naar de resourcepagina van uw app. Selecteer Implementaties> en implementatieslots, en selecteer vervolgens de gewenste bronlot.
Selecteer inhet linkermenu>>algemene instellingen.
Als Automatisch wisselen is ingeschakeld, selecteert u Aan. Selecteer het doelvak voor de automatische wissel van de implementatie. Selecteer Vervolgens Opslaan op de opdrachtbalk.
Voer een codepush uit naar de bronsite. Automatisch wisselen vindt plaats na korte tijd. De update wordt weergegeven op de URL van uw doelsite.
Raadpleeg Swaps oplossen verderop in dit artikel als u problemen ondervindt.
Aangepaste opwarming specificeren
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. De wisselbewerking wacht tot deze aangepaste opwarmbewerking is voltooid voordat deze wordt verwisseld met de doelsleuf. 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 is200,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: Een relatief pad op de site dat gepingt moet worden wanneer de site opnieuw opstart (niet alleen tijdens het wisselen van slot). Voorbeelden van waarden zijn/statuscheckof 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.
Selecteer activiteitenlogboek in het linkermenu op de resourcepagina van uw app in de portal.
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 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.
Ga naar de resourcepagina van uw web-app en selecteer Implementatie>Implementatieslots.
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.
Nadat u de instelling hebt opgeslagen, wordt het opgegeven percentage cliënten willekeurig gerouteerd naar de niet-productieomgeving.
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. Een aanvraag die naar de staging-plek wordt doorgestuurd, heeft de 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>
De tekenreeks x-ms-routing-name=self specificeert de productiesleuf. Nadat de clientbrowser toegang heeft tot de koppeling, wordt deze omgeleid naar de productiesite. Elke volgende aanvraag heeft het x-ms-routing-name=self cookie waarmee de sessie aan het productieslot wordt vastgemaakt.
Als u wilt dat gebruikers zich aanmelden voor uw bèta-app, stelt u dezelfde queryparameter in op de naam van de niet-productie-omgeving. 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. **
Deze configuratie is een geavanceerd scenario waarin u uw staging-gebied kunt verbergen voor het publiek, terwijl interne teams wijzigingen in dit gebied kunnen testen.
Een slot verwijderen
Zoek en selecteer uw app.
Selecteer Implementatie>Implementatieslots>slot te verwijderen>Overzicht. Het app-type wordt weergegeven als App Service (Slot) om u eraan te herinneren dat u een implementatieslot bekijkt.
Stop het slot en stel het verkeer in het slot in op nul.
Selecteer Verwijderen op de opdrachtbalk.
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: Een tekenreeks-eigenschap die de huidige versie van de app vertegenwoordigt die in de slot is geïmplementeerd. Bijvoorbeeld:v1,1.0.0.1of2019-09-20T11:53:25.2887393-07:00. -
targetBuildVersion: Een stringeigenschap die aangeeft welke waarde de slot moet hebben. Als detargetBuildVersionwaarde niet gelijk is aan de huidigebuildVersionwaarde, wordt de wisselbewerking geactiveerd door de slot met de opgegevenbuildVersionwaarde 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')]"
}
}
]
}
Deze Resource Manager-sjabloon is idempotent. U kunt het herhaaldelijk uitvoeren en dezelfde toestand van de slots produceren. Zonder enige wijziging in de sjabloon activeren volgende uitvoeringen van dezelfde sjabloon geen wisseling van sites omdat de sites al de gewenste status hebben.
Storingen bij wisselingen oplossen
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:
Er wordt een HTTP-aanvraag naar de hoofdmap van de toepassing getimed. De wisselbewerking wacht 90 seconden voor elke HTTP-aanvraag en probeert maximaal vijf keer opnieuw. Als alle pogingen een time-out hebben, wordt de wisselbewerking gestopt.
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.
Tijdens een site-updatebewerking kan de volgende fout optreden: 'De slot kan niet worden gewijzigd omdat de configuratie-instellingen zijn voorbereid voor een wisseling'. Deze fout kan optreden als de eerste fase in een wissel in meerdere fasen is voltooid, maar de tweede fase niet heeft plaatsgevonden. 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=1in op alle slots. Deze app-instelling werkt echter niet met WCF-apps (Windows Communication Foundation).