Delen 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. Er wordt ook van uitgegaan dat u de quickstart functions voor PowerShell hebt 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 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 meerdere argumenten doorgegeven 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. Deze 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 op verschillende manieren met bindingen.

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.

In het volgende voorbeeld 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 veel 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 wordt doorgegeven aan het script 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 voorbeeld:

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 het 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 deze bewerking uitvoeren 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

Het beheren van modules in Azure Functions die in PowerShell zijn geschreven, kan op twee manieren worden benaderd: met behulp van de functie Beheerde afhankelijkheden of het rechtstreeks opnemen van de modules in uw app-inhoud. Elke methode heeft zijn eigen voordelen en het kiezen van de juiste methode is afhankelijk van uw specifieke behoeften.

De juiste modulebeheerbenadering kiezen

Waarom de functie Beheerde afhankelijkheden gebruiken?

  • Vereenvoudigde initiële installatie: de installatie van de module wordt automatisch afgehandeld op basis van uw requirements.psd1 bestand.
  • Automatische upgrades: Modules worden automatisch bijgewerkt, inclusief beveiligingscorrecties, zonder handmatige tussenkomst.

Waarom modules opnemen in app-inhoud?

  • Geen afhankelijkheid van de PowerShell Gallery: Modules worden gebundeld met uw app, waardoor externe afhankelijkheden worden geëlimineerd.
  • Meer controle: vermijdt het risico op regressies die worden veroorzaakt door automatische upgrades, waardoor u volledige controle hebt over welke moduleversies worden gebruikt.
  • Compatibiliteit: Werkt op Flex-verbruik en wordt aanbevolen voor andere Linux-SKU's.

Functie Beheerde afhankelijkheden

Met de functie Beheerde afhankelijkheden kan Azure Functions Automatisch PowerShell-modules downloaden en beheren die zijn opgegeven in het requirements.psd1 bestand. Deze functie is standaard ingeschakeld in nieuwe PowerShell-functie-apps.

Vereisten configureren.psd1

Als u beheerde afhankelijkheden in Azure Functions wilt gebruiken met PowerShell, moet u een requirements.psd1 bestand configureren. Dit bestand specificeert de modules die uw functie nodig heeft, en Azure Functions downloadt en werkt deze modules automatisch bij om ervoor te zorgen dat uw omgeving up-to-date blijft.

U kunt het requirements.psd1 bestand als volgt instellen en configureren:

  1. Maak een requirements.psd1 bestand in de hoofdmap van uw Azure-functie als deze nog niet bestaat.
  2. Definieer de modules en de bijbehorende versies in een PowerShell-gegevensstructuur.

Voorbeeld van requirements.psd1-bestand:

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

Modules opnemen in app-inhoud

Voor meer controle over uw moduleversies en om afhankelijkheden van externe resources te voorkomen, kunt u modules rechtstreeks opnemen in de inhoud van uw functie-app.

Aangepaste modules opnemen:

  1. Maak een Modules map in de hoofdmap van uw functie-app.

    mkdir ./Modules

  2. Kopieer modules naar de Modules map met behulp van een van de volgende methoden:

    • Als modules al lokaal beschikbaar zijn:

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

    • Gebruiken Save-Module om op te halen uit de PowerShell Gallery:

      Save-Module -Name MyCustomModule -Path ./Modules

    • Met behulp Save-PSResource van de PSResourceGet module:

      Save-PSResource -Name MyCustomModule -Path ./Modules

Uw functie-app moet de volgende structuur 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.

Problemen met beheerde afhankelijkheden oplossen

Beheerde afhankelijkheden inschakelen

Als u beheerde afhankelijkheden wilt laten functioneren, moet de functie zijn ingeschakeld in host.json:

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

Doelspecifieke versies

Als u zich richt op specifieke moduleversies, is het belangrijk om beide van de volgende stappen uit te voeren om ervoor te zorgen dat de juiste moduleversie wordt geladen:

  1. Geef de moduleversie op in requirements.psd1:

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

  2. Voeg een importinstructie toe aan profile.ps1:

    Import-Module Az.Accounts -RequiredVersion '1.9.5'

Als u deze stappen uitvoert, wordt de opgegeven versie geladen wanneer uw functie wordt gestart.

Specifieke instellingen voor het interval voor beheerde afhankelijkheden configureren

U kunt configureren hoe beheerde afhankelijkheden worden gedownload en geïnstalleerd met behulp van de volgende app-instellingen:

Instelling Standaardwaarde Beschrijving
MDMaxBackgroundUpgradePeriod 7.00:00:00 (zeven dagen) Hiermee bepaalt u de periode van de achtergrondupdate voor PowerShell-functie-apps.
MDNewSnapshotCheckPeriod 01:00:00 (één uur) Hiermee geeft u op hoe vaak de PowerShell-werkrol controleert op updates.
MDMinBackgroundUpgradePeriod 1.00:00:00 (één dag) Minimale tijd tussen upgradecontroles.

Overwegingen voor afhankelijkheidsbeheer

  • Internettoegang: beheerde afhankelijkheden vereisen toegang om modules te https://www.powershellgallery.com downloaden. Zorg ervoor dat uw omgeving deze toegang toestaat, inclusief het wijzigen van firewall-/VNet-regels indien nodig.
  • Acceptatie van licenties: beheerde afhankelijkheden bieden geen ondersteuning voor modules waarvoor licentieacceptatie is vereist.
  • Flex Consumption Plan: de functie Beheerde afhankelijkheden wordt niet ondersteund in het Flex Consumption-abonnement. Gebruik in plaats daarvan aangepaste modules.
  • Modulelocaties: op uw lokale computer worden modules meestal geïnstalleerd in een van de wereldwijd beschikbare mappen in uw $env:PSModulePath. Wanneer u in Azure uitvoert, verschilt de $env:PSModulePath voor een PowerShell-functie-app van $env:PSModulePath een normaal PowerShell-script en bevat deze zowel de Modules map die is geüpload met de inhoud van uw app als een afzonderlijke locatie die wordt beheerd door beheerde afhankelijkheden.

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. Door deze instelling te verhogen, kunnen functie-aanroepen in meerdere processen binnen hetzelfde exemplaar worden verwerkt, 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. Als u deze instelling verhoogt, kunt u meerdere runspaces binnen hetzelfde proces maken, 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 van uw functie-app 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

PowerShell-functies in dit artikel worden weergegeven met het standaardscriptbestand run.ps1 dat door de sjablonen wordt gegenereerd. 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.

Vermijd het gebruik van Install-Module

Het uitvoeren Install-Module in uw functiescript bij elke aanroep kan prestatieproblemen veroorzaken. Gebruik in plaats daarvan Save-Module of Save-PSResource voordat u uw functie-app publiceert om de benodigde modules te bundelen.

Zie de sectie Afhankelijkheidsbeheer voor meer informatie.

Volgende stappen

Voor meer informatie raadpleegt u de volgende bronnen: