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 implementatiesleuf gebruiken in plaats van de standaardproductiesleuf wanneer u de laag Standard, Premium of Isolated App Service plan gebruikt. Implementatiesleuven zijn live-apps met hun eigen hostnamen. App-inhoud en configuratie-elementen kunnen worden gewisseld tussen twee implementatiesleuven, waaronder de productiesleuf.

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

• U kunt app-wijzigingen valideren in een staging-implementatiesleuf voordat u deze verwisselt met de productiesleuf.
• 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 verkeersomleiding is naadloos en er worden geen aanvragen ingetrokken vanwege wisselbewerkingen. U kunt deze hele werkstroom automatiseren door automatisch wisselen te configureren wanneer validatie vóór wisseling niet nodig is.
• Na een wissel heeft de sleuf met de eerder gefaseerd app nu de vorige productie-app. Als de wijzigingen die in de productiesite zijn gewisseld niet zijn zoals verwacht, kunt u dezelfde wissel onmiddellijk uitvoeren om uw 'laatst bekende goede site' terug te krijgen.

Elke App Service planlaag ondersteunt een ander aantal implementatiesleuven. Er worden geen extra kosten in rekening brengen voor het gebruik van implementatiesleuven. Zie Limieten voor App Service voor meer informatie over het aantal sleuven dat door de laag van uw app App Service ondersteund.

Als u uw app wilt schalen naar een andere laag, moet u ervoor zorgen dat de doellaag ondersteuning biedt voor het aantal sleuven dat uw app al gebruikt. Als uw app bijvoorbeeld meer dan vijf sleuven heeft, kunt u deze niet omlaag schalen naar de standard-laag, omdat de Standard-laag slechts vijf implementatiesleuven ondersteunt.

Een sleuf toevoegen

De app moet worden uitgevoerd in de laag Standard, Premium of Isolated, zodat u meerdere implementatiesleuven kunt inschakelen.

1. zoek en Azure Portalin de App Services en selecteer uw app.

   

2. Selecteer in het linkerdeelvenster Implementatiesleuven > Sleuf toevoegen.

   

   Notitie

   Als de app zich nog niet in de standard-, Premium- of Isolated-laag ziet, ontvangt u een bericht met de ondersteunde lagen voor het inschakelen van gefaseerd publiceren. U hebt nu de optie om Upgraden te selecteren en naar het tabblad Schalen van uw app te gaan voordat u doorgaat.

3. Geef in het dialoogvenster Een sleuf toevoegen een naam op voor de sleuf en selecteer of u een app-configuratie van een andere implementatiesleuf wilt klonen. Selecteer Toevoegen om door te gaan.

   

   U kunt een configuratie klonen vanuit een bestaande sleuf. Instellingen die kunnen worden gekloond, zijn onder andere app-instellingen, verbindingsreeksen, taal frameworkversies, websockers, HTTP-versie en platform bitness.

4. Nadat de sleuf is toegevoegd, selecteert u Sluiten om het dialoogvenster te sluiten. De nieuwe site wordt nu weergegeven op de pagina Implementatiesleuven. Verkeer % is standaard ingesteld op 0 voor de nieuwe sleuf, met al het klantverkeer gerouteerd naar de productiesleuf.

5. Selecteer de nieuwe implementatiesleuf om de resourcepagina van die site te openen.

   

   De staging-site heeft een beheerpagina, net zoals elke andere App Service app. U kunt de configuratie van de sleuf wijzigen. Om u eraan te herinneren dat u de implementatiesleuf bekijkt, wordt de naam van de app weergegeven als en is het <app-name>/<slot-name> app-type App Service (sleuf). U kunt de sleuf ook zien als een afzonderlijke app in uw resourcegroep, met dezelfde aanduidingen.

6. Selecteer de APP-URL op de resourcepagina van de site. De implementatiesleuf heeft een eigen hostnaam en is ook een live-app. Als u openbare toegang tot de implementatiesleuf wilt beperken, Azure App Service IP-beperkingen.

De nieuwe implementatiesleuf bevat geen inhoud, zelfs niet als u de instellingen van een andere site kloont. U kunt bijvoorbeeld publiceren naar deze sleuf met Git. U kunt implementeren in de sleuf vanuit een andere vertakking van de opslagplaats of vanuit een andere opslagplaats.

De URL van de site heeft de indeling http://sitename-slotname.azurewebsites.net . Als u de URL-lengte binnen de benodigde DNS-limieten wilt houden, wordt de sitenaam afgekapt tot 40 tekens, wordt de sitenaam afgekapt met 19 tekens en worden er 4 extra willekeurige tekens toegevoegd om ervoor te zorgen dat de resulterende domeinnaam uniek is.

Wat er gebeurt tijdens een wisseling

Bewerkingsstappen wisselen

Wanneer u twee sleuven (meestal van een staging-slot naar de productiesleuf) wisselt, doet App Service het volgende om ervoor te zorgen dat de doelsleuf geen downtime ervaart:

1. Pas de volgende instellingen van de doelsleuf (bijvoorbeeld de productiesleuf) toe op alle exemplaren van de bronsleuf:

   • Sitespecifieke app-instellingen en verbindingsreeksen, indien van toepassing.
   • Instellingen voor continue implementatie, indien ingeschakeld.
   • App Service verificatie-instellingen, indien ingeschakeld.

   Elk van deze gevallen activeert alle exemplaren in de bronsleuf om opnieuw op te starten. Tijdens het wisselen met de preview-versiewordt hiermee het einde van de eerste fase markeert. De wisselbewerking is onderbroken en u kunt controleren of de bronsleuf correct werkt met de instellingen van de doelsleuf.

2. Wacht tot elke instantie in de bronsleuf de herstart heeft voltooid. Als een exemplaar niet opnieuw kan worden opgestart, worden met de wisselbewerking alle wijzigingen in de bronsleuf terugverdraaid en wordt de bewerking gestopt.

3. Als lokale cache is ingeschakeld, activeert u de initialisatie van de lokale cache door op elk exemplaar van de bronsleuf een HTTP-aanvraag naar de hoofdmap van de toepassing ('/') te sturen. Wacht totdat elk exemplaar een HTTP-antwoord retourneert. Initialisatie van de lokale cache zorgt ervoor dat elk exemplaar opnieuw wordt opgestart.

4. Als automatisch wisselen is ingeschakeld met aangepaste opwarming, activeert u Application Initiation door een HTTP-aanvraagte maken naar de hoofdmap van de toepassing (/) op elk exemplaar van de bronsleuf.

   Als niet is opgegeven, activeert u een HTTP-aanvraag naar de hoofdmap van de toepassing applicationInitialization van de bronsleuf op elk exemplaar.

   Als een exemplaar een HTTP-antwoord retourneert, wordt dit beschouwd als opgewarmd.

5. Als alle exemplaren op de bronsleuf zijn opgewarmd, verwisselt u de twee sleuven door de routeringsregels voor de twee sleuven te wisselen. Na deze stap heeft de doelsleuf (bijvoorbeeld de productiesleuf) de app die eerder is opgewarmd in de bronsleuf.

6. Nu de bronsleuf de app vooraf heeft gewisseld in de doelsleuf, voert u dezelfde bewerking uit door alle instellingen toe te passen en de exemplaren opnieuw te starten.

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

Welke instellingen worden gewisseld?

Wanneer u de configuratie van een andere implementatiesleuf kloont, kan de gekloonde configuratie worden bewerkt. Sommige configuratie-elementen volgen de inhoud van een wisseling (niet sleufs specifiek), terwijl andere configuratie-elementen in dezelfde sleuf blijven na een wisseling (sleufsysyte). De volgende lijsten geven de instellingen weer die veranderen wanneer u van site wisselt.

Instellingen die worden gewisseld:

• Algemene instellingen, zoals frameworkversie, 32/64-bits websockockers
• App-instellingen (kunnen worden geconfigureerd om een site te blijven gebruiken)
• Verbindingsreeksen (kunnen worden geconfigureerd om een sleuf te blijven gebruiken)
• Handlertoewijzingen
• Openbare certificaten
• WebJobs-inhoud
• Hybride verbindingen *
• Service-eindpunten *
• Azure Content Delivery Network *
• Padtoewijzingen

Functies die zijn gemarkeerd met een sterretje (*) worden gepland om te worden losgeappt.

Instellingen die niet worden gewisseld:

• Eindpunten publiceren
• Aangepaste domeinnamen
• Niet-openbare certificaten en TLS/SSL-instellingen
• Schaalinstellingen
• WebJobs-schedulers
• IP-beperkingen
• AlwaysOn
• Diagnostische instellingen
• CORS (Cross-Origin Resource Sharing, cross-origin-resource delen)
• Integratie van virtueel netwerk
• Beheerde identiteiten
• Instellingen dat eindigt met het achtervoegsel _EXTENSION_VERSION

Als u een app-instelling wilt configureren of connection string u zich wilt houden aan een specifieke site (niet gewisseld), gaat u naar de pagina Configuratie voor die site. Voeg een instelling toe of bewerk deze en selecteer vervolgens implementatiesleufinstelling. Als u dit selectievakje incheckt, App Service dat de instelling niet kan worden gewisseld.

Twee sleuven wisselen

U kunt implementatiesleuven wisselen op de pagina Implementatiesleuven van uw app en de pagina Overzicht. Zie Wat gebeurt er tijdens het wisselen voor technische details over het wisselen van de sleuf.

Implementatiesleuven wisselen:

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

   

   In het dialoogvenster Wisselen worden instellingen weergegeven in de geselecteerde bron- en doelsleuven die worden gewijzigd.

2. Selecteer de gewenste bron- en doelsleuven. Normaal gesproken is het doel de productiesleuf. Selecteer ook de tabbladen Bronwijzigingen en Doelwijzigingen en controleer of de configuratiewijzigingen worden verwacht. Wanneer u klaar bent, kunt u de sleuven onmiddellijk wisselen door Wisselen te selecteren.

   

   Als u wilt zien hoe uw doelsleuf wordt uitgevoerd met de nieuwe instellingen voordat de wisseling daadwerkelijk wordt uitgevoerd, selecteert u niet Wisselen, maar volgt u de instructies in Wisselen met preview.

3. Wanneer u klaar bent, sluit u het dialoogvenster door Sluiten te selecteren.

Zie Problemen met wisselingen oplossen als u problemen hebt.

Wisselen met preview (wisselen in meerdere fasen)

Voordat u naar productie wisselt als doelsleuf, controleert u of de app wordt uitgevoerd met de gewisselde instellingen. De bronsleuf wordt ook opgewarmd vóór de wisseling, wat wenselijk is voor bedrijfskritische toepassingen.

Wanneer u een wissel met preview uitvoert, voert App Service dezelfde wisselbewerking uit, maar wordt na de eerste stap gepauzeerd. Vervolgens kunt u het resultaat op de staging-sleuf controleren voordat u de wissel voltooit.

Als u de wisseling annuleert, App Service configuratie-elementen opnieuw op de bronsleuf.

Om te wisselen met preview:

1. Volg de stappen in Implementatiesleuven wisselen, maar selecteer Wisselen met preview uitvoeren.

   

   In het dialoogvenster ziet u hoe de configuratie in de bronsleuf in fase 1 verandert en hoe de bron- en doelsleuf in fase 2 veranderen.

2. Wanneer u klaar bent om de wisseling te starten, selecteert u Wisselen starten.

   Wanneer fase 1 is bereikt, wordt u hiervan op de hoogte gesteld in het dialoogvenster. Bekijk een voorbeeld van de wissel in de bronsleuf door naar te https://<app_name>-<source-slot-name>.azurewebsites.net gaan.

3. Wanneer u klaar bent om de wisseling in behandeling te voltooien, selecteert u Wisselen voltooien in de actie Wisselen en selecteert u Wisselen voltooien.

   Als u een wisseling in behandeling wilt annuleren, selecteert u in plaats daarvan Wisselen annuleren.

4. Wanneer u klaar bent, sluit u het dialoogvenster door Sluiten te selecteren.

Zie Problemen met wisselingen oplossen als u problemen hebt.

Zie Automate with PowerShell(Automatiseren met PowerShell) als u een wissel in meerdere fasen wilt automatiseren.

Een wissel terugdraaien

Als er fouten optreden in de doelsleuf (bijvoorbeeld de productiesleuf) na het wisselen van een sleuf, herstelt u de sleuven naar hun pre-swap-staat door dezelfde twee sleuven onmiddellijk om te wisselen.

Automatisch wisselen configureren

Automatisch wisselen stroomlijnt Azure DevOps-scenario's waarbij u uw app continu wilt implementeren met nul koude starts en geen downtime voor klanten van de app. Wanneer automatisch wisselen is ingeschakeld vanuit een sleuf naar productie, verwisselt App Service elke keer dat u uw codewijzigingen naar die sleuf pusht, de app automatisch in productie nadat deze is opgewarmd in de bronsleuf.

Automatisch wisselen configureren:

1. Ga naar de resourcepagina van uw app. Selecteer Implementatiesleuven > <desired source slot> > Configuratie > Algemene instellingen.

2. Voor Automatisch wisselen ingeschakeld selecteert u Aan. Selecteer vervolgens de gewenste doelsleuf voor de implementatiesleuf Automatisch wisselen en selecteer Opslaan op de opdrachtbalk.

   

3. Voer een code-push uit naar de bronsleuf. Automatisch wisselen vindt na korte tijd plaats en de update wordt weergegeven op de URL van uw doelsleuf.

Zie Problemen met wisselingen oplossen als u problemen hebt.

Aangepaste opwarming opgeven

Voor sommige apps zijn mogelijk aangepaste opwarmacties vereist vóór de wisseling. Met applicationInitialization het configuratie-element in web.config kunt u aangepaste initialisatieacties opgeven. De wisselbewerking wacht tot deze aangepaste opwarmbewerking is uitgevoerd voordat deze wordt gewisseld met de doelsleuf. Hier is een voorbeeld van web.config fragment.

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

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

U kunt het opwarmgedrag ook aanpassen met een of beide van de volgende app-instellingen:

• WEBSITE_SWAP_WARMUP_PING_PATH: Het pad om te pingen via HTTP 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 niet in de lijst staat, worden de opwarm- en wisselbewerkingen gestopt. Standaard zijn alle antwoordcodes geldig.
• WEBSITE_WARMUP_PATH: Een relatief pad op de site dat moet worden gepingd wanneer de site opnieuw wordt opgestart (niet alleen tijdens sitewisselingen). Voorbeeldwaarden zijn /statuscheck of het hoofdpad, / .

Zie Problemen met wisselingen oplossen als u problemen hebt.

Een wisseling bewaken

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

Selecteer op de resourcepagina van uw app in de portal in het linkerdeelvenster Activiteitenlogboek.

Een wisselbewerking wordt in de logboekquery weergegeven als Swap Web App Slots . U kunt deze uitv vouwen en een van de suboperaties of fouten selecteren om de details te bekijken.

Verkeer omgeleid

Standaard worden alle clientaanvragen naar de productie-URL van de app ( http://<app_name>.azurewebsites.net ) doorgeleid naar de productiesleuf. U kunt een deel van het verkeer naar een andere sleuf doorsleufen. Deze functie is handig als u feedback van gebruikers nodig hebt voor een nieuwe update, maar u nog niet klaar bent om deze in productie te brengen.

Productieverkeer automatisch doorseen

Productieverkeer automatisch door te laten gaan:

1. Ga naar de resourcepagina van uw app en selecteer Implementatiesleuven.

2. Geef in de kolom Traffic % van de sleuf die u wilt doorsleufen een percentage (tussen 0 en 100) op dat de totale hoeveelheid verkeer vertegenwoordigt die u wilt routeeren. Selecteer Opslaan.

   

Nadat de instelling is opgeslagen, wordt het opgegeven percentage clients willekeurig gerouteerd naar de niet-productiesleuf.

Nadat een client automatisch wordt doorgeleid naar een specifieke sleuf, wordt deze 'vastgemaakt' aan die sleuf voor de levensduur van die clientsessie. In de clientbrowser kunt u zien aan welke site uw sessie is vastgemaakt door te kijken naar de x-ms-routing-name cookie in uw HTTP-headers. Een aanvraag die wordt doorgeleid naar de staging-sleuf heeft de cookie x-ms-routing-name=staging . Een aanvraag die wordt doorgeleid naar de productiesleuf heeft de cookie x-ms-routing-name=self .

Productieverkeer handmatig doorseen

Naast automatische verkeersroutering kunnen App Service naar een specifieke sleuf routeren. Dit is handig wanneer u wilt dat uw gebruikers zich kunnen in- of uit te kiezen voor uw bèta-app. Als u productieverkeer handmatig wilt doorsuuren, gebruikt u de x-ms-routing-name queryparameter.

Als u wilt dat gebruikers zich bijvoorbeeld kunnen af- en uit-van-uw bèta-app, kunt u deze koppeling 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 productiesleuf aan. Nadat de clientbrowser de koppeling heeft geopend, wordt deze omgeleid naar de productiesleuf. Elke volgende aanvraag heeft de x-ms-routing-name=self cookie die de sessie vastgemaakt aan de productiesleuf.

Als u wilt dat gebruikers zich kunnen opgeven voor uw bèta-app, stelt u dezelfde queryparameter in op de naam van de niet-productiesleuf. Hier volgt een voorbeeld:

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

Nieuwe sleuven krijgen standaard een routeringsregel van 0% , die grijs wordt weergegeven. Wanneer u deze waarde expliciet instelt op (weergegeven in zwarte tekst), hebben uw gebruikers handmatig toegang tot de 0% staging-sleuf met behulp van de x-ms-routing-name queryparameter. Maar ze worden niet automatisch doorgeleid naar de sleuf omdat het routeringspercentage is ingesteld op 0. Dit is een geavanceerd scenario waarin u uw staging-sleuf voor het publiek kunt 'verbergen' terwijl interne teams wijzigingen in de sleuf kunnen testen.

Een sleuf verwijderen

Zoek en selecteer uw app. Selecteer Overzicht van > <slot to delete> > implementatiesleuven. Het app-type wordt weergegeven als App Service (sleuf) om u eraan te herinneren dat u een implementatiesleuf bekijkt. Selecteer Verwijderen op de opdrachtbalk.

Automatiseren met PowerShell

Azure PowerShell is een module die cmdlets biedt voor het beheren van Azure via Windows PowerShell, inclusief ondersteuning voor het beheren van implementatiesleuven in Azure App Service.

Zie Azure PowerShell How to install and configure Microsoft Azure PowerShell voor meer informatie over het installeren en configureren van Azure PowerShell en het authenticeren van Azure PowerShell met uw Azure-Microsoft Azure PowerShell.

Een web-app maken

New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]

Een sleuf maken

New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]

Start een wissel met een preview (wisselen in meerdere fasen) en pas de configuratie van de doelsleuf toe op de bronsleuf

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01

Een wisseling in behandeling annuleren (wisselen met beoordeling) en de configuratie van de bronsleuf herstellen

Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01

Implementatiesites wisselen

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01

Wisselgebeurtenissen in het activiteitenlogboek bewaken

Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor  

Een sleuf verwijderen

Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01

Automatiseren met Resource Manager sjablonen

Azure Resource Manager zijn declaratieve JSON-bestanden die worden gebruikt om de implementatie en configuratie van Azure-resources te automatiseren. Als u sites wilt wisselen met behulp Resource Manager sjablonen, stelt u twee eigenschappen in op de resources Microsoft.Web/sites/slots en Microsoft.Web/sites:

• buildVersion: dit is een tekenreeks-eigenschap die de huidige versie van de app vertegenwoordigt die in de sleuf is geïmplementeerd. Bijvoorbeeld: 'v1', '1.0.0.1' of '2019-09-20T11:53:25.2887393-07:00'.
• targetBuildVersion: dit is een tekenreeks-eigenschap die aangeeft wat buildVersion de sleuf moet hebben. Als de targetBuildVersion niet gelijk is aan de huidige , wordt de wisselbewerking door het vinden van de sleuf met buildVersion de opgegeven buildVersion .

Voorbeeld van Resource Manager sjabloon

Met de Resource Manager wordt de van de buildVersion staging-sleuf bijgewerkt en ingesteld op de targetBuildVersion productiesite. Hiermee worden de twee sleuven gewisseld. In de sjabloon wordt ervan uitgenomen dat u al een web-app hebt gemaakt met een site 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 is idempotent, wat betekent dat deze herhaaldelijk kan worden uitgevoerd en dezelfde status van de sleuven kan produceren. Na de eerste uitvoering komt targetBuildVersion overeen met de huidige , zodat er geen wissel wordt buildVersion geactiveerd.

Automatiseren met de CLI

Zie az webapp deployment slotvoor Azure CLI-opdrachten voor implementatiesleuven.

Problemen met wisselen oplossen

Als er een fout optreedt tijdens het wisselen van een sleuf,wordt deze aangemeld bij D:\home\LogFiles\eventlog.xml. Het wordt ook geregistreerd in het toepassingsspecifieke foutenlogboek.

Hier zijn enkele veelvoorkomende wisselfouten:

• Een HTTP-aanvraag naar de hoofdmap van de toepassing wordt getijde. De wisselbewerking wacht 90 seconden voor elke HTTP-aanvraag en doet maximaal vijf nieuwe keren. Als er een time-out is voor alle nieuwe proberen, 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 Overzicht van lokale cache voor meer informatie.

• Tijdens aangepaste opwarmingworden de HTTP-aanvragen intern gemaakt (zonder de externe URL te gebruiken). Ze kunnen mislukken met bepaalde regels voor het herschrijven van URL's inWeb.config. Regels voor het omleiden van domeinnamen of het afdwingen van HTTPS kunnen bijvoorbeeld voorkomen dat opwarmaanvragen de app-code bereiken. Als u dit probleem wilt oplossen, wijzigt u de regels voor herschrijven 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 aangepaste opwarming kunnen de regels voor het herschrijven van URL's nog steeds HTTP-aanvragen blokkeren. Als u dit probleem wilt oplossen, wijzigt u de regels voor herschrijven door de volgende voorwaarde toe te voegen:

  <conditions>
    <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
    ...
  </conditions>
  

• Nadat de sleuf is gewisseld, kan de app onverwacht opnieuw worden opgestart. Dit komt doordat na een wisseling de configuratie van de hostnaambinding niet meer is gesynchroniseerd, wat op zichzelf geen herstart veroorzaakt. Bepaalde onderliggende opslaggebeurtenissen (zoals failovers van opslagvolumes) kunnen deze discrepanties echter detecteren en alle werkprocessen gedwongen opnieuw opstarten. Als u deze typen opnieuw opstarten wilt minimaliseren, stelt u de WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 app-instelling in op alle sleuven. Deze app-instelling werkt echter niet met Windows WCF-apps (Communication Foundation).

Volgende stappen

Toegang tot niet-productiesleuven blokkeren