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

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

Funkce powershellu Azure (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 tématu Azure Functions koncepty triggerů a vazeb.

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 příručku pro vývojáře Azure Functions. Předpokládá se také, že jste dokončili Functions quickstart pro PowerShell a vytvořili svou 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 naleznete 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 prostředí Functions runtime jsou definována v extensions.csproj souboru, kde jsou skutečné soubory knihovny umístěny ve složce bin. Při místním vývoji musíte zaregistrovat rozšíření vazeb. Při vývoji funkcí na portálu Azure se tato registrace provádí za vás.

V aplikacích funkcí PowerShellu můžete volitelně mít profile.ps1, která se aktivuje při spuštění aplikace funkcí (jinak známé 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 run.ps1, kde run.ps1 sdílí stejný nadřazený adresář jako odpovídající function.json.

Skript přijímá 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ší vazba od vazby, 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	Datum a čas
NázevMetody	Název funkce, která se aktivovala	řetězec
RandGuid	jedinečný identifikátor GUID pro toto spuštění funkce	řetězec

Každý typ triggeru má jinou sadu metadat. Například for $TriggerMetadataQueueTrigger obsahuje InsertionTime, IdDequeueCount, mimo jiné. Další informace o metadatech triggerů fronty najdete v oficiální dokumentaci ke triggerům 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 souboru function.json funkce. Funkce pracují s vazbami mnoha způsoby.

Čtení spouštěcích a vstupních dat

Aktivační události a vstupní vazby se čtou jako parametry předané vaší funkci. Vstupní vazby mají v souboru function.json nastaveny direction na 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 vlastnost vazby name, jak je definována v function.json, odpovídá parametru Name 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ě, abyste vložili více hodnot.

• Pokud výstupní vazba přijímá pouze jedinou hodnotu, opakované volání Push-OutputBinding vyvolá chybu.

Syntaxe Push-OutputBinding

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

Název	Typ	Postavení	Popis
-Name	Řetězec	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í přinutí nastavit hodnotu pro zadané výstupní připojení.

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: HTTP odpovědi

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":

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, je při druhém zavolání Push-OutputBinding vyvolána chyba.

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. Tím, že použijete -Clobber, odpověď z následujícího příkladu přepíše stávající hodnotu a vrátí hodnotu „output #3“.

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

Příklad použití "Push-OutputBinding": výstupní vazba na frontu

Push-OutputBinding je používán k odeslá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 (queue) hodnotu „output #1“.

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

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

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

Následující příklad, pokud je použit po předchozích dvou, přidá do výstupní kolekce dvě další hodnoty:

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".

Cmdlet 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ásledující příklad používá 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 probíhá 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í	Protokolovací cmdlet
Chyba	Write-Error
Upozornění	Write-Warning
Informace	Write-Information Write-Host Write-Output Zapisuje na úroveň protokolu Information.
Ladění	Write-Debug
Trasování	Write-Progress Write-Verbose

Kromě těchto příkazů cmdlet se vše zapisované 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 nestačí k zobrazení protokolování na úrovni podrobného a ladění. Musíte také nakonfigurovat práh úrovně protokolování, která určuje, o jakou úroveň protokolování vám skutečně jde. Další informace najdete v tématu Konfigurace úrovně protokolu aplikace funkcí.

Konfigurace úrovně protokolu funkční aplikace

Azure Functions umožňuje definovat prahovou úroveň, která usnadňuje řízení způsobu, jakým funkce zapisují 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 specifickou funkci 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. Přečtěte si monitorování Azure Functions, abyste se dozvěděli více o zobrazení a dotazování protokolů funkcí.

Pokud používáte aplikaci funkce místně pro vývoj, záznamy jsou ve výchozím nastavení ukládány do 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

Je zde mnoho triggerů a propojování, které můžete použít ve své funkční aplikaci. Úplný seznam triggerů a vazeb najdete v tématu Podporované vazby.

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

• hašovací tabulka
• řetězec
• byte[]
• int (integer)
• dvojitý
• HttpRequestContext
• HttpResponseContext

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

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

HTTP spouštěče a vazby

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 nejvhodnějšího typu na základě dat. Pokud jsou například data JSON, předají 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.	Dictionary<string,string>*
Method	Metoda HTTP požadavku.	řetězec
Params	Objekt, který obsahuje parametry směrování požadavku.	Slovník<string,string>*
Query	Objekt, který obsahuje parametry dotazu.	Slovník<string,string>*
Url	Adresa URL požadavku.	řetězec

^* 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ěď.	řetězec
Headers	Objekt, který obsahuje hlavičky odpovědi.	Slovník nebo hašovací tabulka
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:

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

Přetypování pro spouště a vazby

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

Pokud například chcete mít data z úložiště blob dodána jako řetězec, přidejte do mého bloku param následující 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 zastavení (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 jsou Visual Studio Code a Azure Functions Core Tools, vytvoří se pro vás výchozí profile.ps1. Výchozí profil se udržuje o úložišti nástrojů Core Tools GitHub a obsahuje:

• Automatické ověřování MSI pro Azure
• Existuje možnost zapnout aliasy PowerShellu pro Azure PowerShell AzureRM, pokud si přejete.

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 article

Poznámka:

Podpora PowerShellu 7.2 v 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. Pokud chcete upgradovat na PowerShell 7.4, postupujte podle tohoto průvodce migrací.

Spuštění lokálně na konkrétní verzi

Když spouštíte funkce PowerShellu místně, musíte do pole v "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4" souboru local.setting.json v kořenovém adresáři projektu přidat nastavení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. Do budoucna pro aplikace funkcí PowerShell vyžadujeme, aby aplikace zadaly hlavní a vedlejší verzi, na kterou chtějí zaměřit. 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 v aplikaci zavést zásadní změny, přečtěte si tuto příručku pro migrace 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 najdete v tématu Zobrazení 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 portálu Azure, nebo pomocí PowerShellu.

Portal

1. Na portálu Azure 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 pro PowerShell 7.4 v Azure Functions je nyní obecně dostupná (GA). PowerShell 7.4 se může na portálu Azure stále zobrazovat jako verze Preview, ale tato hodnota se brzy aktualizuje, aby odrážela stav obecné dostupnosti (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>, <RESOURCE_GROUP> a <FUNCTION_APP> ID vašeho předplatného Azure, název vaší skupiny prostředků a aplikace funkcí. Také nahraďte <VERSION> s 7.4. Můžete ověřit aktualizovanou hodnotu nastavení powerShellVersion ve vrácené tabulce hash Properties.

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

Správa závislostí

Ke správě modulů v Azure Functions napsaných 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 PowerShell Gallery: Moduly jsou integrovány s vaší aplikací, 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 Azure Functions automaticky stahovat a spravovat moduly PowerShellu zadané v souboru requirements.psd1. 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 v Azure Functions s PowerShellem, musíte nakonfigurovat soubor requirements.psd1. Tento soubor určuje moduly, které vaše funkce vyžaduje, a Azure Functions automaticky stahuje a aktualizuje tyto moduly, aby se zajistilo, že vaše prostředí zůstane aktuální.

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

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

Příklad requirements.psd1 souboru:

@{
    '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 PowerShell Gallery:

     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 funkční aplikace pod správou zdrojového kódu, měli byste potvrdit, že veškerý obsah ve složce Modules, které přidáte, není vyloučený souborem .gitignore. Pokud například jeden z vašich modulů obsahuje složku bin, která je vynechána, budete chtít upravit soubor .gitignore 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.

Konfigurovat specifické nastavení intervalu spravovaných závislostí

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 aktualizace

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

• Přístup k internetu: Řízené závislosti vyžadují přístup k https://www.powershellgallery.com ke stažení 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. Požadované koncové body jsou popsané v rutinách pro řešení potíží. Tyto koncové body je možné podle potřeby přidat do seznamu povolených.
• 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 se $env:PSModulePath pro aplikaci funkcí PowerShellu liší od $env:PSModulePath v běžném skriptu PowerShellu a obsahuje složku Modules 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ězce 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 portálu Azure
• Pomocí Azure CLI
• Pomocí Azure PowerShell

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 .

Konkurence

Modul runtime Functions PowerShell ve výchozím nastavení může zpracovávat 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é funkční aplikaci.

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 tímto zatížením netrpí. 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 Durable Functions vzory aplikací.

Poznámka:

Může se zobrazit upozornění, že se požadavky zařadí do fronty kvůli nedostupnosti spustitelných prostředí. Tato zpráva není chybou. Zpráva vám říká, že se požadavky zařazují do fronty. Zpracovávají se po dokončení předchozích požadavků.

Úvahy o používání souběžnosti

PowerShell je ve výchozím nastavení jednovláknový skriptovací jazyk. Souběžnost lze přidat použitím více PowerShell runspace ve stejném procesu. Počet vytvořených runspace a tím i počet souběžných vláken na pracovní vlákno je omezen nastavením aplikace PSWorkerInProcConcurrencyUpperBound. Ve výchozím nastavení je počet runspaces ve verzi 4.x runtime Functions nastaven na 1 000. Ve verzích 3.x a níže je maximální počet runspaces nastaven na hodnotu 1. Propustnost aplikace funkcí ovlivňuje množství procesoru a paměti dostupné ve vybraném plánu.

Azure PowerShell používá některé kontexty a stav process-level, 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 se závodními podmínkami. Tyto podmínky souběhu 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 PowerShell, protože některé operace mohou trvat poměrně dlouho. Musíte však pokračovat s opatrností. Pokud máte podezření, že dochází ke závodní podmínce, nastavte nastavení aplikace PSWorkerInProcConcurrencyUpperBound na 1 a místo toho použijte izolaci na úrovni procesu jazykového pracovníka pro souběžnost.

Konfigurace funkce skriptového souboru scriptFile

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 function.json vlastnost odkazující myFunctionscriptFile 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ě stejně jako 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 hostování serverless 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 funkční aplikace 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 a předtím, než publikujete svou funkční aplikaci, zabalte potřebné moduly.

Další informace naleznete v tématu Správa závislostí.

Další kroky

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

• Doporučené postupy pro Azure Functions
• Azure Functions reference pro vývojáře
• Triggery a vazby Azure Functions