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. Měli byste také dokončit rychlý start functions pro PowerShell a vytvořit 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 níže.

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á 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. Další metadata se liší od vazby na vazbu, ale všechny obsahují sys vlastnost, která obsahuje následující data:

$TriggerMetadata.sys

Každý typ triggeru má jinou sadu metadat. Například for $TriggerMetadata QueueTrigger 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 pracují s vazbami několika 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:

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

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.

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 celá řada 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:

^* 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:

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:

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

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

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

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í. Můžete to udělat buď na webu Azure Portal, nebo pomocí PowerShellu.

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

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

Správa závislostí

Funkce umožňují využít galerii Prostředí PowerShell ke správě závislostí. Při povolené správě závislostí se soubor requirements.psd1 používá k automatickému stahování požadovaných modulů. Toto chování povolíte nastavením managedDependency vlastnosti v true kořenovém adresáři souboru host.json, jak je znázorněno v následujícím příkladu:

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

Při vytváření nového projektu funkcí PowerShellu je ve výchozím nastavení povolená správa závislostí s zahrnutým modulem AzureAz. Maximální počet modulů, které jsou aktuálně podporovány, je 10. Podporovaná syntaxe je MajorNumber.* nebo přesná verze modulu, jak je znázorněno v následujícím příkladu requirements.psd1:

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

Při aktualizaci souboru requirements.psd1 se po restartování nainstalují aktualizované moduly.

Cílení na konkrétní verze

V souboru requirements.psd1 můžete chtít cílit na konkrétní verzi modulu. Pokud byste například chtěli použít starší verzi Az.Accounts než v zahrnuté verzi modulu Az, museli byste cílit na konkrétní verzi, jak je znázorněno v následujícím příkladu:

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

V tomto případě musíte také přidat příkaz importu do horní části souboru profile.ps1, který vypadá jako v následujícím příkladu:

Import-Module Az.Accounts -RequiredVersion '1.9.5'

Tímto způsobem se při spuštění funkce nejprve načte starší verze modulu Az.Account.

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

Při použití správy závislostí platí následující aspekty:

• Spravované závislosti vyžadují přístup ke https://www.powershellgallery.com stahování modulů. Při místním spuštění se ujistěte, že modul runtime má přístup k této adrese URL přidáním požadovaných pravidel brány firewall.

• Spravované závislosti v současné době nepodporují moduly, které vyžadují, aby uživatel přijal licenci, a to buď interaktivně přijetím licence, nebo poskytnutím -AcceptLicense přepínače při vyvolání Install-Module.

• Spravované závislosti se nepodporují, když hostujete aplikaci funkcí v plánu Flex Consumption. Místo toho musíte definovat vlastní moduly.

Nastavení aplikace pro správu závislostí

Pomocí následujících nastavení aplikace můžete změnit způsob stahování a instalace spravovaných závislostí.

Upgrade aplikace se v podstatě spustí v rámci MDMaxBackgroundUpgradePerioda proces upgradu se dokončí přibližně v rámci MDNewSnapshotCheckPeriod.

Vlastní moduly

Využití vlastních modulů ve službě Azure Functions se liší od toho, jak byste to normálně dělali pro PowerShell.

Na místním počítači se modul nainstaluje do jedné z globálně dostupných složek ve vašem $env:PSModulePathpočítači . Při spuštění v Azure nemáte přístup k modulům nainstalovaným na vašem počítači. To znamená, že se $env:PSModulePath aplikace funkcí PowerShellu liší od $env:PSModulePath normálního skriptu PowerShellu.

Ve službě Functions PSModulePath obsahuje dvě cesty:

• Složka Modules , která existuje v kořenovém adresáři vaší aplikace funkcí.
• Cesta ke Modules složce, kterou řídí pracovní proces jazyka PowerShellu.

Složka modulů na úrovni aplikace funkcí

Pokud chcete použít vlastní moduly, můžete umístit moduly, na kterých vaše funkce závisí ve Modules složce. Z této složky jsou moduly automaticky dostupné modulu runtime funkcí. Všechny funkce v aplikaci funkcí můžou tyto moduly používat.

Pokud chcete využít výhod funkce vlastního modulu, vytvořte Modules složku v kořenovém adresáři aplikace funkcí. Zkopírujte moduly, které chcete použít ve svých funkcích, do tohoto umístění.

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

Modules U složky by vaše aplikace funkcí měla mít následující strukturu složek:

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.

Složka modulů na úrovni pracovního procesu jazyka

Pracovní proces jazyka PowerShellu běžně používá několik modulů. Tyto moduly jsou definovány v poslední pozici PSModulePath.

Aktuální seznam modulů je následující:

• Microsoft.PowerShell.Archive: modul používaný pro práci s archivy, jako je .zip, .nupkga další.
• ThreadJob: Implementace rozhraní API úloh PowerShellu založená na vláknech.

Služba Functions ve výchozím nastavení používá nejnovější verzi těchto modulů. Pokud chcete použít konkrétní verzi modulu, vložte tuto konkrétní verzi do Modules složky vaší aplikace funkcí.

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. To 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 nebudou touto režií trpět. U funkcí vázaných na procesor může být dopad významný.

• PSWorkerInProcConcurrencyUpperBound Zvyšte hodnotu nastavení aplikace. To umožňuje vytvářet více prostředí runspace ve stejném procesu, což výrazně snižuje režijní náklady na procesor a paměť.

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.

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 bude ovlivněna množstvím 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.json myFunction na soubor s exportovanou funkcí, která se má spustit.

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

Konfigurace vstupního bodu pomocí modulů PowerShellu

Tento článek ukazuje funkce PowerShellu ve výchozím run.ps1 souboru 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.

Sbalování modulů místo použití modulu Install-Module

Váš skript se spustí při každém vyvolání. Vyhněte se použití Install-Module ve skriptu. Místo toho použijte Save-Module před publikováním, aby funkce nemusela ztrácet čas stažením modulu. Pokud na vaše funkce dopadají studené starty, zvažte nasazení aplikace funkcí do plánu služby App Service nastaveného tak, aby byla vždy zapnutá nebo na plán Premium.

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