Azure Functions 中的部署技術
您可以使用幾個不同的技術,將 Azure Functions 專案程式碼部署至 Azure。 本文提供可供您使用的部署方法概觀,以及各種案例中最佳使用方法的建議。 其也會提供基礎部署技術的完整清單與重要詳細資料。
部署方法
您用於在 Azure 中將程式碼發佈至函式應用程式的部署技術,取決於您的特定需求和開發週期中的時間點。 例如,在開發與測試期間,您可以直接從開發工具 (例如 Visual Studio Code) 進行部署。 當您的應用程式位於生產環境中時,更可能從原始檔控制中或使用自動化發佈管線持續發佈,其中包括驗證與測試。
下表描述程式碼專案的可用部署方法。
部署類型 | 方法 | 適用對象 |
---|---|---|
以工具為基礎 | • Visual Studio Code 發佈 • Visual Studio 發佈 • Core Tools 發佈 |
開發與其他即興部署期間的部署。 使用本機開發工具視需要部署程式碼。 |
受 App Service 管理 | • 部署中心 (CI/CD) • 容器部署 |
來自原始檔控制或容器登錄的持續部署 (CI/CD)。 由 App Service 平台 (Kudu) 管理部署。 |
外部管線 | • Azure Pipelines • GitHub Actions |
包含驗證、測試與其他動作的生產管線必須在自動化部署中執行。 由管線管理部署。 |
特定部署應根據特定案例使用最佳技術。 許多部署方法都是以 zip 部署為基礎,建議用於部署。
部署技術可用性
部署方法也取決於您執行函式應用程式的主控方案和作業系統。
Functions 目前提供三個主控方案:
每個方案都有不同的行為。 並非所有部署技術都適用於每個主控方案和作業系統。 此圖表提供所支援部署技術的相關資訊:
部署技術 | Windows 使用量 | Windows 進階 | Windows 專用 | Linux 使用量 | Linux 進階 | Linux 專用 |
---|---|---|---|---|---|---|
外部套件 URL1 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
Zip 部署 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
Docker 容器 | ✔ | ✔ | ||||
原始檔控制 | ✔ | ✔ | ✔ | ✔ | ✔ | |
本機 Git1 | ✔ | ✔ | ✔ | ✔ | ✔ | |
FTPS1 | ✔ | ✔ | ✔ | ✔ | ✔ | |
入口網站內編輯2 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
1 不建議使用需要手動同步觸發程序的部署技術。
2 當程式碼從入口網站外部部署至函式應用程式時,入口網站內編輯會停用。 如需詳細資訊,包括入口網站內編輯的語言支援詳細資料,請參閱語言支援詳細資料。
重要概念
某些重要概念對於了解部署在 Azure Functions 中的運作方式非常重要。
觸發同步
當您變更任何觸發程序時,Functions 基礎結構必須注意這些變更。 許多部署技術都會自動進行同步處理。 然而,在某些情況下,您必須手動同步觸發程序。
使用這些部署選項時,您必須手動同步觸發程序:
您可以分別以三種方式同步觸發程序:
- 重新啟動 Azure 入口網站中的函數應用程式。
- 使用主要金鑰將 HTTP POST 要求傳送至
https://{functionappname}.azurewebsites.net/admin/host/synctriggers?code=<API_KEY>
。 - 將 HTTP POST 要求傳送至
https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.Web/sites/<FUNCTION_APP_NAME>/syncfunctiontriggers?api-version=2016-08-01
。 以您的訂閱識別碼、資源群組名稱與函數應用程式名稱取代預留位置。 此要求需要Authorization
要求標頭中的存取權杖。
當您部署已更新的部署套件版本並維護相同的外部套件 URL 時,您必須手動重新啟動函數應用程式。 這表示主機應該從相同的套件 URL 同步和重新部署您的更新。 Functions 主機也會在應用程式啟動之後執行背景觸發程序同步。 不過,針對使用量和彈性進階主控方案,您也應該在這些案例中手動同步觸發程序:
- 使用外部套件 URL 搭配 ARM 範本或 Terraform 進行部署。
- 在相同的外部套件 URL 上更新部署套件時。
遠端組建
Azure Functions 可以在 zip 部署之後收到的程式碼上自動執行組建。 這些組建會依據您的應用程式是在 Windows 或 Linux 上執行而有不同。
在 Windows 上執行的所有函數應用程式都有小型管理應用程式,即 Kudu 所提供的 scm
網站。 此網站會處理 Azure Functions 的大部分部署與建置邏輯。
當應用程式部署至 Windows 時,會執行 dotnet restore
(C#) 或 npm install
(JavaScript) 等特定語言命令。
在部署期間使用遠端建置時,適用下列考量:
- 在使用者方案中,Linux 上執行的函數應用程式支援遠端組建。 不過,這些應用程式的部署選項會受到限制,因為其沒有
scm
(Kudu) 網站。 - 進階方案或專用 (App Service) 方案中在 Linux 上執行的函式應用程式確實有
scm
(Kudu) 網站,但與 Windows 相比,此方案受到限制。 - 當應用程式使用 run-from-package 時,不會執行遠端組建。 若要了解如何在這些情況下使用遠端建置,請參閱 Zip 部署。
- 若您的應用程式在遠端建置功能提供之前 (2019 年 8 月 1 日) 建立,您可能會有遠端建置的問題。 對於較舊的應用程式,請建立新的函式應用程式,或執行
az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME>
來更新函式應用程式。 此命令可能需要嘗試兩次才能成功。
應用程式內容儲存體
數個部署方法會將已部署或建置的應用程式承載存放在與函式應用程式相關聯的儲存體帳戶上。 Functions 會在設定時嘗試使用 Azure 檔案儲存體內容共用,但有些方法會改為將承載存放在與 AzureWebJobsStorage
連線相關聯的 Blob 儲存體執行個體中。 請參閱下一節所涵蓋之每項部署技術的應用程式內容的儲存位置段落中的詳細資料。
重要
儲存體帳戶可用來儲存重要的應用程式資料,有時還包含應用程式的程式碼本身。 您應該限制其他應用程式和使用者存取儲存體帳戶。
部署技術詳細資料
下列部署方法可在 Azure Functions 中使用。
外部套件 URL
您可以使用外部套件 URL 來參考包含函數應用程式的遠端套件 (.zip) 檔案。 檔案會從提供的 URL 下載,且應用程式會在從套件執行模式中執行。
使用方式:將
WEBSITE_RUN_FROM_PACKAGE
新增至您的應用程式設定。 此設定的值應該是 URL (您所要執行特定套件檔案的位置)。 您可以在入口網站中新增設定,或使用 Azure CLI 來新增設定。若您使用 Azure Blob 儲存體,請使用具有共用存取簽章 (SAS) 的私人容器,為 Functions 提供套件的存取權。 每當應用程式重新啟動時,其會擷取內容的複本。 在應用程式的存留期內,您的參考必須有效。
使用時機:若使用者不想要發生遠端組建,則外部套件 URL 是唯一支援使用情況方案中 Azure Functions 在 Linux 上執行的部署方法。 當您部署函數應用程式參考的套件檔案時,您必須手動同步觸發程序,包括初始部署。 當您變更套件檔案的內容,而不是 URL 本身時,也必須手動重新啟動函數應用程式來同步觸發程序。
應用程式內容的儲存位置:應用程式內容會存放在指定的 URL。 這可能位於 Azure Blob 上,可能是在
AzureWebJobsStorage
連線所指定的儲存體帳戶中。 有些用戶端工具預設會部署至此帳戶中的 Blob。 例如,針對 Linux 取用應用程式,Azure CLI 會嘗試透過儲存在AzureWebJobsStorage
所指定帳戶上 Blob 中的套件進行部署。
Zip 部署
使用 .zip 部署,將包含函數應用程式的 .zip 檔案推送至 Azure。 您可以選擇性地將應用程式設定為從套件開始執行,或指定發生遠端組建。
使用方式:使用您慣用的用戶端工具來部署:Visual Studio Code、Visual Studio;或使用 Azure Functions Core Tools 從命令列進行部署。 根據預設,這些工具會使用 zip 部署,並從套件中執行。 Core Tools 與 Visual Studio Code 延伸模組都會在部署至 Linux 時啟用遠端組建。 若要手動將 .zip 檔案部署至函數應用程式,請遵循從 .zip 檔案或 URL 部署中的指示。
當您使用 zip 部署進行部署時,您可以將應用程式設定 為從套件執行。 若要從套件執行,請將
WEBSITE_RUN_FROM_PACKAGE
應用程式設定值設定為1
。 建議使用 zip 部署。 其會為您的應用程式產生更快的載入時間,且其為 VS Code、Visual Studio 與 Azure CLI 的預設值。
使用時機:Zip 部署是建議用於 Azure Functions 的部署技術。
應用程式內容的儲存位置:zip 部署的應用程式內容預設會儲存在檔案系統上,這可能由建立函式應用程式時指定的儲存體帳戶中的 Azure 檔案儲存體提供支援。 在 Linux 取用中,應用程式內容會改為保存在
AzureWebJobsStorage
連線所指定的儲存體帳戶中的 Blob 上。
Docker 容器
您可以部署在 Linux 容器中執行的函式應用程式。
使用方式: 在 Linux 容器中建立函式,然後將容器部署至 Azure Functions 或其他容器主機中的進階或專用方案。 使用 Azure Functions Core Tools,為您用來建置容器化函式應用程式的專案建立自訂 Dockerfile。 您可以在下列部署中使用容器:
- 部署至您在 Azure 入口網站中建立的 Azure Functions 資源。 如需詳細資訊,請參閱使用容器在 Azure 入口網站中建立。
- 部署至您從命令列建立的 Azure Functions 資源。 需要進階或專用 (App Service) 方案。 若要了解做法,請參閱建立您的第一個容器化 Azure Functions。
- 部署至 Azure 容器應用程式。 若要了解做法,請參閱在 Azure 容器應用程式上建立您的第一個容器化 Azure Functions。
- 部署至 Azure Arc (預覽)。 若要了解做法,請參閱在 Azure Arc 上建立您的第一個容器化 Azure Functions (預覽)。
- 部署至 Kubernetes 叢集。 您可使用 Azure Functions Core Tools 部署至叢集。 使用
func kubernetes deploy
命令。
使用時機:當您需要更充分掌控函式應用程式執行所在和容器裝載所在的 Linux 環境時,請使用 Docker 容器選項。 此部署機制僅適用於在 Linux 上執行的函式。
應用程式內容的儲存位置:應用程式內容會儲存在指定的容器登錄中作為映像的一部分。
原始檔控制
您可以啟用函數應用程式與原始程式碼存放庫之間的持續整合。 啟用原始檔控制後,連線的來源存放庫中的程式碼更新會觸發從存放庫部署最新的程式碼。 如需詳細資訊,請參閱 Azure Functions 的持續部署。
使用方式:從原始檔控制設定發佈的最簡單方式是,使用入口網站 [Functions] 區域中的 [部署中心]。 如需詳細資訊,請參閱 Azure Functions 的持續部署。
使用時機:針對在其函數應用程式上共同作業的小組,使用原始檔控制是最佳做法。 原始檔控制是一個很好的部署選項,可啟用更複雜的部署管線。 原始檔控制通常會在預備位置上啟用,這可以在從存放庫驗證更新之後交換為生產環境。 如需詳細資訊,請參閱 Azure Functions 部署位置。
應用程式內容的儲存位置:應用程式內容位於原始檔控制系統中,但本機複製和建置的應用程式內容會儲存在應用程式檔案系統上,這可能由建立函式應用程式時指定的儲存體帳戶中的 Azure 檔案儲存體提供支援。
本機 Git
您可以使用本機 Git,藉由使用 Git 將程式碼從本機電腦推送至 Azure Functions。
使用方式:遵循 Azure App Service 其本機 Git 部署中的指示。
應用程式內容的儲存位置:應用程式內容會儲存在檔案系統上,這可能由建立函式應用程式時指定的儲存體帳戶中的 Azure 檔案儲存體提供支援。
FTP/S
雖然不建議使用此部署方法,但您可使用 FTP/S 將檔案直接傳輸至 Azure Functions。 當您不打算使用 FTP 時,應該予以停用。 如果您選擇使用 FTP,則應該強制使用 FTPS。 若要了解如何在 Azure 入口網站中進行,請參閱強制使用 FTPS。
使用方式:遵循 FTPS 部署設定中的指示,以取得您可使用 FTPS 部署至函式應用程式的 URL 和認證。
應用程式內容的儲存位置:應用程式內容會儲存在檔案系統上,這可能由建立函式應用程式時指定的儲存體帳戶中的 Azure 檔案儲存體提供支援。
入口網站編輯
在入口網站型編輯器中,您可以直接編輯函數應用程式中的檔案 (基本上會在每次儲存變更時進行部署)。
使用方式:若要能夠在 Azure 入口網站中編輯函式,您必須已在入口網站中建立函式。 若要保留單一事實來源,使用任何其他部署方法可讓您的函式唯讀,並防止繼續編輯入口網站。 若要回到您可以在 Azure 入口網站中編輯檔案的狀態,可以手動將編輯模式切換回
Read/Write
,並移除任何與部署相關的應用程式設定 (例如WEBSITE_RUN_FROM_PACKAGE
)。
使用時機:入口網站是開始使用 Azure Functions 的好方式。 如需更進階的開發工作,建議您使用下列其中一個用戶端工具:
應用程式內容的儲存位置:應用程式內容會儲存在檔案系統上,這可能由建立函式應用程式時指定的儲存體帳戶中的 Azure 檔案儲存體提供支援。
下表顯示支援入口網站內編輯的作業系統與語言:
語言 | Windows 使用量 | Windows 進階 | Windows 專用 | Linux 使用量 | Linux 進階 | Linux 專用 |
---|---|---|---|---|---|---|
C#1 | ||||||
Java | ||||||
JavaScript (Node.js) | ✔ | ✔ | ✔ | ✔ | ✔ | |
Python2 | ✔ | ✔ | ✔ | |||
PowerShell | ✔ | ✔ | ✔ | |||
TypeScript (Node.js) |
1 僅 C# 指令檔支援入口網站內編輯,這些檔案會與主機一起進行同執行序執行。 如需詳細資訊,請參閱 Azure Functions C# 指令碼 (.csx) 開發人員參考。
2 入口網站內編輯僅支援 v1 Python 程式設計模型。
部署行為
當您將更新部署至函數應用程式程式碼時,目前執行的函式將會終止。 部署完成之後,會載入新的程式碼以開始處理要求。 請檢閱改善 Azure Functions 的效能和可靠性,以了解如何撰寫無狀態和防禦性函式。
若您需要更充分掌控此轉換,應該使用部署位置。
部署位置
當您將函數應用程式部署至 Azure 時,可以部署至個別的部署位置,而不是直接部署至生產環境。 部署至部署位置然後在驗證之後交換至生產環境,是設定持續部署的建議方式。
部署至位置的方式取決於您使用的特定部署工具。 例如,使用 Azure Functions Core Tools 時,您會包含 --slot
選項來指出 func azure functionapp publish
命令的特定位置名稱。
如需部署位置的詳細資訊,請參閱 Azure Functions 部署位置文件以取得詳細資料。
下一步
請閱讀下列文章,以深入了解如何部署函數應用程式: