在 Azure 容器应用中更新和部署更改
在云中开发容器化应用程序时，更改管理可能会很困难。 最终，你需要支持来跟踪更改，确保运行时间，并具有处理平滑回滚的机制。
Azure 容器应用中的更改管理由修订提供支持，这些修订是容器应用的每个版本的快照。
修订的主要特征包括：
不可变：建立后，修订保持不变。
版本控制：修订充当容器应用版本的记录，在各个阶段捕获其状态。
自动预配：首次部署容器应用时，会自动创建初始修订。
历史记录：默认情况下，你可以访问 100 个非活动修订项，但你可手动调整此阈值。
多个修订：可以并发运行多个修订。 当你需要同时管理应用的不同版本时，此功能特别有用。
生命周期
每个修订都会经历特定状态，受其状态和可用性影响。 在其生命周期内，容器应用会经历不同的预配、运行和非活动状态。
预配状态
创建新的修订时，容器应用将进行启动和准备情况检查。 在此阶段，预配状态充当跟踪容器应用进度的指南。
| 状态 | 说明 |
|---|---|
| Provisioning | 修订正在验证过程中。 |
| 已预配 | 修订已成功通过所有检查。 |
| 预配失败 | 修订在验证期间遇到问题。 |
运行状态
成功预配容器应用后，修订将进入其操作阶段。 运行状态有助于监视容器应用的运行状况和功能。
| 状态 | 说明 |
|---|---|
| Provisioning | 修订正在验证过程中。 |
| 缩放到 0 | 零个副本在运行，没有任何新副本在预配。 如果触发缩放规则，容器应用可以创建新的副本。 |
| 正在激活 | 零个副本在运行，一个副本在预配。 |
| 激活失败 | 第一个副本无法预配。 |
| 缩放/处理 | 正在横向缩放。 一个或多个副本在运行，而其他副本在预配。 |
| 正在运行 | 一个或多个副本在运行。 没有要报告的问题。 |
| 运行（最大） | 最大副本数（根据修订的规模规则）正在运行。 没有要报告的问题。 |
| 取消设置 | 修订正在从活动过渡到非活动状态，并删除已创建的任何资源。 |
| 已降级 | 修订中的至少一个副本处于失败状态。 查看特定问题的运行状态详细信息。 |
| 已失败 | 严重错误导致修订失败。 运行状态提供了详细信息。 常见原因包括： • 终止 • 退出代码 137 |
非活动状态
修订还可以进入非活动状态。 这些修订不具有预配或运行状态。 但是，Azure 容器应用维护这些修订的列表，最多可容纳 100 个非活动条目。 可以随时激活修订。
更改非活动修订项限制
可将 --max-inactive-revisions 参数与 containerapp create 或 containerapp 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，在就绪之前，流量不会切换到最新版本。
使用多个修订
虽然单一修订模式是默认设置，但有时你可能希望完全控制修订的管理方式。
使用多个修订模式可以灵活地手动管理修订。 例如，使用多个修订模式，可以确切地确定为每个修订分配了多少流量。
流量拆分
下图显示了一个具有两个修订的容器应用。
此场景假设容器应用处于以下状态：
- 入口已启用，这样就可以通过 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 create 和 az containerapp update 命令或在通过 Azure 门户创建修订时在 ARM 模板 中设置修订后缀。
用例
下面是在容器应用中使用修订的常见用例。 此列表不是使用容器应用修订的目的或功能的详尽列表。
发布管理
修订简化了引入应用新版本的过程。 准备好推出更新或新功能时，可以创建新的修订，而不会影响当前实时版本。 此方法可确保顺利过渡，并最大程度地减少最终用户的中断。
还原到以前的版本
有时，需要快速还原到以前稳定的应用版本。 如有必要，可以回滚到容器应用的上一个修订版。
蓝绿部署
修订支持蓝绿部署策略。 通过具有两个并行修订（实时版本为蓝色，新版本为绿色），可以逐步分阶段进行新的修订。 确信新版本的稳定性和性能后，可以将流量完全切换到绿色环境。