配置应用程序和虚拟机

已完成

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

生成应用

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

生成过程将源代码编译为二进制文件或可执行文件。 生成过程通常包括其他活动：压缩将提供给网站用户的图像文件、对代码进行 Lint 分析以验证其是否遵循良好的编码做法，以及运行单元测试来验证应用各个部分的行为。 还可以执行对文件进行数字签名等步骤，以帮助确保文件无法修改。

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

注意

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

工作流项目

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

工作流项目提供了一种在 GitHub Actions 中存储文件的方法，并且它们与工作流的特定运行相关联。 使用 actions/upload-artifact 工作流操作指示 GitHub Actions 从运行器的文件系统上传文件或文件夹作为工作流项目：

- name: Upload folder as a workflow artifact
  uses: actions/upload-artifact@v3
  with:
    name: my-artifact-name
    path: ./my-folder

path 属性是作业运行器文件系统上包含已编译代码或输出文件的位置。 此位置的内容将上传到项目。 可以指定单个文件、多个文件或文件夹。

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

使用 actions/download-artifact 操作下载所有工作流项目：

- uses: actions/download-artifact@v3

或者，指定项目名称以仅下载特定项目：

- uses: actions/download-artifact@v3
  with:
    name: my-artifact-name

部署应用

应用的生成过程会生成并上传可部署的项目。 工作流中的后续作业将部署项目。 应用的部署方式取决于用于托管应用的服务。

部署到 Azure 应用服务

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

最常见的方法是使用 azure/webapps-deploy 操作：

- uses: azure/webapps-deploy@v2
  with:
    app-name: my-app-service
    package: my-artifact-name/website.zip

将应用部署到应用服务时需要提供几条信息。 此信息包括使用 app-name 属性指定的应用服务应用的资源名称。 正如在上一单元中了解到的，应该将输出添加到 Bicep 文件，并使用工作流变量在工作流中传播应用名称。 还需要使用 package 属性指定包含要部署的应用的 .zip 文件。 这通常是工作流项目的路径。

应用服务拥有自己的数据平面身份验证系统用于部署。 azure/webapps-deploy 操作会自动处理身份验证过程：

azure/webapps-deploy 操作使用与作业的活动 Azure 会话相关联的标识，该会话是使用工作负载标识登录的。 该操作会创建并下载部署所需的凭据。 然后，它使用部署凭据与应用服务数据平面 API 进行通信。

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

将应用部署到其他 Azure 服务

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

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

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

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

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

测试工作流中的应用

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

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

你的部署工作流

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