Azure Functions 的儲存考量事項
當您建立函數應用程式執行個體時,Azure Functions 需要 Azure 儲存體帳戶。 您的函數應用程式可使用下列儲存體服務:
儲存體服務 | 函式使用方式 |
---|---|
Azure Blob 儲存體 | 維護繫結狀態和函式金鑰1。 在 Flex 取用方案 中執行應用程式的部署來源。 根據預設,由 Durable Functions 的工作中樞使用。 可用來儲存 Linux 使用量遠端組建的函數應用程式程式碼,或做為外部套件 URL 部署的一部分。 |
Azure 檔案儲存體2 | 檔案共用,用於儲存和執行使用情況方案和進階方案中的函數應用程式程式碼。 |
Azure 佇列儲存體 | 根據預設,由 Durable Functions 的工作中樞使用。 用於特定 Azure Functions 觸發程序中的失敗和重試處理。 用於 Blob 儲存體觸發程序的物件追蹤。 |
Azure 資料表儲存體 | 根據預設,由 Durable Functions 的工作中樞使用。 |
- Blob 儲存體是函式金鑰的預設存放區,但您可以設定替代存放區。
- 預設會設定 Azure 檔案儲存體,但您可以在某些情況下建立應用程式,但不需要 Azure 檔案儲存體。
您必須強烈考慮下列有關函數應用程式所用儲存體帳戶的事實:
當函數應用程式在使用量方案或進階方案上主控時,您的函式程式碼和設定檔會儲存在連結儲存體帳戶的 Azure 檔案儲存體中。 當您刪除此儲存體帳戶時,會刪除此內容且無法復原。 如需詳細資訊,請參閱已刪除儲存體帳戶
重要資料,例如函式程式碼、存取金鑰和其他重要的服務相關資料,都可以保存在儲存體帳戶中。 您必須以下列方式仔細管理函數應用程式所使用的儲存體帳戶存取權:
根據最低權限模型稽核及限制應用程式和使用者的儲存體帳戶存取權。 儲存體帳戶的權限可以來自指派角色中的資料動作,或透過執行 listKeys 作業的權限提供。
監視儲存體帳戶中的控制平面活動 (例如擷取金鑰) 和資料平面作業 (例如寫入 Blob)。 請考慮在 Azure 儲存體以外的位置維護儲存體記錄。 如需詳細資訊,請參閱儲存記錄。
在 Azure 入口網站之函數應用程式建立流程中建立的儲存體帳戶,保證會使用新的函數應用程式。 當您選擇使用現有的儲存體帳戶時,所提供的清單不包含特定不支援的儲存體帳戶。 下列限制適用於函數應用程式所使用的儲存體帳戶,因此您必須確定現有的儲存體帳戶符合下列需求:
帳戶類型必須支援 Blob、佇列和資料表儲存體。 某些儲存體帳戶不支援佇列和資料表。 這些帳戶包括僅限 Blob 的儲存體帳戶和 Azure 進階儲存體。 若要深入了解儲存體帳戶類型,請參閱儲存體帳戶概觀。
當函數應用程式裝載於使用量方案時,您無法使用網路保護的儲存體帳戶。
在入口網站中建立函數應用程式時,您只能選擇與所要建立函數應用程式位於相同區域中的現有儲存體帳戶。 這是效能最佳化,而不是嚴格的限制。 若要深入了解,請參閱儲存體帳戶位置。
使用部署自動化建立具有網路保護儲存體帳戶的函數應用程式時,您必須在 ARM 範本或 Bicep 檔案中包含特定的網路設定。 當您未包含這些設定和資源時,自動化部署在驗證中可能會失敗。 如需更具體的 ARM 和 Bicep 指引,請參閱安全部署。 如需使用網路設定儲存體帳戶的概觀,請參閱如何搭配 Azure Functions 使用安全的儲存體帳戶。
每個函式應用程式都需要有儲存體帳戶才能運作。 該帳戶刪除後,您的函式應用程式就不會執行。 若要為儲存體相關問題疑難排解,請參閱如何為儲存體相關問題疑難排解。 下列其他考量事項適用於函式應用程式所使用的儲存體帳戶。
為獲得最佳效能,您的函數應用程式應該使用同一區域中的儲存體帳戶,以減少延遲。 Azure 入口網站會強制執行此最佳做法。 如果因為某些原因需要使用與函式應用程式不同區域的儲存體帳戶,您必須在入口網站外部建立函式應用程式。
函數應用程式必須能夠存取儲存體帳戶。 如果您需要使用安全的儲存體帳戶,請考慮將儲存體帳戶限制為虛擬網路。
根據預設,函數應用程式會將 AzureWebJobsStorage
連線設定為儲存在 AzureWebJobsStorage 應用程式設定中的連接字串,但您也可以將 AzureWebJobsStorage 設定為不使用秘密的身分識別型連線。
在使用量方案 (僅限 Windows) 或彈性進階方案 (Windows 或 Linux) 中執行的函數應用程式可以使用 Azure 檔案儲存體來儲存啟用動態調整所需的映像。 針對這些方案,請在 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 設定中設定儲存體帳戶的連接字串,並在 WEBSITE_CONTENTSHARE 設定中設定檔案共用的名稱。 這通常是用於 AzureWebJobsStorage
的相同帳戶。 您也可以建立不會使用 Azure 檔案儲存體的函數應用程式,但調整可能會受到限制。
注意
當您重新產生儲存體金鑰時,必須更新儲存體帳戶連接字串。 在此深入了解儲存體金鑰管理。
可能有多個函數應用程式共用相同的儲存體帳戶,而沒有任何問題。 例如,在 Visual Studio 中,您可以使用 Azure 儲存體模擬器開發多個應用程式。 在此情況下,模擬器的作用就像單一儲存體帳戶。 您的函數應用程式所使用的相同儲存體帳戶也可用來儲存您的應用程式資料。 不過,在實際執行環境中,這個方法不一定理想。
您可能需要使用不同的儲存體帳戶,以避免主機識別碼衝突。
您不應該將生命週期管理原則套用至函數應用程式所使用的 Blob 儲存體帳戶。 函式會使用 Blob 儲存體來保存重要資訊,例如函式存取金鑰,且原則可能會移除 Functions 主機所需的 Blob (例如金鑰)。 如果您必須使用原則,請排除 Functions 所使用的容器,其前面加上 azure-webjobs
或 scm
。
因為函式程式碼和金鑰可能會儲存在儲存體帳戶中,因此針對儲存體帳戶的活動記錄是監視未經授權存取的絕佳方法。 Azure 監視器資源記錄可用來追蹤儲存體資料平面的事件。 如需如何設定及檢查這些記錄的詳細資料,請參閱監視 Azure 儲存體。
Azure 監視器活動記錄會顯示控制平面事件,包括 listKeys 作業。 不過,您也應該設定儲存體帳戶的資源記錄,以追蹤金鑰或其他身分識別型資料平面作業的後續使用情況。 您應該至少啟用 StorageWrite 記錄類別,才能識別對一般 Functions 作業外部資料所進行的修改。
若要限制任何廣泛儲存體權限的潛在影響,請考慮針對這些記錄使用非儲存體目的地,例如 Log Analytics。 如需詳細資訊,請參閱監視 Azure Blob 儲存體 (機器翻譯)。
若要盡可能提高效能,每個函數應用程式應使用個別的儲存體帳戶。 當您有 Durable Functions 或事件中樞觸發的函式時,這一點特別重要,這兩個函式都會產生大量的儲存體交易。 當您的應用程式邏輯與 Azure 儲存體互動 (不論是直接 (使用儲存體 SDK) 或透過其中一個儲存體繫結) 時,您應該使用專用的儲存體帳戶。 例如,若有事件中樞觸發的函式將一些資料寫入 Blob 儲存體,請使用兩個儲存體帳戶,一個用於函數應用程式,另一個用於函式所儲存的 Blob。
裝載於相同方案中的多個函式應用程式也可以針對 Azure 檔案儲存體內容共用使用相同的儲存體帳戶 (由 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
定義)。 當此儲存體帳戶也受到虛擬網路保護時,所有這些應用程式也應該針對 vnetContentShareEnabled
使用相同的值 (先前為 WEBSITE_CONTENTOVERVNET
),以確保流量會透過預期的虛擬網路一致地路由傳送。 使用相同 Azure 檔案儲存體帳戶之應用程式間的此設定若不相符,可能會導致流量透過公用網路路由傳送,並造成儲存體帳戶網路規則封鎖存取。
Functions 的主要案例是處理 Blob 容器中的檔案,例如映像處理或情感分析。 若要深入了解,請參閱處理檔案上傳。
有數種方式可以根據儲存體容器中 Blob 的變更來執行函式程式碼。 使用下表來判斷哪一個函式觸發程序最符合您的需求:
策略 | 容器 (輪詢) | 容器 (事件) | 佇列觸發程序 | 事件方格 |
---|---|---|---|---|
Latency | 高 (最多 10 分鐘) | 低 | 中 | 低 |
儲存體帳戶限制 | 僅限 Blob 帳戶不支援的¹ | 不支援一般用途 v1 | none | 不支援一般用途 v1 |
觸發程序類型 | Blob 儲存體 | Blob 儲存體 | 佇列儲存體 | Event Grid |
延伸模組版本 | 任意 | 儲存體 v5.x+ | 任意 | 任意 |
處理現有的 Blob | 是 | 無 | 無 | No |
篩選 | Blob 名稱模式 | 事件篩選器 | n/a | 事件篩選器 |
需要事件訂用帳戶 | No | .是 | 無 | Yes |
支援 Flex 取用方案 | No | .是 | .是 | Yes |
支援高延展性² | No | .是 | .是 | Yes |
描述 | 預設觸發程序行為,其依賴輪詢容器以進行更新。 如需詳細資訊,請參閱 Blob 儲存體觸發程序參考中的範例。 | 從事件訂用帳戶取用 Blob 儲存體事件。 需要 EventGrid 的 Source 參數值。 如需詳細資訊,請參閱教學課程:使用事件訂閱在 Blob 容器上觸發 Azure Functions。 |
將 Blob 新增至容器時,Blob 名稱字串會手動新增至儲存體佇列。 此值會由佇列儲存體觸發程序直接傳遞至相同函式上的 Blob 儲存體輸入繫結。 | 除了來自儲存體容器的事件之外,提供觸發事件的彈性。 當需要同時有非儲存體事件觸發您的函式時,請使用此項目。 如需詳細資訊,請參閱如何在 Azure Functions 中使用事件方格觸發程序和繫結。 |
- Blob 儲存體輸入和輸出繫結支援僅限 Blob 的帳戶。
- 可將高延展性寬鬆地定義為可容納超過 100,000 個 Blob 的容器,或每秒 Blob 更新超過 100 次的儲存體帳戶。
Azure 儲存體會加密待用儲存體帳戶中的所有資料。 如需詳細資訊,請參閱待用資料的 Azure 儲存體加密。
根據預設,資料是以使用 Microsoft 管理的金鑰加密。 若要進一步控制加密金鑰,您可以提供客戶管理的金鑰,以用於加密 blob 和檔案資料。 這些金鑰必須存在於 Azure Key Vault 中,Functions 才能存取儲存體帳戶。 若要深入了解,請參閱使用客戶管理的金鑰待用加密。
當所有客戶資料都必須保留在單一區域內時,與函數應用程式相關聯的儲存體帳戶必須是具有區域備援的儲存體帳戶。 區域備援儲存體帳戶也必須搭配 Azure Durable Functions 使用。
當使用內部負載平衡的 App Service 環境 (ASE) 裝載時,其他平台管理的客戶資料只會儲存在區域內。 若要深入了解,請參閱 ASE 區域備援。
函式會使用主機識別碼值作為唯一識別預存成品中特定函數應用程式的方法。 此識別碼預設會從函數應用程式的名稱中自動產生,並截斷在前 32 個字元處。 然後,在連結的儲存體帳戶中儲存依應用程式相互關聯和追蹤資訊時,會使用此識別碼。 當您有多個函數應用程式名稱超過 32 個字元,且前 32 個字元完全相同時,此截斷可能會導致重複的主機識別碼值。 當兩個具有相同主機識別碼的函數應用程式使用相同的儲存體帳戶時,您會收到主機識別碼衝突,因為儲存的資料無法唯一連結到正確的數式應用程式。
注意
如果生產位置和預備位置使用相同的儲存體帳戶,則這兩個位置中的函式應用程式之間可能會發生此相同種類的主機識別碼衝突。
從 Functions 執行階段 3.x 版開始,會偵測主機識別碼衝突並記錄警告。 在 4.x 版中,會記錄錯誤並停止主機,導致嚴重失敗。 如需有關主機識別碼衝突的詳細資訊,請參閱此問題。
您可以使用下列策略以避免主機識別碼衝突:
- 對於涉及衝突的每個函式應用程式或位置,請使用個別的儲存體帳戶。
- 將其中一個函式應用程式重新命名為長度短於 32 個字元的值,這會變更應用程式計算的主機識別碼,並移除衝突。
- 為一或多個衝突的應用程式設定明確的主機識別碼。 若要深入了解,請參閱主機識別碼覆寫。
重要
變更與現有函數應用程式相關聯的儲存體帳戶,或變更應用程式的主機識別碼,都會影響現有函式的行為。 例如,Blob 儲存體觸發程序會藉由在儲存體中的特定主機識別碼路徑下寫入收據,追蹤是否已處理個別的 Blob。 當主機識別碼變更或您指向新的儲存體帳戶時,可能會重新處理以前處理過的 Blob。
您可以使用 AzureFunctionsWebHost__hostid
設定,在應用程式設定中明確設定函數應用程式的特定主機識別碼。 如需詳細資訊,請參閱 AzureFunctionsWebHost__hostid。
當位置之間發生衝突時,您必須為每個位置設定特定的主機識別碼,包括生產位置。 您也必須將這些設定標示為部署設定,使其不會進行交換。 若要了解如何建立應用程式設定,請參閱使用應用程式設定。
當您的函數應用程式部署至已啟用 Azure Arc 的 Kubernetes 叢集時,函數應用程式可能不需要儲存體帳戶。 在此情況下,只有在函數應用程式使用一個需要儲存體的觸發程序時,Functions 才需要儲存體帳戶。 下表指出哪些觸發程序可能需要儲存體帳戶,以及哪些觸發程序不需要。
非必要 | 可能需要儲存體 |
---|---|
• Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Service Bus |
• Azure SQL • Blob 儲存體 • 事件方格 • 事件中樞 • IoT 中樞 • 佇列儲存體 • SendGrid • SignalR • 表格儲存體 • 計時器 • Twilio |
若要在沒有儲存體的情況下,在已啟用 Azure Arc 的 Kubernetes 叢集上建立函數應用程式,您必須使用 Azure CLI 命令 az functionapp create。 Azure CLI 的版本必須包含 0.1.7 版或更新版本的 appservice-kube 延伸模組。 使用 az --version
命令來驗證是否已安裝延伸模組,而且是正確的版本。
使用 Azure CLI 以外的方法建立函數應用程式資源需要現有的儲存體帳戶。 如果您打算使用任何需要儲存體帳戶的觸發程序,則應該先建立帳戶,再建立函數應用程式。
Azure 檔案儲存體服務提供支援大規模案例的共用文件系統。 當您的函數應用程式在彈性進階或使用量方案中於 Windows 上執行時,預設會在儲存體帳戶中建立 Azure 檔案儲存體共用。 Functions 會使用該共用來啟用特定功能,例如記錄串流。 其也用來做為共用套件部署位置,可保證所有執行個體上已部署函式程式碼的一致性。
根據預設,裝載於進階和使用量方案中的函數應用程式會使用 zip 部署,並將部署套件儲存在此 Azure 檔案共用中。 本節僅與這些主控方案相關。
使用 Azure 檔案儲存體需要使用連接字串,而連接字串會以 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
的形式儲存在您的應用程式設定中。 Azure 檔案儲存體目前不支援身分識別型的連線。 如果您的案例要求您不要將任何秘密儲存在應用程式設定中,則必須移除應用程式對 Azure 檔案儲存體的相依性。 您可以建立沒有預設 Azure 檔案儲存體相依性的應用程式來執行此動作。
注意
您也應該考慮在 Flex 取用方案中的函式應用程式中執行,其可提供對部署套件的更大控制權,包括使用受控識別連線的能力。 如需詳細資訊,請參閱 Flex 使用量一文中的設定部署設定。
若要在沒有 Azure 檔案共用的情況下執行您的應用程式,您必須符合下列需求:
- 您必須將套件部署至遠端 Azure Blob 儲存體容器,然後將提供該套件存取權的 URL 設定為
WEBSITE_RUN_FROM_PACKAGE
應用程式設定。 此選項可讓您將應用程式內容儲存在 Blob 儲存體中,而不是儲存在支援受控識別的 Azure 檔案儲存體中。
您必須負責手動更新部署套件並維護部署套件 URL,其中可能會包含共用存取簽章 (SAS)。
- 您的應用程式不能依賴共用的可寫入檔案系統。
- 應用程式無法使用 Functions 執行階段 1.x 版。
- Azure 入口網站等用戶端記錄串流體驗,預設為檔案系統記錄。 建議改為依賴 Application Insights 記錄。
如果上述需求符合您的案例,您可以繼續建立沒有 Azure 檔案儲存體的函數應用程式。 您可以建立不含 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
和 WEBSITE_CONTENTSHARE
應用程式設定的應用程式來執行此動作。 若要開始使用,請產生標準部署的 ARM 範本、移除這兩項設定,然後部署修改過的範本。
由於 Azure 檔案儲存體是用來啟用 Functions 的動態向外延展,因此若要在 Windows 上執行的彈性進階方案和使用量方案中不使用 Azure 檔案儲存體的情況下執行應用程式,縮放可能會受到限制。
「目前只有在 Linux 上執行時,才能使用這項功能。」
您可以將現有的 Azure 檔案儲存體共用掛接至 Linux 函數應用程式。 藉由將共用掛接至 Linux 函式應用程式,您可以使用現有的機器學習模型或函式中的其他資料。 您可以使用下列命令,將現有的共用掛接到您的 Linux 函式應用程式。
az webapp config storage-account add
在此命令中,share-name
是現有 Azure 檔案儲存體共用的名稱,而且 custom-id
可以是掛接到函數應用程式時,唯一定義共用的任何字串。 此外,mount-path
是在函數應用程式中存取共用的路徑。 mount-path
的格式必須是 /dir-name
,而且開頭不可為 /home
。
如需完整範例,請參閱建立 Python 函數應用程式並掛接 Azure 檔案儲存體共用中的指令碼。
目前,僅支援 AzureFiles
的 storage-type
。 您只能將五個共用掛接至指定的函數應用程式。 當儲存體帳戶位於不同區域時,掛接檔案共用可能會讓冷啟動時間至少增加 200-300 毫秒,甚至更多。
掛接的共用可供 mount-path
指定的函式程式碼使用。 例如,當 mount-path
為 /path/to/mount
時,您可以根據檔案系統 API 存取目標目錄,如以下 Python 範例所示:
import os
...
files_in_share = os.listdir("/path/to/mount")
深入了解 Azure Functions 裝載選項。