在 Azure 容器应用中更新和部署更改

在云中开发容器化应用程序时,更改管理可能会很困难。 最终,你需要支持来跟踪更改,确保运行时间,并具有处理平滑回滚的机制。

Azure 容器应用中的更改管理由修订提供支持,这些修订是容器应用的每个版本的快照。

修订的主要特征包括:

  • 不可变:建立后,修订保持不变。

  • 版本控制:修订充当容器应用版本的记录,在各个阶段捕获其状态。

  • 自动预配:首次部署容器应用时,会自动创建初始修订。

  • 范围更改:虽然修订保持静态,但 应用程序范围 更改可能会影响所有修订,而修订范围更改会创建新的修订。

  • 历史记录:默认情况下,你可以访问 100 个非活动修订项,但你可手动调整此阈值

  • 多个修订:可以并发运行多个修订。 当你需要同时管理应用的不同版本时,此功能特别有用。

生命周期

每个修订都会经历特定状态,受其状态和可用性影响。 在其生命周期内,容器应用会经历不同的预配、运行和非活动状态。

预配状态

创建新的修订时,容器应用将进行启动和准备情况检查。 在此阶段,预配状态充当跟踪容器应用进度的指南。

状态 说明
Provisioning 修订正在验证过程中。
已预配 修订已成功通过所有检查。
预配失败 修订在验证期间遇到问题。

运行状态

成功预配容器应用后,修订将进入其操作阶段。 运行状态有助于监视容器应用的运行状况和功能。

状态 说明
Provisioning 修订正在验证过程中。
缩放到 0 零个副本在运行,没有任何新副本在预配。 如果触发缩放规则,容器应用可以创建新的副本。
正在激活 零个副本在运行,一个副本在预配。
激活失败 第一个副本无法预配。
缩放/处理 正在横向缩放。 一个或多个副本在运行,而其他副本在预配。
正在运行 一个或多个副本在运行。 没有要报告的问题。
运行(最大) 最大副本数(根据修订的规模规则)正在运行。 没有要报告的问题。
取消设置 修订正在从活动过渡到非活动状态,并删除已创建的任何资源。
已降级 修订中的至少一个副本处于失败状态。 查看特定问题的运行状态详细信息。
已失败 严重错误导致修订失败。 运行状态提供了详细信息。 常见原因包括:
• 终止
• 退出代码 137

非活动状态

修订还可以进入非活动状态。 这些修订不具有预配或运行状态。 但是,Azure 容器应用维护这些修订的列表,最多可容纳 100 个非活动条目。 可以随时激活修订。

更改非活动修订项限制

可将 --max-inactive-revisions 参数与 containerapp createcontainerapp update 命令一起使用,以控制容器应用跟踪的非活动修订项数。

此示例演示如何新建一个跟踪 50 个非活动修订项的容器应用:

az containerapp create --max-inactive-revisions 50

修订模式

Azure 容器应用支持两种修订模式。 你选择的模式决定了应用同时处于活动状态的修订数。

修订模式 说明 Default
Single 新修订会自动预配、激活和缩放到所需的大小。 缩放规则定义的所有副本运行后,流量将从旧版本转移到新副本。 如果更新失败,流量仍指向旧修订。 旧修订会自动取消预配。
多个 可以有多个活动修订,在修订之间拆分流量,并选择何时取消预配旧修订。 此级别的控制有助于测试应用的多个版本、蓝绿测试或完全控制应用更新。 有关更多详细信息,请参阅流量拆分

标签

对于具有外部 HTTP 流量的容器应用,请标记将流量定向到特定修订。 标签提供了一个唯一 URL,可用于将流量路由到已分配标签的修订。

若要在修订之间切换流量,可以将标签从一个修订移动到另一个修订。

  • 标签在从一个修订移动到另一个修订时会保留相同的 URL。
  • 一个标签一次只能应用于一个修订。
  • 对于具有标签的修订,不需要分配流量拆分。
  • 当应用处于“多修订模式”时,标签最有用。
  • 可以启用标签、流量拆分或同时启用。

标签可用于测试新修订。 例如,如果想向一组测试用户授予访问权限,可以向他们提供标签的 URL。 然后,如果要将用户移动到其他修订,可以将标签移动到该修订。

标签独立于流量拆分。 流量拆分会根据流量百分比将流向容器应用 URL 的流量分配给修订。 当流量定向到标签的 URL 时,流量将路由到一个特定的修订。

标签名称必须:

  • 包含小写字母数字字符或短划线 (-)
  • 以字母字符开头
  • 以字母数字字符结尾

标签不得:

  • 有两个连续短划线 (--)
  • 超过 64 个字符

可以从 Azure 门户中的容器应用“修订管理”页管理标签。

容器应用修订管理的屏幕截图。

标签 URL 在修订详细信息窗格中可用。

容器应用修订详细信息的屏幕截图。

零停机时间部署

单一修订模式下,容器应用可确保应用在创建新修订时不会经历停机。 在新修订准备就绪之前,不会停用现有活动修订。

如果已启用 Ingress,在新修订准备就绪之前,现有修订将继续获得 100% 的流量。

在以下情况下,新修订被视为准备就绪:

  • 修订已成功预配
  • 修订已纵向扩展,以匹配以前的修订副本计数(遵循新修订的最小和最大副本数)
  • 所有副本都已通过其启动和就绪情况探测

多个修订模式中,可以控制何时激活或停用修订以及哪些修订接收入口流量。 如果流量拆分规则配置为 latestRevision 设置为 true,在就绪之前,流量不会切换到最新版本。

使用多个修订

虽然单一修订模式是默认设置,但有时你可能希望完全控制修订的管理方式。

使用多个修订模式可以灵活地手动管理修订。 例如,使用多个修订模式,可以确切地确定为每个修订分配了多少流量。

流量拆分

下图显示了一个具有两个修订的容器应用。

Azure 容器应用:修订间的流量拆分

此场景假设容器应用处于以下状态:

  • 入口已启用,这样就可以通过 HTTP 或 TCP 来使用容器应用。
  • 第一个修订部署为修订 1。
  • 容器更新后,新修订将作为修订 2 激活。
  • 流量拆分规则配置为修订 1 接收 80% 的请求,而修订 2 接收剩余的 20%。

直接修订访问

你可能希望对特定 URL 的请求提供修订,而不是使用路由规则将流量转移到修订。 多个修订模式可用于将传入域的所有请求发送到最新修订,而较旧修订的请求可通过标签直接访问。

激活状态

在多个修订模式下,可以根据需要激活或停用修订。 活动修订是可操作的,可以处理请求,而非活动修订仍处于休眠状态。

容器应用对非活动修订不收费。 但是,可用修订总数有上限,超过 100 后,会清除最早的修订。

更改类型

对容器应用的更改分为两类:修订范围或应用程序范围的更改。 修订范围的更改会在你部署应用时触发新的修订,而应用程序范围的更改则不会。

修订范围的更改

当使用修订范围的更改更新容器应用时,会创建一个新修订。 更改仅限于部署它们的修订,不会影响其他修订。

修订范围的更改是对容器应用资源模板的 properties.template 部分中参数的任何更改。

这些参数包括:

  • 修订后缀
  • 容器配置和映像
  • 容器应用程序的缩放规则

应用程序范围的更改

部署具有应用程序范围的更改的容器应用时:

  • 更改将全局应用于所有修订。
  • 不会创建新修订。

应用程序范围的更改定义为对容器应用资源模板的 properties.configuration 部分中参数的任何更改。

这些参数包括:

自定义修订

可以自定义修订名称和标签,以便更好地与命名约定或版本控制策略保持一致。

名称后缀

容器应用中的每个修订都分配有唯一标识符。 自动生成名称时,可以个性化修订名称。

修订名称的常见格式为:

<CONTAINER_APP_NAME>-<REVISION_SUFFIX>

例如,如果容器应用名为 album-api 并确定修订后缀为 first-revision,则完整的修订名称变成 album-api-first-revision

修订后缀名称必须:

  • 仅包含小写字母数字字符或短划线 (-)
  • 以字母字符开头
  • 以字母数字字符结尾

名称不得包含:

  • 连续两个短划线 (--)
  • 超过 64 个字符

可以通过 Azure CLI az containerapp createaz containerapp update 命令或在通过 Azure 门户创建修订时在 ARM 模板 中设置修订后缀。

用例

下面是在容器应用中使用修订的常见用例。 此列表不是使用容器应用修订的目的或功能的详尽列表。

发布管理

修订简化了引入应用新版本的过程。 准备好推出更新或新功能时,可以创建新的修订,而不会影响当前实时版本。 此方法可确保顺利过渡,并最大程度地减少最终用户的中断。

还原到以前的版本

有时,需要快速还原到以前稳定的应用版本。 如有必要,可以回滚到容器应用的上一个修订版。

蓝绿部署

修订支持蓝绿部署策略。 通过具有两个并行修订(实时版本为蓝色,新版本为绿色),可以逐步分阶段进行新的修订。 确信新版本的稳定性和性能后,可以将流量完全切换到绿色环境。

后续步骤