Azure Functions-implementatiesites

  • Artikel

Met Azure Functions-implementatiesites kan uw functie-app verschillende exemplaren met de naam slots uitvoeren. Sites zijn verschillende omgevingen die beschikbaar zijn via een openbaar beschikbaar eindpunt. Eén app-exemplaar wordt altijd toegewezen aan de productiesite en u kunt exemplaren die zijn toegewezen aan een site op aanvraag wisselen. Functie-apps die in een Verbruiksabonnement worden uitgevoerd, hebben één extra site voor fasering. U kunt meer faseringssites verkrijgen door uw app uit te voeren in een Premium-abonnement of Een Toegewezen (App Service)-abonnement. Zie Servicelimieten voor meer informatie.

Hieronder ziet u hoe functies worden beïnvloed door sites te wisselen:

  • Verkeersomleiding is naadloos; er worden geen aanvragen verwijderd vanwege een swap. Dit naadloze gedrag treedt op omdat de volgende functietrigger wordt gerouteerd naar de gewisselde site.
  • De functie die momenteel wordt uitgevoerd, wordt beëindigd tijdens het wisselen. Zie De prestaties en betrouwbaarheid van Azure Functions verbeteren voor meer informatie over het schrijven van staatloze en defensieve functies.

Waarom slots gebruiken?

Er zijn veel voordelen bij het gebruik van implementatiesites, waaronder:

  • Verschillende omgevingen voor verschillende doeleinden: als u verschillende sites gebruikt, hebt u de mogelijkheid om app-exemplaren te onderscheiden voordat u overgaat naar productie of een staging-site.
  • Voorbereiding: Door in een site te implementeren in plaats van rechtstreeks naar productie te gaan, kan de app worden opgewarmd voordat de app live gaat. Daarnaast vermindert het gebruik van sleuven de latentie voor door HTTP geactiveerde workloads. Exemplaren worden opgewarmd vóór de implementatie, waardoor de koude start voor nieuw geïmplementeerde functies wordt verminderd.
  • Eenvoudige terugval: Na een wisseling met productie heeft de site met een eerder gefaseerde app nu de vorige productie-app. Als de wijzigingen die zijn gewisseld in de productiesite niet zoals verwacht, kunt u de wissel direct omkeren om uw 'laatst bekende goede exemplaar' terug te krijgen.
  • Het aantal herstarts minimaliseren: voor het wijzigen van app-instellingen in een productiesite moet de actieve app opnieuw worden opgestart. U kunt in plaats daarvan instellingen in een staging-site wijzigen en de instellingen wisselen in productie met een voorafwarmd exemplaar. Sites zijn de aanbevolen manier om te migreren tussen runtimeversies van Functions, met behoud van de hoogste beschikbaarheid. Zie Minimale downtime-update voor meer informatie.

Wisselbewerkingen

Tijdens een wisseling wordt één site beschouwd als de bron en de andere is het doel. De bronsite heeft het exemplaar van de toepassing die wordt toegepast op de doelsite. De volgende stappen zorgen ervoor dat de doelsite geen downtime ondervindt tijdens een wissel:

  1. Instellingen toepassen: Instellingen van de doelsite worden toegepast op alle exemplaren van de bronsite. De productie-instellingen worden bijvoorbeeld toegepast op het faseringsexemplaren. De toegepaste instellingen omvatten de volgende categorieën:

  2. Wacht op opnieuw opstarten en beschikbaarheid: de wissel wacht tot elk exemplaar in de bronsite de herstart heeft voltooid en beschikbaar is voor aanvragen. Als een exemplaar niet opnieuw kan worden opgestart, worden alle wijzigingen in de bronsite hersteld en wordt de bewerking gestopt.

  3. Updateroutering: Als alle exemplaren op de bronsite met succes worden opgewarmd, worden de twee sites omgewisseld door om te schakelen tussen routeringsregels. Na deze stap heeft de doelsite (bijvoorbeeld de productiesite) de app die eerder is opgewarmd in de bronsite.

  4. Herhalingsbewerking: Nu de bronsite de preswap-app eerder in de doelsite heeft, voltooit u dezelfde bewerking door alle instellingen toe te passen en de exemplaren voor de bronsite opnieuw op te starten.

Houd rekening met de volgende belangrijke punten:

  • Op elk moment van de wisselbewerking vindt initialisatie van de gewisselde apps plaats op de bronsite. De doelsite blijft online terwijl de bronsite wordt voorbereid, 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.

  • Instellingen gerelateerd aan gebeurtenisbronnen en bindingen moet worden geconfigureerd als instellingen voor de implementatiesitevoordat u een wissel start. Als u ze vooraf als 'plakkerig' markeert, worden gebeurtenissen en uitvoer doorgestuurd naar het juiste exemplaar.

Instellingen beheren

Sommige configuratie-instellingen zijn sitespecifiek. In de volgende lijst vindt u details over welke instellingen worden gewijzigd wanneer u sites verwisselt en die hetzelfde blijven.

Sitespecifieke instellingen:

  • Eindpunten publiceren
  • Aangepaste domeinnamen
  • Niet-openbare certificaten en TLS/SSL-instellingen
  • Schaalinstellingen
  • IP-beperkingen
  • Altijd ingeschakeld
  • Diagnostische instellingen
  • CORS (Cross-Origin Resource Sharing, cross-origin-resource delen)
  • Privé-eindpunten

Niet-sitespecifieke instellingen:

  • 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
  • Hybride verbindingen *
  • Integratie van virtueel netwerk *
  • Service-eindpunten *
  • Azure Content Delivery Network *

Functies die zijn gemarkeerd met een sterretje (*) worden standaard niet gewisseld.

Notitie

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.

Een implementatie-instelling maken

U kunt instellingen markeren als een implementatie-instelling, waardoor deze plakkerig wordt. Een plakinstelling wordt niet gewisseld met het app-exemplaar.

Als u een implementatie-instelling in één site maakt, moet u dezelfde instelling maken met een unieke waarde in een andere site die betrokken is bij een wisseling. Op deze manier blijven de instellingsnamen consistent tussen sites, terwijl de waarde van een instelling niet verandert. Deze naamconsistentie zorgt ervoor dat uw code geen toegang probeert te krijgen tot een instelling die in de ene site is gedefinieerd, maar niet tot een andere.

Gebruik de volgende stappen om een implementatie-instelling te maken:

  1. Navigeer naar Implementatiesites in de functie-app en selecteer vervolgens de naam van de site.

    Find slots in the Azure portal.

  2. Selecteer Configuratie en selecteer vervolgens de naam van de instelling die u aan de huidige site wilt houden.

    Configure the application setting for a slot in the Azure portal.

  3. Selecteer de instelling implementatiesite en selecteer vervolgens OK.

    Configure the deployment slot setting.

  4. Zodra de instellingssectie verdwijnt, selecteert u Opslaan om de wijzigingen te behouden

    Save the deployment slot setting.

Implementatie

Sites zijn leeg wanneer u een site maakt. U kunt een van de ondersteunde implementatietechnologieën gebruiken om uw toepassing te implementeren in een site.

Schalen

Alle sites worden geschaald naar hetzelfde aantal werkrollen als de productiesite.

  • Voor verbruiksabonnementen wordt de site geschaald naarmate de functie-app wordt geschaald.
  • Voor App Service-abonnementen wordt de app geschaald naar een vast aantal werkrollen. Sites worden uitgevoerd op hetzelfde aantal werkrollen als het app-plan.

Sites weergeven

U kunt informatie over bestaande sites weergeven met behulp van de Azure CLI of via Azure Portal.

Gebruik deze stappen om een nieuwe site te maken in de portal:

  1. Navigeer naar uw functie-app.

  2. Selecteer Implementatiesites en de bestaande sites worden weergegeven.

Een sleuf toevoegen

U kunt een site toevoegen met behulp van de Azure CLI of via Azure Portal.

Gebruik deze stappen om een site te maken in de portal:

  1. Navigeer naar uw functie-app.

  2. Selecteer Implementatiesites en selecteer vervolgens + Site toevoegen.

    Add Azure Functions deployment slot.

  3. Typ de naam van de site en selecteer Toevoegen.

    Name the Azure Functions deployment slot.

Toegang tot sitebronnen

U opent resources (HTTP-triggers en beheerderseindpunten) in een staging-site op dezelfde manier als de productiesite. In plaats van de hostnaam van de functie-app gebruikt u echter de sitespecifieke hostnaam in de aanvraag-URL, samen met eventuele sitespecifieke sleutels. Omdat staging-sites live-apps zijn, moet u uw functies in een staging-site beveiligen zoals u dat zou doen in de productiesite.

Sites wisselen

U kunt sites in een out-of-productieomgeving wisselen met behulp van de Azure CLI of via Azure Portal.

Gebruik deze stappen om een staging-site in productie te wisselen:

  1. Navigeer naar de functie-app.

  2. Selecteer Implementatiesites en selecteer Vervolgens Wisselen.

    Screenshot that shows the 'Deployment slot' page with the 'Add Slot' action selected.

  3. Controleer de configuratie-instellingen voor uw wissel en selecteer Wisselen

    Swap the deployment slot.

De wisselbewerking kan enkele seconden duren.

Een wissel terugdraaien

Als een wissel resulteert in een fout of als u gewoon een wissel ongedaan wilt maken, kunt u terugdraaien naar de oorspronkelijke status. Als u wilt terugkeren naar de vooraf gemaakte status, voert u een andere wisseling uit om de wissel om te draaien.

Een site verwijderen

U kunt een site verwijderen met behulp van de Azure CLI of via Azure Portal.

Gebruik deze stappen om een site uit uw app in de portal te verwijderen:

  1. Navigeer naar Implementatiesites in de functie-app en selecteer vervolgens de naam van de site.

    Find slots in the Azure portal.

  2. Selecteer Verwijderen.

    Screenshot that shows the 'Overview' page with the 'Delete' action selected.

  3. Typ de naam van de implementatiesite die u wilt verwijderen en selecteer Vervolgens Verwijderen.

    Delete the deployment slot in the Azure portal.

  4. Sluit het bevestigingsvenster.

    Deployment slot delete confirmation.

App Service-plan wijzigen

Met een functie-app die wordt uitgevoerd onder een App Service-plan, kunt u het onderliggende App Service-plan voor een site wijzigen.

Notitie

U kunt het App Service-abonnement van een site niet wijzigen onder het verbruiksabonnement.

Gebruik de volgende stappen om het App Service-plan van een site te wijzigen:

  1. Navigeer naar Implementatiesites in de functie-app en selecteer vervolgens de naam van de site.

    Find slots in the Azure portal.

  2. Selecteer Onder App Service-plan de optie App Service-plan wijzigen.

  3. Selecteer het abonnement waarnaar u een upgrade wilt uitvoeren of maak een nieuw plan.

    Change the App Service plan in the Azure portal.

  4. Selecteer OK.

Overwegingen

Azure Functions-implementatiesites hebben de volgende overwegingen:

  • Het aantal sites dat beschikbaar is voor een app, is afhankelijk van het abonnement. Het verbruiksabonnement is slechts één implementatiesite toegestaan. Er zijn meer sites beschikbaar voor apps die worden uitgevoerd onder andere abonnementen. Zie Servicelimieten voor meer informatie.
  • Als u een site verwisselt, worden sleutels opnieuw ingesteld voor apps met een AzureWebJobsSecretStorageType app-instelling die gelijk is aan files.
  • Wanneer sites zijn ingeschakeld, wordt uw functie-app ingesteld op de modus Alleen-lezen in de portal.
  • Sitewisselingen kunnen mislukken wanneer uw functie-app een beveiligd opslagaccount gebruikt als het standaardopslagaccount (ingesteld in AzureWebJobsStorage). Raadpleeg de referentie WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS voor meer informatie.
  • Gebruik namen van functie-apps die korter zijn dan 32 tekens. Namen die langer zijn dan 32 tekens, lopen het risico dat er host-id-conflicten ontstaan.

Volgende stappen