Azure Functions 中的部署技术

可以使用多种不同的技术将 Azure Functions 项目代码部署到 Azure。 本文概述了可用的部署方法,以及在各种方案中使用的最佳方法建议。 此外,还提供了有关基本部署技术的详尽列表和重要详细信息。

部署方法

用于将代码发布到 Azure 中的函数应用的部署技术取决于特定需求和在开发周期中所处的阶段。 例如,在开发和测试期间,可以直接从开发工具(如 Visual Studio Code)进行部署。 当应用处于生产阶段时,你更有可能从源代码管理或使用自动发布管道(其中可能包括验证和测试)持续发布。

下表介绍了代码项目的可用部署方法。

部署类型 方法 最适用于...
基于工具 Visual Studio Code 发布
Visual Studio 发布
Core Tools 发布
开发期间的部署和其他临时部署。 使用本地开发工具按需部署代码。
托管的应用服务 • 部署中心 (CI/CD)
• 容器部署
从源代码管理或从容器注册表进行持续部署 (CI/CD)。 部署由应用服务平台 (Kudu) 进行管理。
外部管道 GitHub Actions 生产管道,包含验证、测试和必须作为自动部署的一部分运行的其他操作。 部署由管道进行管理。

具体部署应根据具体方案采用最佳技术。 很多部署方式都基于压缩部署,这是建议的部署方法。

部署技术的可用性

部署方法还取决于运行函数应用的托管计划和操作系统。
目前,Functions 提供三种托管计划:

每种计划有不同的行为。 并非所有部署技术都适用于每个托管计划和操作系统。 此图表提供有关支持的部署技术的信息:

部署技术 Windows 消耗计划 Windows 高级计划 Windows 专用计划 Linux 消耗计划 Linux 高级计划 Linux 专用计划
外部包 URL1
压缩部署
Docker 容器
源代码管理
本地 Git1
FTPS1
门户中编辑2

1 不建议使用需要手动同步触发器的部署技术。
2 从门户外部将代码部署到函数应用时,将禁用门户内编辑。 有关详细信息(包括门户内编辑的语言支持详细信息),请参阅语言支持详细信息

关键概念

若要了解 Azure Functions 中的部署工作原理,必须先掌握一些关键概念。

触发器同步

更改任何触发器时,Functions 基础结构必须意识到这些更改。 对于许多部署技术而言,同步会自动进行。 但在某些情况下,必须手动同步触发器。

使用这些部署选项时,必须手动同步触发器:

可通过以下三种方式之一来同步触发器:

  • 在 Azure 门户中重启函数应用。
  • 使用https://{functionappname}.chinacloudsites.cn/admin/host/synctriggers?code=<API_KEY>将 HTTP POST 请求发送到 https://{functionappname}.chinacloudsites.cn/admin/host/synctriggers?code=<API_KEY>
  • 将 HTTP POST 请求发送到 https://management.chinacloudapi.cn/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.Web/sites/<FUNCTION_APP_NAME>/syncfunctiontriggers?api-version=2016-08-01。 请将占位符替换为你的订阅 ID、资源组名称和函数应用名称。 此请求需要在Authorization请求标头中提供访问令牌

对部署包的更新版本进行部署并保持同一外部包 URL 时,需要手动重启函数应用。 这向主机表明它应该从同一包 URL 同步并重新部署更新。 Functions 主机还会在应用程序启动后执行后台触发器同步。 但是,对于消耗和弹性高级托管计划,还应在以下情况下手动同步触发器

  • 使用外部包 URL 与 ARM 模板或 Terraform 进行部署。
  • 在同一外部包 URL 更新部署包时。

远程生成

Azure Functions 可以自动在它在压缩部署后接收的代码上执行生成操作。 根据应用程序是在 Windows 还是 Linux 上运行,这些构建会有所不同。

在 Windows 上运行的所有函数应用都有一个小的管理应用,即由 Kudu 提供的 scm 站点。 该站点会处理 Azure Functions 的很多部署和生成逻辑。

将应用部署到 Windows 时,会运行特定于语言的命令,例如 dotnet restore (C#) 或 npm install (JavaScript)。

在部署期间使用远程生成时,应注意以下事项:

  • 消耗计划中运行的函数应用支持远程生成。 但是,这些应用的部署选项受到限制,因为它们没有 scm (Kudu) 站点。
  • 高级计划专用(应用服务)计划中,Linux 上运行的函数应用则具有 scm (Kudu) 站点,但与 Windows 上运行的函数应用相比,它们是受限的。
  • 当应用使用从包运行时,不会执行远程生成。 若要了解如何在这些情况下使用远程生成,请参阅 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 下载该文件,应用将在“从包运行”模式下运行。

如何使用:将 添加到应用程序设置。 此设置的值应是一个 URL(要运行的特定包文件的位置)。 可以在门户中使用 Azure CLI 来添加设置。

如果使用 Azure Blob 存储,请结合共享访问签名 (SAS) 使用专用容器,使 Functions 能够访问该包。 每当应用程序重启时,都会提取内容的副本。 引用必须在应用程序的整个生存期内有效。

何时使用: 如果用户不希望进行远程生成,则对于消耗计划中的在 Linux 上运行的 Azure Functions,外部包 URL 是唯一受支持的部署方法。 每当部署函数应用引用的包文件时,都必须手动同步触发器,包括初始部署。 如果你更改包文件的内容但不更改 URL 本身,还必须重启你的函数应用以同步触发器。

应用内容存储在哪里:应用内容存储在 URL 指定的位置。 可能存储在 Azure Blob 上,可能存储在 AzureWebJobsStorage 连接指定的存储帐户中。 某些客户端工具可能默认部署到此帐户中的 Blob。 例如,对于 Linux 消耗计划应用,Azure CLI 将会试图通过 AzureWebJobsStorage 在帐户上的 Blob 中存储的包进行部署。

压缩部署

使用压缩部署可将包含函数应用的 .zip 文件推送到 Azure。 可以选择将应用设置为开始从包运行,或者指定进行远程生成

如何使用: 使用偏爱的客户端工具进行部署:Visual Studio CodeVisual Studio,或从命令行使用 Azure Functions Core Tools。 默认情况下,这些工具使用 zip 部署并从包运行。 Core Tools 和 Visual Studio Code 扩展在部署到 Linux 时都启用远程生成。 若要手动将 .zip 文件部署到函数应用,请遵照从 .zip 文件或 URL 进行部署中的说明操作。

使用压缩部署方法时,可将应用设置为从包运行。 若要从包运行,请将 WEBSITE_RUN_FROM_PACKAGE 应用程序设置值设置为 1。 我们建议使用压缩部署。 此方法可以缩短应用程序加载时间,并且是 VS Code、Visual Studio 和 Azure CLI 的默认部署方法。

何时使用: 压缩部署是建议用于 Azure Functions 的部署技术。

应用内容存储在哪里:来自 zip 压缩包的应用内容默认存储在文件系统中,该系统可能由在创建函数应用时指定的存储帐户中的 Azure 文件提供支持。 在 Linux 消耗计划中,应用内容仍然在 AzureWebJobsStorage 连接指定的存储帐户中的 Blob 上。

Docker 容器

可以部署在 Linux 容器中运行的函数应用。

如何使用它:在 Linux 容器中创建函数,然后将容器部署到 Azure Functions 或其他容器主机中的高级或专用计划。 使用 Azure Functions Core Tools 为用于生成容器化函数应用的项目创建自定义 Dockerfile。 可以在以下部署中使用容器:

何时使用:在需要更好地控制运行函数应用以及托管容器的 Linux 环境时,请使用 Docker 容器选项。 此部署机制仅适用于在 Linux 上运行的函数。

应用内容存储在哪里:应用内容作为映像的一部分,存储在指定的容器注册表中。

源代码管理

可以在函数应用和源代码存储库之间启用持续集成。 启用源代码管理后,对连接的源存储库中的代码的更新会触发存储库中最新代码的部署。

如何使用它: 从源代码管理设置发布的最简单方法是从门户的 Functions 区域中的部署中心进行发布。

何时使用: 对于协作开发函数应用的团队而言,最佳做法是使用源代码管理。 源代码管理是一种很好的部署选项,可实现更复杂的部署管道。 源代码管理通常在过渡槽上启用,该槽可以在从存储库验证更新后交换到生产中。 有关详细信息,请参阅 Azure Functions 部署槽

应用内容存储在哪里:应用内容位于源代码管理系统中,但本地克隆和生成的应用内容则存储在应用文件系统中,该系统可能由在创建函数应用时指定的存储帐户中的 Azure 文件提供支持。

本地 Git

可以使用本地 Git 将代码从本地计算机推送到 Azure Functions。

如何使用: 请遵照使用本地 Git 部署到 Azure 应用服务中的说明。

何时使用:为了降低出错的可能性,应避免使用需要手动同步触发器这一额外步骤的部署方法。 尽可能使用压缩部署

应用内容存储在哪里:应用内容存储在文件系统中,该系统可能由在创建函数应用时指定的存储帐户中的 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 文件提供支持。

下表显示了支持门户内编辑的操作系统和语言:

Language Windows 消耗计划 Windows 高级计划 Windows 专用计划 Linux 消耗计划 Linux 高级计划 Linux 专用计划
C#1
Java
JavaScript (Node.js)
Python2
PowerShell
TypeScript (Node.js)

1 仅支持使用主机运行进程内 C# 脚本文件的 C# 脚本文件。 有关详细信息,请参阅 Azure Functions C# 脚本 (.csx) 开发人员参考
2v1 Python 编程模型支持门户内编辑。

部署行为

将更新部署到函数应用代码时,当前正在执行的函数将终止。 部署完成后,将加载新代码以开始处理请求。 查看提高 Azure Functions 的性能和可靠性,了解如何编写无状态函数和防御函数。

如果需要对此转换进行更多控制,则应使用部署槽。

部署槽

将函数应用部署到 Azure 时,可以部署到单独的部署槽,而不是直接部署到生产槽。

部署到槽的方式取决于你使用的特定部署工具。 例如,使用 Azure Functions Core Tools 时,可以包含 --slot 选项,以指示 func azure functionapp publish 命令的特定槽的名称。

有关部署槽的详细信息,请参阅 Azure Functions 部署槽文档。

后续步骤

请阅读以下文章详细了解如何部署函数应用: