Share via

Ontwikkelaarshandleiding voor Azure Functions PowerShell

  • Artikel

Dit artikel bevat informatie over hoe u Azure Functions schrijft met behulp van PowerShell.

Een PowerShell Azure-functie (functie) wordt weergegeven als een PowerShell-script dat wordt uitgevoerd wanneer deze wordt geactiveerd. Elk functiescript heeft een gerelateerd function.json bestand dat definieert hoe de functie zich gedraagt, zoals hoe deze wordt geactiveerd en de invoer- en uitvoerparameters. Zie het artikel Triggers en binding voor meer informatie.

Net als andere soorten functies nemen PowerShell-scriptfuncties parameters op die overeenkomen met de namen van alle invoerbindingen die in het function.json bestand zijn gedefinieerd. Er wordt ook een TriggerMetadata parameter doorgegeven die aanvullende informatie bevat over de trigger waarmee de functie is gestart.

In dit artikel wordt ervan uitgegaan dat u de naslaginformatie voor Azure Functions-ontwikkelaars al hebt gelezen. U moet ook de quickstart functions voor PowerShell hebben voltooid om uw eerste PowerShell-functie te maken.

Mapstructuur

De vereiste mapstructuur voor een PowerShell-project ziet er als volgt uit. Deze standaardwaarde kan worden gewijzigd. Zie de sectie scriptFile hieronder voor meer informatie.

PSFunctionApp
 | - MyFirstFunction
 | | - run.ps1
 | | - function.json
 | - MySecondFunction
 | | - run.ps1
 | | - function.json
 | - Modules
 | | - myFirstHelperModule
 | | | - myFirstHelperModule.psd1
 | | | - myFirstHelperModule.psm1
 | | - mySecondHelperModule
 | | | - mySecondHelperModule.psd1
 | | | - mySecondHelperModule.psm1
 | - local.settings.json
 | - host.json
 | - requirements.psd1
 | - profile.ps1
 | - extensions.csproj
 | - bin

In de hoofdmap van het project bevindt zich een gedeeld host.json bestand dat kan worden gebruikt om de functie-app te configureren. Elke functie heeft een map met een eigen codebestand (.ps1) en een bindingconfiguratiebestand (function.json). De naam van de bovenliggende map van het function.json-bestand is altijd de naam van uw functie.

Voor bepaalde bindingen is de aanwezigheid van een extensions.csproj bestand vereist. Bindingextensies, vereist in versie 2.x en latere versies van de Functions-runtime, worden gedefinieerd in het extensions.csproj bestand, met de werkelijke bibliotheekbestanden in de bin map. Wanneer u lokaal ontwikkelt, moet u bindingsextensies registreren. Wanneer u functies in Azure Portal ontwikkelt, wordt deze registratie voor u uitgevoerd.

In PowerShell-functie-apps kunt u eventueel een profile.ps1 functie hebben die wordt uitgevoerd wanneer een functie-app wordt uitgevoerd (anders bekend als een koude start). Zie Het PowerShell-profiel voor meer informatie.

Een PowerShell-script definiëren als een functie

Standaard zoekt de Functions-runtime naar uw functie in run.ps1, waarbij run.ps1 dezelfde bovenliggende map wordt gedeeld als de bijbehorende function.jsonmap.

Uw script wordt doorgegeven aan een aantal argumenten voor de uitvoering. Als u deze parameters wilt verwerken, voegt u een param blok toe aan het begin van uw script, zoals in het volgende voorbeeld:

# $TriggerMetadata is optional here. If you don't need it, you can safely remove it from the param block
param($MyFirstInputBinding, $MySecondInputBinding, $TriggerMetadata)

Parameter TriggerMetadata

De TriggerMetadata parameter wordt gebruikt om aanvullende informatie over de trigger op te geven. De aanvullende metagegevens variëren van binding tot binding, maar ze bevatten allemaal een sys eigenschap die de volgende gegevens bevat:

$TriggerMetadata.sys
Eigenschappen Beschrijving Type
UtcNow Wanneer, in UTC, is de functie geactiveerd Datum en tijd
MethodName De naam van de functie die is geactiveerd tekenreeks
RandGuid een unieke guid voor deze uitvoering van de functie tekenreeks

Elk triggertype heeft een andere set metagegevens. De for bevat bijvoorbeeld $TriggerMetadata onder andere de InsertionTime, Id, DequeueCount.QueueTrigger Ga naar de officiële documentatie voor wachtrijtriggers voor meer informatie over de metagegevens van de wachtrijtrigger. Raadpleeg de documentatie over de triggers waarmee u werkt om te zien wat er binnen de metagegevens van de trigger komt.

Bindingen

In PowerShell worden bindingen geconfigureerd en gedefinieerd in de function.json van een functie. Functies communiceren met bindingen op een aantal manieren.

Trigger- en invoergegevens lezen

Trigger- en invoerbindingen worden gelezen als parameters die worden doorgegeven aan uw functie. Invoerbindingen hebben een direction set in in function.json. De name eigenschap die is gedefinieerd in function.json is de naam van de parameter, in het param blok. Omdat PowerShell benoemde parameters gebruikt voor binding, maakt de volgorde van de parameters niet uit. Het is echter een best practice om de volgorde van de bindingen te volgen die zijn gedefinieerd in de function.json.

param($MyFirstInputBinding, $MySecondInputBinding)

Uitvoergegevens schrijven

In Functions is direction een uitvoerbinding ingesteld op out in de function.json. U kunt schrijven naar een uitvoerbinding met behulp van de Push-OutputBinding cmdlet, die beschikbaar is voor de Functions-runtime. In alle gevallen komt de name eigenschap van de binding zoals gedefinieerd in function.json overeen met de Name parameter van de Push-OutputBinding cmdlet.

Hieronder ziet u hoe u uw functiescript aanroept Push-OutputBinding :

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

U kunt ook een waarde doorgeven voor een specifieke binding via de pijplijn.

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Push-OutputBinding gedraagt zich anders op basis van de waarde die is opgegeven voor -Name:

  • Wanneer de opgegeven naam niet kan worden omgezet in een geldige uitvoerbinding, wordt er een fout gegenereerd.

  • Wanneer de uitvoerbinding een verzameling waarden accepteert, kunt u herhaaldelijk aanroepen Push-OutputBinding om meerdere waarden te pushen.

  • Wanneer de uitvoerbinding slechts een singleton-waarde accepteert, Push-OutputBinding wordt een tweede keer een fout gegenereerd.

Push-OutputBinding-syntaxis

Hier volgen geldige parameters voor het aanroepen Push-OutputBinding:

Name Type Position Beschrijving
-Name String 1 De naam van de uitvoerbinding die u wilt instellen.
-Value Object 2 De waarde van de uitvoerbinding die u wilt instellen, die wordt geaccepteerd vanuit de pijplijn ByValue.
-Clobber SwitchParameter Genaamd (Optioneel) Wanneer u deze waarde opgeeft, moet de waarde worden ingesteld voor een opgegeven uitvoerbinding.

De volgende algemene parameters worden ook ondersteund:

  • Verbose
  • Debug
  • ErrorAction
  • ErrorVariable
  • WarningAction
  • WarningVariable
  • OutBuffer
  • PipelineVariable
  • OutVariable

Zie Over CommonParameters voor meer informatie.

Voorbeeld van Push-OutputBinding: HTTP-antwoorden

Een HTTP-trigger retourneert een antwoord met behulp van een uitvoerbinding met de naam response. In het volgende voorbeeld heeft de uitvoerbinding response de waarde 'uitvoer 1':

PS >Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "output #1"
})

Omdat de uitvoer naar HTTP gaat, die alleen een singleton-waarde accepteert, wordt er een fout gegenereerd wanneer Push-OutputBinding deze een tweede keer wordt aangeroepen.

PS >Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "output #2"
})

Voor uitvoer die alleen singleton-waarden accepteren, kunt u de -Clobber parameter gebruiken om de oude waarde te overschrijven in plaats van deze toe te voegen aan een verzameling. In het volgende voorbeeld wordt ervan uitgegaan dat u al een waarde hebt toegevoegd. Door het antwoord uit het volgende voorbeeld te gebruiken -Clobber, wordt de bestaande waarde overschreven om een waarde van 'uitvoer #3' te retourneren:

PS >Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "output #3"
}) -Clobber

Voorbeeld van Push-OutputBinding: Queue Output Binding

Push-OutputBinding wordt gebruikt voor het verzenden van gegevens naar uitvoerbindingen, zoals een Azure Queue Storage-uitvoerbinding. In het volgende voorbeeld heeft het bericht dat naar de wachtrij is geschreven de waarde 'uitvoer 1':

PS >Push-OutputBinding -Name outQueue -Value "output #1"

De uitvoerbinding voor een opslagwachtrij accepteert meerdere uitvoerwaarden. In dit geval roept u het volgende voorbeeld aan nadat de eerste naar de wachtrij is geschreven, een lijst met twee items: "output #1" en "output #2".

PS >Push-OutputBinding -Name outQueue -Value "output #2"

In het volgende voorbeeld, wanneer deze wordt aangeroepen na de vorige twee, voegt u nog twee waarden toe aan de uitvoerverzameling:

PS >Push-OutputBinding -Name outQueue -Value @("output #3", "output #4")

Wanneer het bericht naar de wachtrij wordt geschreven, bevat het bericht deze vier waarden: "output #1", "output #2", "output #3" en "output #4".

Get-OutputBinding-cmdlet

U kunt de Get-OutputBinding cmdlet gebruiken om de waarden op te halen die momenteel zijn ingesteld voor uw uitvoerbindingen. Met deze cmdlet wordt een hashtabel opgehaald die de namen van de uitvoerbindingen met hun respectieve waarden bevat.

Hier volgt een voorbeeld van het gebruik Get-OutputBinding om huidige bindingswaarden te retourneren:

Get-OutputBinding

Name                           Value
----                           -----
MyQueue                        myData
MyOtherQueue                   myData

Get-OutputBinding bevat ook een parameter met de naam -Name, die kan worden gebruikt om de geretourneerde binding te filteren, zoals in het volgende voorbeeld:

Get-OutputBinding -Name MyQ*

Name                           Value
----                           -----
MyQueue                        myData

Jokertekens (*) worden ondersteund in Get-OutputBinding.

Logboekregistratie

Logboekregistratie in PowerShell-functies werkt net als gewone PowerShell-logboekregistratie. U kunt de cmdlets voor logboekregistratie gebruiken om naar elke uitvoerstroom te schrijven. Elke cmdlet wordt toegewezen aan een logboekniveau dat wordt gebruikt door Functions.

Niveau van logboekregistratie van functies Cmdlet voor logboekregistratie
Fout Write-Error
Waarschuwing Write-Warning
Gegevens Write-Information
Write-Host
Write-Output
Schrijft naar het Information logboekniveau.
Fouten opsporen Write-Debug
Trace Write-Progress
Write-Verbose

Naast deze cmdlets wordt alles wat naar de pijplijn wordt geschreven, omgeleid naar het Information logboekniveau en weergegeven met de standaard PowerShell-opmaak.

Belangrijk

Het gebruik van de Write-Verbose of Write-Debug cmdlets is niet voldoende om uitgebreide logboekregistratie op foutopsporingsniveau te zien. U moet ook de drempelwaarde voor logboekniveau configureren, waarmee wordt aangegeven welk niveau van logboeken u eigenlijk belangrijk vindt. Zie Het logboekniveau van de functie-app configureren voor meer informatie.

Het logboekniveau van de functie-app configureren

Met Azure Functions kunt u het drempelwaardeniveau definiëren, zodat u eenvoudig kunt bepalen hoe Functions naar de logboeken schrijft. Als u de drempelwaarde wilt instellen voor alle traceringen die naar de console zijn geschreven, gebruikt u de logging.logLevel.default eigenschap in het host.json bestand. Deze instelling is van toepassing op alle functies in uw functie-app.

In het volgende voorbeeld wordt de drempelwaarde ingesteld om uitgebreide logboekregistratie in te schakelen voor alle functies, maar wordt de drempelwaarde ingesteld om logboekregistratie voor foutopsporing in te schakelen voor een functie met de naam MyFunction:

{
    "logging": {
        "logLevel": {
            "Function.MyFunction": "Debug",
            "default": "Trace"
        }
    }
}

Zie host.json naslaginformatie voor meer informatie.

De logboeken weergeven

Als uw functie-app wordt uitgevoerd in Azure, kunt u Application Insights gebruiken om deze te bewaken. Lees bewaking van Azure Functions voor meer informatie over het weergeven en opvragen van functielogboeken.

Als u uw functie-app lokaal uitvoert voor ontwikkeling, worden de logboeken standaard ingesteld op het bestandssysteem. Als u de logboeken in de console wilt zien, stelt u de AZURE_FUNCTIONS_ENVIRONMENT omgevingsvariabele Development in op voordat u de functie-app start.

Typen triggers en bindingen

Er zijn een aantal triggers en bindingen beschikbaar die u kunt gebruiken met uw functie-app. De volledige lijst met triggers en bindingen vindt u hier.

Alle triggers en bindingen worden in code weergegeven als enkele echte gegevenstypen:

  • Hashtable
  • tekenreeks
  • byte[]
  • int
  • dubbel
  • HttpRequestContext
  • HttpResponseContext

De eerste vijf typen in deze lijst zijn standaard .NET-typen. De laatste twee worden alleen gebruikt door de HttpTrigger-trigger.

Elke bindingsparameter in uw functies moet een van deze typen zijn.

HTTP-triggers en -bindingen

HTTP- en webhooktriggers en HTTP-uitvoerbindingen maken gebruik van aanvraag- en antwoordobjecten om de HTTP-berichten weer te geven.

Aanvraagobject

Het aanvraagobject dat in het script wordt doorgegeven, is van het type HttpRequestContext, dat de volgende eigenschappen heeft:

Eigenschappen Beschrijving Type
Body Een object dat de hoofdtekst van de aanvraag bevat. Body wordt geserialiseerd in het beste type op basis van de gegevens. Als de gegevens bijvoorbeeld JSON zijn, worden deze doorgegeven als een hashtabel. Als de gegevens een tekenreeks zijn, worden deze doorgegeven als een tekenreeks. object
Headers Een woordenlijst met de aanvraagheaders. Woordenlijsttekenreeks<, tekenreeks>*
Method De HTTP-methode van de aanvraag. tekenreeks
Params Een object dat de routeringsparameters van de aanvraag bevat. Woordenlijsttekenreeks<, tekenreeks>*
Query Een object dat de queryparameters bevat. Woordenlijsttekenreeks<, tekenreeks>*
Url De URL van de aanvraag. tekenreeks

* Alle Dictionary<string,string> sleutels zijn hoofdlettergevoelig.

Responsobject

Het antwoordobject dat u moet terugsturen, is van het type HttpResponseContext, dat de volgende eigenschappen heeft:

Eigenschappen Beschrijving Type
Body Een object dat de hoofdtekst van het antwoord bevat. object
ContentType Een korte hand voor het instellen van het inhoudstype voor het antwoord. tekenreeks
Headers Een object dat de antwoordheaders bevat. Woordenlijst of hashtabel
StatusCode De HTTP-statuscode van het antwoord. tekenreeks of int

Toegang tot de aanvraag en het antwoord

Wanneer u met HTTP-triggers werkt, kunt u de HTTP-aanvraag op dezelfde manier openen als bij elke andere invoerbinding. Het zit in het param blok.

Gebruik een HttpResponseContext object om een antwoord te retourneren, zoals wordt weergegeven in het volgende:

function.json

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "authLevel": "anonymous"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

run.ps1

param($req, $TriggerMetadata)

$name = $req.Query.Name

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "Hello $name!"
})

Het resultaat van het aanroepen van deze functie is:

PS > irm http://localhost:5001?Name=Functions
Hello Functions!

Typecasting voor triggers en bindingen

Voor bepaalde bindingen, zoals de blobbinding, kunt u het type van de parameter opgeven.

Als u bijvoorbeeld gegevens uit blobopslag wilt laten opgegeven als een tekenreeks, voegt u het volgende type cast toe aan mijn param blok:

param([string] $myBlob)

PowerShell-profiel

In PowerShell is er het concept van een PowerShell-profiel. Zie Over profielen als u niet bekend bent met PowerShell-profielen.

In PowerShell Functions wordt het profielscript eenmaal uitgevoerd per PowerShell-werkrolexemplaren in de app wanneer het voor het eerst wordt geïmplementeerd en na inactiviteit (koude start). Wanneer gelijktijdigheid is ingeschakeld door de waarde PSWorkerInProcConcurrencyUpperBound in te stellen, wordt het profielscript uitgevoerd voor elke gemaakte runspace.

Wanneer u een functie-app maakt met behulp van hulpprogramma's, zoals Visual Studio Code en Azure Functions Core Tools, wordt er een standaard profile.ps1 voor u gemaakt. Het standaardprofiel wordt onderhouden in de GitHub-opslagplaats Core Tools en bevat:

  • Automatische MSI-verificatie naar Azure.
  • De mogelijkheid om de Azure PowerShell PowerShell-aliassen AzureRM in te schakelen als u wilt.

PowerShell-versies

In de volgende tabel ziet u de PowerShell-versies die beschikbaar zijn voor elke primaire versie van de Functions-runtime en de vereiste .NET-versie:

Functions-versie PowerShell-versie .NET-versie
4.x PowerShell 7.4 .NET 8
4.x PowerShell 7.2 (ondersteuning eindigt) .NET 6

U kunt de huidige versie zien door af te drukken $PSVersionTable vanuit elke functie.

Raadpleeg dit artikel voor meer informatie over ondersteuningsbeleid voor Azure Functions Runtime

Notitie

Ondersteuning voor PowerShell 7.2 in Azure Functions eindigt op 8 november 2024. Mogelijk moet u enkele belangrijke wijzigingen oplossen bij het upgraden van uw PowerShell 7.2-functies die moeten worden uitgevoerd in PowerShell 7.4. Volg deze migratiehandleiding om een upgrade uit te voeren naar PowerShell 7.4.

Lokaal uitvoeren op een specifieke versie

Wanneer u uw PowerShell-functies lokaal uitvoert, moet u de instelling "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4" toevoegen aan de Values matrix in het local.setting.json-bestand in de hoofdmap van het project. Wanneer uw local.settings.json lokaal wordt uitgevoerd in PowerShell 7.4, ziet het volgende voorbeeld eruit:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "",
    "FUNCTIONS_WORKER_RUNTIME": "powershell",
    "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4"
  }
}

Notitie

In PowerShell Functions verwijst de waarde '~7' voor FUNCTIONS_WORKER_RUNTIME_VERSION naar '7.0.x'. PowerShell Function-apps met ~7 worden niet automatisch bijgewerkt naar 7.4. In de toekomst moeten we voor PowerShell-functie-apps zowel de primaire als de secundaire versie opgeven waarop ze zich willen richten. Daarom is het nodig om "7.4" te vermelden als u wilt targeten "7.4.x"

De PowerShell-versie wijzigen

Neem rekening met deze overwegingen voordat u uw PowerShell-functie-app migreert naar PowerShell 7.4:

  • Omdat de migratie belangrijke wijzigingen in uw app kan veroorzaken, raadpleegt u deze migratiehandleiding voordat u uw app bijwerkt naar PowerShell 7.4.

  • Zorg ervoor dat uw functie-app wordt uitgevoerd op de nieuwste versie van de Functions-runtime in Azure, versie 4.x. Zie De huidige runtimeversie weergeven en bijwerken voor meer informatie.

Gebruik de volgende stappen om de PowerShell-versie te wijzigen die wordt gebruikt door uw functie-app. U kunt dit doen in Azure Portal of met behulp van PowerShell.

  1. Blader in de Azure-portal naar uw functie-app.

  2. Kies Onder Instellingen de optie Configuratie. Zoek op het tabblad Algemene instellingen de PowerShell-versie.

    image

  3. Kies de gewenste PowerShell Core-versie en selecteer Opslaan. Wanneer u wordt gewaarschuwd dat het opnieuw opstarten in behandeling is, kiest u Doorgaan. De functie-app wordt opnieuw opgestart op de gekozen PowerShell-versie.

Notitie

Azure Functions-ondersteuning voor PowerShell 7.4 is algemeen beschikbaar (GA). Mogelijk ziet u PowerShell 7.4 nog steeds aangegeven als preview in Azure Portal, maar dit wordt binnenkort bijgewerkt om de ALGEMENE status weer te geven.

De functie-app wordt opnieuw opgestart nadat de wijziging is aangebracht in de configuratie.

Beheer van afhankelijkheden

Met Functions kunt u gebruikmaken van de PowerShell-galerie voor het beheren van afhankelijkheden. Als afhankelijkheidsbeheer is ingeschakeld, wordt het bestand requirements.psd1 gebruikt om automatisch vereiste modules te downloaden. U schakelt dit gedrag in door de managedDependency eigenschap true in te stellen in de hoofdmap van het host.json-bestand, zoals in het volgende voorbeeld:

{
  "managedDependency": {
          "enabled": true
       }
}

Wanneer u een nieuw PowerShell Functions-project maakt, wordt afhankelijkheidsbeheer standaard ingeschakeld, met de Azure-module Az opgenomen. Het maximum aantal modules dat momenteel wordt ondersteund, is 10. De ondersteunde syntaxis is MajorNumber.* of de exacte moduleversie, zoals wordt weergegeven in het volgende voorbeeld requirements.psd1:

@{
	Az = '1.*'
	SqlServer = '21.1.18147'
}

Wanneer u het bestand requirements.psd1 bijwerkt, worden bijgewerkte modules na het opnieuw opstarten geïnstalleerd.

Doelspecifieke versies

Mogelijk wilt u zich richten op een specifieke versie van een module in uw bestand requirements.psd1. Als u bijvoorbeeld een oudere versie van Az.Accounts wilt gebruiken dan de versie in de meegeleverde Az-module, moet u een specifieke versie instellen, zoals wordt weergegeven in het volgende voorbeeld:

@{
	'Az.Accounts' = '1.9.5'
}

In dit geval moet u ook een importinstructie toevoegen aan het begin van uw profiel.ps1-bestand, zoals in het volgende voorbeeld:

Import-Module Az.Accounts -RequiredVersion '1.9.5'

Op deze manier wordt de oudere versie van de Az.Account-module eerst geladen wanneer de functie wordt gestart.

Overwegingen voor afhankelijkheidsbeheer

De volgende overwegingen zijn van toepassing bij het gebruik van afhankelijkheidsbeheer:

  • Voor beheerde afhankelijkheden is toegang vereist om modules te https://www.powershellgallery.com downloaden. Wanneer u lokaal werkt, moet u ervoor zorgen dat de runtime toegang heeft tot deze URL door vereiste firewallregels toe te voegen.

  • Beheerde afhankelijkheden bieden momenteel geen ondersteuning voor modules waarvoor de gebruiker een licentie moet accepteren, door de licentie interactief te accepteren of door -AcceptLicense over te schakelen bij het aanroepen Install-Module.

  • Beheerde afhankelijkheden worden niet ondersteund wanneer u uw functie-app host in een Flex Consumption-abonnement. In plaats daarvan moet u uw eigen aangepaste modules definiëren.

App-instellingen voor afhankelijkheidsbeheer

De volgende toepassingsinstellingen kunnen worden gebruikt om te wijzigen hoe de beheerde afhankelijkheden worden gedownload en geïnstalleerd.

Instelling van functie-app Default value Beschrijving
MDMaxBackgroundUpgradePeriod 7.00:00:00 (zeven dagen) Hiermee bepaalt u de periode van de achtergrondupdate voor PowerShell-functie-apps. Zie MDMaxBackgroundUpgradePeriod voor meer informatie.
MDNewSnapshotCheckPeriod 01:00:00 (één uur) Hiermee geeft u op hoe vaak elke PowerShell-werkrol controleert of beheerde afhankelijkheidsupgrades zijn geïnstalleerd. Zie MDNewSnapshotCheckPeriod voor meer informatie.
MDMinBackgroundUpgradePeriod 1.00:00:00 (één dag) De periode na een vorige upgradecontrole voordat een andere upgradecontrole wordt gestart. Zie MDMinBackgroundUpgradePeriod voor meer informatie.

In wezen begint uw app-upgrade binnen MDMaxBackgroundUpgradePerioden wordt het upgradeproces binnen ongeveer het MDNewSnapshotCheckPeriodproces voltooid.

Aangepaste modules

Het gebruik van uw eigen aangepaste modules in Azure Functions verschilt van de manier waarop u dit normaal zou doen voor PowerShell.

Op uw lokale computer wordt de module geïnstalleerd in een van de wereldwijd beschikbare mappen in uw $env:PSModulePath. Wanneer u in Azure werkt, hebt u geen toegang tot de modules die op uw computer zijn geïnstalleerd. Dit betekent dat de $env:PSModulePath voor een PowerShell-functie-app verschilt van $env:PSModulePath in een normaal PowerShell-script.

In Functions PSModulePath bevat u twee paden:

  • Een Modules map die zich in de hoofdmap van uw functie-app bevindt.
  • Een pad naar een Modules map die wordt beheerd door de PowerShell-taalwerker.

Map modules op functie-appniveau

Als u aangepaste modules wilt gebruiken, kunt u modules plaatsen waarvan uw functies afhankelijk zijn in een Modules map. Vanuit deze map zijn modules automatisch beschikbaar voor de functions-runtime. Elke functie in de functie-app kan deze modules gebruiken.

Notitie

Modules die zijn opgegeven in het bestand requirements.psd1 worden automatisch gedownload en opgenomen in het pad, zodat u ze niet hoeft op te nemen in de map modules. Deze worden lokaal opgeslagen in de $env:LOCALAPPDATA/AzureFunctions map en in de /data/ManagedDependencies map wanneer ze worden uitgevoerd in de cloud.

Als u wilt profiteren van de aangepaste modulefunctie, maakt u een Modules map in de hoofdmap van uw functie-app. Kopieer de modules die u in uw functies wilt gebruiken naar deze locatie.

mkdir ./Modules
Copy-Item -Path /mymodules/mycustommodule -Destination ./Modules -Recurse

Met een Modules map moet uw functie-app de volgende mapstructuur hebben:

PSFunctionApp
 | - MyFunction
 | | - run.ps1
 | | - function.json
 | - Modules
 | | - MyCustomModule
 | | - MyOtherCustomModule
 | | - MySpecialModule.psm1
 | - local.settings.json
 | - host.json
 | - requirements.psd1

Wanneer u de functie-app start, voegt de PowerShell-taalmedewerker deze Modules map toe aan de $env:PSModulePath map, zodat u kunt vertrouwen op automatisch laden van modules, net zoals in een normaal PowerShell-script.

Map met modules op taalwerkniveau

Verschillende modules worden vaak gebruikt door de PowerShell-taalwerker. Deze modules worden gedefinieerd op de laatste positie van PSModulePath.

De huidige lijst met modules is als volgt:

  • Microsoft.PowerShell.Archive: module die wordt gebruikt voor het werken met archieven, zoals .zip, .nupkgen anderen.
  • ThreadJob: Een threadgebaseerde implementatie van de PowerShell-taak-API's.

Functions gebruikt standaard de meest recente versie van deze modules. Als u een specifieke moduleversie wilt gebruiken, plaatst u die specifieke versie in de Modules map van uw functie-app.

Omgevingsvariabelen

In Functions worden app-instellingen, zoals service-verbindingsreeks s, tijdens de uitvoering weergegeven als omgevingsvariabelen. U kunt deze instellingen openen met behulp van $env:NAME_OF_ENV_VAR, zoals wordt weergegeven in het volgende voorbeeld:

param($myTimer)

Write-Host "PowerShell timer trigger function ran! $(Get-Date)"
Write-Host $env:AzureWebJobsStorage
Write-Host $env:WEBSITE_SITE_NAME

Er zijn verschillende manieren waarop u instellingen van een functie app kunt toevoegen, bijwerken en verwijderen:

Voor wijzigingen in de instellingen van de functie-app moet uw functie-app opnieuw worden gestart.

Wanneer u lokaal werkt, worden app-instellingen gelezen uit het local.settings.json projectbestand.

Gelijktijdigheid

Standaard kan de Functions PowerShell-runtime slechts één aanroep van een functie tegelijk verwerken. Dit gelijktijdigheidsniveau is echter mogelijk niet voldoende in de volgende situaties:

  • Wanneer u een groot aantal aanroepen tegelijk probeert af te handelen.
  • Wanneer u functies hebt die andere functies in dezelfde functie-app aanroepen.

Er zijn enkele gelijktijdigheidsmodellen die u kunt verkennen, afhankelijk van het type workload:

  • Toename FUNCTIONS_WORKER_PROCESS_COUNT. Dit maakt het mogelijk om functie-aanroepen in meerdere processen binnen hetzelfde exemplaar te verwerken, waardoor bepaalde CPU- en geheugenoverhead wordt geïntroduceerd. Over het algemeen hebben I/O-afhankelijke functies geen last van deze overhead. Voor CPU-afhankelijke functies kan de impact aanzienlijk zijn.

  • Verhoog de waarde van de PSWorkerInProcConcurrencyUpperBound app-instelling. Hierdoor kunnen meerdere runspaces binnen hetzelfde proces worden gemaakt, wat de CPU- en geheugenoverhead aanzienlijk vermindert.

U stelt deze omgevingsvariabelen in de app-instellingen van uw functie-app in.

Afhankelijk van uw use-case kan Durable Functions de schaalbaarheid aanzienlijk verbeteren. Zie Durable Functions-toepassingspatronen voor meer informatie.

Notitie

Mogelijk krijgt u 'aanvragen worden in de wachtrij geplaatst vanwege geen beschikbare runspaces'-waarschuwingen. Houd er rekening mee dat dit geen fout is. Het bericht vertelt u dat aanvragen in de wachtrij worden geplaatst en dat ze worden verwerkt wanneer de vorige aanvragen zijn voltooid.

Overwegingen voor het gebruik van gelijktijdigheid

PowerShell is standaard een single_threaded scripttaal. Gelijktijdigheid kan echter worden toegevoegd met behulp van meerdere PowerShell-runspaces in hetzelfde proces. Het aantal gemaakte runspaces en daarom wordt het aantal gelijktijdige threads per werkrol beperkt door de PSWorkerInProcConcurrencyUpperBound toepassingsinstelling. Standaard is het aantal runspaces ingesteld op 1000 in versie 4.x van de Functions-runtime. In versie 3.x en lager is het maximum aantal runspaces ingesteld op 1. De doorvoer wordt beïnvloed door de hoeveelheid CPU en geheugen die beschikbaar is in het geselecteerde plan.

Azure PowerShell maakt gebruik van bepaalde contexten en status op procesniveau om u te helpen bij overtollig typen. Als u echter gelijktijdigheid inschakelt in uw functie-app en acties aanroept die de status wijzigen, kunt u uiteindelijk racevoorwaarden hebben. Deze racevoorwaarden zijn moeilijk op te sporen omdat één aanroep afhankelijk is van een bepaalde status en de andere aanroep de status heeft gewijzigd.

Er is enorme waarde in gelijktijdigheid met Azure PowerShell, omdat sommige bewerkingen veel tijd in beslag kunnen nemen. U moet echter voorzichtig zijn. Als u vermoedt dat u een racevoorwaarde ondervindt, stelt u de app 1 PSWorkerInProcConcurrencyUpperbound in op en gebruikt u in plaats daarvan isolatie op taalprocesniveau voor gelijktijdigheid.

FunctiescriptFile configureren

Standaard wordt een PowerShell-functie uitgevoerd vanuit run.ps1, een bestand dat dezelfde bovenliggende map deelt als de bijbehorende function.jsonmap.

De scriptFile eigenschap in de function.json eigenschap kan worden gebruikt om een mapstructuur op te halen die eruitziet als in het volgende voorbeeld:

FunctionApp
 | - host.json
 | - myFunction
 | | - function.json
 | - lib
 | | - PSFunction.ps1

In dit geval bevat de function.json for myFunction een scriptFile eigenschap die verwijst naar het bestand met de geëxporteerde functie die moet worden uitgevoerd.

{
  "scriptFile": "../lib/PSFunction.ps1",
  "bindings": [
    // ...
  ]
}

PowerShell-modules gebruiken door een entryPoint te configureren

In dit artikel worden PowerShell-functies weergegeven in het standaardscriptbestand run.ps1 dat is gegenereerd door de sjablonen. U kunt uw functies echter ook opnemen in PowerShell-modules. U kunt verwijzen naar uw specifieke functiecode in de module met behulp van de scriptFile velden entryPoint in het configuratiebestand van de function.json.

In dit geval entryPoint is dit de naam van een functie of cmdlet in de PowerShell-module waarnaar wordt verwezen.scriptFile

Houd rekening met de volgende mapstructuur:

FunctionApp
 | - host.json
 | - myFunction
 | | - function.json
 | - lib
 | | - PSFunction.psm1

Waar PSFunction.psm1 staat:

function Invoke-PSTestFunc {
    param($InputBinding, $TriggerMetadata)

    Push-OutputBinding -Name OutputBinding -Value "output"
}

Export-ModuleMember -Function "Invoke-PSTestFunc"

In dit voorbeeld bevat de configuratie een myFunction scriptFile eigenschap die verwijst naar PSFunction.psm1een PowerShell-module in een andere map. De entryPoint eigenschap verwijst naar de Invoke-PSTestFunc functie, het toegangspunt in de module.

{
  "scriptFile": "../lib/PSFunction.psm1",
  "entryPoint": "Invoke-PSTestFunc",
  "bindings": [
    // ...
  ]
}

Met deze configuratie wordt de Invoke-PSTestFunc uitvoering precies zo uitgevoerd als een run.ps1 .

Overwegingen voor PowerShell-functies

Wanneer u met PowerShell-functies werkt, moet u rekening houden met de overwegingen in de volgende secties.

Koude begindatum

Bij het ontwikkelen van Azure Functions in het serverloze hostingmodel is koude start een realiteit. Koude start verwijst naar de tijd die nodig is voordat uw functie-app wordt uitgevoerd om een aanvraag te verwerken. Koude start vindt vaker plaats in het verbruiksabonnement omdat uw functie-app wordt afgesloten tijdens perioden van inactiviteit.

Modules bundelen in plaats van install-module te gebruiken

Uw script wordt uitgevoerd bij elke aanroep. Vermijd het gebruik Install-Module in uw script. Gebruik in plaats daarvan Save-Module voordat u publiceert, zodat uw functie geen tijd hoeft te verspillen aan het downloaden van de module. Als koude start van invloed is op uw functies, kunt u overwegen om uw functie-app te implementeren in een App Service-plan dat is ingesteld op altijd aan of op een Premium-abonnement.

Volgende stappen

Voor meer informatie raadpleegt u de volgende bronnen: