本文將詳細說明如何使用 PowerShell 撰寫 Azure Functions。
PowerShell Azure 函式(function)以 PowerShell 腳本表示,觸發時會執行。 每個函式指令碼都有相關的 檔案來定義函式的行為,例如其觸發方式及其輸入和輸出參數。 想了解更多,請參考Azure Functions觸發與綁定概念。
如同其他類型的函式,PowerShell 指令碼函式會採用符合 檔案中所定義所有輸入繫結名稱的參數。 也會傳遞 參數,其中包含有關啟動函式觸發器的其他資訊。
本文假設你已經閱讀過 Azure Functions 開發者指南。 它也假設您已完成 PowerShell 功能快速入門指南,從而建立了您的第一個 PowerShell 函式。
資料夾結構
PowerShell 專案的必要資料夾結構如下所示。 此預設值可以變更。 如需詳細資訊,請參閱 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
在專案根目錄中,有共用的 檔案可用來設定函式應用程式。 每個函式都有包含本身程式碼檔案 (.ps1) 和繫結組態檔 () 的資料夾。 function.json 檔案的父目錄名稱一律是函式的名稱。
某些繫結需要 檔案存在。 在 Functions 執行階段 2.x 版和更新版本中所需的繫結延伸模組,是在 檔案中定義,而實際的程式庫檔案則位於 資料夾中。 在當地開發時,您必須註冊繫結擴充功能。 當你在 Azure 入口網站開發函式時,這個註冊會自動幫你完成。
在 PowerShell 函式應用程式中,您可以選擇性地建立一個 ,當函式應用程式開始執行時執行 (也稱為冷啟動)。 如需詳細資訊,請參閱 PowerShell 設定檔。
將 PowerShell 指令碼定義為函式
根據預設,Functions 執行階段會在 中尋找您的函式,其中 與對應的 會共用相同的父目錄。
您的文稿會在執行時傳遞數個自變數。 若要處理這些參數,請將 區塊新增至指令碼頂端,如下列範例所示:
# $TriggerMetadata is optional here. If you don't need it, you can safely remove it from the param block
param($MyFirstInputBinding, $MySecondInputBinding, $TriggerMetadata)
TriggerMetadata 參數
參數可用來提供有關觸發程序的其他資訊。 此元數據會因系結到系結而有所不同,但它們都包含具有下列數據的 屬性:
$TriggerMetadata.sys
| 屬性 | 描述 | 類型 |
|---|---|---|
| UtcNow | 函式在 UTC 時被觸發的時間 | 日期時間 |
| 方法名稱 | 觸發的函式名稱 | 字串 |
| RandGuid | 此函式執行的唯一 GUID | 字串 |
每種觸發類型都有一組不同的中繼資料。 例如, 的 包含 、、 等等。 如需了解有關佇列觸發器中繼資料的詳細資訊,請前往佇列觸發器的官方文件。 請查看您所用觸發程序的文件,以了解觸發程序中繼資料的內容。
繫結
在 PowerShell 中,繫結會設定並定義於函式的 function.json 中。 函式會以多種方式與系結互動。
讀取觸發器和輸入資料
觸發程序和輸入繫結會被讀取為傳遞給您函式的參數。 輸入繫結在 function.json 中將 設定為 。 中定義的 屬性是 區塊中的參數名稱。 由於 PowerShell 會使用具名參數進行繫結,因此參數的順序並不重要。 不過,最佳做法是遵循 中定義的繫結順序。
param($MyFirstInputBinding, $MySecondInputBinding)
寫入輸出資料
在函式中,輸出繫結在 function.json 中有一個 設定為 。 您可以使用 Functions 執行階段可用的 Cmdlet 來寫入輸出繫結。 在所有情況下,繫結的 屬性 (如 中所定義) 都會對應到 Cmdlet 的 參數。
下列範例示範如何在函式腳本中呼叫 :
param($MyFirstInputBinding, $MySecondInputBinding)
Push-OutputBinding -Name myQueue -Value $myValue
您也可以透過管線傳入特定繫結的值。
param($MyFirstInputBinding, $MySecondInputBinding)
Produce-MyOutputValue | Push-OutputBinding -Name myQueue
會根據為 指定的值,以不同的方式運作:
當指定的名稱無法解析為有效的輸出系結時,就會擲回錯誤。
當輸出繫結接受值的集合時,您可以重複呼叫 以推送多個值。
當輸出繫結只接受單一值時,第二次呼叫 會引發錯誤。
Push-OutputBinding 語法
以下是呼叫 的有效參數:
| 名稱 | 類型 | 位置 | 描述 |
|---|---|---|---|
-Name |
繩子 | 1 | 您想要設定的輸出繫結名稱。 |
-Value |
物體 | 2 | 您想要設定的輸出繫結值,這是從管線 ByValue 接受的值。 |
-Clobber |
SwitchParameter | 已命名 | (選擇性) 指定此值時會強制為指定的輸出繫結設定值。 |
也支援下列常見參數:
VerboseDebugErrorActionErrorVariableWarningActionWarningVariableOutBufferPipelineVariableOutVariable
如需詳細資訊,請參閱關於 CommonParameters。
Push-OutputBinding 範例:HTTP 回應
HTTP 觸發程序會使用名為 的輸出繫結傳回回應。 在下列範例中, 的輸出繫結具有 "output #1" 的值:
Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
StatusCode = [System.Net.HttpStatusCode]::OK
Body = "output #1"
})
由於輸出目標是 HTTP,而 HTTP 僅接受單一值,因此當 被第二次呼叫時便會擲回錯誤。
Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
StatusCode = [System.Net.HttpStatusCode]::OK
Body = "output #2"
})
對於只接受單一值的輸出,您可以使用 參數來覆寫舊值,而不是嘗試新增至集合。 假設您已經將某個值新增至系統,下列範例說明如何操作。 藉由使用 ,下列範例的回應會覆寫現有的值,以傳回 "output #3" 的值:
Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
StatusCode = [System.Net.HttpStatusCode]::OK
Body = "output #3"
}) -Clobber
Push-OutputBinding 範例:佇列輸出繫結
Push-OutputBinding 用於將資料傳送到輸出綁定,例如 Azure 佇列儲存輸出綁定。 在下列範例中,寫入佇列的訊息值為 "output #1":
Push-OutputBinding -Name outQueue -Value "output #1"
儲存體佇列的輸出繫結可接受多個輸出值。 在此案例中,在第一次呼叫後呼叫下列範例會將包含以下兩個項目的清單寫入佇列:"output #1" 和 "output #2"。
Push-OutputBinding -Name outQueue -Value "output #2"
在前兩次呼叫之後呼叫下列範例,則會再將兩個值新增至輸出集合:
Push-OutputBinding -Name outQueue -Value @("output #3", "output #4")
寫入佇列時,訊息會包含下列四個值:"output #1"、"output #2"、"output #3" 和 "output #4"。
Get-OutputBinding cmdlet 指令
您可以使用 Cmdlet 來擷取目前為輸出繫結設定的值。 此 Cmdlet 會擷取雜湊表,其中包含輸出繫結名稱和其個別值。
下列範例會使用 傳回目前的繫結值:
Get-OutputBinding
Name Value
---- -----
MyQueue myData
MyOtherQueue myData
也會包含稱為 的參數,可用來篩選傳回的繫結,如下列範例所示:
Get-OutputBinding -Name MyQ*
Name Value
---- -----
MyQueue myData
支援萬用字元 (*)。
記錄
PowerShell 函式中的日誌記錄運作原理就像一般 PowerShell 日誌記錄。 您可以使用記錄 Cmdlet 來寫入每個輸出串流。 每個 Cmdlet 都會對應至函式所使用的記錄層級。
| 函式記錄層級 | 記錄 Cmdlet |
|---|---|
| 錯誤 | Write-Error |
| 警告 | Write-Warning |
| 資訊 | Write-Information Write-Host Write-Output 寫入到 記錄層級。 |
| 偵錯 | Write-Debug |
| 追蹤 | Write-Progress Write-Verbose |
除了這些 Cmdlet 之外,寫入管線的任何項目都會重新導向至 記錄層級,並以預設的 PowerShell 格式顯示。
重要
使用 或 cmdlet 並不足以查看詳細資訊和偵錯層級的記錄。 您也必須設定記錄層級閾值,以宣告您實際關注的記錄層級。 若要深入了解,請參閱設定函式應用程式記錄層級。
設定函式應用程式的日誌層級
Azure Functions 允許你定義閾值等級,方便控制 Functions 如何寫入日誌。 若要設定寫入至主控台之所有追蹤的閾值,請在 檔案 中使用 屬性。 這個設定會套用到函式應用程式中的所有函式。
下列範例將閾值設定為啟用所有函式的詳細資訊記錄,但將閾值設定為針對名為 的函式啟用偵錯記錄:
{
"logging": {
"logLevel": {
"Function.MyFunction": "Debug",
"default": "Trace"
}
}
}
如需詳細資訊,請參閱 host.json 參考。
檢視記錄
如果你的函式應用程式是在 Azure 上運行,你可以用 Application Insights 來監控它。 閱讀 monitoring Azure Functions 以了解更多關於查看與查詢功能日誌的方法。
如果您在本機執行函式應用程式以進行開發,記錄預設會輸出到檔案系統。 若要在主控台中查看記錄,請在啟動函式應用程式之前,將 環境變數設定為 。
觸發程序和繫結類型
有許多觸發器和系結可供您搭配功能應用程式使用。 如需觸發程式和系結的完整清單,請參閱 支援的系結。
所有觸發程序和繫結都會以程式碼表示為幾個實際資料類型:
- 哈希表
- 字串
- byte[]
- 整數 (int)
- double
- HttpRequestContext(HTTP請求上下文)
- HttpResponseContext(HTTP回應上下文)
此列表中的前五種類型是標準的 .NET 類型。 最後兩個只會由 HttpTrigger 觸發程序使用。
函式中的每個繫結參數都必須是下列其中一種類型。
HTTP 觸發程序和繫結
HTTP 和 Webhook 觸發程序以及 HTTP 輸出繫結會使用要求和回應物件來代表 HTTP 傳訊。
要求物件
傳遞至文稿的要求物件屬於 類型 ,其具有下列屬性:
| 屬性 | 描述 | 類型 |
|---|---|---|
Body |
包含要求主體的物件。 會根據資料序列化為最佳類型。 例如,如果資料是 JSON,則會以雜湊表的形式傳入。 如果資料是字串,則會以字串的形式傳入。 | 物件 |
Headers |
包含要求標頭的字典。 | 字典字串,字串 |
Method |
要求的 HTTP 方法。 | 字串 |
Params |
包含要求之路由傳送參數的物件。 | 字典字串,字串 |
Query |
包含查詢參數的物件。 | 字典字串,字串 |
Url |
要求的 URL。 | 字串 |
所有 鍵皆不區分大小寫。
回應物件
您應該傳回的回應物件屬於 類型,其具有下列屬性:
| 屬性 | 描述 | 類型 |
|---|---|---|
Body |
包含回應內容的物件。 | 物件 |
ContentType |
設定回應的內容類型時,使用的簡易方式。 | 字串 |
Headers |
包含回應標頭的物件。 | 字典或雜湊表 |
StatusCode |
回應的 HTTP 狀態碼。 | 字串或整數 |
存取請求和回應
當您使用 HTTP 觸發程序時,您可以使用與任何其他輸入繫結相同的方式來存取 HTTP 要求。 其位於 區塊中。
以物件來傳回回應,如下列範例所示:
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!"
})
叫用此函式的結果如下:
irm http://localhost:5001?Name=Functions
Hello Functions!
觸發程序和繫結的類型轉換
對於 Blob 繫結之類的特定繫結,您可以指定參數的類型。
例如,若要將 Blob 儲存體中的資料提供為字串,請將下列類型轉換新增至我的 區塊:
param([string] $myBlob)
PowerShell 環境設定檔
PowerShell 中會有 PowerShell 設定檔的概念。 如果您不熟悉 PowerShell 設定檔,請參閱關於設定檔。
在 PowerShell 函式中,設定檔指令碼在應用程式首次部署後,以及經歷閒置後 (冷啟動),會在應用程式中的每個 PowerShell 背景工作角色執行個體上執行一次。 藉由設定 PSWorkerInProcConcurrencyUpperBound 值來啟用並行功能時,設定檔指令碼會針對每個建立的 Runspace 執行。
當你使用工具(如 Visual Studio Code 和 Azure Functions Core Tools)建立函式應用程式時,預設的 profile.ps1 會自動為你建立。 預設設定檔位於 Core Tools 的 GitHub 儲存庫中,其中包括:
- 自動化 MSI 驗證至 Azure。
- 如果你願意,可以開啟 Azure PowerShell
AzureRMPowerShell 別名的功能。
PowerShell 版本
下表顯示各主要版本 Functions 執行環境可用的 PowerShell 版本,以及所需的 .NET 版本:
| Functions 版本 | PowerShell 版本 | .NET 版本 |
|---|---|---|
| 4.x | PowerShell 7.4 | .NET 8 |
| 4.x | PowerShell 7.2 (支援結束) | .NET 6 |
您可以藉由從任何函式列印 ,來查看目前的版本。
欲了解更多Azure Functions執行時支援政策,請參閱此 article
注意
Azure Functions 對 PowerShell 7.2 的支援將於 2024 年 11 月 8 日結束。 升級您的 PowerShell 7.2 函式至 PowerShell 7.4 時,您可能需要解決一些重大變更。 請依照這份 遷移指南 升級至 PowerShell 7.4。
在特定版本上於本機執行
當您在本機執行 PowerShell 函式時,您必須將設定 新增至 專案根目錄中 local.setting.json 檔案中的陣列。 在 PowerShell 7.4 上在本機執行時,local.settings.json 檔案如下所示:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "",
"FUNCTIONS_WORKER_RUNTIME": "powershell",
"FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4"
}
}
注意
在 PowerShell Functions 中,FUNCTIONS_WORKER_RUNTIME_VERSION 的值 "~7" 是指 "7.0.x"。 我們不會自動將具有 “~7” 的 PowerShell 函式應用程式升級為 “7.4”。 接下來,針對 PowerShell 函式應用程式,我們需要應用程式同時指定他們想要鎖定的主要和次要版本。 如果您想要以 「7.4.x」 為目標,則必須提及 「7.4」。。
變更 PowerShell 版本
將 PowerShell 函式應用程式移轉至 PowerShell 7.4 之前,請先考量以下幾點:
由於遷移可能會在您的應用程式中引入破壞性變更,請在升級應用程式至 PowerShell 7.4 前,先閱讀這份 migration 指南。
確保你的函式應用程式在 Azure 的 Functions 執行時是最新版本,也就是 4.x 版本。 如需詳細資訊,請參閱 檢視目前的運行時間版本。
請使用下列步驟來變更函式應用程式所使用的 PowerShell 版本。 你可以在 Azure 入口網站或使用 PowerShell 執行此操作。
- 入口網站
- PowerShell
在 Azure 入口網站,瀏覽你的 Function App。
在 [設定] 底下,選擇 [組態]。 在 [一般設定] 索引標籤中,找出 PowerShell 版本。
顯示如何選取 PowerShell 版本的螢幕快照。
選擇您想要的 PowerShell Core 版本,然後選取 [儲存]。 出現即將重新啟動的警告時,請選擇 [繼續]。 函式應用程式會在所選的 PowerShell 版本上重新啟動。
注意
Azure Functions 對 PowerShell 7.4 的支援已普遍提供(GA)。 你可能會在 Azure 入口網站看到 PowerShell 7.4 仍標示為預覽版,但這個值很快會更新以反映 GA 狀態。
函式應用程式會在變更組態後重新啟動。
相依性管理
在 Azure Functions 中管理用 PowerShell 撰寫的模組有兩種方法:使用受管理相依功能,或直接將模組納入應用程式內容。 每個方法都有自己的優點,而選擇正確的方法取決於您的特定需求。
選擇正確的模組管理方法
為什麼要使用受控相依性功能?
- 簡化的初始安裝:根據您的 檔案自動處理模組安裝。
- 自動升級:模組會自動更新,包括安全性修正,而不需要手動介入。
為什麼在應用程式內容中包含模組?
- 不依賴 PowerShell 資源庫:模組會隨你的應用程式捆綁,消除外部依賴。
- 更多控制:避免自動升級所造成的回歸風險,讓您完全控制使用哪些模組版本。
- 相容性:適用於 Flex Consumption,並且建議應用於其他 Linux SKU。
受控相依項功能
受管理相依功能允許Azure Functions自動下載並管理 requirements.psd1 檔案中指定的 PowerShell 模組。 這項功能預設會在新的PowerShell函式應用程式中啟用。
設定 requirements.psd1
要在 PowerShell Azure Functions 中使用受管理的相依性,你需要設定一個 requirements.psd1 檔案。 這個檔案會指定你的函式所需的模組,Azure Functions會自動下載和更新這些模組,確保你的環境保持 up-to-date。
以下是設定和配置 檔案的方法:
- 如果Azure函式的根目錄還沒有,請在根目錄建立一個
requirements.psd1檔案。 - 在 PowerShell 數據結構中定義模組及其版本。
範例 檔案:
@{
'Az' = '9.*' # Specifies the Az module and will use the latest version with major version 9
}
在應用程式內容中包含模組
若要進一步控制模組版本,並避免相依於外部資源,您可以直接在函式應用程式的內容中包含模組。
若要包含自訂模組:
在 函式應用程式的根目錄建立資料夾 。
mkdir ./Modules使用下列其中一種方法,將模組複製到 資料夾 :
如果模組已在本機存在:
Copy-Item -Path /mymodules/mycustommodule -Destination ./Modules -Recurse使用
Save-Module從 PowerShell 資源庫 擷取:Save-Module -Name MyCustomModule -Path ./Modules使用來自模組的:
Save-PSResource -Name MyCustomModule -Path ./Modules
您的函式應用程式應該具有下列結構:
PSFunctionApp
| - MyFunction
| | - run.ps1
| | - function.json
| - Modules
| | - MyCustomModule
| | - MyOtherCustomModule
| | - MySpecialModule.psm1
| - local.settings.json
| - host.json
| - requirements.psd1
當您啟動函式應用程式時,PowerShell 語言背景工作角色會將此 資料夾新增至 ,因此您可以依賴模組自動載入,就像您在一般 PowerShell 指令碼中所做的一樣。
注意
如果您的函式應用程式位於原始檔控制之下,您應該確認您新增的Modules資料夾中的所有內容並未由 .gitignore 排除。 例如,如果您的其中一個模組有一個正在被排除的 bin 資料夾,您需要藉由在 .gitignore 中替換 來進行修改。
**/bin/**
!Modules/**
針對受控相依關係進行疑難解答
啟用受控依賴項
若要讓Managed相依性運作,必須在host.json中啟用此功能:
{
"managedDependency": {
"enabled": true
}
}
以特定版本為目標
以特定模組版本為目標時,請務必遵循下列步驟,以確保載入正確的模組版本:
在 中 指定模組版本:
@{ 'Az.Accounts' = '1.9.5' }將 import 語句新增至 :
Import-Module Az.Accounts -RequiredVersion '1.9.5'
遵循下列步驟可確保函式啟動時會載入指定的版本。
設定特定的受控相依性間隔設定
您可以使用下列應用程式設定來設定如何下載及安裝受控相依性:
| 設定 | 預設值 | 描述 |
|---|---|---|
| MDMaxBackgroundUpgradePeriod | (7 天) | 控制 PowerShell 函式應用程式的背景更新期間。 |
| MDNewSnapshotCheckPeriod | (一小時) | 指定 PowerShell 工作者檢查更新的頻率。 |
| MDMinBackgroundUpgradePeriod | (一天) | 升級檢查之間的最短時間。 |
相依性管理考量
- 因特網存取:受控的相依性需要訪問以下載模組。 請確定您的環境允許此存取,包括視需要修改防火牆/VNet 規則。 Troubleshooting Cmdlets 中描述所需的端點。 您可以視需要將這些端點新增至允許清單。
- 授權接受:受控相依性不支援需要接受授權的模組。
- Flex 取用方案:在 Flex 取用方案中不支援 Managed Dependencies 功能。 請改用自定義模組。
- 模組位置:在您的本機計算機上,模組通常會安裝在 您 中其中一個全域可用的資料夾中。 在 Azure 執行時,PowerShell 函式應用程式的
$env:PSModulePath與一般 PowerShell 腳本中的$env:PSModulePath不同,包含上傳的Modules資料夾(包含你的應用程式內容)以及由受管理相依管理的獨立位置。
環境變數
在 Functions 中,應用程式設定 (例如服務連接字串) 在執行期間會公開為環境變數。 您可以使用 存取這些設定,如下列範例所示:
param($myTimer)
Write-Host "PowerShell timer trigger function ran! $(Get-Date)"
Write-Host $env:AzureWebJobsStorage
Write-Host $env:WEBSITE_SITE_NAME
有數種方式可供您新增、更新和刪除函式應用程式設定:
對函式應用程式設定的變更需要將函式應用程式重新啟動。
在本機執行時,應用程式設定會讀取自 local.settings.json 專案檔。
並行
根據預設,Functions PowerShell 執行階段一次只能處理一個函式叫用。 不過,在下列情況下,此並行層級可能不夠:
- 當您嘗試同時處理大量叫用時。
- 當您擁有在同一函式應用程式內叫用其他函式的函式時。
您可以根據工作負載類型來探索幾個並行模型:
增加 。 增加此設定可讓處理相同實例內多個進程的函式調用,這會導致特定 CPU 和記憶體額外負荷。 一般而言,I/O 系結函式不會因為此額外負荷而受到影響。 對於 CPU 系結函式,影響可能很大。
增加 應用程式設定值。 增加此設定可讓您在同一個進程中建立多個 Runspace,這可大幅降低 CPU 和記憶體額外負荷。
您可以在函式應用程式的應用程式設定中設定這些環境變數。
根據你的使用情境,Durable Functions 可能會大幅提升可擴展性。 欲了解更多,請參閱 Durable Functions 應用模式。
注意
您可能會收到「因為沒有可用的執行空間,要求已排入佇列」警告。 此訊息不是錯誤。 該訊息告訴您要求正被排入佇列。 這些要求會在先前要求完成後進行處理。
使用並行的考慮
PowerShell 預設為 single_threaded 指令碼語言。 不過,您可以在相同程序中使用多個 PowerShell Runspace 來新增並行功能。 應用程式設定會限制建立的 Runspace 數目,因此每個背景工作角色的並行執行緒數目也會受限。 根據預設,Runspace 數目在 Functions 執行階段的 4.x 版中會設定為 1,000 個。 在 3.x 版和較低版本中,Runspace 數目的上限會設定為 1 個。 函式應用程式的流量會受到所選方案中可用的 CPU 和記憶體數量的影響。
Azure PowerShell 會使用一些
Azure PowerShell 的並行性非常有價值,因為有些操作可能需要相當長的時間。 不過,您必須小心。 如果您懷疑遇到競爭情況,請將 PSWorkerInProcConcurrencyUpperBound 應用程式的設定設定至 ,並改為使用語言背景工作處理序層級隔離來進行並行作業。
設定函式 scriptFile
預設會從 執行 PowerShell 函式,這是與對應的 共用相同父目錄的檔案。
中的 屬性可用來取得如下列範例所示的資料夾結構:
FunctionApp
| - host.json
| - myFunction
| | - function.json
| - lib
| | - PSFunction.ps1
在此案例中, 的 會包含一個 屬性,該屬性會指向包含要執行之匯出函式的檔案。
{
"scriptFile": "../lib/PSFunction.ps1",
"bindings": [
// ...
]
}
藉由設定 entryPoint 來使用 PowerShell 模組
本文中的PowerShell函式會顯示範本所產生的預設 腳本檔案。 不過,您也可以在 PowerShell 模組中包含函式。 您可以使用 function.json 組態檔中的 和 欄位,在模組中參考您的特定函式程式碼。
在此案例中, 是 PowerShell 模組中 參考的函式或 Cmdlet 名稱。
考慮下列資料夾結構:
FunctionApp
| - host.json
| - myFunction
| | - function.json
| - lib
| | - PSFunction.psm1
其中 包含:
function Invoke-PSTestFunc {
param($InputBinding, $TriggerMetadata)
Push-OutputBinding -Name OutputBinding -Value "output"
}
Export-ModuleMember -Function "Invoke-PSTestFunc"
在此範例中, 的組態會包含參考 (這是另一個資料夾中的 PowerShell 模組) 的 屬性。 屬性會參考 函式,這是模組中的進入點。
{
"scriptFile": "../lib/PSFunction.psm1",
"entryPoint": "Invoke-PSTestFunc",
"bindings": [
// ...
]
}
使用此組態時, 像 一樣執行。
PowerShell 函式的考量
當您使用 PowerShell 函式時,請留意下列小節中的考量事項。
冷啟動
在以無伺服器主機模型開發 Azure Functions 時,冷啟動是常態。 冷啟動是指函式應用程式開始執行以處理要求所需的時間。 冷啟動在使用量方案中更為常見,因為當您的函式應用程式處於非使用狀態時會被關閉。
避免使用 Install-Module
在函式腳本的每次調用中執行 可能會導致效能問題。 請改用 或 發佈函式應用程式之前,將必要的模組組合在一起。
如需詳細資訊,請參閱 相依性管理。
下一步
如需詳細資訊,請參閱以下資源:
Azure Functions 的最佳實務 - Azure Functions 開發指南
- Azure Functions 觸發器與繫結