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. Det förutsätter också att du har 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 .

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 Portal 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 flera 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. Dessa 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 .

I följande exempel visas 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 många utlösare och bindningar som du kan använda med funktionsappen. 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, som du ser i följande exempel:

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 utföra den här åtgärden antingen i Azure Portal 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 Portal, men detta uppdateras snart för att återspegla ga-statusen.

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

Beroendehantering

Du kan hantera moduler i Azure Functions som skrivits i PowerShell på två sätt: använda funktionen Hanterade beroenden eller inkludera modulerna direkt i appinnehållet. Varje metod har sina egna fördelar, och att välja rätt är beroende av dina specifika behov.

Välja rätt metod för modulhantering

Varför ska du använda funktionen Hanterade beroenden?

  • Förenklad inledande installation: Hanterar modulinstallation automatiskt baserat på din requirements.psd1 fil.
  • Automatiska uppgraderingar: Moduler uppdateras automatiskt, inklusive säkerhetskorrigeringar, utan att manuella åtgärder krävs.

Varför inkludera moduler i appinnehåll?

  • Inget beroende av PowerShell-galleriet: Moduler paketeras med din app, vilket eliminerar externa beroenden.
  • Mer kontroll: Undviker risken för regressioner som orsakas av automatiska uppgraderingar, vilket ger dig fullständig kontroll över vilka modulversioner som används.
  • Kompatibilitet: Fungerar med Flex-förbrukning och rekommenderas för andra Linux-SKU:er.

Funktionen Hanterade beroenden

Med funktionen Hanterade beroenden kan Azure Functions automatiskt ladda ned och hantera PowerShell-moduler som anges i requirements.psd1 filen. Den här funktionen är aktiverad som standard i nya PowerShell-funktionsappar.

Konfigurera requirements.psd1

Om du vill använda hanterade beroenden i Azure Functions med PowerShell måste du konfigurera en requirements.psd1 fil. Den här filen anger de moduler som din funktion kräver, och Azure Functions laddar automatiskt ned och uppdaterar dessa moduler för att säkerställa att din miljö är uppdaterad.

Så här konfigurerar du requirements.psd1 filen:

  1. Skapa en requirements.psd1 fil i rotkatalogen för din Azure-funktion om det inte redan finns någon.
  2. Definiera modulerna och deras versioner i en PowerShell-datastruktur.

requirements.psd1-exempelfil:

@{
    'Az' = '9.*'  # Specifies the Az module and will use the latest version with major version 9
}

Inkludera moduler i appinnehåll

Om du vill ha mer kontroll över dina modulversioner och för att undvika beroenden av externa resurser kan du inkludera moduler direkt i funktionsappens innehåll.

Så här inkluderar du anpassade moduler:

  1. Skapa en Modules mapp i roten för funktionsappen.

    mkdir ./Modules

  2. Kopiera moduler till Modules mappen med någon av följande metoder:

    • Om moduler redan är tillgängliga lokalt:

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

    • Använda Save-Module för att hämta från PowerShell-galleriet:

      Save-Module -Name MyCustomModule -Path ./Modules

    • Använda Save-PSResource från modulenPSResourceGet:

      Save-PSResource -Name MyCustomModule -Path ./Modules

Funktionsappen bör ha följande struktur:

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.

Felsöka hanterade beroenden

Aktivera hanterade beroenden

För att hanterade beroenden ska fungera måste funktionen vara aktiverad i host.json:

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

Målspecifika versioner

När du riktar in dig på specifika modulversioner är det viktigt att följa båda följande steg för att säkerställa att rätt modulversion läses in:

  1. Ange modulversionen i requirements.psd1:

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

  2. Lägg till en import-instruktion i profile.ps1:

    Import-Module Az.Accounts -RequiredVersion '1.9.5'

Genom att följa dessa steg ser du till att den angivna versionen läses in när funktionen startas.

Konfigurera specifika inställningar för hanterat beroendeintervall

Du kan konfigurera hur hanterade beroenden laddas ned och installeras med hjälp av följande appinställningar:

Inställning Standardvärde beskrivning
MDMaxBackgroundUpgradePeriod 7.00:00:00 (sju dagar) Styr bakgrundsuppdateringsperioden för PowerShell-funktionsappar.
MDNewSnapshotCheckPeriod 01:00:00 (en timme) Anger hur ofta PowerShell-arbetaren söker efter uppdateringar.
MDMinBackgroundUpgradePeriod 1.00:00:00 (en dag) Minsta tid mellan uppgraderingskontroller.

Överväganden för beroendehantering

  • Internetåtkomst: Hanterade beroenden kräver åtkomst till https://www.powershellgallery.com att ladda ned moduler. Se till att din miljö tillåter den här åtkomsten, inklusive att ändra brandväggs-/VNet-regler efter behov.
  • Licensgodkännande: Hanterade beroenden stöder inte moduler som kräver godkännande av licenser.
  • Flex Consumption Plan: Funktionen Hanterade beroenden stöds inte i Flex Consumption-planen. Använd anpassade moduler i stället.
  • Modulplatser: På den lokala datorn installeras moduler vanligtvis i en av de globalt tillgängliga mapparna i .$env:PSModulePath När du kör i Azure $env:PSModulePath skiljer sig för en PowerShell-funktionsapp från $env:PSModulePath i ett vanligt PowerShell-skript och innehåller både mappen Modules som laddas upp med ditt appinnehåll och en separat plats som hanteras av hanterade beroenden.

Miljövariabler

I Functions exponeras appinställningar, till exempel tjänst anslutningssträng, 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. Om du ökar den här inställningen kan du hantera funktionsanrop i flera processer i samma instans, vilket medför vissa processor- och minnesomkostnader. I allmänhet drabbas inte I/O-bundna funktioner av den här kostnaden. För CPU-bundna funktioner kan effekten vara betydande.

  • Öka appinställningsvärdet PSWorkerInProcConcurrencyUpperBound . Om du ökar den här inställningen 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 för din funktionsapp 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

PowerShell-funktioner i den här artikeln visas med 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.

Undvik att använda Install-Module

Om du kör Install-Module i funktionsskriptet för varje anrop kan det orsaka prestandaproblem. Använd Save-Module i stället eller Save-PSResource innan du publicerar funktionsappen för att paketera nödvändiga moduler.

Mer information finns i avsnittet Beroendehantering .

Nästa steg

Mer information finns i följande resurser: