通过

使用 Azure 开发人员 CLI 进行全堆栈部署

合并前端和后端服务的全堆栈应用程序是新式 Web 开发中的常见模式。 Azure 开发人员 CLI （azd） 支持部署前端和后端作为单独服务托管的全堆栈应用程序。 本文介绍如何使用azd部署全栈应用程序，并重点介绍有效部署的策略和优势。

什么是全堆栈部署？

全堆栈部署 azd 通常包括：

  • 前端服务：面向用户的 Web 应用程序，通常使用 React、Angular、Vue 或 Blazor 等框架构建。 前端可以托管为静态站点或容器化应用程序。
  • 后端服务：用于处理业务逻辑、数据访问和集成的 API 或服务层。 后端通常托管在容器或无服务器函数中。
  • 共享资源：数据库、存储帐户、密钥保管库和其他两个服务可能使用的 Azure 资源。

通过使用 azd，可以在单个 azure.yaml 文件中定义这两个服务，并使用基础结构即代码（Bicep 或 Terraform）将它们预配在一起。

Azure 开发人员 CLI 生命周期

Azure 开发人员 CLI 遵循具有不同生命周期事件的结构化工作流：

显示包含包、预配和部署阶段的 Azure 开发人员 CLI 生命周期的关系图。

  1. 包：生成应用程序源代码并准备用于部署的项目。
  2. 预配：使用 Bicep 或 Terraform 创建或更新 Azure 基础结构资源。
  3. 部署：将打包的应用程序代码部署到预配的基础结构。

该 azd up 命令按顺序运行所有三个阶段。 还可以通过独立运行每个阶段，并使用azd package、azd provision和azd deploy来获得更精细的控制。 了解此生命周期对于管理服务之间的依赖关系至关重要，尤其是在计时和顺序很重要的全堆栈部署中。

有关生命周期和工作流自定义的详细信息azd，请参阅探索 azd up 工作流。

基础结构设计注意事项

使用完整堆栈应用程序 azd设计时，为前端和后端选择适当的 Azure 托管服务：

服务类型 托管选项 用例
前端 Azure 静态 Web 应用、 Azure 应用服务、 Azure 容器应用 静态站点、SPA、服务器呈现的应用
后端 Azure 容器应用、 Azure 应用服务、 Azure Functions、 Azure Kubernetes 服务 API、微服务、无服务器函数

详细了解如何在 Azure 上托管应用程序。

了解前端和后端应用程序之间的相互依赖关系

全堆栈部署通常遇到循环依赖项挑战，其中每个服务都需要有关其他服务的信息，然后才能完全配置。 了解这些相互依赖性有助于设计有效的部署工作流。

说明完整堆栈部署中前端和后端服务之间的循环依赖关系的关系图。

前端需要后端 URL：前端应用程序通常需要在生成时或运行时知道后端 API 终结点 URL。 但是，后端服务在部署到 Azure 之前没有 URL。

后端需要前端 URL：后端服务可能需要前端 URL 来配置 CORS 策略，但前端在部署前没有 URL。

共享资源依赖项：这两个服务可能依赖于共享资源，例如数据库、密钥保管库或存储帐户。 必须先预配这些资源，然后才能将任一服务配置为使用它们。

特定于环境的配置：不同的环境（开发、过渡、生产）需要不同的终结点 URL 和配置，但这些值在预配完成之前是未知的。

了解配置策略

Azure 开发人员 CLI 通过两种方法处理这些相互依赖性：

  • 部署时配置：在预配和部署期间解决依赖项
  • 运行时配置：将依赖项配置推迟到应用程序运行时

这些方法表示在生成应用程序时做出的设计决策。 可以根据体系结构和要求单独使用一种策略或组合这两种策略。

比较全堆栈部署的部署时间与运行时配置策略的关系图。

部署时配置

部署时的配置意味着服务连接和配置是在azd provision和azd deploy阶段期间确定并锁定的。 通过这种方法，可以在服务开始运行之前配置具有特定终结点 URL、连接字符串和其他依赖项信息的服务。 此配置将成为已部署服务环境的一部分，无论是作为环境变量，还是作为随部署一起打包的配置文件中。

基础结构优先预配：运行 azd up 或 azd provision首先创建基础结构。 此步骤在部署开始之前生成必要的 URL 和连接字符串，确保依赖服务具有所需的信息。

输出变量：预配后，Bicep 和 Terraform 可以输出值，例如 URL 和连接字符串。 这些输出在部署阶段可用作环境变量，因此可以在服务启动之前使用正确的终结点配置服务。

顺序部署：对于复杂方案，可能需要按特定顺序部署服务。 使用 azd挂钩 控制部署顺序，确保必备服务在部署依赖服务之前运行。

容器更新或插入模式：Azure 验证模块（AVM）提供容器应用模式，如 container-app-upsert ，可以与 azd 的两阶段工作流无缝合作。 在预配期间，将创建基础结构和初始容器。 在部署期间， azd 更新了容器映像，其中包含预配期间生成的值，例如数据库连接字符串或服务 URL。 此模式通过先允许基础设施存在，然后用所有必需的依赖信息更新容器配置，从而解决先有鸡还是先有蛋的问题。

包含容器 API 后端的 React 前端的示例工作流：

  1. 运行 azd up，它按顺序执行包、预配和部署阶段。
  2. 预配期间，Bicep 使用 AVM container-app-upsert 模块创建 Azure 容器应用基础结构，并输出后端 API URL。
  3. 在部署期间， azd 使用正确的环境变量自动更新两个容器，包括前端的 API URL。
  4. 这两个服务都以正确的配置开头。 将来进行 azd up 或 azd deploy 时，将容器更新为任何新的配置值。

运行时配置

运行时配置使应用程序能够在应用程序运行时而不是部署期间加载配置。 此方法可灵活地更新服务终结点、连接字符串和策略，而无需重新部署应用程序。

配置源：应用程序可以从两个主要源加载运行时配置：

  • 本地配置文件：部署配置文件，例如 config.json，与应用程序一起部署配置文件。 应用程序在启动时加载此文件，以获取当前终结点 URL、身份验证设置和其他配置值。 此方法适用于 React、Angular、Vue 和 Blazor WebAssembly 等客户端框架，可在应用程序在浏览器中启动时提取配置。

  • 云配置服务：使用 Azure 应用配置 或类似服务集中管理所有环境中的配置。 应用程序在启动时或按需查询配置服务以检索当前值。 此方法对于多个服务需要协调配置更新的微服务体系结构非常有用。

优点：无论采用哪种方法，配置更改都立即可用，无需重新部署。 通过部署管道更新配置文件，或通过 Azure 门户更改 Azure 应用配置 中的值。 当应用程序重启或刷新其配置时，它会选取新值。 此模式特别适用于：

  • 需要发现后端 API URL、身份验证终结点和微服务位置的前端应用程序
  • 需要随着前端 URL 的变化而更新 CORS 策略的后端服务
  • 在开发、预发布和生产环境中需要不同配置的服务

React 前端发现后端 API 的示例工作流：

  1. 运行 azd up 以预配基础结构并部署这两个服务。
  2. 部署后挂钩生成包含 config.json 后端 URL 的文件，并将其上传到前端的存储位置。
  3. React 应用在启动时提取 config.json 以发现 API 终结点。
  4. 若要稍后更新终结点，请修改 config.json 而不重新部署前端。

此方法不适用于在生成时预呈现所有内容的静态生成的网站。

规划部署工作流

在设计完整堆栈部署时，请考虑以下因素：

  1. 确定依赖项：映射哪些服务需要来自其他服务的信息。 对于单向依赖项（如依赖于数据库的 API），预配平台（Bicep 或 Terraform）会自动处理排序。 对于循环依赖项（例如，在启动时需要彼此的 URL 的前端和后端服务），必须使用部署时或运行时配置策略设计协调。
  2. 部署前进行预配：在部署应用程序代码之前，请确保存在所有基础结构。
  3. 使用环境变量：使用 azd 环境变量在基础结构层和应用程序层之间传递配置。
  4. 针对多个环境进行设计：规划配置在开发、过渡和生产环境中的不同之处。
  5. 考虑部署顺序：某些方案可能需要按特定顺序部署服务。

该 azd up 命令通过自动运行预配并在单个工作流中部署来处理大多数部署方案。 对于标准单一应用程序，此方法非常有效，需要最少的配置。

对于更复杂的部署，例如具有循环依赖项的完整堆栈：

  • 配置服务顺序：在 azure.yaml 文件中，按照部署服务的顺序定义服务。 默认情况下，azd 并行部署服务，但在需要时，你可以使用 挂钩 来强制实施顺序部署。

  • 自定义工作流步骤：通过在文件中定义自定义azd up属性workflows来替代默认azure.yaml工作流。 例如，可以在生成应用程序源代码之前更改默认行为以运行预配：

    name: todo-nodejs-mongo
metadata:
  template: todo-nodejs-mongo@0.0.1-beta
workflows:
  up: 
    steps:
      - azd: provision
      - azd: package
      - azd: deploy

    当生成过程需要仅在预配完成后才可用的配置值时，此模式非常有用。

  • 单独预配和部署：而不是使用 azd up、运行 azd provision 和 azd deploy 作为单独的命令。 在部署应用程序代码之前或排查部署问题时，需要验证基础结构配置时，这种分离非常有用。 可以预配基础结构一次，然后多次部署和重新部署应用程序代码，而无需重新预配。

  • 使用挂钩进行自定义：在文件中添加预azure.yaml和发布挂钩，以在预配和部署阶段之间执行自定义逻辑。 使用挂钩来填充配置文件、验证环境状态或协调复杂的部署序列。

最佳做法

当使用 azd 构建全堆栈应用程序时，请遵循以下最佳实践：

  1. 提前映射依赖项：确定哪些服务需要在设计阶段从其他服务获取信息。 区分 Bicep 或 Terraform 自动处理的单向依赖项，以及需要部署时间或运行时配置策略的循环依赖项。
  2. 选择正确的配置策略：当服务需要在部署中锁定配置时使用部署时配置。 如果需要灵活地在不重新部署的情况下更新配置，请使用运行时配置。 适当时合并这两种策略。
  3. 使用 Azure 验证模块 （AVM）：利用 Azure 验证模块 的 Bicep 模块来支持 container-app-upsert 容器应用。 这些模式与 azd's 双阶段工作流无缝配合工作，以解决循环依赖项。
  4. 根据需要自定义工作流：对于简单部署，请使用 azd up 默认设置。 对于具有循环依赖项的复杂方案，请自定义 workflows 文件中的属性 azure.yaml ，以控制包、预配和部署步骤的顺序。
  5. 利用运行时配置：为了在环境中实现最大的灵活性，请使用 Azure 应用配置或本地配置文件来管理无需重新部署即可更新的服务终结点和设置。
  6. 跨环境进行测试：确保配置策略在服务 URL 和配置不同的开发、过渡和生产环境中正常运行。

后续步骤

  • Last updated on