培训
模块
本模块介绍 Azure 容器应用中的修订概念,并讨论应用程序生命周期管理的选项。 本模块还介绍缩放选项和流入量设置,包括 Azure 容器应用的流量拆分。
你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
在云中开发容器化应用程序时,更改管理可能会很困难。 最终,你需要支持来跟踪更改,确保运行时间,并具有处理平滑回滚的机制。
Azure 容器应用中的更改管理由修订提供支持,这些修订是容器应用的每个版本的快照。
修订的主要特征包括:
不可变:建立后,修订保持不变。
版本控制:修订充当容器应用版本的记录,在各个阶段捕获其状态。
自动预配:首次部署容器应用时,会自动创建初始修订。
历史记录:默认情况下,你可以访问 100 个非活动修订,但你可以 手动调整此阈值。
多个修订:可以并发运行多个修订。 当你需要同时管理应用的不同版本时,此功能特别有用。
每个修订都会经历特定状态,受其状态和可用性影响。 在其生命周期内,容器应用会经历不同的预配、运行和非活动状态。
创建新的修订时,容器应用将进行启动和准备情况检查。 在此阶段,预配状态充当跟踪容器应用进度的指南。
状态 | 说明 |
---|---|
Provisioning | 修订正在验证过程中。 |
已预配 | 修订已成功通过所有检查。 |
预配失败 | 修订在验证期间遇到问题。 |
成功预配容器应用后,修订将进入其操作阶段。 运行状态有助于监视容器应用的运行状况和功能。
状态 | 说明 |
---|---|
Provisioning | 修订正在验证过程中。 |
缩放到 0 | 零个副本在运行,没有任何新副本在预配。 如果触发缩放规则,容器应用可以创建新的副本。 |
正在激活 | 零个副本在运行,一个副本在预配。 |
激活失败 | 第一个副本无法预配。 |
缩放/处理 | 正在横向缩放。 一个或多个副本在运行,而其他副本在预配。 |
正在运行 | 一个或多个副本在运行。 没有要报告的问题。 |
运行(最大) | 最大副本数(根据修订的规模规则)正在运行。 没有要报告的问题。 |
取消设置 | 修订正在从活动过渡到非活动状态,并删除已创建的任何资源。 |
已降级 | 修订中的至少一个副本处于失败状态。 查看特定问题的运行状态详细信息。 |
已失败 | 严重错误导致修订失败。 运行状态提供了详细信息。 常见原因包括: • 终止 • 退出代码 137 |
修订还可以进入非活动状态。 这些修订不具有预配或运行状态。 但是,Azure 容器应用维护这些修订的列表,最多可容纳 100 个非活动条目。 可以随时激活修订。
可以将--max-inactive-revisions
参数与或containerapp update
命令一起使用containerapp create
,以控制容器应用跟踪的非活动修订数。
此示例演示如何创建跟踪 50 个非活动修订的新容器应用:
az containerapp create --max-inactive-revisions 50
Azure 容器应用支持两种修订模式。 你选择的模式决定了应用同时处于活动状态的修订数。
修订模式 | 说明 | Default |
---|---|---|
Single | 新修订会自动预配、激活和缩放到所需的大小。 缩放规则定义的所有副本运行后,流量将从旧版本转移到新副本。 如果更新失败,流量仍指向旧修订。 旧修订会自动取消预配。 | 是 |
多个 | 可以有多个活动修订,在修订之间拆分流量,并选择何时取消预配旧修订。 此级别的控制有助于测试应用的多个版本、蓝绿测试或完全控制应用更新。 有关更多详细信息,请参阅流量拆分 。 |
对于具有外部 HTTP 流量的容器应用,请标记将流量定向到特定修订。 标签提供了一个唯一 URL,可用于将流量路由到已分配标签的修订。
若要在修订之间切换流量,可以将标签从一个修订移动到另一个修订。
标签可用于测试新修订。 例如,如果想向一组测试用户授予访问权限,可以向他们提供标签的 URL。 然后,如果要将用户移动到其他修订,可以将标签移动到该修订。
标签独立于流量拆分。 流量拆分会根据流量百分比将流向容器应用 URL 的流量分配给修订。 当流量定向到标签的 URL 时,流量将路由到一个特定的修订。
标签名称必须:
-
)标签不得:
--
)可以从 Azure 门户中的容器应用“修订管理”页管理标签。
标签 URL 在修订详细信息窗格中可用。
在 单一修订模式下,容器应用可确保应用在创建新修订时不会经历停机。 在新修订准备就绪之前,不会停用现有活动修订。
如果已启用 Ingress,在新修订准备就绪之前,现有修订将继续获得 100% 的流量。
在以下情况下,新修订被视为准备就绪:
在多个修订模式中,可以控制何时激活或停用修订以及哪些修订接收入口流量。 如果流量拆分规则配置为 latestRevision
设置为 true
,在就绪之前,流量不会切换到最新版本。
虽然单一修订模式是默认设置,但有时你可能希望完全控制修订的管理方式。
使用多个修订模式可以灵活地手动管理修订。 例如,使用多个修订模式,可以确切地确定为每个修订分配了多少流量。
下图显示了一个具有两个修订的容器应用。
此场景假设容器应用处于以下状态:
你可能希望对特定 URL 的请求提供修订,而不是使用路由规则将流量转移到修订。 多个修订模式可用于将传入域的所有请求发送到最新修订,而较旧修订的请求可通过标签直接访问。
在多个修订模式下,可以根据需要激活或停用修订。 活动修订是可操作的,可以处理请求,而非活动修订仍处于休眠状态。
容器应用对非活动修订不收费。 但是,可用修订总数有上限,超过 100 后,会清除最早的修订。
对容器应用的更改分为两类:修订范围或应用程序范围的更改。 修订范围的更改会在你部署应用时触发新的修订,而应用程序范围的更改则不会。
当使用修订范围的更改更新容器应用时,会创建一个新修订。 更改仅限于部署它们的修订,不会影响其他修订。
修订范围的更改是对容器应用资源模板的 properties.template
部分中参数的任何更改。
这些参数包括:
部署具有应用程序范围的更改的容器应用时:
应用程序范围的更改定义为对容器应用资源模板的 properties.configuration
部分中参数的任何更改。
这些参数包括:
可以自定义修订名称和标签,以便更好地与命名约定或版本控制策略保持一致。
容器应用中的每个修订都分配有唯一标识符。 自动生成名称时,可以个性化修订名称。
修订名称的常见格式为:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
例如,如果容器应用名为 album-api 并确定修订后缀为 first-revision,则完整的修订名称变成 album-api-first-revision。
修订后缀名称必须:
-
)名称不得包含:
--
)可以通过 Azure CLI az containerapp create
和 az containerapp update
命令或在通过 Azure 门户创建修订时在 ARM 模板 中设置修订后缀。
下面是在容器应用中使用修订的常见用例。 此列表不是使用容器应用修订的目的或功能的详尽列表。
修订简化了引入应用新版本的过程。 准备好推出更新或新功能时,可以创建新的修订,而不会影响当前实时版本。 此方法可确保顺利过渡,并最大程度地减少最终用户的中断。
有时,需要快速还原到以前稳定的应用版本。 如有必要,可以回滚到容器应用的上一个修订版。
如果要测试应用的不同版本,修订可以支持 A/B 测试。 可以将一部分用户路由到新的修订,收集反馈,并根据实际数据做出明智的决策。
修订支持蓝绿部署策略。 通过具有两个并行修订(实时版本为蓝色,新版本为绿色),可以逐步分阶段进行新的修订。 确信新版本的稳定性和性能后,可以将流量完全切换到绿色环境。
培训
模块
本模块介绍 Azure 容器应用中的修订概念,并讨论应用程序生命周期管理的选项。 本模块还介绍缩放选项和流入量设置,包括 Azure 容器应用的流量拆分。
文档
了解 Azure 容器应用中的完整应用程序生命周期
在 Azure 容器应用中管理修订
了解如何在 Azure 容器应用中管理和配置容器