Dela via

PowerShell-utvecklarhandbok för Azure Functions

  • Artikel

Den här artikeln innehåller information om hur du skriver Azure Functions med hjälp av PowerShell.

En PowerShell Azure-funktion (funktion) representeras som ett PowerShell-skript som körs när den utlöses. Varje funktionsskript har en relaterad function.json fil som definierar hur funktionen fungerar, till exempel hur den utlöses och dess indata- och utdataparametrar. Mer information finns i artikeln Utlösare och bindning.

Liksom andra typer av funktioner tar PowerShell-skriptfunktioner in parametrar som matchar namnen på alla indatabindningar som definierats i function.json filen. En TriggerMetadata parameter skickas också som innehåller ytterligare information om utlösaren som startade funktionen.

Den här artikeln förutsätter att du redan har läst azure functions-utvecklarreferensen. Du bör också ha slutfört snabbstarten Functions för PowerShell för att skapa din första PowerShell-funktion.

Mappstrukturen

Den nödvändiga mappstrukturen för ett PowerShell-projekt ser ut så här. Det här standardvärdet kan ändras. Mer information finns i avsnittet scriptFile nedan.

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

I projektets rot finns det en delad host.json fil som kan användas för att konfigurera funktionsappen. Varje funktion har en mapp med en egen kodfil (.ps1) och en bindningskonfigurationsfil (function.json). Namnet på den function.json filens överordnade katalog är alltid namnet på din funktion.

Vissa bindningar kräver förekomst av en extensions.csproj fil. Bindningstillägg som krävs i version 2.x och senare versioner av Functions-körningen extensions.csproj definieras i filen med de faktiska biblioteksfilerna bin i mappen. När du utvecklar lokalt måste du registrera bindningstillägg. När du utvecklar funktioner i Azure-portalen görs den här registreringen åt dig.

I PowerShell-funktionsappar kan du eventuellt ha en profile.ps1 som körs när en funktionsapp börjar köras (annars kallas det kallstart). Mer information finns i PowerShell-profil.

Definiera ett PowerShell-skript som en funktion

Som standard letar Functions-körningen efter funktionen i run.ps1, där run.ps1 delar samma överordnade katalog som motsvarande function.json.

Skriptet skickas ett antal argument vid körning. Om du vill hantera dessa parametrar lägger du till ett param block överst i skriptet som i följande exempel:

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

Parametern TriggerMetadata

Parametern TriggerMetadata används för att ange ytterligare information om utlösaren. De ytterligare metadata varierar från bindning till bindning, men alla innehåller en sys egenskap som innehåller följande data:

$TriggerMetadata.sys
Property Beskrivning Typ
UtcNow När funktionen utlöstes i UTC Datum/tid
MethodName Namnet på funktionen som utlöstes sträng
RandGuid ett unikt guid för den här körningen av funktionen sträng

Varje utlösartyp har en annan uppsättning metadata. Till exempel $TriggerMetadata innehåller InsertionTimefor QueueTrigger bland annat , Id, DequeueCount, . Mer information om köutlösarens metadata finns i den officiella dokumentationen för köutlösare. Läs dokumentationen om de utlösare som du arbetar med för att se vad som finns i utlösarmetadata.

Bindningar

I PowerShell konfigureras och definieras bindningar i en funktions function.json. Funktioner interagerar med bindningar på flera olika sätt.

Läsa utlösare och indata

Utlösar- och indatabindningar läses som parametrar som skickas till din funktion. Indatabindningar har en direction uppsättning i in function.json. Egenskapen name som definieras i function.json är namnet på parametern i param blocket. Eftersom PowerShell använder namngivna parametrar för bindning spelar parametrarnas ordning ingen roll. Det är dock bästa praxis att följa ordningen på bindningarna som definieras i function.json.

param($MyFirstInputBinding, $MySecondInputBinding)

Skriva utdata

I Functions har en utdatabindning en direction uppsättning i out function.json. Du kan skriva till en utdatabindning med hjälp av cmdleten Push-OutputBinding , som är tillgänglig för Functions-körningen. I samtliga fall name motsvarar egenskapen för bindningen enligt definitionen i function.json parametern Name för cmdleten Push-OutputBinding .

Följande visar hur du anropar Push-OutputBinding i funktionsskriptet:

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

Du kan också skicka in ett värde för en specifik bindning via pipelinen.

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Push-OutputBinding beter sig annorlunda baserat på det värde som angetts för -Name:

  • När det angivna namnet inte kan matchas till en giltig utdatabindning utlöses ett fel.

  • När utdatabindningen accepterar en samling värden kan du anropa Push-OutputBinding flera gånger för att push-överföra flera värden.

  • När utdatabindningen endast accepterar ett singleton-värde genererar anrop Push-OutputBinding en andra gång ett fel.

Syntax för Push-OutputBinding

Följande är giltiga parametrar för att anropa Push-OutputBinding:

Namn Type Position beskrivning
-Name String 1 Namnet på den utdatabindning som du vill ange.
-Value Objekt 2 Värdet för den utdatabindning som du vill ange, som accepteras från pipelinen ByValue.
-Clobber SwitchParameter Heter (Valfritt) När det anges tvingar du värdet som ska anges för en angiven utdatabindning.

Följande vanliga parametrar stöds också:

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

Mer information finns i Om CommonParameters.

Push-OutputBinding-exempel: HTTP-svar

En HTTP-utlösare returnerar ett svar med en utdatabindning med namnet response. I följande exempel har utdatabindningen response värdet "output #1":

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

Eftersom utdata är till HTTP, som endast accepterar ett singleton-värde, utlöses ett fel när Push-OutputBinding anropas en andra gång.

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

För utdata som endast accepterar singleton-värden kan du använda parametern -Clobber för att åsidosätta det gamla värdet i stället för att försöka lägga till i en samling. I följande exempel förutsätts att du redan har lagt till ett värde. Med hjälp -Clobberav åsidosätter svaret från följande exempel det befintliga värdet för att returnera värdet "output #3":

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

Push-OutputBinding-exempel: Bindning av köutdata

Push-OutputBinding används för att skicka data till utdatabindningar, till exempel en Azure Queue Storage-utdatabindning. I följande exempel har meddelandet som skrivits till kön värdet "output #1":

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

Utdatabindningen för en lagringskö accepterar flera utdatavärden. I det här fallet anropar du följande exempel efter de första skrivningar till kön en lista med två objekt: "output #1" och "output #2".

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

I följande exempel, när det anropas efter de föregående två, läggs ytterligare två värden till i utdatasamlingen:

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

När meddelandet skrivs till kön innehåller det följande fyra värden: "output #1", "output #2", "output #3" och "output #4".

Cmdleten Get-OutputBinding

Du kan använda cmdleten Get-OutputBinding för att hämta de värden som för närvarande anges för dina utdatabindningar. Den här cmdleten hämtar en hashtable som innehåller namnen på utdatabindningarna med respektive värden.

Följande är ett exempel på hur du använder Get-OutputBinding för att returnera aktuella bindningsvärden:

Get-OutputBinding

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

Get-OutputBinding innehåller också en parameter med namnet -Name, som kan användas för att filtrera den returnerade bindningen, som i följande exempel:

Get-OutputBinding -Name MyQ*

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

Jokertecken (*) stöds i Get-OutputBinding.

Loggning

Loggning i PowerShell-funktioner fungerar som vanlig PowerShell-loggning. Du kan använda loggnings-cmdletarna för att skriva till varje utdataström. Varje cmdlet mappar till en loggnivå som används av Functions.

Funktionsloggningsnivå Loggnings-cmdlet
Fel Write-Error
Varning Write-Warning
Information Write-Information
Write-Host
Write-Output
Skriver till Information loggnivån.
Felsöka Write-Debug
Spårning Write-Progress
Write-Verbose

Utöver dessa cmdletar omdirigeras allt som skrivs till pipelinen till Information loggnivån och visas med standardformateringen för PowerShell.

Viktigt!

Write-Verbose Det räcker inte att använda cmdletarna eller Write-Debug för att se utförlig och felsökningsnivåloggning. Du måste också konfigurera tröskelvärdet för loggnivå, som anger vilken nivå av loggar du faktiskt bryr dig om. Mer information finns i Konfigurera funktionsappens loggnivå.

Konfigurera funktionsappens loggnivå

Med Azure Functions kan du definiera tröskelvärdet för att göra det enkelt att styra hur Functions skriver till loggarna. Om du vill ange tröskelvärdet för alla spårningar som skrivits till konsolen använder du logging.logLevel.default egenskapen i host.json filen. Den här inställningen gäller för alla funktioner i funktionsappen.

I följande exempel anges tröskelvärdet för att aktivera utförlig loggning för alla funktioner, men anger tröskelvärdet för att aktivera felsökningsloggning för en funktion med namnet MyFunction:

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

Mer information finns i host.json referens.

Visa loggarna

Om funktionsappen körs i Azure kan du använda Application Insights för att övervaka den. Läs övervakning av Azure Functions om du vill veta mer om att visa och köra frågor mot funktionsloggar.

Om du kör funktionsappen lokalt för utveckling loggar som standard till filsystemet. Om du vill se loggarna i konsolen anger du AZURE_FUNCTIONS_ENVIRONMENT miljövariabeln till Development innan du startar funktionsappen.

Typer av utlösare och bindningar

Det finns ett antal utlösare och bindningar som du kan använda med din funktionsapp. Den fullständiga listan över utlösare och bindningar finns här.

Alla utlösare och bindningar representeras i kod som några verkliga datatyper:

  • Hashtable
  • sträng
  • byte[]
  • heltal
  • dubbel
  • HttpRequestContext
  • HttpResponseContext

De första fem typerna i den här listan är standardtyper för .NET. De två sista används endast av HttpTrigger-utlösaren.

Varje bindningsparameter i dina funktioner måste vara en av dessa typer.

HTTP-utlösare och bindningar

HTTP- och webhook-utlösare och HTTP-utdatabindningar använder begärande- och svarsobjekt för att representera HTTP-meddelanden.

Begär objekt

Begärandeobjektet som skickas till skriptet är av typen HttpRequestContext, som har följande egenskaper:

Property Beskrivning Typ
Body Ett objekt som innehåller brödtexten i begäran. Body serialiseras till den bästa typen baserat på data. Om data till exempel är JSON skickas de som en hashtable. Om data är en sträng skickas de som en sträng. objekt
Headers En ordlista som innehåller begäranderubrikerna. Ordlistesträng,sträng<>*
Method HTTP-metoden för begäran. sträng
Params Ett objekt som innehåller routningsparametrarna för begäran. Ordlistesträng,sträng<>*
Query Ett objekt som innehåller frågeparametrarna. Ordlistesträng,sträng<>*
Url URL:en för begäran. sträng

* Alla Dictionary<string,string> nycklar är skiftlägesokänsliga.

Svarsobjekt

Svarsobjektet som du ska skicka tillbaka är av typen HttpResponseContext, som har följande egenskaper:

Property Beskrivning Typ
Body Ett objekt som innehåller svarets brödtext. objekt
ContentType En kort hand för att ange innehållstypen för svaret. sträng
Headers Ett objekt som innehåller svarshuvudena. Ordlista eller hashtable
StatusCode HTTP-statuskoden för svaret. sträng eller int

Åtkomst till begäran och svar

När du arbetar med HTTP-utlösare kan du komma åt HTTP-begäran på samma sätt som med andra indatabindningar. Det är i param kvarteret.

Använd ett HttpResponseContext -objekt för att returnera ett svar, enligt följande:

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!"
})

Resultatet av att anropa den här funktionen är:

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

Typgjutning för utlösare och bindningar

För vissa bindningar som blobbindningen kan du ange parametertypen.

Om du till exempel vill att data från Blob Storage ska levereras som en sträng lägger du till följande typ cast i mitt param block:

param([string] $myBlob)

PowerShell-profil

I PowerShell finns begreppet PowerShell-profil. Om du inte är bekant med PowerShell-profiler kan du läsa Om profiler.

I PowerShell Functions körs profilskriptet en gång per PowerShell-arbetsinstans i appen när det först distribueras och efter att ha varit inaktivt (kallstart. När samtidighet aktiveras genom att ange värdet PSWorkerInProcConcurrencyUpperBound körs profilskriptet för varje runspace som skapas.

När du skapar en funktionsapp med verktyg, till exempel Visual Studio Code och Azure Functions Core Tools, skapas en standard profile.ps1 för dig. Standardprofilen underhålls på GitHub-lagringsplatsen Core Tools och innehåller:

  • Automatisk MSI-autentisering till Azure.
  • Möjligheten att aktivera Azure PowerShell PowerShell-alias AzureRM om du vill.

PowerShell-versioner

I följande tabell visas de PowerShell-versioner som är tillgängliga för varje huvudversion av Functions-körningen och den .NET-version som krävs:

Funktionsversion PowerShell-version .NET-version
4.x PowerShell 7.4 .NET 8
4.x PowerShell 7.2 (supportavslut) .NET 6

Du kan se den aktuella versionen genom att skriva ut $PSVersionTable från valfri funktion.

Mer information om supportprinciper för Azure Functions-körning finns i den här artikeln

Kommentar

Stödet för PowerShell 7.2 i Azure Functions upphör den 8 november 2024. Du kan behöva lösa vissa icke-bakåtkompatibla ändringar när du uppgraderar powershell 7.2-funktionerna för att köras på PowerShell 7.4. Följ den här migreringsguiden för att uppgradera till PowerShell 7.4.

Köra lokalt på en viss version

När du kör PowerShell-funktionerna lokalt måste du lägga till inställningen "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4" i matrisen Values i local.setting.json-filen i projektroten. När du kör lokalt på PowerShell 7.4 ser din local.settings.json-fil ut som följande exempel:

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

Kommentar

I PowerShell Functions refererar värdet "~7" för FUNCTIONS_WORKER_RUNTIME_VERSION till "7.0.x". Vi uppgraderar inte PowerShell-funktionsappar automatiskt som har "~7" till "7.4". För PowerShell-funktionsappar framöver kräver vi att appar anger både den huvudversion och delversion som de vill rikta in sig på. Därför är det nödvändigt att nämna "7.4" om du vill rikta "7.4.x"

Ändra PowerShell-versionen

Ta hänsyn till dessa överväganden innan du migrerar powershell-funktionsappen till PowerShell 7.4:

  • Eftersom migreringen kan medföra icke-bakåtkompatibla ändringar i din app kan du läsa den här migreringsguiden innan du uppgraderar appen till PowerShell 7.4.

  • Kontrollera att funktionsappen körs på den senaste versionen av Functions-körningen i Azure, som är version 4.x. Mer information finns i Visa och uppdatera den aktuella körningsversionen.

Använd följande steg för att ändra den PowerShell-version som används av funktionsappen. Du kan göra detta antingen i Azure-portalen eller med hjälp av PowerShell.

  1. I Azure-portalen bläddrar du till din funktionsapp.

  2. Under Inställningar väljer du Konfiguration. Leta upp PowerShell-versionen på fliken Allmänna inställningar.

    bild

  3. Välj önskad PowerShell Core-version och välj Spara. När du varnas om den väntande omstarten väljer du Fortsätt. Funktionsappen startas om på den valda PowerShell-versionen.

Kommentar

Azure Functions-stöd för PowerShell 7.4 är allmänt tillgängligt (GA). PowerShell 7.4 visas kanske fortfarande som förhandsversion i Azure-portalen, men detta uppdateras snart för att återspegla ga-statusen.

Funktionsappen startas om när ändringen har gjorts i konfigurationen.

Beroendehantering

Med Functions kan du använda PowerShell-galleriet för att hantera beroenden. När beroendehantering är aktiverat används filen requirements.psd1 för att automatiskt ladda ned nödvändiga moduler. Du aktiverar det här beteendet genom att ange managedDependency egenskapen till true i roten för host.json-filen, som i följande exempel:

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

När du skapar ett nytt PowerShell-funktionsprojekt aktiveras beroendehantering som standard, med Azure-modulen Az inkluderad. Det maximala antalet moduler som stöds för närvarande är 10. Syntaxen som stöds är MajorNumber.* eller exakt modulversion, enligt följande krav.psd1-exempel:

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

När du uppdaterar filen requirements.psd1 installeras uppdaterade moduler efter en omstart.

Målspecifika versioner

Du kanske vill rikta in dig på en specifik version av en modul i filen requirements.psd1. Om du till exempel vill använda en äldre version av Az.Accounts än den i den inkluderade Az-modulen måste du rikta in dig på en specifik version enligt följande exempel:

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

I det här fallet måste du också lägga till en importinstruktion överst i filen profile.ps1, som ser ut som i följande exempel:

Import-Module Az.Accounts -RequiredVersion '1.9.5'

På så sätt läses den äldre versionen av Az.Account-modulen in först när funktionen startas.

Överväganden för beroendehantering

Följande överväganden gäller när du använder beroendehantering:

  • Hanterade beroenden kräver åtkomst till https://www.powershellgallery.com att ladda ned moduler. När du kör lokalt kontrollerar du att körningen kan komma åt den här URL:en genom att lägga till nödvändiga brandväggsregler.

  • Hanterade beroenden stöder för närvarande inte moduler som kräver att användaren accepterar en licens, antingen genom att acceptera licensen interaktivt eller genom att tillhandahålla -AcceptLicense växel när den anropar Install-Module.

  • Hanterade beroenden stöds inte när du är värd för din funktionsapp i en Flex Consumption-plan. Du måste i stället definiera dina egna anpassade moduler.

Appinställningar för beroendehantering

Följande programinställningar kan användas för att ändra hur hanterade beroenden laddas ned och installeras.

Inställning för funktionsapp Standardvärde beskrivning
MDMaxBackgroundUpgradePeriod 7.00:00:00 (sju dagar) Styr bakgrundsuppdateringsperioden för PowerShell-funktionsappar. Mer information finns i MDMaxBackgroundUpgradePeriod.
MDNewSnapshotCheckPeriod 01:00:00 (en timme) Anger hur ofta varje PowerShell-arbetare kontrollerar om hanterade beroendeuppgraderingar har installerats. Mer information finns i MDNewSnapshotCheckPeriod.
MDMinBackgroundUpgradePeriod 1.00:00:00 (en dag) Tidsperioden efter en tidigare uppgraderingskontroll innan en ny uppgraderingskontroll startas. Mer information finns i MDMinBackgroundUpgradePeriod.

I princip startar appuppgraderingen inom MDMaxBackgroundUpgradePeriod, och uppgraderingsprocessen slutförs inom ungefär MDNewSnapshotCheckPeriod.

Anpassade moduler

Att utnyttja dina egna anpassade moduler i Azure Functions skiljer sig från hur du skulle göra det normalt för PowerShell.

På den lokala datorn installeras modulen i en av de globalt tillgängliga mapparna i .$env:PSModulePath När du kör i Azure har du inte åtkomst till de moduler som är installerade på datorn. Det innebär att $env:PSModulePath för en PowerShell-funktionsapp skiljer sig från $env:PSModulePath i ett vanligt PowerShell-skript.

I Functions PSModulePath innehåller två sökvägar:

  • En Modules mapp som finns i roten för funktionsappen.
  • En sökväg till en Modules mapp som styrs av PowerShell-språkarbetaren.

Funktionsappnivåmodulmapp

Om du vill använda anpassade moduler kan du placera moduler som dina funktioner är beroende av i en Modules mapp. Från den här mappen är moduler automatiskt tillgängliga för funktionskörningen. Alla funktioner i funktionsappen kan använda dessa moduler.

Kommentar

Moduler som anges i filen requirements.psd1 laddas ned automatiskt och ingår i sökvägen så att du inte behöver inkludera dem i modulmappen. Dessa lagras lokalt i $env:LOCALAPPDATA/AzureFunctions mappen och i mappen när de /data/ManagedDependencies körs i molnet.

Om du vill dra nytta av funktionen för anpassad modul skapar du en Modules mapp i roten för funktionsappen. Kopiera de moduler som du vill använda i dina funktioner till den här platsen.

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

Med en Modules mapp bör funktionsappen ha följande mappstruktur:

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

När du startar funktionsappen lägger PowerShell-språkarbetaren till den $env:PSModulePath här Modules mappen så att du kan lita på att modulen läses in automatiskt på samma sätt som i ett vanligt PowerShell-skript.

Mappen Moduler på språkarbetsnivå

Flera moduler används ofta av PowerShell-språkarbetaren. Dessa moduler definieras i den sista positionen för PSModulePath.

Den aktuella listan över moduler är följande:

  • Microsoft.PowerShell.Archive: modul som används för att arbeta med arkiv, till exempel .zip, .nupkgoch andra.
  • ThreadJob: En trådbaserad implementering av PowerShell-jobb-API:erna.

Som standard använder Functions den senaste versionen av dessa moduler. Om du vill använda en specifik modulversion placerar du den specifika versionen i mappen för funktionsappen Modules .

Miljövariabler

I Functions exponeras appinställningar, till exempel tjänst niska veze, som miljövariabler under körningen. Du kan komma åt de här inställningarna med hjälp av $env:NAME_OF_ENV_VAR, som du ser i följande exempel:

param($myTimer)

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

Det finns flera sätt att lägga till, uppdatera och ta bort funktionsappinställningar:

Ändringar i funktionsappsinställningarna kräver att funktionsappen startas om.

När du kör lokalt läse appinställningarna från local.settings.json-projektfilen.

Samtidighet

Som standard kan Functions PowerShell-körningen endast bearbeta ett anrop av en funktion i taget. Den här samtidighetsnivån kanske dock inte räcker i följande situationer:

  • När du försöker hantera ett stort antal anrop samtidigt.
  • När du har funktioner som anropar andra funktioner i samma funktionsapp.

Det finns några samtidighetsmodeller som du kan utforska beroende på typen av arbetsbelastning:

  • Öka FUNCTIONS_WORKER_PROCESS_COUNT. Detta gör det möjligt att hantera funktionsanrop i flera processer i samma instans, vilket medför vissa processor- och minnesomkostnader. I allmänhet kommer I/O-bundna funktioner inte att drabbas av den här kostnaden. För CPU-bundna funktioner kan effekten vara betydande.

  • Öka appinställningsvärdet PSWorkerInProcConcurrencyUpperBound . På så sätt kan du skapa flera runspaces inom samma process, vilket avsevärt minskar processor- och minneskostnaderna.

Du anger dessa miljövariabler i appinställningarna för funktionsappen.

Beroende på ditt användningsfall kan Durable Functions avsevärt förbättra skalbarheten. Mer information finns i Durable Functions-programmönster.

Kommentar

Du kan få varningar om att "begäranden placeras i kö på grund av inga tillgängliga runspaces". Observera att detta inte är ett fel. Meddelandet talar om för dig att begäranden placeras i kö och att de kommer att hanteras när de tidigare begärandena har slutförts.

Överväganden för att använda samtidighet

PowerShell är ett single_threaded skriptspråk som standard. Samtidighet kan dock läggas till med hjälp av flera PowerShell-runspaces i samma process. Antalet skapade runspaces och därmed antalet samtidiga trådar per arbetare begränsas av programinställningen PSWorkerInProcConcurrencyUpperBound . Som standard är antalet runspaces inställt på 1 000 i version 4.x av Functions-körningen. I version 3.x och senare är det maximala antalet runspaces inställt på 1. Dataflödet påverkas av mängden processor och minne som är tillgängligt i den valda planen.

Azure PowerShell använder vissa kontexter och tillstånd på processnivå för att spara dig från överflödig typning. Men om du aktiverar samtidighet i funktionsappen och anropar åtgärder som ändrar tillstånd kan du få konkurrensvillkor. Dessa konkurrensförhållanden är svåra att felsöka eftersom ett anrop förlitar sig på ett visst tillstånd och det andra anropet ändrade tillståndet.

Det finns ett enormt värde i samtidighet med Azure PowerShell, eftersom vissa åtgärder kan ta lång tid. Du måste dock fortsätta med försiktighet. Om du misstänker att du har ett konkurrenstillstånd anger du appinställningen PSWorkerInProcConcurrencyUpperBound till 1 och använder i stället språkarbetarens processnivåisolering för samtidighet.

Konfigurera funktionsskriptFil

Som standard körs en PowerShell-funktion från run.ps1, en fil som delar samma överordnade katalog som motsvarande function.json.

Egenskapen scriptFile i function.json kan användas för att hämta en mappstruktur som ser ut som i följande exempel:

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

I det här fallet function.json innehåller for myFunction en scriptFile egenskap som refererar till filen med den exporterade funktionen som ska köras.

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

Använda PowerShell-moduler genom att konfigurera en entryPoint

Den här artikeln har visat PowerShell-funktioner i standardskriptfilen run.ps1 som genereras av mallarna. Du kan dock även inkludera dina funktioner i PowerShell-moduler. Du kan referera till din specifika funktionskod i modulen med hjälp av fälten scriptFile och entryPoint i konfigurationsfilen function.json.

I det här fallet entryPoint är namnet på en funktion eller cmdlet i PowerShell-modulen som refereras i scriptFile.

Överväg följande mappstruktur:

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

Var PSFunction.psm1 innehåller:

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

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

Export-ModuleMember -Function "Invoke-PSTestFunc"

I det här exemplet innehåller konfigurationen för myFunction en scriptFile egenskap som refererar till PSFunction.psm1, som är en PowerShell-modul i en annan mapp. Egenskapen entryPoint refererar till Invoke-PSTestFunc funktionen, som är startpunkten i modulen.

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

Med den här konfigurationen Invoke-PSTestFunc körs den exakt som en run.ps1 skulle.

Överväganden för PowerShell-funktioner

När du arbetar med PowerShell-funktioner bör du vara medveten om övervägandena i följande avsnitt.

Kall start

När du utvecklar Azure Functions i den serverlösa värdmodellen är kallstarter verklighet. Kallstart refererar till den tidsperiod det tar för funktionsappen att börja köras för att bearbeta en begäran. Kallstart sker oftare i förbrukningsplanen eftersom funktionsappen stängs av under perioder av inaktivitet.

Paketmoduler i stället för att använda Install-Module

Skriptet körs på varje anrop. Undvik att använda Install-Module i skriptet. Använd Save-Module i stället innan du publicerar så att funktionen inte behöver slösa tid på att ladda ned modulen. Om kallstarter påverkar dina funktioner kan du överväga att distribuera din funktionsapp till en App Service-plan som är inställd på alltid på eller till en Premium-plan.

Nästa steg

Mer information finns i följande resurser: