• 项目

2018 年 10 月

33 卷，第 10

此文章由机器翻译

Azure-部署到 Azure 应用服务和 Azure Functions

通过Stuart Leeks |2018 年 10 月

Microsoft Azure 应用服务是一种平台即服务解决方案，允许你构建和部署 Web、 移动和 API 应用在任何平台上运行。它也是 Azure Functions，提供了一种事件驱动、 无服务器计算体验的平台。在本文中我将主要是指 Azure 应用服务，但讨论的部署技术同样适用于 Azure Functions。

部署应用程序时，应用服务提供范围广泛的可供选择的选项。在本文中我将快速看一下不同的部署选项，然后花一些时间深入探讨更多新推出的 zipdeploy，以及运行从包的方法 （它在撰写本文时为预览版）。

介绍的应用服务部署选项

我一直在使用应用服务多年 （因为之前调用应用服务），但在撰写本文时我发现我不知道有关的部署选项：云同步 ！因此，让我们看一看其他更传统上开发人员为中心的方法属于应用服务之前启动的。

云同步与云同步可以将应用服务连接到 OneDrive 或 Dropbox 帐户，它将创建您的网站的文件夹。可以编辑本地站点内容，并具有到云存储在 OneDrive 或 Dropbox 的客户端同步。当你想要将站点从云存储更新时，可以单击门户中的同步按钮。如果在具有静态内容的站点上，并且希望单击一次更新的方法，此流可能是非常适合。云同步部署的完整演练，请参阅bit.ly/2w7C1VK。

好这可怜的家伙 FTP如果您已在编写 Web 应用程序一段时间，则很可能在某一时刻您已使用过古老文件传输协议 (FTP) 作为一种方法 （啊咳） 将文件传输到 Web 服务器。使用应用服务为您的网站，以便您可以使用偏好的 FTP 客户端连接到并与 site/wwwroot 目录同步你的内容获取 FTP 终结点。（默认情况下，启用终结点，但如果您希望可以禁用。）

更多详细信息的使用 FTP 进行部署 （包括使用或通过 SSL 强制 FTP），请参阅bit.ly/2Bw9NtV。

zipdeploy zipdeploy 真正吸引人的方面之一是它很简单。你可能创建的.zip 文件多年以来，和它也很简单.zips 创建跨平台和持续集成 (CI) / 持续部署 (CD) 服务 (如 Visual Studio Team Services (VSTS):

# Bash
zip -r <file-name>.zip .
# PowerShell
Compress-Archive -Path * -DestinationPath <file-name>.zip

.Zip 文件后可以将其部署在多个方面。例如，您可以导航到项目 Kudu 站点，"https:// < a p p _ >.scm.azurewebsites.net/ZipDeploy，"并将该.zip 文件，或者可以使用 Azure CLI:

az webapp deployment source config-zip --resource-group myResourceGroup
   --name <app_name> --src clouddrive/<filename>.zip

或者，你可以对 REST API 使用.zip 文件发布 HTTP 请求：

curl -X POST -u <deployment_user> --data-binary @"<zip_file_path>"
  https://<app_name>.scm.azurewebsites.net/api/zipdeploy

所有这些方法 （包括如何调用从 PowerShell zipdeploy） 涵盖更详细地介绍bit.ly/2tQwaGD。

当部署通过.zip 文件时，你具有吸引力的 Kudu 的部署机制，即，向应用服务中的站点的站点/wwwroot 文件夹中.zip 添加文件。在 Kudu 上的详细信息，请参阅本文中的"项目 Kudu"。

还有可能具有 Kudu 执行部署脚本。若要执行此操作，请告知要运行的脚本的 Kudu.zip 根目录中创建.deployment 文件。此脚本可以执行 npm 安装、 dotnet 生成或任何内容将指导你需要部署的一部分。

如果您正在使用 C# 项目和压缩源，可以设置 SCM_DO_BUILD_DURING_DEPLOYMENT 环境变量 （通过应用设置），并且 Kudu 将自动生成.sln 或.csproj 文件中，提供它为文件夹的根目录中。

.Deployment 方法的完整详细信息，请参阅bit.ly/2MosYe4。

本地 Git 部署Git 已成为开发人员的广泛采用的工具。Git 版本控制系统的功能之一是其分布式的特征。这意味着，当正在开发人员计算机上使用的本地存储库，将更改同步到远程服务器 （如 VSTS、 GitHub 或 BitBucket） 的方法是通过添加 Git remote，并将所做的更改推送到它。

启用应用服务中的本地 Git 部署选项时，为你创建 Git 存储库。可以配置为从本地 Git 存储库远程并触发通过"git push"命令的部署。

与 zipdeployment，可以在部署期间执行生成步骤。使用本地 Git 部署时，Kudu 将自动查找.sln/.csproj 根目录中的文件，来生成。对于其他语言 （或更多的控制），您可以使用.deployment 文件来控制生成过程。

如果您有用于生成更丰富的要求，您可以使用 VSTS 执行生成，如中所示图 1。这提供了对生成功能内置到 VSTS，以及在 marketplace 中可用的自定义任务的访问。

若要执行的生成阶段的 Kudu 和 Visual Studio Team Services (VSTS) 之间进行选择
图 1 Kudu 和 Visual Studio Team Services (VSTS) 之间进行选择来执行的生成阶段

使用本地 Git 部署的更多详细信息可从bit.ly/2BljdIx。 

连续部署应用服务中的连续部署选项是类似于本地 Git 部署。而不是代码推送到 Git 存储库的 Kudu 程序托管为您的区别是，将代码推送到 VSTS、 GitHub 或 BitBucket 中 Git 存储库。在配置此选项时，应用服务设置了 webhook 将更改推送到你的存储库，而这是部署触发器时收到通知。

使用本地 Git 部署，可以选择 Kudu 生成或 VSTS 生成管道。

连续部署的详细信息可从bit.ly/2vOS23k。

其他部署

我讨论的选项是直接集成到应用服务。生成和 CI/CD 平台提供商可能提供自己的任务，以便可以部署到应用服务。所有基础上所述的应用服务机制之一来生成此类任务，因此任何围绕这些应用程序服务方法的讨论将应用于这些任务。例如，AppVeyor 具有用于将部署到应用服务中使用 zipdeployment 任务 (bit.ly/2OK535j)，因此 zipdeployment 注意事项将适用于 AppVeyor 任务。

解决难题

在部署到应用服务应用程序时，您修改 site/wwwroot 文件夹内容。这些是用于提供你的站点，因此有可能会遇到一些难题的文件。如果您的网站正在使用中，可能会发现，一些文件被锁定时部署尝试通过将新文件复制。此外，因为更新的文件不是所有在完全相同的时间点，就可以在部署期间获取不可预知的行为。

使用部署槽 （在应用服务的标准和高级层） 是应对这些挑战的好办法。在创建部署槽时，你创建新的站点内都有其自己的 URL 和 site/wwwroot 将 Web 应用内容，但可以使用单个操作交换你测试的站点槽成为生产槽。

如果您创建"test"槽，可能是部署的流程：

  • 将部署到测试槽
  • 验证新的版本正常
  • 到生产槽将测试槽交换

如果不想要在中间执行验证步骤，您甚至可以配置为自动交换到生产环境的槽，完成部署后。

部署槽位的详细信息可从bit.ly/2L4rsIt。

新的备选方法

通常发展你的部署作为项目的进展，并在应用服务中可用的部署选项的范围为您提供了很大的灵活性在项目生存期内。例如，使用.deployment 文件指定要执行的生成/部署步骤可以大大提高工作效率，但随着项目的进展，可能想要将移动到拆分出生成过程以便控制通过 VSTS 或类似的方法。如前文所述，所有部署都方法曾进行过讨论到目前为止工作同步到你的应用服务的站点/wwwroot 文件夹的内容。

应用服务 （和函数） 具有名为运行从包 （处于预览状态，在撰写本文时） 采用 zipdeployment 进一步的新部署方法。与所有的部署选项为止讨论 (包括 zipdeploy)，运行从包不需要新的内容以及将其同步与 site/wwwroot 文件夹。相反，与运行从包提供，作为在 wwwroot 中的只读的文件系统装载的.zip 文件。

不是每个应用程序将处理的包从运行;从历史上看，wwwroot 文件夹已被可写 （和 ASP.NET 应用程序特别习惯于写入到 App_Data 文件夹）。此外，由于装载该.zip 文件后，您不能使用.deployment 文件方法来运行生成/部署步骤：该.zip 文件需要包含最后一组运行你的站点所需的文件。这实际上可以是一项权益，不过：因为没有任何同步文件或还原包，您知道哪些文件进行准确的步骤将会显示为一个给定的.zip 文件，并在 npm 或 NuGet 服务上没有依赖项。只要保留这些.zip 文件，请恢复到以前版本是站点的指向该版本的.zip 文件一样简单。

另一个关键优势是部署的一致性：装载的.zip 文件，因为没有任何同步的文件和部署步骤都是原子。这将立即避免我"寻址质询"部分中讨论的问题。

对于需要加载大量的文件的应用程序，可以有初始的性能问题时新的主机开始运行代码 （通常称为"冷启动"）;例如，对于具有数千个 npm_modules 中的文件的 Node.js 应用程序。因为进行主动的方式缩放以处理传入请求，这会导致新主机，将会推出，冷启动问题时在 Azure Functions 中的动态的计费计划上尤其明显。有现有的方法来缓解此冷启动问题 （如 funcpack 或 webpack），但运行从包的实现方式为您解决这一问题。

总结

很明显应用服务实现范围广泛的方法可用于部署应用程序。在我使用过 Azure 应用服务和 Azure Functions 的各种项目，我已尝试太多了这些方法，通常使用多个单个项目作为项目的需求的不断发展变化。运行从包部署方法的这些新增现在提供了简单而又强大的新添加到这些部署选项。任何人想利用可靠的回滚计划进行不可变的部署，运行从包很值得介绍。

项目 Kudu

Kudu 是将后台功能与显示在 Kudu 门户中的功能相结合的应用服务的内置组件。

在后台前面我提到过，Kudu 如何公开您可以调用它以触发 zipdeployment 的终结点。管理部署到应用服务是 Kudu; 的幕后功能例如，执行你中的"git push"，到应用服务 Git 终结点时，它是代码的 Kudu 采用该代码并将其应用到应用服务文件系统。

Kudu 还使应用服务的 web 作业功能 (bit.ly/2OHHuKz);Web 作业提供使 Web 应用所在的同一上下文中执行的后台任务的功能。这些任务可以手动触发，按计划运行或可以连续运行并从队列检索消息，依此类推。

Kudu 提供的另一个后台功能是站点扩展。站点扩展，可以将额外的功能添加到你的站点，并且可以对你的网站，Kudu 门户和 web 作业中公开的 UI 的配置更改的组合。可以从 Kudu 门户中显示库中安装站点扩展，甚至编写自己的 (bit.ly/2PioL9z)。

Kudu 门户Kudu 门户可以非常方便地。如果你的应用服务站点 URL 是 https://mysite.azurewebsites.net，您可以访问 https://mysite.scm.azurewebsites.net Kudu 门户 （如果你已使用 Azure 门户帐户身份验证，你将会自动登录，否则您会系统提示您进行身份验证）。您还可以通过单击开发工具部分中的高级工具项为应用服务或函数应用导航到 Azure 门户中的 Kudu。

在 Kudu 门户登录你将看到后的轻型但功能 UI。在顶部菜单中的常见任务包括和 Kudu REST API 的链接显示在主页的正文中。虽然这篇文章的讨论范围内是 Kudu 的完整演练，我想要查看几个很棒的功能。(您还可以在项目的 Wiki 在找到大量内容bit.ly/2KZoQM1。)

我大量使用的功能之一是在调试控制台。单击菜单项，可以获取选择的命令提示符 (CMD) 或 PowerShell。这使你的文件夹/文件浏览器界面和嵌入的控制台组合 （和出色功能是，当前的每个位置保持同步在导航时），并且还没有内置的一个简单的文件编辑器。我发现这是一个非常有用的工具，尤其是在生成 web 作业和站点扩展。

帮助我出在许多情况下的另一个功能是环境页。这是一种简单方式查看应用程序设置、 环境变量以及为你的网站，配置等，但正在编写脚本基于 Kudu 的部署或甚至只是进行完整性检查的配置上看到你的站点时，会很方便。并且没有在您会发现很有用，从列出触发进程小型转储的进程的 Kudu 了更多。如果尚没有采取 Kudu 看，强烈建议。

Stuart Leeks是 Web 和云极客在 Microsoft 担任软件工程师，帮助客户和合作伙伴使用其云的采用。你可以在 twitter 找到他@stuartleeks并在blogs.msdn.microsoft.com/stuartleeks。

衷心感谢以下 Microsoft 技术专家对本文的审阅：David ebbo 协作完成
David ebbo 协作完成是 Azure 应用服务和 Functions 团队的开发经理。你可以在 Twitter 找到他： @davidebbo

在 MSDN 杂志论坛讨论这篇文章