将应用部署到 Azure 应用服务

本文可帮助你确定将 Web 应用、移动应用后端或 API 应用的文件部署到 Azure 应用服务的最佳选项,然后将你引导到相应的资源,其中包含特定于你的首选选项的操作说明。

Azure 应用服务部署概述

Azure 应用服务保留了应用程序框架(ASP.NET、PHP、Node.js 等等)。 某些框架在默认情况下已启用,而其他框架(如 Java 和 Python)可能需要进行简单的复选标记配置才能启用。 此外,你还可以自定义应用程序框架,如运行时的 PHP 版本或位元。 有关详细信息,请参阅在 Azure 应用服务中配置应用

由于你无需担心 Web 服务器或应用程序框架,因此将应用部署到应用服务只需将代码、二进制文件、内容文件及其各自的目录结构部署到 Azure 中的 /site/wwwroot 目录(对于 Web 作业,部署到 /site/wwwroot/App_Data/Jobs/ 目录)。 应用服务支持 3 种不同的部署进程。 本文中的所有部署方法使用以下进程之一:

  • FTP 或 FTPS:使用你常用的支持 FTP 或 FTPS 的工具(从 FileZilla 到功能齐全的 IDE,如 NetBeans)将文件移至 Azure。 这完全是文件上传进程。 应用服务不提供任何附加服务,例如版本控制、文件结构管理等。
  • Kudu (Git/Mercurial):Kudu 是应用服务中的部署引擎。 从任何存储库将你的代码直接推送到 Kudu。 只要代码推送到 Kudu,Kudu 还提供附加服务,包括版本控制、程序包还原、MSBuild 和 Web 挂钩 以用于连续部署和其他自动化任务。 Kudu 部署引擎支持 2 种不同类型的部署源:

    • 从 GitHub 使用自动同步进行基于存储库的连续部署
    • 从本地 Git 使用手动同步进行基于存储库的部署
  • Web 部署:使用自动部署到 IIS 服务器的相同工具,直接从偏好的 Microsoft 工具(例如 Visual Studio)将代码部署到应用服务。 此工具支持仅差异部署、创建数据库、连接字符串转换等操作。Web 部署与 Kudu 的不同之处在于,应用程序二进制文件在部署到 Azure 之前生成。 与 FTP 类似,应用服务不提供任何附加服务。

常用的 Web 开发工具支持其中的一个或多个部署进程。 虽然你选择的工具确定了你可以利用的部署进程,但是由你支配的实际 DevOps 功能取决于部署进程和你选择的特定工具的组合。 例如,如果从 包含 Azure SDK 的 Visual Studio执行 Web 部署,即使你未从 Kudu 自动执行,也会在 Visual Studio 中自动执行程序包还原和 MSBuild。

Note

这些部署过程并不会真正预配应用可能需要的 Azure 资源。 但是,大多数链接的操作方法文章会向你展示如何预配应用并端到端地将代码部署到该应用。 还可以在 使用命令行工具自动部署 部分中找到用于预配 Azure 资源的其他选项。

通过 FTP 上传文件进行手动部署

如果你习惯于手动将 Web 内容复制到 Web 服务器,可以使用 FTP 实用工具(如 Windows 资源管理器或 FileZilla)复制文件。

手动复制文件的优点是:

  • FTP 工具使用顺手且复杂性很低。
  • 完全知道文件要复制到何处。
  • 使用 FTPS 可增加安全性。

手动复制文件的缺点是:

  • 必须知道如何将文件部署到应用服务中的正确目录。
  • 发生故障时没有针对回退的版本控制。
  • 无法提供用于排查部署问题的内置部署历史记录。
  • 部署时间可能很长,因为许多 FTP 工具不提供仅差异复制,而只是复制所有文件。

如何使用 FTP 上传文件

Azure 门户中提供了使用 FTP 或 FTPS 连接到应用目录所需的全部信息。

从基于云的源代码管理服务连续部署

如果开发团队使用基于云的源代码管理 (SCM) 服务,如 GitHub,则可以将应用服务配置为与存储库集成并连续进行部署。

从基于云的源代码管理服务部署的优点是:

  • 版本控制支持回退。
  • 能够为 Git(以及 Mercurial,如果适用)存储库配置连续部署。
  • 分支特定的部署,可以将不同分支部署到不同的
  • Kudu 部署引擎中的所有功能都可用(例如,部署版本控制、回退、程序包还原、自动化)。

从基于云的源代码管理服务部署的缺点是:

  • 需要对相关 SCM 服务有一定的了解。

如何从基于云的源代码管理服务连续部署

在 Kudu 中,可以配置从 GitHub 进行的连续部署。

若要了解如何通过 Azure 门户中未列出的云存储库(如 GitLab)手动配置连续部署,请参阅使用手动步骤设置连续部署

从本地 Git 部署

如果你的开发团队使用基于 Git 的本地源代码管理 (SCM) 服务,可将它配置为应用服务的部署源。

从本地 Git 进行部署的优点是:

  • 版本控制支持回退。
  • 分支特定的部署,可以将不同分支部署到不同的
  • Kudu 部署引擎中的所有功能都可用(例如,部署版本控制、回退、程序包还原、自动化)。

从本地 Git 进行部署的缺点是:

  • 需要对相关 SCM 系统有一定的了解。
  • 连续部署没有任何现成的解决方案。

如何从本地 Git 部署

Azure 门户中,可以配置本地 Git 部署。

使用 IDE 进行部署

如果你已在使用包含 Azure SDKVisual Studio 或其他 IDE 套件(如 XcodeEclipseIntelliJ IDEA),可以直接从 IDE 内部署到 Azure。 此选项非常适合于单个开发人员。

Visual Studio 支持所有这三种部署过程(FTP、Git 和 Web 部署),具体取决于你的首选项,而其他 IDE 在已集成 FTP 或 Git 时可部署到应用服务(请参阅部署过程概述)。

使用 IDE 进行部署的优点是:

  • 可最大程度减少在端到端应用程序生命周期中使用工具。 开发、调试、跟踪你的应用以及将其部署到 Azure,所有这些操作都在 IDE 内部执行。

使用 IDE 进行部署的缺点是:

  • 增加了工具使用方面的复杂性。
  • 团队项目仍需要源代码管理系统。

使用包含 Azure SDK 的 Visual Studio 进行部署的其他优点是:

  • Azure SDK 使 Azure 资源在 Visual Studio 中处于第一等级。 创建、删除、编辑、启动和停止应用、查询后端 SQL 数据库、实时调试 Azure 应用,以及执行更多操作。
  • 实时编辑 Azure 上的代码文件。
  • 实时调试 Azure 上的应用。
  • 已集成 Azure 资源管理器。
  • 允许进行仅差异部署。

如何直接从 Visual Studio 部署

Note

若要将 Visual Studio 连接到 Azure 中国区,可按使用 Visual Studio 2015 连接中国区 Azure中的说明操作。

如果使用的是 Visual Studio 2015 Update 2 或更高版本,可以按照以下图片中的说明,选中“启用隔离的 Azure Active Directory 配置”选项。

enable-isolated-azure-active-directory-configuration

如果使用的是 Visual Studio 2017,可按 使用 Visual Studio 2017 连接中国区 Azure中的说明操作。

使用命令行工具自动部署

如果你偏好命令行终端作为所选开发环境,则可使用命令行工具针对应用服务应用编写部署任务的脚本。

使用命令行工具进行部署的优点是:

  • 允许编写部署方案的脚本。
  • 集成 Azure 资源和代码部署的预配。
  • 将 Azure 部署集成到现有的连续集成脚本。

使用命令行工具进行部署的缺点是:

  • 不适用于首选 GUI 的开发人员。

如何使用命令行工具实现部署自动化

有关命令行工具的列表和教程链接,请参阅使用命令行工具自动部署 Azure 应用

后续步骤

在某些情况下,你可能想要能够轻松地在应用的过渡版本和生产版本之间来回切换。 有关详细信息,请参阅 Web 应用上的过渡部署

准备好备份和还原计划是任何部署工作流的一个重要部分。 有关应用服务备份和还原功能的信息,请参阅 Web 应用备份

有关如何使用 Azure 的基于角色的访问控制来管理应用服务部署访问权限的信息,请参阅 RBAC and Web App Publishing(RBAC 和 Web 应用发布)。