Delen via

Implementatietechnologieën in Azure Functions

U kunt verschillende technologieën gebruiken om uw Azure Functions-projectcode te implementeren in Azure. Dit artikel bevat een overzicht van de implementatiemethoden die voor u beschikbaar zijn en aanbevelingen voor de beste methode die u in verschillende scenario's kunt gebruiken. Het biedt ook een uitgebreide lijst met en belangrijke details over de onderliggende implementatietechnologieën.

Implementatiemethoden

De implementatietechnologie die u gebruikt om code te publiceren naar uw functie-app in Azure, is afhankelijk van uw specifieke behoeften en het punt in de ontwikkelingscyclus. Tijdens het ontwikkelen en testen kunt u bijvoorbeeld rechtstreeks vanuit uw ontwikkelprogramma, zoals Visual Studio Code, implementeren. Wanneer uw app in productie is, is het waarschijnlijker dat u continu publiceert vanuit broncodebeheer of met behulp van een geautomatiseerde publicatiepijplijn, waaronder validatie en testen.

In de volgende tabel worden de beschikbare implementatiemethoden voor uw codeproject beschreven.

Implementatietype Methoden Geschikt voor...
Op basis van hulpprogramma's • Azure CLI
• Visual Studio Code publiceren
• Visual Studio publiceren
• Core Tools publiceren		 Implementaties tijdens ontwikkeling en andere geïmproviseerde implementaties. Implementeer uw code op aanvraag met behulp van lokale ontwikkelhulpprogramma's.
App Service beheerd • Implementatiecentrum (CI/CD)
• Containerimplementaties		 Continue implementatie (CI/CD) vanuit broncodebeheer of vanuit een containerregister. Het App Service-platform (Kudu) beheert implementaties.
Externe pijplijnen • Azure Pipelines
• GitHub Actions		 Productiepijplijnen met validatie, testen en andere acties die moeten worden uitgevoerd als onderdeel van een geautomatiseerde implementatie. De pijplijn beheert implementaties.

Gebruik de beste technologie voor uw specifieke scenario. Veel van de implementatiemethoden zijn gebaseerd op zip-implementatie, die wordt aanbevolen voor implementatie.

Beschikbaarheid van implementatietechnologie

De implementatiemethode is ook afhankelijk van het hostingplan en het besturingssysteem waarop u uw functie-app uitvoert.

Op dit moment biedt Functions vijf opties voor het hosten van uw functie-apps:

Elk plan heeft verschillende gedragingen. Niet alle implementatietechnologieën zijn beschikbaar voor elk hostingabonnement en besturingssysteem. Deze grafiek bevat informatie over de ondersteunde implementatietechnologieën:

Implementatietechnologie Flexverbruik Verbruik Elastic Premium Toegewezen Container-toepassingen
Eén implementatie ✔
Zip-implementatie ✔ ✔ ✔
URLvan extern pakket 1 ✔ ✔ ✔
Docker-container Alleen Linux Alleen Linux Alleen Linux ✔
Broncodebeheer Alleen Windows ✔ ✔
Lokale Git1 Alleen Windows ✔ ✔
FTPS1 Alleen Windows ✔ ✔
In portal bewerken2 ✔ ✔ ✔

1 Implementatietechnologieën waarvoor u handmatig triggers moet synchroniseren, worden niet aanbevolen.
2 Bewerking in de portal is uitgeschakeld wanneer code wordt geïmplementeerd in uw functie-app van buiten de portal. Zie Taalondersteuningsdetails voor meer informatie, waaronder taalondersteuningsdetails voor bewerking in de portal.

Belangrijke concepten

Enkele belangrijke concepten zijn essentieel om inzicht te krijgen in de werking van implementaties in Azure Functions.

Synchronisatie activeren

Wanneer u een van uw triggers wijzigt, moet de Infrastructuur van Functions op de hoogte zijn van de wijzigingen. 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:

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

  • Start uw functie-app opnieuw op in 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 gebruikmaken van een externe pakket-URL met een deployment op basis van Resource Manager, waarbij ARM-sjablonen of Bicep- of Terraform-bestanden worden gebruikt.
    • 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 Een beveiligd opslagaccount gebruiken met Azure Functions voor meer informatie.

Externe build

U kunt Azure Functions aanvragen 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 op een Windows-computer hebt ontwikkeld. Deze situatie is meestal het geval bij het ontwikkelen van Python-apps. U kunt uiteindelijk onjuiste bibliotheken gebruiken wanneer u het implementatiepakket lokaal in Windows bouwt.
  • 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 in Windows of Linux.

Alle functie-apps die in Windows worden uitgevoerd, hebben een kleine beheer-app, de scm site van Kudu. Deze site verwerkt veel van de implementatie- en buildlogica voor Azure Functions.

Wanneer u een app implementeert in Windows, voert het implementatieproces taalspecifieke opdrachten uit, zoals dotnet restore (C#) of npm install (JavaScript).

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

  • Externe builds worden ondersteund voor functie-apps die worden uitgevoerd op Linux in het verbruiksabonnement. Implementatieopties zijn echter beperkt voor deze apps omdat ze geen (Kudu)-site hebben scm .
  • Functie-apps die worden uitgevoerd op Linux in een Premium-abonnement of in een Dedicated (App Service)-abonnement hebben wel een scm (Kudu)-site, maar deze is beperkt in vergelijking met Windows.
  • Externe builds vinden niet plaats wanneer een app run-from-package gebruikt. Zie Zip deploy voor meer informatie over het gebruik van externe build in deze gevallen.
  • 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 deze uit az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME> om uw functie-app bij te werken. Met deze opdracht kunnen twee pogingen worden uitgevoerd.

App-inhoudsopslag

Met op pakketten gebaseerde implementatiemethoden wordt het pakket opgeslagen in het opslagaccount dat is gekoppeld aan de functie-app, die door de instelling AzureWebJobsStorage wordt gedefinieerd. Wanneer deze beschikbaar zijn, proberen verbruiks- en Elastic Premium-abonnements-apps de Azure Files-inhoudsshare van dit account te gebruiken, maar u kunt het pakket ook op een andere locatie onderhouden. Flex Consumption-abonnementsapps maken gebruik van een opslagcontainer in een standaardopslagaccount, tenzij u een ander opslagaccount configureert voor implementatie. Raadpleeg de details in Waar app-inhoud wordt opgeslagen in elke implementatietechnologie die in de volgende sectie wordt behandeld voor meer informatie.

Belangrijk

Het opslagaccount wordt gebruikt voor het opslaan van belangrijke app-gegevens, soms inclusief de toepassingscode zelf. U moet de toegang van andere apps en gebruikers tot het opslagaccount beperken.

Details van implementatietechnologie

De volgende implementatiemethoden zijn beschikbaar in Azure Functions. Raadpleeg de beschikbaarheidstabel voor implementatietechnologie om te bepalen welke technologieën elk hostingabonnement ondersteunt.

Eén implementatie

Eén implementatie is de enige implementatietechnologie die wordt ondersteund voor apps in een Flex Consumption-abonnement. Het eindresultaat is een kant-en-klaar .zip pakket waarop uw functie-app wordt uitgevoerd.

Hoe u deze kunt gebruiken: Implementeer met behulp van de Visual Studio Code-publicatiefunctie of vanaf de opdrachtregel met behulp van Azure Functions Core Tools of de Azure CLI. Onze Azure Dev Ops Task en GitHub Action maken op dezelfde manier gebruik van één implementatie wanneer ze detecteren dat een Flex Consumption-app wordt geïmplementeerd.

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 de verificatiemethode. Uw implementatie-instellingen worden dus geconfigureerd tijdens het maken van apps zonder dat er toepassingsinstellingen nodig zijn.

Wanneer moet u deze gebruiken: Eén implementatie is de enige implementatietechnologie die beschikbaar is voor functie-apps die worden uitgevoerd in een Flex Consumption-abonnement.

Waar app-inhoud wordt opgeslagen: wanneer u een functie-app flexverbruik maakt, geeft u een opslagcontainer voor de implementatie op. In deze blobcontainer uploaden uw hulpprogramma's de app-inhoud die u hebt geïmplementeerd. Als u de locatie wilt wijzigen, gaat u naar de blade Implementatie-instellingen in Azure Portal of gebruikt u de Azure CLI.

Aanbeveling

Er is een diagnostisch hulpprogramma voor de implementatie van een Flex Function-app beschikbaar in Azure Portal. Open uw Flex Consumption-app, selecteer Problemen vaststellen en oplossen en zoek naar Flex Function App deployment details. Dit hulpprogramma bevat gedetailleerde informatie over uw implementaties, waaronder de implementatiegeschiedenis, pakketstatus en aanbevelingen voor probleemoplossing.

Zip-implementatie

Zip-implementatie is de standaard- en aanbevolen implementatietechnologie voor functie-apps in de abonnementen Consumption, Elastic Premium en App Service (Dedicated). 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 u dit kunt gebruiken: Implementeren met behulp van uw favoriete clienthulpprogramma: Visual Studio Code, Visual Studio of vanaf de opdrachtregel met behulp van Azure Functions Core Tools of de Azure CLI. Onze Azure Dev Ops Task en GitHub Action maken op dezelfde manier gebruik van zip deploy.

Wanneer u implementeert met behulp van zip deploy, kunt u instellen dat uw app wordt uitgevoerd vanuit het pakket. Als u wilt uitvoeren vanuit het pakket, stelt u de waarde van de WEBSITE_RUN_FROM_PACKAGE toepassingsinstelling in op 1. U wordt aangeraden zip-implementatie te implementeren. Het levert snellere laadtijden voor uw toepassingen op en dit is de standaardinstelling voor VS Code, Visual Studio en de Azure CLI.

Wanneer u deze wilt gebruiken: Zip deploy is de standaard- en aanbevolen implementatietechnologie voor functie-apps in de abonnementen Windows Consumption, Windows en Linux Elastic Premium en Windows en Linux App Service (Dedicated).

Waar app-inhoud wordt opgeslagen: App-inhoud van een zip-implementatie wordt standaard opgeslagen in het bestandssysteem. Azure kan teruggaan door Azure Files vanuit het opslagaccount dat u 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

De URL van het externe pakket is een optie als u handmatig wilt bepalen hoe implementaties worden uitgevoerd. U neemt de verantwoordelijkheid voor het uploaden van een kant-en-klaar .zip pakket met uw ingebouwde app-inhoud naar blobopslag en verwijst naar deze externe URL als een toepassingsinstelling in uw functie-app. Wanneer uw app opnieuw wordt opgestart, wordt het pakket opgehaald, eraan bevestigd en uitgevoerd in de modus Uitvoeren vanuit 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 met behulp van de Azure CLI.

Als u Azure Blob Storage gebruikt, heeft uw functie-app toegang tot de container via een op beheerde identiteit gebaseerde verbinding of met een SAS (Shared Access Signature). 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. Raadpleeg onze handleiding voor het configureren van deze implementatietechnologie.

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. U kunt elk blob-opslagaccount 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 en implementeer de container vervolgens 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 bouwen. U kunt de container in de volgende implementaties gebruiken:

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 continue 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 Continue 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-implementatiesites voor meer informatie.

Waar app-inhoud wordt opgeslagen: Het broncodebeheersysteem slaat de app-inhoud op. In het bestandssysteem van de app wordt lokaal gekloonde en gebouwde app-content opgeslagen, die mogelijk wordt ondersteund door Azure-bestanden uit het opslagaccount dat is opgegeven toen de functie-app werd gemaakt.

Lokale Git

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

Hoe u dit kunt gebruiken: volg de instructies in de lokale 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: App-inhoud wordt opgeslagen in het bestandssysteem, dat mogelijk wordt ondersteund door Azure Files vanuit het opslagaccount dat u opgeeft bij het maken van de functie-app.

FTP/S

U kunt FTP/S gebruiken om bestanden rechtstreeks over te dragen naar Azure Functions, maar gebruik deze implementatiemethode niet. Als u niet van plan bent FTP te gebruiken, schakelt u deze uit. Als u ervoor kiest FTP te gebruiken, zorg ervoor dat FTPS wordt afgedwongen. Zie FTPS afdwingen in Azure Portal voor meer informatie.

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.

Portal bewerken

In de portaleditor kunt u de bestanden die zich in uw functie-app bevinden, rechtstreeks bewerken (in feite elke keer dat u uw wijzigingen opslaat) implementeren.

Hoe u deze kunt gebruiken: Als u uw functies in Azure Portal wilt bewerken, moet u uw functies maken in de portal. Als u één bron van waarheid wilt behouden, maakt u met behulp van een andere implementatiemethode uw functie alleen-lezen en voorkomt u dat de portal blijft bewerken. 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 kunt gebruiken: De portal is een goede manier om aan de slag te gaan met Azure Functions. Vanwege ontwikkelingsbeperkingen in Azure Portal moet u een van de volgende clienthulpprogramma's gebruiken voor geavanceerdere ontwikkelwerkzaamheden:

Waar app-inhoud wordt opgeslagen: App-inhoud wordt opgeslagen in het bestandssysteem, dat mogelijk wordt ondersteund door Azure Files vanuit het opslagaccount dat u opgeeft bij het maken van de functie-app.

Implementatiegedrag

Wanneer u updates implementeert in de code van uw functie-app, is het implementatiegedrag afhankelijk van uw hostingabonnement:

Verbruiks-, Elastic Premium- en Dedicated-abonnementen: Het uitvoeren van functies wordt momenteel beëindigd wanneer nieuwe code wordt geïmplementeerd. Nadat de implementatie is voltooid, wordt de nieuwe code geladen om aanvragen te verwerken. Dit geforceerde beëindigingsgedrag wordt een strategie voor opnieuw maken genoemd. Gebruik implementatiesites voor implementaties met bijna nul downtime voor verbruiks-, Elastic Premium- en Dedicated-abonnementen.

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

Flex Consumption-abonnement: Het standaardgedrag maakt ook gebruik van de strategie voor opnieuw maken, waardoor functies worden beëindigd tijdens de implementatie. Flex Consumption biedt echter unieke ondersteuning voor twee verschillende site-updatestrategieën. U kunt rolling updates configureren voor implementaties zonder downtime.

Implementatiesites

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

De manier waarop u in een site implementeert, is afhankelijk van het specifieke implementatieprogramma dat u gebruikt. Als u bijvoorbeeld Azure Functions Core Tools gebruikt, neemt u de --slot parameter op om de naam van een specifieke slot voor de func azure functionapp publish opdracht aan te geven.

Zie de documentatie over Implementatiesites van Azure Functions voor meer informatie over implementatiesites.

Volgende stappen

Lees deze artikelen voor meer informatie over het implementeren van uw functie-apps:

  • Last updated on