Faseringsomgevingen in Azure App Service instellen
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 standaardproductiesite wanneer u in de Standard-, Premium- of Isolated App Service-planlaag werkt. Implementatiesites zijn live-apps met hun eigen hostnamen. App-inhoud en configuratie-elementen kunnen worden uitgewisseld tussen twee implementatiesites, inclusief de productiesite.
Het implementeren van uw toepassing in een niet-productiesite heeft de volgende voordelen:
- U kunt app-wijzigingen in een staging-implementatiesite valideren voordat u deze verwisselt met de productiesite.
- Als u eerst een app in een sleuf implementeert en vervolgens naar productie omwisselt, zorgt u ervoor dat alle instanties van de sleuf worden voorbereid voordat ze naar productie worden omgewisseld. Dit elimineert downtime wanneer u de app implementeert. De omleiding van verkeer is naadloos en er worden geen aanvragen verwijderd vanwege wisselbewerkingen. U kunt deze volledige werkstroom automatiseren door automatisch wisselen te configureren wanneer de validatie vooraf wisselen niet nodig is.
- Na een wisseling heeft de site met eerder gefaseerde app nu de vorige productie-app. Als de wijzigingen die zijn gewisseld in de productiesite niet zoals verwacht, kunt u dezelfde wissel direct uitvoeren om uw laatst bekende goede site terug te krijgen.
Elke App Service-planlaag ondersteunt een ander aantal implementatiesites. Er worden geen extra kosten in rekening gebracht voor het gebruik van implementatiesites. Zie App Service-limieten voor meer informatie over het aantal sites dat door de laag van uw app wordt 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 sites heeft, kunt u deze niet omlaag schalen naar de Standard-laag , omdat de Standard-laag slechts vijf implementatiesites ondersteunt.
In deze video ziet u hoe u faseringsomgevingen instelt in Azure-app Service.
De stappen in de video worden ook beschreven in de volgende secties.
Vereisten
Zie Resourceproviderbewerkingen (bijvoorbeeld zoeken naar site) voor informatie over de machtigingen die u nodig hebt om de gewenste sitebewerking uit te voeren.
Een sleuf toevoegen
De app moet worden uitgevoerd in de laag Standard, Premium of Isolated om meerdere implementatiesites in te schakelen.
Navigeer in Azure Portal naar de beheerpagina van uw app.
Selecteer in het linkerdeelvenster Implementatiesites>Site toevoegen.
Notitie
Als de app zich nog niet in de laag Standard, Premium of Isolated bevindt, selecteert u Upgraden en gaat u naar het tabblad Schaal van uw app voordat u doorgaat.
Geef in het dialoogvenster Een 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 site. Instellingen die kunnen worden gekloond, zijn app-instellingen, verbindingsreeks s, taalframeworkversies, websockets, HTTP-versie en platformbitness.
Notitie
Op dit moment wordt een privé-eindpunt niet gekloond tussen sites.
Nadat de site is toegevoegd, selecteert u Sluiten om het dialoogvenster te sluiten. De nieuwe site wordt nu weergegeven op de pagina Implementatiesites . Standaard is het verkeerspercentage ingesteld op 0 voor de nieuwe site, waarbij al het klantverkeer naar de productiesite wordt gerouteerd.
Selecteer de nieuwe implementatiesite om de resourcepagina van die site te openen.
De staging-site heeft net als elke andere App Service-app een beheerpagina. U kunt de configuratie van de site wijzigen. Om u eraan te herinneren dat u de implementatiesite bekijkt, wordt de app-naam weergegeven als app-naam>/<sitenaam en is het app-type> App Service (Slot).< U kunt de site ook zien als een afzonderlijke app in uw resourcegroep, met dezelfde aanduidingen.
Selecteer de APP-URL op de resourcepagina van de site. De implementatiesite heeft een eigen hostnaam en is ook een live-app. Zie Azure-app Service IP-beperkingen om de openbare toegang tot de implementatiesite te beperken.
De nieuwe implementatiesite heeft geen inhoud, zelfs als u de instellingen van een andere site kloont. U kunt bijvoorbeeld publiceren naar deze site met Git. U kunt implementeren naar de site vanuit een andere opslagplaatsbranch of een andere opslagplaats. Publicatieprofiel ophalen van Azure-app Service kan vereiste informatie verstrekken om te implementeren op de site. Het profiel kan worden geïmporteerd door Visual Studio om inhoud naar de site te implementeren.
De URL van de site 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 en moet de gecombineerde sitenaam en sitenaam uit minder dan 59 tekens bestaan.
Wat gebeurt er tijdens een wissel
Stappen voor wisselbewerking
Wanneer u twee sites wisselt (meestal van een staging-site als bron in de productiesite als doel), 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 verbindingsreeks s, indien van toepassing.
- Instellingen voor continue implementatie , indien ingeschakeld.
- App Service-verificatie-instellingen , indien ingeschakeld.
In elk van deze gevallen worden alle exemplaren in de bronsite geactiveerd om opnieuw te starten. Tijdens het wisselen met preview markeert dit het einde van de eerste fase. De wisselbewerking is onderbroken en u kunt controleren of de bronsite correct werkt met de instellingen van de doelsite.
Wacht tot elke instantie in de bronsite de herstart heeft voltooid. Als een exemplaar niet opnieuw kan worden opgestart, worden alle wijzigingen in de bronsite hersteld 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 opwarmbewerking, activeert u Application Initiation door een HTTP-aanvraag naar de hoofdmap van de toepassing (/) te verzenden op elk exemplaar van de bronsite.
Als
applicationInitializationdit niet is opgegeven, activeert u een HTTP-aanvraag naar de hoofdmap van de toepassing van de bronsite op elk exemplaar.Als een exemplaar een HTTP-antwoord retourneert, wordt het beschouwd als opgewarmd.
Als alle exemplaren op de bronsite zijn opgewarmd, wisselt u de twee sites door de routeringsregels voor de twee sites te wisselen. Na deze stap heeft de doelsite (bijvoorbeeld de productiesite) de app die eerder is opgewarmd in de bronsite.
Nu de bronsite de app vooraf heeft gewisseld in de doelsite, voert u dezelfde bewerking uit door alle instellingen toe te passen en de exemplaren opnieuw op te starten.
Op elk moment van 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 waar de wisseling 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
De exemplaren in uw voormalige productie-exemplaren (exemplaren die na deze wisselbewerking in fasering worden gewisseld) worden snel gerecycled in de laatste stap van het wisselproces. Als u langdurige bewerkingen in uw toepassing hebt, worden ze afgelaten wanneer de werknemers recyclen. Dit geldt ook voor functie-apps. Daarom moet uw toepassingscode op een fouttolerante manier worden geschreven.
Welke instellingen worden gewisseld?
Wanneer u de configuratie van een andere implementatiesite kloont, kan de gekloonde configuratie worden bewerkt. Sommige configuratie-elementen volgen de inhoud van een wissel (niet sitespecifiek), terwijl andere configuratie-elementen na een wisseling (sitespecifiek) in dezelfde site blijven. In de volgende lijsten worden de instellingen weergegeven die worden gewijzigd wanneer u sites verwisselt.
Instellingen die worden gewisseld:
- Algemene instellingen, zoals frameworkversie, 32/64-bits, websockets
- App-instellingen (kan worden geconfigureerd om aan een site te blijven)
- Verbinding maken iontekenreeksen (kan worden geconfigureerd om vast te houden aan een sleuf)
- Handlertoewijzingen
- Openbare certificaten
- WebJobs-inhoud
- Hybride verbindingen *
- Service-eindpunten *
- Azure Content Delivery Network *
- Padtoewijzingen
Functies die zijn gemarkeerd met een sterretje (*) zijn gepland om niet te worden opgewapt.
Instellingen die niet worden gewisseld:
- Eindpunten publiceren
- Aangepaste domeinnamen
- Niet-openbare certificaten en TLS/SSL-instellingen
- Schaalinstellingen
- WebJobs-planners
- IP-beperkingen
- Altijd ingeschakeld
- Diagnostische instellingen
- CORS (Cross-Origin Resource Sharing, cross-origin-resource delen)
- Integratie van virtueel netwerk
- Beheerde identiteiten en gerelateerde instellingen
- Instellingen dat eindigt op het achtervoegsel _EXTENSION_VERSION
- Instellingen die zijn gemaakt door Service Verbinding maken or
Notitie
Als u deze instellingen wilt verwisselen, voegt u de app-instelling WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS toe in elke site van de app en stelt u de waarde in op 0 of false. Deze instellingen zijn allemaal wisselbaar of helemaal niet. U kunt niet alleen bepaalde instellingen wisselen en niet de andere. Beheerde identiteiten worden nooit gewisseld en worden niet beïnvloed door deze onderdrukkings-app-instelling.
Bepaalde app-instellingen die van toepassing zijn op niet-opgewapte instellingen, worden ook niet gewisseld. Omdat diagnostische instellingen bijvoorbeeld niet worden gewisseld, worden gerelateerde app-instellingen zoals WEBSITE_HTTPLOGGING_RETENTION_DAYS en DIAGNOSTICS_AZUREBLOBRETENTIONDAYS worden ze ook niet gewisseld, zelfs niet als ze niet worden weergegeven als site-instellingen.
Als u een app-instelling of verbindingsreeks wilt configureren om aan een specifieke site te blijven (niet gewisseld), gaat u naar de pagina Configuratie voor die site. Voeg een instelling toe of bewerk deze en selecteer vervolgens de instelling van de implementatiesite. Als u dit selectievakje inschakelt, wordt in App Service aangegeven dat de instelling niet kan worden gewisseld.
Twee sites wisselen
U kunt implementatiesites wisselen op de pagina Implementatiesites van uw app en op de pagina Overzicht . Zie Wat er gebeurt tijdens het wisselen voor technische informatie over de wisseling van sites.
Belangrijk
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.
Implementatiesites wisselen:
Ga naar de pagina Implementatiesites van uw app en selecteer Wisselen.
In het dialoogvenster Wisselen worden instellingen weergegeven in de geselecteerde bron- en doelsites die worden gewijzigd.
Selecteer de gewenste bron - en doelsites . Meestal is het doel de productiesite. Selecteer ook de tabbladen Bronwijzigingen en Doelwijzigingen en controleer of de configuratiewijzigingen worden verwacht. Wanneer u klaar bent, kunt u de sites direct wisselen door Wisselen te selecteren.
Als u wilt zien hoe uw doelsite wordt uitgevoerd met de nieuwe instellingen voordat de wissel daadwerkelijk plaatsvindt, selecteert u Wisselen niet, maar volgt u de instructies in Wisselen met preview.
Wanneer u klaar bent, sluit u het dialoogvenster door Sluiten te selecteren.
Als u problemen ondervindt, raadpleegt u Swaps oplossen.
Wisselen met preview (wisselen in meerdere fasen)
Voordat u naar productie overgaat als doelsite, controleert u of de app wordt uitgevoerd 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. Vervolgens kunt u het resultaat op de staging-site controleren voordat u de wissel voltooit.
Als u de wissel annuleert, worden configuratie-elementen opnieuw door App Service toegepast op de bronsite.
Notitie
Wisselen met preview kan niet worden gebruikt wanneer een van de sites siteverificatie heeft ingeschakeld.
Wisselen met preview:
Volg de stappen in Implementatiesites wisselen, maar selecteer Wisselen met preview.
In het dialoogvenster ziet u hoe de configuratie in de bronsite verandert in fase 1 en hoe de bron- en doelsite in fase 2 veranderen.
Wanneer u klaar bent om de wissel te starten, selecteert u Wisselen starten.
Wanneer fase 1 is voltooid, krijgt u een melding in het dialoogvenster. Bekijk een voorbeeld van de wissel in de bronsite door naar
https://<app_name>-<source-slot-name>.azurewebsites.net.Wanneer u klaar bent om de wisseling in behandeling te voltooien, selecteert u Wisseling voltooien in de actie Wisselen en selecteert u Wisseling voltooien.
Als u een wisseling in behandeling wilt annuleren, selecteert u In plaats daarvan Wisselen annuleren en selecteert u Vervolgens onderaan de optie Wisselen annuleren.
Wanneer u klaar bent, sluit u het dialoogvenster door Sluiten te selecteren.
Als u problemen ondervindt, raadpleegt u Swaps oplossen.
Een wissel terugdraaien
Als er fouten optreden in de doelsite (bijvoorbeeld de productiesite) na een wisseling van sites, herstelt u de sites in de status vooraf wisselen door dezelfde twee sites onmiddellijk te verwisselen.
Automatisch wisselen configureren
Notitie
Automatisch wisselen wordt niet ondersteund in web-apps in Linux en Web App for Containers.
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 site in productie, wordt de app automatisch in productie gewisseld wanneer u de codewijzigingen naar die site pusht nadat deze is opgewarmd in de bronsite.
Notitie
Voordat u automatisch wisselen configureert voor de productiesite, kunt u overwegen om automatisch wisselen te testen op een niet-productiedoelsite.
Automatisch wisselen configureren:
Ga naar de resourcepagina van uw app. Selecteer De gewenste instellingen voor de configuratie van de bronsite>><>>configureren.
Als Automatisch wisselen is ingeschakeld, selecteert u Aan. Selecteer vervolgens de gewenste doelsite voor de implementatiesite voor automatisch wisselen en selecteer Opslaan op de opdrachtbalk.
Voer een codepush uit naar de bronsite. Automatisch wisselen vindt plaats na korte tijd en de update wordt weergegeven op de URL van uw doelsite.
Als u problemen ondervindt, raadpleegt u Swaps oplossen.
Aangepaste opwarming opgeven
Voor sommige apps zijn mogelijk aangepaste opwarmacties vereist voordat de wissel wordt uitgevoerd. Met het applicationInitialization configuratie-element in web.config kunt u aangepaste initialisatieacties opgeven. De wisselbewerking wacht tot deze aangepaste opwarmbewerking is voltooid voordat deze wordt gewisseld met de doelsite. Hier volgt een voorbeeld van een web.config-fragment.
<system.webServer>
<applicationInitialization>
<add initializationPage="/" hostName="[app hostname]" />
<add initializationPage="/Home/About" hostName="[app hostname]" />
</applicationInitialization>
</system.webServer>
Zie De meest voorkomende wisselfouten in de implementatiesite en hoe u dit kunt oplossen voor meer informatie over het aanpassen van het applicationInitialization element.
U kunt het opwarmgedrag ook aanpassen met een of beide 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 die moet worden pingen wanneer de site opnieuw wordt opgestart (niet alleen tijdens het wisselen van sites). Voorbeelden van waarden zijn/statuscheckof het hoofdpad./
Notitie
Het <applicationInitialization> configuratie-element maakt deel uit van elke app-opstartbewerking, terwijl de twee instellingen voor het opwarmen van de app alleen van toepassing zijn op sitewisselingen.
Als u problemen ondervindt, raadpleegt u Swaps oplossen.
Een wissel bewaken
Als het lang duurt voordat de wisselbewerking is voltooid, kunt u informatie krijgen over de wisselbewerking in het activiteitenlogboek.
Selecteer activiteitenlogboek op de resourcepagina van uw app in de portal in het linkerdeelvenster.
Er wordt een wisselbewerking weergegeven in de logboekquery als Swap Web App Slots. U kunt deze uitvouwen en een van de suboperaties of fouten selecteren om de details te bekijken.
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 site 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.
Productieverkeer automatisch routeren:
Ga naar de resourcepagina van uw app en selecteer Implementatiesites.
Geef in de kolom Verkeerspercentage van de site waarnaar u wilt routeren een percentage op (tussen 0 en 100) om het totale verkeer weer te geven dat u wilt routeren. Selecteer Opslaan.
Nadat de instelling is opgeslagen, wordt het opgegeven percentage clients willekeurig gerouteerd naar de niet-productiesite.
Nadat een client automatisch naar een specifieke site wordt gerouteerd, wordt deze gedurende één uur 'vastgemaakt' aan die site 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-site wordt gerouteerd, 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 aanvragen routeren naar een specifieke site. Dit 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 geeft de productiesite op. Nadat de clientbrowser toegang heeft tot de koppeling, wordt deze omgeleid naar de productiesite. Elke volgende aanvraag heeft de x-ms-routing-name=self cookie waarmee de sessie aan de productiesite 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-productiesite. Hier volgt een voorbeeld:
<webappname>.azurewebsites.net/?x-ms-routing-name=staging
Nieuwe sites krijgen standaard een routeringsregel van 0%, weergegeven in grijs. Wanneer u deze waarde 0% expliciet instelt op (weergegeven in zwarte tekst), hebben uw gebruikers handmatig toegang tot de staging-site met behulp van de x-ms-routing-name queryparameter. Ze worden echter niet automatisch doorgestuurd naar de site omdat het routeringspercentage is ingesteld op 0. Dit is een geavanceerd scenario waarin u uw staging-site voor het publiek kunt verbergen, terwijl interne teams wijzigingen op de site kunnen testen.
Een site verwijderen
Zoek en selecteer uw app. Selecteer de site Implementatiesites><om Overzicht te verwijderen.>> Het app-type wordt weergegeven als App Service (Site) om u eraan te herinneren dat u een implementatiesite bekijkt. Voordat u een site verwijdert, moet u de site stoppen en het verkeer in de site instellen op nul. Selecteer Verwijderen op de opdrachtbalk.
Automatiseren met Resource Manager-sjablonen
Azure Resource Manager-sjablonen zijn declaratieve JSON-bestanden die worden gebruikt om de implementatie en configuratie van Azure-resources te automatiseren. Als u sites wilt wisselen met behulp van Resource Manager-sjablonen, stelt u twee eigenschappen in op de resources Microsoft.Web/sites/sites en Microsoft.Web/sites :
buildVersion: dit is een tekenreekseigenschap die de huidige versie van de app vertegenwoordigt die in de site is geïmplementeerd. Bijvoorbeeld: 'v1', '1.0.0.1' of '2019-09-20T11:53:25.2887393-07:00'.targetBuildVersion: dit is een tekenreekseigenschap die aangeeft watbuildVersionde site moet hebben. Als detargetBuildVersionwaarde niet gelijk is aan de huidigebuildVersion, wordt de wisselbewerking geactiveerd door de site met de opgegevenbuildVersionsite te zoeken.
Voorbeeld van Een Resource Manager-sjabloon
De volgende Resource Manager-sjabloon wisselt twee sites door de buildVersionstaging site bij te werken en de targetBuildVersion site in te stellen op de productiesite. Hierbij wordt ervan uitgegaan dat u een site hebt gemaakt 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, wat betekent dat deze herhaaldelijk kan worden uitgevoerd en dezelfde status van de sleuven kan 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.
Problemen met wisselingen oplossen
Als er een fout optreedt tijdens een sitewisseling, wordt deze geregistreerd 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 er een time-out optreedt voor alle nieuwe pogingen, wordt de wisselbewerking gestopt.
Initialisatie van lokale cache kan mislukken wanneer de app-inhoud het lokale schijfquotum overschrijdt dat is opgegeven voor de lokale cache. Zie het overzicht van lokale cache voor meer informatie.
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>Nadat de site is gewisseld, kan de app onverwachte herstarts ondervinden. Dit komt doordat na een wisseling de configuratie van de hostnaambinding niet meer wordt gesynchroniseerd, wat op zichzelf geen herstart veroorzaakt. 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 sites. Deze app-instelling werkt echter niet met WCF-apps (Windows Communication Foundation).