Delen via

Implementatietechnologieën in Azure Functions

  • Artikel

U kunt een aantal 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 • Visual Studio Code publiceren
• Visual Studio publiceren
• Core Tools publiceren		 Implementaties tijdens ontwikkeling en andere geïmproviseerde implementaties. Uw code op aanvraag implementeren met behulp van lokale ontwikkelhulpprogramma's.
App Service beheerd • Implementatiecentrum (CI/CD)
• Containerimplementaties		 Continue implementatie (CI/CD) vanuit broncodebeheer of vanuit een containerregister. Implementaties worden beheerd door het App Service-platform (Kudu).
Externe pijplijnen • Azure Pipelines
• GitHub Actions		 Productiepijplijnen die validatie, testen en andere acties bevatten die moeten worden uitgevoerd als onderdeel van een geautomatiseerde implementatie. Implementaties worden beheerd door de pijplijn.

Specifieke implementaties moeten de beste technologie gebruiken op basis van het 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 Apps
OneDeploy ✔
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 handmatig synchroniseren wanneer u deze implementatieopties gebruikt:

U kunt triggers op een van de volgende manieren synchroniseren:

  • Start uw functie-app opnieuw op in Azure Portal.

  • 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

Wanneer u een bijgewerkte versie van het implementatiepakket implementeert en dezelfde URL voor het externe pakket onderhoudt, moet u de functie-app handmatig opnieuw opstarten. Dit geeft aan aan de host dat uw updates moeten worden gesynchroniseerd en opnieuw moeten worden geïmplementeerd vanuit dezelfde pakket-URL. De Functions-host voert ook een achtergrondtriggersynchronisatie uit nadat de toepassing is gestart. Voor de hostingabonnementen Consumption en Elastic Premium moet u echter ook triggers handmatig synchroniseren in deze scenario's:

  • Implementaties met behulp van een EXTERNE pakket-URL met ARM-sjablonen of Terraform.
  • Bij het bijwerken van het implementatiepakket op dezelfde URL van het externe pakket.

Externe build

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

  • U implementeert een app in een op Linux gebaseerde functie-app die is ontwikkeld op een Windows-computer. Dit is meestal het geval bij het ontwikkelen van Python-apps. U kunt uiteindelijk in onjuiste bibliotheken terechtkomen die worden gebruikt bij het lokaal bouwen van het implementatiepakket in 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 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 een app wordt geïmplementeerd in Windows, worden taalspecifieke opdrachten, zoals dotnet restore (C#) of npm install (JavaScript) uitgevoerd.

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 worden niet uitgevoerd 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 is gedefinieerd in de instelling AzureWebJobsStorage . 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. Apps voor Flex Consumption-abonnement gebruiken in plaats daarvan een opslagcontainer in het 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.

Eén implementatie

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

Hoe u dit kunt gebruiken: Implementeren met 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 u deze wilt gebruiken: Een implementatie is de enige implementatietechnologie die beschikbaar is voor functie-apps die worden uitgevoerd in het Flex Consumption-abonnement.

Waar app-inhoud wordt opgeslagen: wanneer u een functie-app flexverbruik maakt, geeft u een opslagcontainer voor de implementatie op. Dit is een blobcontainer waarin het platform de app-inhoud uploadt 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.

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 ons 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, dat mogelijk wordt ondersteund door Azure Files vanuit het opslagaccount dat is opgegeven toen de functie-app werd gemaakt. In Linux-verbruik wordt de app-inhoud in plaats daarvan bewaard 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 gebruikt als de waarde voor 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: app-inhoud wordt opgeslagen 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. Als broncodebeheer is ingeschakeld, 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. Broncodebeheer wordt meestal ingeschakeld op een staging-site, die kan worden omgewisseld in productie na validatie van updates uit de opslagplaats. Zie Azure Functions-implementatiesites voor meer informatie.

Waar app-inhoud wordt opgeslagen: de app-inhoud bevindt zich in het broncodebeheersysteem, maar een lokaal gekloonde en gebouwde app-inhoud wordt opgeslagen in het bestandssysteem van de app, die mogelijk wordt ondersteund door Azure Files vanuit het opslagaccount dat is opgegeven toen de functie-app werd gemaakt.

Lokale Git

U kunt lokale Git gebruiken 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: om de kans op fouten te verminderen, moet u het gebruik van implementatiemethoden vermijden 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 is opgegeven toen de functie-app werd gemaakt.

FTP/S

U kunt FTP/S gebruiken om bestanden rechtstreeks over te dragen naar Azure Functions, hoewel deze implementatiemethode niet wordt aanbevolen. Als u niet van plan bent FTP te gebruiken, moet u deze uitschakelen. Als u ervoor kiest FTP te gebruiken, moet u FTPS afdwingen. Zie FTPS afdwingen in Azure Portal voor meer informatie.

Hoe u dit 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 FTPS.

Wanneer moet u deze gebruiken: om de kans op fouten te verminderen, moet u het gebruik van implementatiemethoden vermijden 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 is opgegeven toen de functie-app werd gemaakt.

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 dit kunt gebruiken: als u uw functies in Azure Portal wilt kunnen bewerken, moet u uw functies in de portal hebben gemaakt. 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. Voor geavanceerdere ontwikkelwerkzaamheden raden we u aan een van de volgende clienthulpprogramma's te gebruiken:

Waar app-inhoud wordt opgeslagen: app-inhoud wordt opgeslagen in het bestandssysteem, dat mogelijk wordt ondersteund door Azure Files vanuit het opslagaccount dat is opgegeven toen de functie-app werd gemaakt.

In de volgende tabel ziet u de besturingssystemen en talen die ondersteuning bieden voor bewerking in de portal:

Taal Windows-verbruik Windows Premium Windows Dedicated Linux-verbruik Linux Premium Linux Dedicated
C#1
Java
JavaScript (node.js) ✔ ✔ ✔ ✔ ✔
Python2 ✔ ✔ ✔
Powershell ✔ ✔ ✔
TypeScript (Node.js)

1 In-portal bewerken wordt alleen ondersteund voor C#-scriptbestanden, die in verwerking worden uitgevoerd met de host. Zie de naslaginformatie voor ontwikkelaars van Azure Functions C#-scripts (.csx) voor meer informatie.
2 Bewerking in de portal wordt alleen ondersteund voor het v1 Python-programmeermodel.

Implementatiegedrag

Wanneer u updates implementeert in de code van uw functie-app, worden momenteel uitgevoerde functies beëindigd. Nadat de implementatie is voltooid, wordt de nieuwe code geladen om aanvragen te verwerken. Bekijk De prestaties en betrouwbaarheid van Azure Functions verbeteren voor meer informatie over het schrijven van staatloze en defensieve functies.

Als u meer controle over deze overgang nodig hebt, moet u implementatiesites gebruiken.

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 optie op om de naam van een specifieke site voor de func azure functionapp publish opdracht aan te geven.

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

Volgende stappen

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