共用方式為

Azure Functions 中的部署技術

您可以使用幾個不同的技術，將 Azure Functions 專案程式碼部署至 Azure。 本文提供可供您使用的部署方法概觀，以及各種案例中最佳使用方法的建議。 其也會提供基礎部署技術的完整清單與重要詳細資料。

部署方法

您用於在 Azure 中將程式碼發佈至函式應用程式的部署技術，取決於您的特定需求和開發週期中的時間點。 例如，在開發和測試期間，您可以直接從開發工具部署，例如 Visual Studio Code。 當您的應用程式位於生產環境中時，更可能從原始檔控制中或使用自動化發佈管線持續發佈，其中包括驗證與測試。

下表描述程式碼專案的可用部署方法。

部署類型 方法 適用對象
以工具為基礎 • Azure CLI
• Visual Studio Code 發佈
• Visual Studio 發佈
• Core Tools 發佈		 開發與其他即興部署期間的部署。 使用本機開發工具視需要部署程式碼。
受 App Service 管理 • 部署中心 (CI/CD)
• 容器部署		 來自原始檔控制或容器登錄的持續部署 (CI/CD)。 由 App Service 平台 (Kudu) 管理部署。
外部管線 • Azure Pipelines
• GitHub 操作		 包含驗證、測試與其他動作的生產管線必須在自動化部署中執行。 由管線管理部署。

特定部署應根據特定案例使用最佳技術。 許多部署方法都是以 zip 部署為基礎，建議用於部署。

部署技術可用性

部署方法也取決於您執行函式應用程式的主控方案和作業系統。

Azure Functions 目前提供了五個用於裝載函式應用程式的選項：

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

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

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

重要概念

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

觸發同步

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

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

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

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

  • 使用 az rest (部分機器翻譯) 命令來傳送會呼叫 syncfunctiontriggers API 的 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 同步並重新部署您的更新。 Azure Functions 主機也會在應用程式啟動之後執行背景觸發程序同步作業。 不過，針對使用量和彈性進階主控方案，您也應該在這些案例中手動同步觸發程序：

  • 當部署使用外部套件 URL，搭配以 ARM 範本或是 Bicep 或 Terraform 檔案來進行的資源管理員型部署時。
  • 當您使用相同的外部套件 URL「就地」更新部署套件時。

遠端組建

您可以要求 Azure Functions 在部署期間執行程式碼專案遠端組建。 在以下案例中，請要求遠端組建，而非進行本機建置：

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

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

在 Windows 上執行的所有函數應用程式都有小型管理應用程式，即 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 中使用。 若要判斷每個主控方案支援哪些技術，請參閱 部署技術可用性 數據表。

一個部署

彈性使用量方案 (部分機器翻譯) 上的應用程式唯一支援的部署技術是「一個部署」。 最終結果是函式應用程式執行所在的可立即執行 .zip 套件。

使用方式：使用 Visual Studio Code (部分機器翻譯) 發佈功能進行部署，或使用 Azure Functions Core Tools 或 Azure CLI (部分機器翻譯) 從命令列進行部署。 我們的 Azure Dev Ops 工作 (部分機器翻譯) 和 GitHub 動作 (部分機器翻譯) 同樣會利用「一個部署」(當其偵測到系統正在部署彈性使用量應用程式時)。

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

使用時機： One deploy 是在 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 本身時，也必須手動重新啟動函數應用程式來同步觸發程序。 請參閱關於如何設定此部署技術的操作指南 (部分機器翻譯)。

使用時機：對於在 Linux 使用量方案上執行的應用程式，當您不想發生遠端組建時，唯一支援的部署方法就是外部套件 URL。 當您建立應用程式而不使用 Azure 檔案儲存體 (部分機器翻譯) 時，此方法也是建議的部署技術。 對於在 Linux 上執行的可調整應用程式，請改為考慮彈性使用量方案裝載。

應用程式內容的儲存位置：您必須負責將應用程式內容上傳至 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 檔案服務支援時，FTP/FTPS 部署會失敗。 FTP/FTPS 使用 Azure 檔案作為掛載存儲時會因FTP 限制而失敗。

入口網站編輯

在入口網站型編輯器中，您可以直接編輯函數應用程式中的檔案 (基本上會在每次儲存變更時進行部署)。

使用方式：若要能夠在 Azure 入口網站中編輯函式，您必須已在入口網站中建立函式。 若要保留單一事實來源，使用任何其他部署方法可讓您的函式唯讀，並防止繼續編輯入口網站。 若要回到您可以在 Azure 入口網站中編輯檔案的狀態，可以手動將編輯模式切換回 Read/Write，並移除任何與部署相關的應用程式設定 (例如 WEBSITE_RUN_FROM_PACKAGE)。

使用時機：入口網站是開始使用 Azure Functions 的好方式。 由於 Azure 入口網站中的開發限制 (部分機器翻譯)，請使用下列其中一個用戶端工具更進階的開發工作：

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

部署行為

當您將更新部署至函式應用程式的程式碼時，部署行爲會取決於您的裝載方案:

消費、彈性進階和專用方案： 部署新程式碼時，目前正在執行的函式會終止。 部署完成之後，會載入新的程式碼以開始處理要求。 這種強制終止行為稱為重新建立策略。 對於使用量、彈性進階版和專用方案上接近零停機時間的部署，請使用 部署位置。

請檢閱改善 Azure Functions 的效能和可靠性，以了解如何撰寫無狀態和防禦性函式。

彈性消費計劃： 預設行為也會使用重新建立策略，在部署期間終止目前執行的函式。 不過，Flex Consumption 唯一支援兩種不同的網站更新策略。 您可以為零停機部署設定 滾動更新 。

部署位置

當您將函數應用程式部署至 Azure 時，可以部署至個別的部署位置，而不是直接部署至生產環境。 部署至部署位置然後在驗證之後交換至生產環境，是設定持續部署的建議方式。

部署至位置的方式取決於您使用的特定部署工具。 例如，使用 Azure Functions Core Tools 時，您會包含 --slot 選項來指出 func azure functionapp publish 命令的特定位置名稱。

如需部署位置的詳細資訊，請參閱 Azure Functions 部署位置文件以取得詳細資料。

後續步驟

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

  • Last updated on