分享方式：

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 提供五個選項來裝載函式應用程式：

每個方案都有不同的行為。 並非所有部署技術都適用於每個主控方案和作業系統。 此圖表提供所支援部署技術的相關資訊：

部署技術 Flex Consumption 耗用 彈性進階 專用 容器應用程式
OneDeploy ✔
Zip 部署 ✔ ✔ ✔
外部套件 URL1 ✔ ✔ ✔
Docker 容器 僅限 Linux 僅限 Linux 僅限 Linux ✔
原始檔控制 僅限 Windows ✔ ✔
本機 Git1 僅限 Windows ✔ ✔
FTPS1 僅限 Windows ✔ ✔
入口網站內編輯2 ✔ ✔ ✔

1 不建議使用需要手動同步觸發程序的部署技術。
2 當程式碼從入口網站外部部署至函式應用程式時，入口網站內編輯會停用。 如需詳細資訊，包括入口網站內編輯的語言支援詳細資料，請參閱語言支援詳細資料。

重要概念

某些重要概念對於了解部署在 Azure Functions 中的運作方式非常重要。

觸發同步

當您變更任何觸發程序時，Functions 基礎結構必須注意這些變更。 許多部署技術都會自動進行同步處理。 然而，在某些情況下，您必須手動同步觸發程序。

使用這些部署選項時，您必須手動同步觸發程序：

您可以使用下列其中一種方式來同步觸發程式：

  • 重新啟動 Azure 入口網站中的函數應用程式。

  • az rest使用 命令來傳送呼叫 API 的 syncfunctiontriggers HTTP POST 要求，如下列範例所示：

    az rest --method post --url https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>/syncfunctiontriggers?api-version=2016-08-01

當您部署已更新的部署套件版本並維護相同的外部套件 URL 時，您必須手動重新啟動函數應用程式。 這表示主機應該從相同的套件 URL 同步和重新部署您的更新。 Functions 主機也會在應用程式啟動之後執行背景觸發程序同步。 不過，針對使用量和彈性進階主控方案，您也應該在這些案例中手動同步觸發程序：

  • 使用外部套件 URL 搭配 ARM 範本或 Terraform 進行部署。
  • 在相同的外部套件 URL 上更新部署套件時。

遠端組建

您可以要求 Azure Functions 在部署期間執行程式碼專案的遠端建置。 在這些案例中，您應該要求遠端組建，而不是在本機建置：

  • 您要將應用程式部署到在 Windows 電腦上開發的 Linux 函式應用程式。 這通常是 Python 應用程式開發的情況。 在 Windows 本機建置部署套件時，您最終可能會使用不正確的連結庫。
  • 您的專案相依於 自定義套件索引。
  • 您想要減少部署套件的大小。

您要求遠端組建的方式取決於您的應用程式是在 Windows 或 Linux 上的 Azure 中執行。

在 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> 來更新函式應用程式。 此命令可能需要嘗試兩次才能成功。

應用程式內容儲存體

以套件為基礎的部署方法會將套件儲存在與函式應用程式相關聯的記憶體帳戶中，此帳戶定義於 AzureWebJobsStorage 設定中。 當可用時，取用和彈性進階方案應用程式會嘗試從此帳戶使用 Azure 檔案儲存體 內容共用，但您也可以在另一個位置維護套件。 彈性取用方案應用程式會改用預設記憶體帳戶中的記憶體容器，除非您 將不同的記憶體帳戶設定為用於部署。 如需詳細資訊，請檢閱 下一節涵蓋的每個部署技術中儲存應用程式內容 的詳細數據。

重要

儲存體帳戶可用來儲存重要的應用程式資料，有時還包含應用程式的程式碼本身。 您應該限制其他應用程式和使用者存取儲存體帳戶。

部署技術詳細資料

下列部署方法可在 Azure Functions 中使用。

一個部署

其中一個部署是 Flex Consumption 方案上唯一支援應用程式的部署技術。 最終結果是函式應用程式執行的現成.zip套件。

作法：使用 Visual Studio Code 發佈功能進行部署，或使用 Azure Functions Core Tools 或 Azure CLI 從命令行進行部署。 我們的 Azure Dev Ops 工作 和 GitHub 動作 同樣會在偵測到 Flex Consumption 應用程式部署至時，利用一個部署。

當您建立 Flex 取用應用程式時，您必須指定部署記憶體 （blob） 容器，以及它的驗證方法。 根據預設，會使用與連線相同的記憶體帳戶AzureWebJobsStorage，並使用 連接字串 做為驗證方法。 因此，您的 部署設定 會在應用程式建立期間設定，而不需要應用程式設定。

使用時機： 一個部署是彈性取用方案上執行之函式應用程式唯一可用的部署技術。

儲存應用程式內容的位置： 當您建立 Flex Consumption 函式應用程式時，您可以指定 部署記憶體容器。 這是 Blob 容器，平臺會上傳您部署的應用程式內容。 若要變更位置，您可以流覽 Azure 入口網站 中的 [部署設定] 刀鋒視窗，或使用 Azure CLI。

Zip 部署

Zip 部署是取用、彈性進階和 App Service （專用） 方案上函式應用程式的預設和建議部署技術。 最終結果為函式應用程式執行的現成.zip套件。 不同於外部套件 URL，我們的平臺負責遠端建置和儲存您的應用程式內容。

作法：使用您慣用的用戶端工具進行部署：Visual Studio Code、Visual Studio，或使用 Azure Functions Core Tools 或 Azure CLI 從命令行進行部署。 我們的 Azure Dev Ops 工作 和 GitHub 動作 同樣會利用 zip 部署。

當您使用 zip 部署進行部署時，您可以將應用程式設定 為從套件執行。 若要從套件執行，請將 WEBSITE_RUN_FROM_PACKAGE 應用程式設定值設定為 1。 建議使用 zip 部署。 其會為您的應用程式產生更快的載入時間，且其為 VS Code、Visual Studio 與 Azure CLI 的預設值。

使用時機： Zip 部署是 Windows 使用量、Windows 和 Linux 彈性進階版和 Windows 和 Linux App Service （專用） 方案上函式應用程式的預設和建議部署技術。

應用程式內容的儲存位置：zip 部署的應用程式內容預設會儲存在檔案系統上，這可能由建立函式應用程式時指定的儲存體帳戶中的 Azure 檔案儲存體提供支援。 在 Linux 取用中，應用程式內容會改為保存在應用程式設定所 AzureWebJobsStorage 指定的記憶體帳戶中的 Blob 上，而應用程式設定 WEBSITE_RUN_FROM_PACKAGE 會採用 Blob URL 的值。

外部套件 URL

如果您想要手動控制部署的執行方式，外部套件 URL 是一個選項。 您必須負責將現成執行.zip套件上傳至 Blob 記憶體，並將此外部 URL 參考為函式應用程式上的應用程式設定。 每當您的應用程式重新啟動時，它會擷取套件、掛接套件，並在 [從套件執行] 模式中執行。

使用方式：將 WEBSITE_RUN_FROM_PACKAGE 新增至您的應用程式設定。 此設定的值應該是一個 Blob URL，指向您想要應用程式執行之特定套件的位置。 您可以在入口網站中新增設定，或使用 Azure CLI 來新增設定。

如果您使用 Azure Blob 儲存體，您的函式應用程式可以使用受控識別型連線或共用存取簽章 （SAS）來存取容器。 您選擇的選項會影響您作為WEBSITE_RUN_FROM_PACKAGE值所使用的 URL 類型。 建議使用受控識別來獲得整體安全性，而且因為 SAS 令牌過期且必須手動維護。

當您部署函數應用程式參考的套件檔案時，您必須手動同步觸發程序，包括初始部署。 當您變更套件檔案的內容，而不是 URL 本身時，也必須手動重新啟動函數應用程式來同步觸發程序。 請參閱設定 此部署技術的作法指南 。

使用時機：當您不想發生遠端組建時，外部套件 URL 是 Linux 取用方案上執行之應用程式唯一支援的部署方法。 當您建立應用程式而不需 Azure 檔案儲存體 時，此方法也是建議的部署技術。 針對在Linux上執行的可調整應用程式，您應該改為考慮 Flex Consumption 方案 裝載。

儲存應用程式內容的位置： 您必須負責將應用程式內容上傳至 Blob 記憶體。 雖然建議使用任何 Blob 記憶體帳戶，但建議使用 Azure Blob 儲存體。

Docker 容器

您可以部署在 Linux 容器中執行的函式應用程式。

使用方式： 在 Linux 容器中建立函式，然後將容器部署至 Azure Functions 或其他容器主機中的進階或專用方案。 使用 Azure Functions Core Tools，為您用來建置容器化函式應用程式的專案建立自訂 Dockerfile。 您可以在下列部署中使用容器：

使用時機：當您需要更充分掌控函式應用程式執行所在和容器裝載所在的 Linux 環境時，請使用 Docker 容器選項。 此部署機制僅適用於在 Linux 上執行的函式。

應用程式內容的儲存位置：應用程式內容會儲存在指定的容器登錄中作為映像的一部分。

原始檔控制

您可以啟用函數應用程式與原始程式碼存放庫之間的持續整合。 啟用原始檔控制後，連線的來源存放庫中的程式碼更新會觸發從存放庫部署最新的程式碼。 如需詳細資訊，請參閱 Azure Functions 的持續部署。

使用方式：從原始檔控制設定發佈的最簡單方式是，使用入口網站 [Functions] 區域中的 [部署中心]。 如需詳細資訊，請參閱 Azure Functions 的持續部署。

使用時機：針對在其函數應用程式上共同作業的小組，使用原始檔控制是最佳做法。 原始檔控制是一個很好的部署選項，可啟用更複雜的部署管線。 原始檔控制通常會在預備位置上啟用，這可以在從存放庫驗證更新之後交換為生產環境。 如需詳細資訊，請參閱 Azure Functions 部署位置。

應用程式內容的儲存位置：應用程式內容位於原始檔控制系統中，但本機複製和建置的應用程式內容會儲存在應用程式檔案系統上，這可能由建立函式應用程式時指定的儲存體帳戶中的 Azure 檔案儲存體提供支援。

本機 Git

您可以使用本機 Git，藉由使用 Git 將程式碼從本機電腦推送至 Azure Functions。

使用方式：遵循 Azure App Service 其本機 Git 部署中的指示。

使用時機：若要減少出錯的機會，您應該避免使用需要手動同步觸發程序額外步驟的部署方法。 盡可能使用 zip 部署。

應用程式內容的儲存位置：應用程式內容會儲存在檔案系統上，這可能由建立函式應用程式時指定的儲存體帳戶中的 Azure 檔案儲存體提供支援。

FTP/S

雖然不建議使用此部署方法，但您可使用 FTP/S 將檔案直接傳輸至 Azure Functions。 當您不打算使用 FTP 時，應該予以停用。 如果您選擇使用 FTP，則應該強制使用 FTPS。 若要了解如何在 Azure 入口網站中進行，請參閱強制使用 FTPS。

使用方式：遵循 FTPS 部署設定中的指示，以取得您可使用 FTPS 部署至函式應用程式的 URL 和認證。

使用時機：若要減少出錯的機會，您應該避免使用需要手動同步觸發程序額外步驟的部署方法。 盡可能使用 zip 部署。

應用程式內容的儲存位置：應用程式內容會儲存在檔案系統上，這可能由建立函式應用程式時指定的儲存體帳戶中的 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 部署位置文件以取得詳細資料。

下一步

請閱讀下列文章，以深入了解如何部署函數應用程式：