Azure Functions – Příručka pro vývojáře v PowerShellu

Tento článek obsahuje podrobnosti o tom, jak psát Azure Functions pomocí PowerShellu.

Funkce Azure PowerShellu (funkce) je reprezentovaná jako skript PowerShellu, který se spustí při aktivaci. Každý skript funkce má související function.json soubor, který definuje, jak se funkce chová, například jak se aktivuje, a její vstupní a výstupní parametry. Další informace najdete v článku o triggerech a vazbách.

Stejně jako jiné druhy funkcí přebírají funkce skriptů PowerShellu parametry, které odpovídají názvům všech vstupních vazeb definovaných v function.json souboru. Předá TriggerMetadata se také parametr, který obsahuje další informace o triggeru, který funkci spustil.

Tento článek předpokládá, že už jste si přečetli referenční informace pro vývojáře azure Functions. Předpokládá se také, že jste dokončili rychlý start functions pro PowerShell a vytvořili první funkci PowerShellu.

Struktura složek

Požadovaná struktura složek pro projekt PowerShellu vypadá takto: Toto výchozí nastavení je možné změnit. Další informace najdete v části 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

V kořenovém adresáři projektu je sdílený host.json soubor, který se dá použít ke konfiguraci aplikace funkcí. Každá funkce má složku s vlastním souborem kódu (.ps1) a konfiguračním souborem vazby (function.json). Název nadřazeného adresáře function.json souboru je vždy název vaší funkce.

Některé vazby vyžadují přítomnost extensions.csproj souboru. Rozšíření vazeb požadovaná ve verzi 2.x a novějších verzích modulu runtime Functions jsou definována v extensions.csproj souboru se skutečnými soubory knihovny ve bin složce. Při místním vývoji musíte zaregistrovat rozšíření vazeb. Při vývoji funkcí na webu Azure Portal se tato registrace provádí za vás.

V aplikacích funkcí PowerShellu můžete volitelně mít profile.ps1 , který se spustí, když se aplikace funkcí spustí (jinak se označuje jako studený start). Další informace najdete v profilu PowerShellu.

Definování skriptu PowerShellu jako funkce

Modul runtime služby Functions ve výchozím nastavení hledá vaši funkci v umístění , kde run.ps1run.ps1 sdílí stejný nadřazený adresář jako odpovídající function.json.

Skript se předává několik argumentů při spuštění. Pokud chcete tyto parametry zpracovat, přidejte param do horní části skriptu blok, jak je znázorněno v následujícím příkladu:

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

Parametr TriggerMetadata

Parametr TriggerMetadata slouží k zadání dalších informací o triggeru. Tato metadata se liší od vazby na vazbu, ale všechny obsahují sys vlastnost, která obsahuje následující data:

$TriggerMetadata.sys

Vlastnost	Popis	Typ
UtcNow	Kdy se ve standardu UTC aktivovala funkce	DateTime
MethodName	Název funkce, která se aktivovala	string
RandGuid	jedinečný identifikátor GUID pro toto spuštění funkce	string

Každý typ triggeru má jinou sadu metadat. Například for $TriggerMetadataQueueTrigger obsahuje InsertionTime, IdDequeueCount, mimo jiné. Další informace o metadatech triggeru fronty najdete v oficiální dokumentaci k aktivačním událostem fronty. Podívejte se do dokumentace k triggerům , se kterými pracujete, a podívejte se, co se nachází v metadatech triggeru.

Vazby

V PowerShellu jsou vazby nakonfigurované a definované v function.json funkce. Funkce interagují s vazbami mnoha způsoby.

Čtení aktivačních událostí a vstupních dat

Aktivační události a vstupní vazby se čtou jako parametry předané vaší funkci. Vstupní vazby mají v function.json nastavenou direction hodnotu in . Vlastnost name definovaná v function.json je název parametru param v bloku. Vzhledem k tomu, že PowerShell používá pro vazbu pojmenované parametry, nezáleží na pořadí parametrů. Osvědčeným postupem je však dodržovat pořadí vazeb definovaných v objektu function.json.

param($MyFirstInputBinding, $MySecondInputBinding)

Zápis výstupních dat

Ve službě Functions má výstupní vazba nastavenou direction hodnotu out v function.json. K zápisu do výstupní vazby můžete použít rutinu Push-OutputBinding , která je k dispozici modulu runtime služby Functions. Ve všech případech name vlastnost vazby, jak je definována, function.json odpovídá Name parametru rutiny Push-OutputBinding .

Následující příklad ukazuje, jak volat Push-OutputBinding ve skriptu funkce:

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

Prostřednictvím kanálu můžete také předat hodnotu pro určitou vazbu.

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Push-OutputBinding chová se odlišně na základě hodnoty zadané pro -Name:

• Pokud zadaný název nelze přeložit na platnou výstupní vazbu, vyvolá se chyba.

• Když výstupní vazba přijme kolekci hodnot, můžete volat Push-OutputBinding opakovaně, aby se nasdílel více hodnot.

• Pokud výstupní vazba přijímá pouze jednu hodnotu, vyvolá volání Push-OutputBinding druhé chyby.

Syntaxe push-outputbinding

Následující parametry jsou platné pro volání Push-OutputBinding:

Name	Type	Position	Popis
-Name	String	0	Název výstupní vazby, kterou chcete nastavit.
-Value	Objekt	2	Hodnota výstupní vazby, kterou chcete nastavit, která je přijata z kanálu ByValue.
-Clobber	SwitchParameter	Pojmenovaný	(Volitelné) Při zadání vynutí nastavení hodnoty pro zadanou výstupní vazbu.

Podporují se také následující běžné parametry:

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

Další informace naleznete v tématu o CommonParameters.

Příklad push-outputBinding: Odpovědi HTTP

Trigger HTTP vrátí odpověď pomocí výstupní vazby s názvem response. V následujícím příkladu má výstupní vazba response hodnotu "output #1":

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

Vzhledem k tomu, že výstup je do protokolu HTTP, který přijímá pouze jednu hodnotu, vyvolá se při druhém zavolání chyby Push-OutputBinding .

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

Pro výstupy, které přijímají pouze hodnoty singleton, můžete použít -Clobber parametr k přepsání staré hodnoty místo pokusu o přidání do kolekce. Následující příklad předpokládá, že jste již přidali hodnotu. Když použijete -Clobberodpověď z následujícího příkladu, přepíše existující hodnotu tak, aby vrátila hodnotu "output #3":

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

Příklad Push-OutputBinding: Výstupní vazba fronty

Push-OutputBinding slouží k odesílání dat do výstupních vazeb, jako je výstupní vazba azure Queue Storage. V následujícím příkladu má zpráva zapsaná do fronty hodnotu "output #1":

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

Výstupní vazba fronty služby Storage přijímá více výstupních hodnot. V tomto případě volání následujícího příkladu po prvním zápisu do fronty seznam se dvěma položkami: "output #1" a "output #2".

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

Následující příklad, když je volána za předchozími dvěma, přidá do výstupní kolekce dvě další hodnoty:

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

Při zápisu do fronty zpráva obsahuje tyto čtyři hodnoty: "output #1", "output #2", "output #3" a "output #4".

Rutina Get-OutputBinding

Pomocí rutiny Get-OutputBinding můžete načíst hodnoty aktuálně nastavené pro výstupní vazby. Tato rutina načte hashtable, která obsahuje názvy výstupních vazeb s příslušnými hodnotami.

Následuje příklad použití Get-OutputBinding k vrácení aktuálních hodnot vazby:

Get-OutputBinding

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

Get-OutputBinding obsahuje také parametr s názvem -Name, který lze použít k filtrování vrácené vazby, jako v následujícím příkladu:

Get-OutputBinding -Name MyQ*

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

Zástupné cardy (*) jsou podporovány v Get-OutputBinding.

Protokolování

Protokolování ve funkcích PowerShellu funguje jako běžné protokolování PowerShellu. Pomocí rutin protokolování můžete zapisovat do každého výstupního datového proudu. Každá rutina se mapuje na úroveň protokolu používanou funkcí.

Úroveň protokolování funkcí	Rutina protokolování
Chyba	Write-Error
Upozorňující	Write-Warning
Informační	Write-Information Write-Host Write-Output Zapisuje se na Information úroveň protokolu.
Ladění	Write-Debug
Trasování	Write-Progress Write-Verbose

Kromě těchto rutin se všechno zapsané do kanálu přesměruje na Information úroveň protokolu a zobrazí se s výchozím formátováním PowerShellu.

Důležité

Použití rutin Write-Verbose nebo Write-Debug rutin nestačí k zobrazení podrobného protokolování a protokolování na úrovni ladění. Musíte také nakonfigurovat prahovou hodnotu na úrovni protokolu, která deklaruje, jakou úroveň protokolů skutečně zajímáte. Další informace najdete v tématu Konfigurace úrovně protokolu aplikace funkcí.

Konfigurace úrovně protokolu aplikace funkcí

Azure Functions umožňuje definovat prahovou úroveň, která usnadňuje řízení způsobu, jakým functions zapisuje do protokolů. Pokud chcete nastavit prahovou hodnotu pro všechny trasování zapsané do konzoly, použijte logging.logLevel.default vlastnost v host.json souboru. Toto nastavení platí pro všechny funkce ve vaší aplikaci funkcí.

Následující příklad nastaví prahovou hodnotu pro povolení podrobného protokolování pro všechny funkce, ale nastaví prahovou hodnotu pro povolení protokolování ladění pro funkci s názvem MyFunction:

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

Další informace najdete v host.json referenčních informacích.

Zobrazení protokolů

Pokud je vaše aplikace funkcí spuštěná v Azure, můžete ji monitorovat pomocí Application Insights. Další informace o zobrazení a dotazování protokolů funkcí najdete v monitorování služby Azure Functions .

Pokud používáte aplikaci Funkcí místně pro vývoj, protokoluje se výchozí nastavení systému souborů. Pokud chcete zobrazit protokoly v konzole, nastavte proměnnou AZURE_FUNCTIONS_ENVIRONMENT prostředí na Development před spuštěním aplikace funkcí.

Typy triggerů a vazeb

Pro použití s vaší aplikací funkcí je k dispozici mnoho triggerů a vazeb. Úplný seznam triggerů a vazeb najdete tady.

Všechny triggery a vazby jsou v kódu reprezentovány jako několik skutečných datových typů:

• Hashtable
• string
• byte[]
• int
• double
• HttpRequestContext
• HttpResponseContext

Prvních pět typů v tomto seznamu je standardních typů .NET. Poslední dva jsou používány pouze triggerem HttpTrigger.

Každý parametr vazby ve vašich funkcích musí být jedním z těchto typů.

Triggery a vazby HTTP

Triggery HTTP a webhooky a výstupní vazby HTTP používají objekty požadavků a odpovědí k reprezentaci zasílání zpráv HTTP.

Objekt požadavku

Objekt požadavku předaný do skriptu je typu HttpRequestContext, který má následující vlastnosti:

Vlastnost	Popis	Typ
Body	Objekt, který obsahuje text požadavku. Body je serializován do nejlepšího typu na základě dat. Pokud jsou například data JSON, předávají se jako hashovací tabulka. Pokud jsou data řetězcem, předají se jako řetězec.	objekt
Headers	Slovník, který obsahuje hlavičky požadavku.	Řetězec slovníku<, řetězec>*
Method	Metoda HTTP požadavku.	string
Params	Objekt, který obsahuje parametry směrování požadavku.	Řetězec slovníku<, řetězec>*
Query	Objekt, který obsahuje parametry dotazu.	Řetězec slovníku<, řetězec>*
Url	Adresa URL požadavku.	string

^* Všechny Dictionary<string,string> klíče nerozlišují malá a velká písmena.

Objekt odpovědi

Objekt odpovědi, který byste měli odeslat zpět, je typu HttpResponseContext, který má následující vlastnosti:

Vlastnost	Popis	Typ
Body	Objekt, který obsahuje text odpovědi.	objekt
ContentType	Krátká ruka pro nastavení typu obsahu pro odpověď.	string
Headers	Objekt, který obsahuje hlavičky odpovědi.	Slovník nebo hashtable
StatusCode	Stavový kód HTTP odpovědi.	řetězec nebo int

Přístup k požadavku a odpovědi

Při práci s triggery HTTP můžete k požadavku HTTP přistupovat stejným způsobem jako u jakékoli jiné vstupní vazby. Je v param bloku.

K vrácení odpovědi použijte HttpResponseContext objekt, jak je znázorněno v následujícím příkladu:

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

Výsledkem vyvolání této funkce by bylo:

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

Přetypování typů pro triggery a vazby

U určitých vazeb, jako je vazba objektu blob, můžete zadat typ parametru.

Pokud například chcete mít data ze služby Blob Storage zadaná jako řetězec, přidejte do bloku param následující typ přetypování:

param([string] $myBlob)

Profil PowerShellu

V PowerShellu je koncept profilu PowerShellu. Pokud neznáte profily PowerShellu, přečtěte si informace o profilech.

Ve funkcích PowerShellu se skript profilu spustí jednou pro instanci pracovního procesu PowerShellu v aplikaci při prvním nasazení a po idizování (studené spuštění). Pokud je povolena souběžnost nastavením hodnoty PSWorkerInProcConcurrencyUpperBound , skript profilu se spustí pro každý vytvořený runspace.

Když vytvoříte aplikaci funkcí pomocí nástrojů, jako je Visual Studio Code a Azure Functions Core Tools, vytvoří se vám výchozí nastavení profile.ps1 . Výchozí profil se udržuje v úložišti GitHub Core Tools a obsahuje:

• Automatické ověřování MSI do Azure.
• Možnost zapnout aliasy PowerShellu v Azure PowerShellu AzureRM , pokud chcete.

Verze PowerShellu

Následující tabulka uvádí verze PowerShellu dostupné pro každou hlavní verzi modulu runtime Functions a požadovanou verzi .NET:

Verze služby Functions	Verze Powershellu	Verze .NET
4.x	PowerShell 7.4	.NET 8
4.x	PowerShell 7.2 (konec podpory)	.NET 6

Aktuální verzi můžete zobrazit tiskem $PSVersionTable z libovolné funkce.

Další informace o zásadách podpory modulu runtime Azure Functions najdete v tomto článku.

Poznámka:

Podpora PowerShellu 7.2 ve službě Azure Functions končí 8. listopadu 2024. Při upgradu funkcí PowerShellu 7.2 na spuštění v PowerShellu 7.4 možná budete muset vyřešit některé zásadní změny. Postupujte podle tohoto průvodce migrací a upgradujte na PowerShell 7.4.

Spuštění místního prostředí v konkrétní verzi

Při místním spouštění funkcí PowerShellu je potřeba do pole v souboru local.setting.json v kořenovém adresáři projektu přidat nastavení "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4"Values . Při místním spuštění v PowerShellu 7.4 vypadá váš local.settings.json soubor jako v následujícím příkladu:

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

Poznámka:

Ve funkcích PowerShellu se hodnota ~7 pro FUNCTIONS_WORKER_RUNTIME_VERSION označuje jako 7.0.x. Neupgradujeme automaticky aplikace funkcí PowerShellu, které mají hodnotu ~7 na 7.4. V případě aplikací funkcí PowerShellu budeme vyžadovat, aby aplikace zadaly hlavní i podverzi, na kterou chtějí cílit. Proto je nutné zmínit "7,4", pokud chcete cílit na "7.4.x".

Změna verze PowerShellu

Před migrací aplikace funkcí PowerShellu do PowerShellu 7.4 vezměte v úvahu tyto aspekty:

• Vzhledem k tomu, že migrace může ve vaší aplikaci zavést zásadní změny, přečtěte si tuto příručku k migraci před upgradem aplikace na PowerShell 7.4.

• Ujistěte se, že vaše aplikace funkcí běží na nejnovější verzi modulu runtime Functions v Azure, což je verze 4.x. Další informace naleznete v tématu Zobrazení a aktualizace aktuální verze modulu runtime.

Pomocí následujících kroků můžete změnit verzi PowerShellu používanou vaší aplikací funkcí. Tuto operaci můžete provést buď na webu Azure Portal, nebo pomocí PowerShellu.

Azure Portal

1. Na webu Azure Portal přejděte do aplikace funkcí.

2. V části Nastavení zvolte Konfigurace. Na kartě Obecné nastavení vyhledejte verzi PowerShellu.

   

3. Zvolte požadovanou verzi PowerShellu Core a vyberte Uložit. Když se zobrazí upozornění na čekající restartování, zvolte Pokračovat. Aplikace funkcí se restartuje ve zvolené verzi PowerShellu.

Poznámka:

Podpora Azure Functions pro PowerShell 7.4 je obecně dostupná (GA). PowerShell 7.4 se na webu Azure Portal může stále zobrazovat ve verzi Preview, ale brzy se aktualizuje tak, aby odrážel stav ga.

PowerShell

Spuštěním následujícího skriptu změňte verzi PowerShellu:

Set-AzResource -ResourceId "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<FUNCTION_APP>/config/web" -Properties @{  powerShellVersion  = '<VERSION>' } -Force -UsePatchSemantics

Nahraďte <SUBSCRIPTION_ID>a <RESOURCE_GROUP><FUNCTION_APP> id vašeho předplatného Azure, názvem vaší skupiny prostředků a aplikace funkcí. Nahraďte <VERSION> také .7.4 Můžete ověřit aktualizovanou hodnotu powerShellVersion nastavení v Properties vrácené tabulce hash.

Aplikace funkcí se restartuje po provedení změny konfigurace.

Správa závislostí

Správa modulů ve službě Azure Functions napsaná v PowerShellu se dá přistupovat dvěma způsoby: pomocí funkce Spravované závislosti nebo zahrnutím modulů přímo do obsahu aplikace. Každá metoda má své vlastní výhody a výběr správné metody závisí na vašich konkrétních potřebách.

Volba správného přístupu ke správě modulů

Proč používat funkci Spravované závislosti?

• Zjednodušená počáteční instalace: Automaticky zpracovává instalaci modulu na základě vašeho requirements.psd1 souboru.
• Automatické upgrady: Moduly se aktualizují automaticky, včetně oprav zabezpečení, aniž by bylo nutné provést ruční zásah.

Proč zahrnout moduly do obsahu aplikace?

• Žádná závislost na Galerie prostředí PowerShell: Moduly jsou součástí vaší aplikace a eliminují externí závislosti.
• Větší kontrola: Zabraňuje riziku regresí způsobených automatickými upgrady a poskytuje úplnou kontrolu nad tím, které verze modulů se používají.
• Kompatibilita: Funguje na Flex Consumption a doporučuje se pro ostatní skladové položky Linuxu.

Funkce spravovaných závislostí

Funkce Spravované závislosti umožňuje službě Azure Functions automaticky stahovat a spravovat moduly PowerShellu requirements.psd1 zadané v souboru. Tato funkce je ve výchozím nastavení povolená v nových aplikacích funkcí PowerShellu.

Konfigurace requirements.psd1

Pokud chcete používat spravované závislosti ve službě Azure Functions s PowerShellem, musíte nakonfigurovat requirements.psd1 soubor. Tento soubor určuje moduly, které vaše funkce vyžaduje, a Azure Functions tyto moduly automaticky stáhne a aktualizuje, aby vaše prostředí zůstalo aktuální.

Tady je postup nastavení a konfigurace requirements.psd1 souboru:

1. Pokud ještě neexistuje, vytvořte requirements.psd1 soubor v kořenovém adresáři funkce Azure Functions.
2. Definujte moduly a jejich verze ve struktuře dat PowerShellu.

Příklad souboru requirements.psd1:

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

Zahrnutí modulů do obsahu aplikace

Pokud chcete mít větší kontrolu nad verzemi modulů a vyhnout se závislostem na externích prostředcích, můžete zahrnout moduly přímo do obsahu aplikace funkcí.

Zahrnutí vlastních modulů:

1. Vytvořte Modules složku v kořenovém adresáři aplikace funkcí.

   mkdir ./Modules
   

2. Zkopírujte moduly do Modules složky pomocí jedné z následujících metod:

   • Pokud už jsou moduly dostupné místně:

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

   • Použití Save-Module k načtení z Galerie prostředí PowerShell:

     Save-Module -Name MyCustomModule -Path ./Modules
     

   • Použití Save-PSResource z PSResourceGet modulu:

     Save-PSResource -Name MyCustomModule -Path ./Modules
     

Aplikace funkcí by měla mít následující strukturu:

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

Když spustíte aplikaci funkcí, pracovní proces jazyka PowerShell tuto Modules složku přidá do $env:PSModulePath této složky, abyste se mohli spolehnout na automatické načítání modulů stejně jako v běžném skriptu PowerShellu.

Poznámka:

Pokud je vaše aplikace funkcí ve správě zdrojového kódu, měli byste potvrdit, že veškerý obsah ve složce Modules, kterou přidáte, není vyloučen .gitignore. Pokud například jeden z modulů obsahuje složku přihrádky, která je vyloučená, budete chtít soubor .gitignore upravit nahrazením bin

**/bin/**
!Modules/**

Řešení potíží se spravovanými závislostmi

Povolení spravovaných závislostí

Aby spravované závislosti fungovaly, musí být tato funkce povolená v host.json:

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

Cílení na konkrétní verze

Při cílení na konkrétní verze modulů je důležité postupovat podle obou následujících kroků, abyste měli jistotu, že se načte správná verze modulu:

1. Zadejte verzi modulu v requirements.psd1:

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

2. Přidejte příkaz importu do profile.ps1:

   Import-Module Az.Accounts -RequiredVersion '1.9.5'
   

Následujícím postupem zajistíte, že se při spuštění funkce načte zadaná verze.

Konfigurace konkrétního nastavení intervalu spravované závislosti

Způsob stahování a instalace spravovaných závislostí můžete nakonfigurovat pomocí následujících nastavení aplikace:

Nastavení	Výchozí hodnota	Popis
MDMaxBackgroundUpgradePeriod	7.00:00:00 (sedm dní)	Řídí období aktualizace na pozadí pro aplikace funkcí PowerShellu.
MDNewSnapshotCheckPeriod	01:00:00 (jedna hodina)	Určuje, jak často pracovní proces PowerShellu kontroluje aktualizace.
MDMinBackgroundUpgradePeriod	1.00:00:00 (jeden den)	Minimální doba mezi kontrolami upgradu

Důležité informace o správě závislostí

• Přístup k internetu: Spravované závislosti vyžadují přístup ke https://www.powershellgallery.com stahování modulů. Ujistěte se, že vaše prostředí umožňuje tento přístup, včetně úprav pravidel brány firewall nebo virtuální sítě podle potřeby.
• Přijetí licence: Spravované závislosti nepodporují moduly, které vyžadují přijetí licence.
• Plán Flex Consumption: Funkce Spravovaných závislostí není v plánu Flex Consumption podporovaná. Místo toho použijte vlastní moduly.
• Umístění modulů: Na místním počítači se moduly obvykle instalují do jedné z globálně dostupných složek ve vašem $env:PSModulePathpočítači . Při spuštění v Azure $env:PSModulePath se aplikace funkcí PowerShellu liší od $env:PSModulePath běžného skriptu PowerShellu a bude obsahovat Modules složku nahranou s obsahem aplikace a samostatné umístění spravované spravovanými závislostmi.

Proměnné prostředí

Ve službě Functions se nastavení aplikace, jako jsou připojovací řetězec služby, zobrazují během provádění jako proměnné prostředí. K těmto nastavením se dostanete pomocí příkazu $env:NAME_OF_ENV_VAR, jak je znázorněno v následujícím příkladu:

param($myTimer)

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

Nastavení aplikace funkcí můžete přidat, aktualizovat a odstranit několika způsoby:

• Na webu Azure Portal.
• Pomocí Azure CLI.
• Pomocí Azure PowerShellu.

Změny nastavení aplikace funkcí vyžadují restartování aplikace funkcí.

Při místním spuštění se nastavení aplikace načítá ze souboru projektu local.settings.json .

Souběžnost

Modul runtime PowerShellu functions ve výchozím nastavení může zpracovat pouze jedno vyvolání funkce najednou. Tato úroveň souběžnosti ale nemusí být v následujících situacích dostačující:

• Při pokusu o zpracování velkého počtu vyvolání najednou.
• Pokud máte funkce, které volají další funkce ve stejné aplikaci funkcí.

V závislosti na typu úlohy můžete prozkoumat několik modelů souběžnosti:

• Zvýšit FUNCTIONS_WORKER_PROCESS_COUNT. Zvýšení tohoto nastavení umožňuje zpracování volání funkcí v několika procesech ve stejné instanci, což přináší určité režijní náklady na procesor a paměť. Obecně platí, že vstupně-výstupní funkce netrpí touto režií. U funkcí vázaných na procesor může být dopad významný.

• PSWorkerInProcConcurrencyUpperBound Zvyšte hodnotu nastavení aplikace. Zvýšení tohoto nastavení umožňuje vytvořit více prostředí runspace ve stejném procesu, což výrazně snižuje režii procesoru a paměti.

Tyto proměnné prostředí nastavíte v nastavení aplikace vaší aplikace funkcí.

V závislosti na vašem případu použití může Durable Functions výrazně zlepšit škálovatelnost. Další informace najdete v tématu Vzory aplikací Durable Functions.

Poznámka:

Může se zobrazit upozornění ,že se požadavky zařadí do fronty kvůli žádným dostupným prostředím runspaces", upozorňujeme, že se nejedná o chybu. Zpráva vám říká, že se požadavky zařadí do fronty a po dokončení předchozích požadavků se budou zpracovávat.

Důležité informace o používání souběžnosti

PowerShell je ve výchozím nastavení single_threaded skriptovací jazyk. Souběžnost se ale dá přidat pomocí několika prostředí Runspace v PowerShellu ve stejném procesu. Počet vytvořených prostředí runspace a počet souběžných vláken na pracovní proces je omezen PSWorkerInProcConcurrencyUpperBound nastavením aplikace. Ve výchozím nastavení je počet runspaces nastavený na 1 000 ve verzi 4.x modulu runtime Služby Functions. Ve verzích 3.x a níže je maximální počet runspaces nastaven na hodnotu 1. Propustnost aplikace funkcí má vliv na množství procesoru a paměti dostupné ve vybraném plánu.

Azure PowerShell používá některé kontexty a stav na úrovni procesu, které vám pomůžou ušetřit před nadbytečným psaním. Pokud ale ve své aplikaci funkcí zapnete souběžnost a vyvoláte akce, které změní stav, můžete skončit s podmínkami časování. Tyto podmínky časování jsou obtížné ladit, protože jedno vyvolání závisí na určitém stavu a druhé vyvolání změnilo stav.

Existuje obrovská hodnota souběžnosti s Azure PowerShellem, protože některé operace můžou nějakou dobu trvat. Musíte však pokračovat s opatrností. Pokud máte podezření, že dochází k konfliktu časování, nastavte nastavení aplikace PSWorkerInProcConcurrencyUpperBound na 1úroveň procesu jazyka pro souběžnost.

Konfigurace souboru scriptFile funkce

Ve výchozím nastavení se spustí funkce PowerShellu ze run.ps1souboru, který sdílí stejný nadřazený adresář jako odpovídající function.json.

Vlastnost scriptFile v objektu function.json lze použít k získání struktury složek, která vypadá jako v následujícím příkladu:

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

V tomto případě obsahuje scriptFile vlastnost odkazující function.jsonmyFunction na soubor s exportovanou funkcí, která se má spustit.

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

Konfigurace vstupního bodu pomocí modulů PowerShellu

Funkce PowerShellu v tomto článku se zobrazují s výchozím run.ps1 souborem skriptu vygenerovaným šablonami. Funkce ale můžete zahrnout i do modulů PowerShellu. Na konkrétní kód funkce v modulu můžete odkazovat pomocí scriptFile polí entryPoint v konfiguračním souboru function.json.

V tomto případě entryPoint je název funkce nebo rutiny v modulu PowerShellu, na který scriptFileodkazuje .

Zvažte následující strukturu složek:

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

Kde PSFunction.psm1 obsahuje:

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

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

Export-ModuleMember -Function "Invoke-PSTestFunc"

V tomto příkladu konfigurace myFunction zahrnuje scriptFile vlastnost, která odkazuje PSFunction.psm1, což je modul PowerShellu v jiné složce. Vlastnost entryPoint odkazuje na Invoke-PSTestFunc funkci, což je vstupní bod v modulu.

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

S touto konfigurací se Invoke-PSTestFunc provede přesně tak, jak by to bylo run.ps1 .

Důležité informace o funkcích PowerShellu

Při práci s funkcemi PowerShellu mějte na paměti důležité informace v následujících částech.

Studený start

Při vývoji Azure Functions v modelu bezserverového hostování jsou studené starty realitou. Studený start označuje dobu potřebnou ke spuštění aplikace funkcí ke zpracování požadavku. V plánu Consumption dochází častěji ke studenému spuštění, protože aplikace funkcí se vypne během období nečinnosti.

Vyhněte se používání modulu Install-Module

Spuštění Install-Module ve skriptu funkce při každém vyvolání může způsobit problémy s výkonem. Místo toho použijte Save-Module nebo Save-PSResource před publikováním aplikace funkcí zabalte potřebné moduly.

Další informace najdete v části Správa závislostí.

Další kroky

Další informace naleznete v následujících zdrojích:

• Osvědčené postupy pro službu Azure Functions
• Referenční informace pro vývojáře Azure Functions
• Triggery a vazby Azure Functions