Implementatietechnologieën in Azure Functions

Synchronisatie activeren

Wanneer een implementatie een functie of de triggerconfiguratie toevoegt, verwijdert of verandert, moet de Functions-infrastructuur de triggermetadata voor de functie-app bijwerken. Deze synchronisatie vindt automatisch plaats voor veel implementatietechnologieën. In sommige gevallen moet u uw triggers echter handmatig synchroniseren.

U moet triggers altijd handmatig synchroniseren wanneer u deze implementatieopties gebruikt:

• URL van extern pakket
• Lokale Git
• FTPS

U kunt triggers op een van de volgende manieren handmatig synchroniseren:

• Start de functie-app opnieuw op in de Azure-portal. De Functions-host voert een achtergrondtriggersynchronisatie uit nadat de toepassing is gestart.

• Gebruik de az rest opdracht om een HTTP POST-aanvraag te verzenden die de syncfunctiontriggers API aanroept, zoals in dit voorbeeld:

  az rest --method post --url https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>/syncfunctiontriggers?api-version=2016-08-01
  

Houd rekening met de volgende overwegingen voor de bewerking van synchronisatietriggers.

• U moet de functie-app handmatig opnieuw starten wanneer u een bijgewerkte versie van het implementatiepakket implementeert met behulp van dezelfde externe pakket-URL.
• Voor apps die worden uitgevoerd in een Consumption- of Elastic Premium-abonnement, moet u ook triggers handmatig synchroniseren in deze scenario's:
  • Wanneer implementaties een externe pakket-url gebruiken bij een implementatie op basis van een resource manager met behulp van ARM-sjablonen of Bicep- of Terraform-bestanden.
  • Wanneer u het implementatiepakket ter plaatse bijwerkt met behulp van dezelfde externe pakket-URL.
• Wanneer u netwerkbeperkingen toevoegt aan een bestaande functie-app, moet u connectiviteit garanderen met het standaardhostopslagaccount dat is ingesteld in de AzureWebJobsStorage app-instelling. Zie Hoe u een beveiligd opslagaccount gebruikt met Azure Functions voor meer informatie.

Externe build

U kunt Azure Functions vragen om een externe build van uw codeproject uit te voeren tijdens de implementatie. In deze scenario's vraagt u een externe build aan in plaats van lokaal te bouwen:

• U implementeert een app in een op Linux gebaseerde functie-app die u hebt ontwikkeld op een Windows computer. Deze situatie is meestal het geval voor Python app-ontwikkeling. U kunt uiteindelijk onjuiste bibliotheken gebruiken wanneer u het implementatiepakket lokaal bouwt op Windows.
• Uw project heeft afhankelijkheden van een aangepaste pakketindex.
• U wilt de grootte van uw implementatiepakket verkleinen.

Hoe u een externe build aanvraagt, is afhankelijk van of uw app wordt uitgevoerd in Azure op Windows of Linux.

De volgende overwegingen zijn van toepassing bij het gebruik van externe builds tijdens de implementatie:

• Remote builds worden ondersteund voor functie-apps die worden uitgevoerd op Linux in de Consumption plan. De uitrolopties zijn echter beperkt voor deze apps omdat ze geen companion-deployment site hebben.
• Functionele apps die op Linux draaien in een Elastic Premium-abonnement of in een Dedicated (App Service) plan hebben wel een bijbehorende implementatiesite, maar die is beperkt vergeleken met Windows.
• Stel het niet in WEBSITE_RUN_FROM_PACKAGE wanneer je een remote build aanvraagt. Voor Linux Consumption, Elastic Premium en dedicated plan-apps kun je in plaats daarvan remote build inschakelen door gebruik te maken van de deployment-instellingen zoals beschreven in het Linux-tabblad . Het deploymentproces kan de build-output verpakken en de app configureren om vanaf dat pakket te draaien.
• Mogelijk ondervindt u problemen met externe build wanneer uw app is gemaakt voordat de functie beschikbaar werd gesteld (1 augustus 2019). Voor oudere apps maakt u een nieuwe functie-app of voert u az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME> uit om uw functie-app bij te werken. Het kan twee pogingen kosten om deze opdracht te laten slagen.

Externe build

Voor Flex Consumption vraag je een remote build aan door een remote build-parameter door te geven wanneer je met deployment begint. Je configureert remote builds niet met applicatieinstellingen. Voor Core Tools en Visual Studio Code wordt altijd een remote build gevraagd wanneer je een Python-app uitrolt. Zie Implementatie voor meer informatie.

App-inhoudsopslag

Flex Consumption slaat het huidige pakket op in de geconfigureerde deployment storage container. Standaard staat deze container in hetzelfde account als gebruikt door AzureWebJobsStorage, maar je kunt een ander deployment storage-account configureren.

App-inhoudsopslag

Afhankelijk van de implementatietechnologie kan je app-inhoud worden opgeslagen op het app-bestandssysteem, een Azure Files-contentdeling, of op een externe pakket-URL. Bekijk in de volgende sectie waar app-inhoud is opgeslagen voor elke implementatietechnologie.

Beveiligde virtuele netwerken

Wanneer je functie-app privé-endpoints heeft ingeschakeld en de toegang tot het publieke netwerk is uitgeschakeld, is het deployment-endpoint niet publiek bereikbaar. Push-implementatietools, waaronder Core Tools, Visual Studio Code, Azure CLI, GitHub Actions en Azure-pipelines, sturen pakketten naar dit endpoint. De machine, runner of agent die de implementatie uitvoert, moet zowel netwerkconnectiviteit als DNS-resolutie hebben voor het private deployment-endpoint.

Je kunt deze connectiviteit op de volgende manieren bieden:

• Voor Azure-pipelines gebruik je een zelf-hostende agent op een verbonden netwerk, of configureer je een beheerde DevOps-agentgroep met netwerkconfiguratie.
• Voor GitHub Actions gebruik je een zelf-gehoste runner op een verbonden netwerk of configureer je een door GitHub gehoste runner met Azure privénetwerk.
• Verbind je ontwikkelmachine met een point-to-site VPN, site-to-site VPN of ExpressRoute.

De implementatieresource kan zich in hetzelfde virtuele netwerk bevinden of in een netwerk dat routerings- en DNS-connectiviteit heeft met het privé-eindpunt, zoals een gekoppeld virtueel netwerk.

Resource Manager-gebaseerde pakketimplementaties pushen het pakket niet van de initierende client naar het deployment-endpoint. In plaats daarvan haalt de implementatieservice het pakket op via de URL die in de implementatieresource is opgegeven. De pakket-URL en de deployment-opslag moeten toegankelijk zijn voor de deploymentservice. Voor Flex Consumption, zie Deploy met Bicep of een Azure Resource Manager-sjabloon.

Zie Het configureren van Azure Functions met een virtueel netwerk voor meer informatie over het configureren van uw functie-app in een virtueel netwerk.

App-inhoudopslag en netwerken

Azure Functions on Azure Container Apps deployt je app als een containerimage. De image wordt opgeslagen in een containerregister en het netwerkbeheer wordt beheerd door de Container Apps-omgeving. Voor meer informatie, zie Azure Functions op Azure Container Apps overzicht en Netwerken in Azure Container Apps.

Implementatie van het Flex Consumption-pakket

Pakketimplementatie is de enige code-implementatietechnologie die wordt ondersteund voor apps op een Flex Consumption-plan. Het implementatieproces slaat een kant-en-klaar .zip-pakket op in de deployment container van de app, en de functionele app draait direct vanaf dat pakket.

Hoe u deze kunt gebruiken: Implementeren met behulp van de functie Visual Studio Code publiceren of vanaf de opdrachtregel met behulp van Azure Functions Core Tools of de Azure CLI. De Azure DevOps-taak en GitHub-actie selecteren op vergelijkbare wijze het juiste pakketimplementatiegedrag wanneer ze een Flex Consumption-app detecteren.

Wanneer u een Flex Consumption-app maakt, moet u een implementatieopslagcontainer (blob) en een verificatiemethode opgeven. Standaard wordt hetzelfde opslagaccount als de AzureWebJobsStorage-verbinding gebruikt, met een verbindingsreeks als verificatiemethode. Uw implementatie-instellingen worden dus geconfigureerd tijdens het maken van apps zonder dat er toepassingsinstellingen nodig zijn.

Wanneer te gebruiken: Gebruik pakketimplementatie voor alle Flex Consumption-code-implementaties. Er wordt geen andere code-implementatietechnologie ondersteund.

Waar app-inhoud wordt opgeslagen: Wanneer u een Flex Consumption functie-app aanmaakt, geeft u een opslagcontainer voor de implementatie op. De deploymentservice slaat het verwerkte, kant-en-klare pakket op in deze container. Push-implementatietools sturen eerst het bronpakket naar het deployment-endpoint van de app; ze uploaden niet direct naar de deploymentcontainer. Om de opslaglocatie te wijzigen, open je de pagina Implementatie-instellingen in het Azure-portaal of gebruik je de Azure CLI.

De onderliggende platform-API wordt soms aangeduid als OneDeploy. Infrastructure-as-code definities maken deze implementatie beschikbaar via de letterlijke /onedeploy resourcenaam. Je hoeft deze API niet te selecteren of te configureren wanneer je deployt met behulp van ondersteunde ontwikkeltools of CI/CD-providers.

ZIP-implementatie

ZIP-implementatie is de standaard en aanbevolen implementatietechnologie voor functionele apps op de Consumption-, Elastic Premium- en Dedicated (App Service)-plannen. Het eindresultaat is een kant-en-klaar .zip pakket waarop uw functie-app wordt uitgevoerd. Het verschilt van de URL van het externe pakket omdat het platform verantwoordelijk is voor het extern bouwen en opslaan van uw app-inhoud.

Hoe gebruik je het: Deploy via je favoriete clienttool: Visual Studio Code, Visual Studio, of via de opdrachtregel met Azure Functions Core Tools of de Azure CLI. De Azure DevOps-taak en GitHub Action gebruiken op vergelijkbare wijze ZIP-deployment.

Wanneer je ZIP-implementatie gebruikt, kun je je app zo instellen dat deze vanuit het pakket draait. Als u wilt uitvoeren vanuit het pakket, stelt u de waarde van de WEBSITE_RUN_FROM_PACKAGE toepassingsinstelling in op 1. Wij raden ZIP-implementatie aan. Het zorgt voor snellere laadtijden voor je applicaties en is de standaard voor Visual Studio Code, Visual Studio en de Azure CLI.

Wanneer te gebruiken: ZIP-implementatie is de standaard en aanbevolen implementatietechnologie voor functionele apps op de Windows Consumption-, Windows- en Linux Elastic Premium-, en Windows- en Linux App Service (Dedicated)-plannen.

Waar app-inhoud wordt opgeslagen: App-inhoud uit een ZIP-implementatie wordt standaard opgeslagen in het bestandssysteem, wat Azure mogelijk ondersteunt met Azure Files vanaf het opslagaccount dat je opgeeft bij het maken van de functie-app. In Linux-verbruik wordt de app-inhoud in plaats daarvan opgeslagen op een blob in het opslagaccount dat is opgegeven door de AzureWebJobsStorage app-instelling. De app-instelling WEBSITE_RUN_FROM_PACKAGE neemt de waarde van de blob-URL in beslag.

URL van extern pakket

Gebruik een externe pakket-URL wanneer je handmatig wilt bepalen hoe de implementaties plaatsvinden. Je bent verantwoordelijk voor het uploaden van een kant-en-klaar .zip-pakket dat de inhoud van je gebouwde app bevat naar blob storage en het refereren naar deze externe URL als applicatie-instelling in je functionele app. Telkens wanneer je app opnieuw opstart, haalt hij het pakket op, mountt het en draait vanaf het pakket.

Hoe u dit kunt gebruiken: Toevoegen WEBSITE_RUN_FROM_PACKAGE aan uw toepassingsinstellingen. De waarde van deze instelling moet een blob-URL zijn die verwijst naar de locatie van het specifieke pakket dat uw app moet uitvoeren. U kunt instellingen toevoegen in de portal of by met behulp van de Azure CLI.

Als je Azure Blob Storage gebruikt, kan je functie-app toegang krijgen tot de container via een beheerde identiteitsgebaseerde verbinding of met een shared access signature (SAS). De optie die u kiest, is van invloed op het type URL dat u als waarde gebruikt WEBSITE_RUN_FROM_PACKAGE. Beheerde identiteit wordt aanbevolen voor algemene beveiliging en omdat SAS-tokens verlopen en handmatig moeten worden onderhouden.

Wanneer u het pakketbestand implementeert waarnaar een functie-app verwijst, moet u triggers handmatig synchroniseren, inclusief de eerste implementatie. Wanneer u de inhoud van het pakketbestand en niet de URL zelf wijzigt, moet u de functie-app ook opnieuw starten om triggers te synchroniseren. Zie voor configuratiestappen Uitvoeren vanaf een URL van een extern pakket.

Wanneer u deze wilt gebruiken: externe pakket-URL is de enige ondersteunde implementatiemethode voor apps die worden uitgevoerd in het Linux-verbruiksabonnement wanneer u niet wilt dat een externe build wordt uitgevoerd. Deze methode is ook de aanbevolen implementatietechnologie wanneer u uw app maakt zonder Azure Files. Voor schaalbare apps die worden uitgevoerd in Linux, moet u in plaats daarvan overwegen om Flex Consumption-abonnement te hosten.

Waar app-inhoud wordt opgeslagen: u bent verantwoordelijk voor het uploaden van uw app-inhoud naar blobopslag. Je kunt elk blob storage-account gebruiken, hoewel Azure Blob Storage wordt aanbevolen.

Docker-container

U kunt een functie-app implementeren die wordt uitgevoerd in een Linux-container.

Hoe u deze kunt gebruiken: Maak uw functies in een Linux-container implementeer vervolgens de container in een Premium- of Dedicated-abonnement in Azure Functions of een andere containerhost. Gebruik de Azure Functions Core Tools om een aangepast Dockerfile te maken voor uw project dat u gebruikt om een containerfunctie-app te maken. U kunt de container in de volgende implementaties gebruiken:

• Implementeer naar Azure Functions-resources die u maakt in de Azure-portal. Zie Azure portal maken met behulp van containers voor meer informatie.
• Implementeer naar Azure Functions-resources die u via de opdrachtregel maakt. Hiervoor is een Premium- of Dedicated-abonnement (App Service) vereist. Zie Maak uw eerste containerized Azure Functions voor meer informatie.
• Implementeren in een Kubernetes-cluster. U kunt implementeren in een cluster met behulp van Azure Functions Core Tools. Gebruik de opdracht func kubernetes deploy.

Wanneer u deze wilt gebruiken: gebruik de Docker-containeroptie wanneer u meer controle nodig hebt over de Linux-omgeving waar uw functie-app wordt uitgevoerd en waar de container wordt gehost. Dit implementatiemechanisme is alleen beschikbaar voor functies die worden uitgevoerd in Linux.

Waar app-inhoud wordt opgeslagen: U slaat app-inhoud op in het opgegeven containerregister als onderdeel van de installatiekopieën.

Bronbeheer

U kunt continue integratie tussen uw functie-app en een opslagplaats voor broncode inschakelen. Wanneer u broncodebeheer inschakelt, activeert een update van code in de verbonden bronopslagplaats de implementatie van de meest recente code uit de opslagplaats. Zie de Continuous-implementatie voor Azure Functions voor meer informatie.

Hoe u dit kunt gebruiken: de eenvoudigste manier om publiceren vanuit broncodebeheer in te stellen, is vanuit het Implementatiecentrum in het gebied Functions van de portal. Zie Continuous-implementatie voor Azure Functions voor meer informatie.

Wanneer u dit gebruikt: het gebruik van broncodebeheer is de aanbevolen procedure voor teams die samenwerken aan hun functie-apps. Broncodebeheer is een goede implementatieoptie die geavanceerdere implementatiepijplijnen mogelijk maakt. Meestal schakelt u versiebeheer in op een staging-slot, dat u na validatie van updates uit de repository kunt verplaatsen naar productie. Zie Azure Functions implementatiesleuven voor meer informatie.

Waar app-inhoud wordt opgeslagen: Het broncodebeheersysteem slaat de app-inhoud op. In het app-bestandssysteem wordt een lokaal gekloonde en gebouwde vorm van app-inhoud bewaard, wat mogelijk wordt ondersteund door Azure-bestanden vanuit de opslagaccount die werd opgegeven bij de aanmaak van de functie-app.

Lokale Git

Gebruik lokale Git om code van uw lokale computer te pushen naar Azure Functions met behulp van Git.

Demplementatie: Volg de instructies in Local Git-implementatie voor Azure App Service.

Wanneer moet u deze gebruiken: Als u de kans op fouten wilt verminderen, vermijdt u het gebruik van implementatiemethoden waarvoor de extra stap van het handmatig synchroniseren van triggers is vereist. Gebruik waar mogelijk zip-implementatie .

Waar app-inhoud wordt opgeslagen: Het bestandssysteem slaat app-inhoud op. Het bestandssysteem kan worden ondersteund door Azure Files vanuit het opslagaccount dat je opgeeft bij het maken van de functie-app.

FTPS

Je kunt FTPS gebruiken om bestanden direct naar Azure Functions over te zetten, maar gebruik deze deploymentmethode niet. Als je niet van plan bent FTPS te gebruiken, schakel het dan uit. Zie Enforce FTPS voor meer informatie in de Azure-portal.

Hoe u deze kunt gebruiken: Volg de instructies in de FTPS-implementatie-instellingen om de URL en referenties op te halen die u kunt gebruiken om te implementeren in uw functie-app met behulp van FTPS.

Wanneer moet u deze gebruiken: Als u de kans op fouten wilt verminderen, vermijdt u het gebruik van implementatiemethoden waarvoor de extra stap van het handmatig synchroniseren van triggers is vereist. Gebruik waar mogelijk zip-implementatie .

Waar app-inhoud wordt opgeslagen: App-inhoud wordt opgeslagen in het bestandssysteem. FTP-/FTPS-implementaties mislukken wanneer het bestandssysteem van uw app wordt ondersteund door Azure Files in het standaardhostopslagaccount. FTP/FTPS mislukt met Azure Files als gekoppelde opslag vanwege FTP-beperkingen.

Bewerken in het portaal

In de portalgebaseerde editor kunt u de bestanden in uw functionele app direct bewerken, waarbij elke wijziging wordt geïmplementeerd zodra u opslaat.

Hoe u deze kunt gebruiken: Als u uw functies wilt bewerken in de portal Azure, moet u uw functies maken in de portal. Als u één bron van waarheid wilt behouden, maakt het gebruik van een andere implementatiemethode uw functie alleen-lezen en verhindert het verdere bewerkingen in de portal. Als u wilt terugkeren naar een status waarin u uw bestanden in de Azure-portal kunt bewerken, kunt u de bewerkingsmodus handmatig terugzetten naar Read/Write en eventuele toepassingsinstellingen voor implementaties verwijderen (zoals WEBSITE_RUN_FROM_PACKAGE).

Wanneer u deze wilt gebruiken: De portal is een goede manier om aan de slag te gaan met Azure Functions. Vanwege ontwikkelingsbeperkingen in de Azure portal moet u een van de volgende clienthulpprogramma's gebruiken voor geavanceerdere ontwikkelwerkzaamheden:

• Visual Studio Code
• Azure Functions Core Tools (opdrachtregelinterface)
• Visual Studio

Waar de app-inhoud wordt opgeslagen: App-inhoud wordt opgeslagen in het bestandssysteem, dat kan worden geback-upt door Azure Files van het opslagaccount dat u opgeeft bij het maken van de Function App.

Implementatie van containerimage

Azure Functions op Azure Container Apps deployt je code als een containerimage. Je kunt vanuit een codeproject deployen via de beheerde Container Apps experience, of een aangepaste image deployen wanneer je controle over de inhoud van de image nodig hebt. Raadpleeg voor meer informatie Een functie-app maken in Azure Container Apps met code en Overzicht van Azure Functions in Azure Container Apps.

Momenteel stoppen uitvoerende functies wanneer je nieuwe code uitrolt. Na de deployment laadt de nieuwe code en begint met het verwerken van verzoeken. Dit gewelddadige beëindigingsgedrag staat bekend als een hercreatiestrategie. Voor implementaties met bijna geen downtime, gebruik deploymentslots.

Bekijk Verdeel de prestaties en betrouwbaarheid van Azure Functions voor meer informatie over het schrijven van staatloze en defensieve functies.

Het standaardgedrag gebruikt de recreate-strategie, die het uitvoeren van functies tijdens de implementatie stopt. Flex Consumption ondersteunt twee site-updatestrategieën. U kunt rolling updates configureren voor implementaties zonder downtime.

Azure Container Apps beheert applicatie-updates door gebruik te maken van revisies. Raadpleeg Wijzigingen bijwerken en implementeren in Azure Container Apps voor meer informatie over het beheren van hoe verkeer naar nieuwe revisies wordt geleid.

Implementatiesites

Flex Consumption ondersteunt geen deployment-slots. Voor implementaties zonder downtime, configureer rolling updates.

Implementatiesites

Wanneer u uw functie-app implementeert in Azure, kunt u implementeren in een afzonderlijke implementatiesite in plaats van rechtstreeks naar productie. Implementeren in een implementatieslot en vervolgens omzetten naar productie na verificatie is de aanbevolen manier om continue implementatie in te stellen.

De manier waarop u naar een slot implementeert, is afhankelijk van de specifieke deploytool die u gebruikt. Als je bijvoorbeeld Azure Functions Core Tools gebruikt, voeg dan de --slot optie toe om de naam van een specifieke slot voor het func azure functionapp publish commando aan te geven.

Zie de documentatie Azure Functions Deployment Slots voor meer informatie over implementatieslots.