配置应用程序和虚拟机

  • 4 分钟

为 Azure 解决方案生成应用和其他自定义代码很常见。 自定义应用可包括无需人工交互即可运行的网站、API 和后台应用。 在本单元中，你将学习如何设计管道来生成和部署应用及其基础结构。

生成应用

许多类型的应用在使用前都需要进行编译或生成。 生成过程采用应用的源代码，对应用执行一系列活动，然后创建一组可部署文件。

生成过程会将源代码编译为二进制文件或可执行文件，但它通常还包括其他活动：

  • 压缩提供给网站用户的图像文件。
  • 对代码进行 Lint 分析，验证其是否遵循了良好的编码做法。
  • 运行单元测试，验证应用的各个部分的行为。

除了这些步骤，还可以执行诸如对文件进行数字签名之类的步骤，以帮助确保他人无法修改这些文件。

无论这一系列的步骤是什么，生成过程的输出都是一个可部署的工件。 该工件通常保存到管道代理的文件系统中。 管道的后期阶段需要用到该工件，以将其部署到环境中，并在部署过程中对其进行测试以确定是否符合在管道定义中定义的质量要求。

注意

你可能听说过“持续集成”(CI) 和“持续部署”(CD) 这两个术语。 生成过程处于管道的持续集成部分。

管道工件

管道中生成的工件不会存储在 Git 存储库中。 它们派生自源代码，但不是代码本身，因此不属于源代码管理存储库。 它们在管道代理的文件系统上创建。 为每个管道作业创建一个新代理，因此你需要一种在作业和代理之间共享文件的方法。

管道工件提供了一种在 Azure Pipelines 中存储文件的方法，并且它们与管道的特定运行相关联。 使用 PublishBuildArtifacts 内置管道任务指示 Azure Pipelines 将代理文件系统中的文件或文件夹作为管道工件发布：

- task: PublishBuildArtifacts@1
  displayName: Publish folder as a pipeline artifact
  inputs:
    artifactName: my-artifact-name
    pathToPublish: '$(Build.ArtifactStagingDirectory)/my-folder'

pathToPublish 属性是管道代理文件系统上包含已编译代码或输出文件的位置。 此位置的内容将发布到生成工件。 可以指定单个文件或文件夹。

每个工件都有一个名称，可以使用 artifactName 任务属性指定该名称。 稍后在管道中，使用工件名称来引用它。 后续管道作业和阶段可以下载工件，并使用工件来执行将网站部署到托管服务器等操作：

Diagram that shows pipeline stages to build and deploy that refer to an artifact named Website.

使用部署作业时，默认情况下会自动下载管道工件。 如果使用常规作业，请使用 DownloadBuildArtifacts 任务下载管道工件：

- task: DownloadBuildArtifacts@0
  inputs:
    buildType: current
    downloadType: single
    artifactName: my-artifact-name
    downloadPath: '$(System.ArtifactsDirectory)'

部署应用

应用的生成过程会生成并发布可部署的工件。 管道的后期阶段将部署工件。 应用的部署方式取决于用于托管应用的服务。

部署到 Azure 应用服务

你所在的玩具公司使用 Azure 应用服务来托管自己的网站。 可以使用 Bicep 创建和配置应用服务应用。 但在需要部署应用时，可以通过多个选项将编译后的应用部署到托管基础结构。 这些选项作为应用服务数据平面的一部分进行管理。

最常见的方法是使用 AzureRmWebAppDeployment Azure Pipelines 任务：

- task: AzureRmWebAppDeployment@4
  inputs:
    azureSubscription: MyServiceConnection
    ResourceGroupName: MyResourceGroup
    WebAppName: my-app-service
    Package: '$(Pipeline.Workspace)/my-artifact-name/website.zip'

将应用部署到应用服务时需要提供几条信息。 此信息包括使用 ResourceGroupName 和 WebAppName 输入指定的应用服务应用的资源组和资源名称。 正如在上一单元中了解到的，应该将输出添加到 Bicep 文件，并使用管道变量在管道中传播应用名称。 还需要使用 Package 输入（通常是管道工件的路径）指定要部署的应用的 .zip 文件。

应用服务拥有自己的数据平面身份验证系统用于部署。 AzureRmWebAppDeployment 任务会自动处理身份验证过程：

Diagram that shows the credential exchange process.

AzureRmWebAppDeployment 任务将使用与服务连接关联的服务主体来自动创建和下载进行部署所需的凭据。 然后，它使用部署凭据与应用服务数据平面 API 进行通信。

应用服务还提供一些与部署相关的其他功能，包括部署槽位。 槽有助于安全部署新版本的应用，而无需停机。 它们还可帮助你在将生产流量发送到应用程序之前，准备并预热新版本的应用程序。 此模块中不会使用槽，但模块结尾的“总结”页面上提供了有关更多信息的链接。

将应用部署到其他 Azure 服务

Azure 提供了许多其他用于托管应用的选项，其中每个选项都有其自己的部署方法。

Azure Functions 基于应用服务构建，其使用类似于前面所述的部署过程。

如果要部署到虚拟机，通常需要连接到虚拟机实例来安装应用。 通常需要使用专用工具（如 Chef、Puppet 或 Ansible）来协调到虚拟机的部署。

如果使用 Kubernetes 或 Azure Kubernetes 服务 (AKS)，那么会使用略微不同的方法来生成和部署解决方案。 生成应用后，管道会创建一个容器映像并将其发布到容器注册表，之后 Kubernetes 群集将从中进行读取。 由于容器注册表可保存已编译的应用程序，因此一般不使用管道工件。

在此模块中，我们将重点介绍 Azure 应用服务，来说明所涉及的管道概念。 在模块结尾的“总结”页面上，我们提供了有关部署到其他托管服务的更多信息的链接。

测试管道中的应用

在上一个模块中，你了解了从管道运行自动测试的价值和重要性。 部署应用时，使用管道运行一些调用应用代码的测试是一种很好的做法。 此类测试可降低应用或部署错误可能导致停机的风险。 在更高级的方案中，甚至可以针对你的应用执行一组测试用例，例如调用 API 或提交和监视综合事务。

许多应用实现运行状况检查终结点。 当运行状况检查终结点收到请求时，它会针对网站执行一系列检查，如确保可从应用环境访问数据库和网络服务。 站点返回的响应会指示应用是否正常。 开发人员可以编写和自定义自己的运行状况检查，以满足应用的要求。 如果你的应用具有运行状况检查终结点，则在部署阶段完成后，通常可以从管道对其进行监视。

部署管道

在下一练习中，你将更新部署管道，以添加新的作业来构建网站的应用程序并将其部署到每个环境：

Diagram that shows the revised pipeline, including a new build stage and an application deployment step.