执行器与更新策略¶
执行器把来源的发布渠道绑定到实际服务。创建前先确认版本筛选和运行时连接正确，并检查目标的支持范围。
创建与绑定¶
- 新建执行器，选择运行时连接并发现目标。
- 为目标绑定具体的追踪器来源和发布渠道；多服务目标逐项核对，不要把不同服务指向同一个镜像来源。
- 首次使用手动模式，复核目标镜像或 Chart 版本后保存。
SSH Compose 目标¶
选择 SSH 主机连接后，可自动发现远程主机上的 Compose 项目；无法可靠发现时手动填写工作目录、Compose 文件（按加载顺序）、环境文件和 Profiles。点击 分析 后只读解析项目，确认 Compose 工具、服务及其版本来源。
| 版本写入方式 | 行为 |
|---|---|
| 修改原文件/环境变量 | 原地更新 Compose 文件或环境文件中的镜像引用 |
| 独立镜像覆盖文件 | 创建并维护 ReleaseTracker 专用的覆盖文件，不改原文件；变量来自进程环境时使用此方式 |
只修改已选择服务的镜像；镜像表达式过于复杂、变量被多处共享或只有 build 配置时拒绝执行。一个项目只能被一个执行器占用。更新前保存项目文件快照；若连接中断导致结果不确定，项目保持锁定，需在执行器中确认远端命令已停止后选择 恢复配置文件 或 核验并解锁。恢复文件不会回滚正在运行的容器。
触发方式¶
| 模式 | 何时执行 |
|---|---|
| 手动 | 操作员在界面触发 |
| 立即 | 发现新的目标版本后自动执行 |
| 维护窗口 | 仅在允许的星期和时段内自动执行，按系统时区解释 |
维护窗口只约束自动部署的首次远程写入；已开始的多步更新和就绪观察可跨窗口完成。没有符合规则的目标版本、配置停用或已是目标版本时，运行会被跳过。
镜像选择¶
| 策略 | 适用情况 |
|---|---|
| 替换当前镜像的 Tag | 保留当前镜像仓库，只使用来源提供的版本标签 |
| 使用追踪器镜像和 Tag | 目标应使用 OCI 来源中配置的镜像仓库 |
| Digest 引用 | 需要锁定到具体构建，且来源提供可用摘要 |
| Tag 引用 | 使用版本标签；同一标签可能被上游重新发布 |
Tag 模式始终保留 image:tag，不会因任务入队或同名 Tag 自动附加 digest。只有不可变镜像证据确认制品相同才跳过；同一 Tag 解析到新摘要时仍会拉取并重建。Digest 模式用于把运行引用固定到具体构建。切换 Tag / Digest 策略时，即使制品摘要相同，也会应用新的引用方式。
Helm Release 不使用这些字段，而是选择 Chart 版本。同名 Git Tag 不一定存在对应镜像 Tag，先核对仓库和构建发布规则。
自动升级版本限制¶
可选“不限版本”（默认）、“仅次版本和补丁”或“仅补丁”。范围限制使用与目标选择一致的版本解析规则，并保留现有可比较版本格式的兼容；预发布版本仍需确认。超出范围会转为部署计划确认，不消耗重试次数。所有策略及手动触发都不能自动绕过降级或未知方向审批；“不限版本”只允许跨主版本升级，不授权降级。容器按运行镜像 tag 判断；Helm 按 Chart 版本而非 appVersion；分组只比较已绑定的服务。无法可靠取得当前版本的路径总是需要确认。手动部署可绕过升级范围限制，但不能绕过方向检查。同 tag 的不同 digest 表示制品变更，不表示版本升级。
选择规则升级后，旧任务保留原目标，但不允许沿用旧复核批准继续执行；确认新目标后发起新任务，不会原地替换已批准目标。
部署计划确认¶
部署前会只读采集目标现状并生成部署计划。以下情况任务会停在 需要确认部署计划，并发送“需要确认部署”通知：
- 初次纳管目标，或目标缺少 ReleaseTracker 纳管标记；
- 运行配置与上次纳管基线不一致（配置漂移）；
- 自动更新超出版本限制，或任意更新涉及降级、方向未知及其他风险审核要求；
- 缺少历史批准或基线证据，或旧版身份需要复核。
已纳管且无配置漂移的目标，手动向前更新与自动更新遵循相同的安全检查，不会仅因手动触发而额外要求确认。手动更新可绕过升级范围限制；风险、降级、方向未知、未纳管、配置漂移与旧版证据等情况仍需审核。已有待审核计划保留历史原因；刷新计划后按当前证据重新判断，不能因规则变化直接沿用旧批准。
部署结果、就绪结果与纳管基线分别记录。部署成功后，暂缺的基线证据会由独立后台任务退避重试；旧计划缺少批准证明、配置或归属不符时显示 基线待审核，不会将成功部署改为失败，也不会仅因此阻挡其他实例。后续实际更新仍需审核配置；自动补齐只接纳能证明属于原部署目标及批准范围的证据，不接纳额外配置变更。
任务详情提供实际阻塞任务的链接，以及 重新核验基线 操作。证据重试耗尽后仍会保留最后一次具体原因与所处阶段（目标校验、运行时检查或基线核验），不显示原始异常。原因区分实时 Chart 版本不可用或不匹配、Chart 部署回执缺失、Chart 摘要不匹配、制品未核实，以及运行时检查超时或失败。重新核验只读检查当前运行证据，不重新部署、不批准配置，也不能补造旧计划缺失的历史证明。已经由后续部署替代的基线核验会结束。成功部署应用相同配置与目标后，较早搁置的任务可标记为 已替代，原因为 目标已应用（target_applied），并链接到实际完成目标的任务，不会重复更新。运行结果不明或写入中断的任务仍保留门禁，需要先核实状态。
Helm 更新先下载 Chart 包；目标含 SHA256 摘要时，校验通过后才使用同一文件执行升级。同版本但不同摘要不会直接跳过。成功回执绑定 Helm release revision，外部升级后不能继续沿用旧摘要。仓库未提供摘要时仍按版本选择，无法提供审批时制品内容不变的保证；OCI manifest 摘要不能作为 Chart 压缩包摘要使用。
Helm 准入与写前复核还绑定同一 revision 的用户 values 和声明 manifest；升级后核对目标 Chart 与精确用户 values，允许新版 Chart 正常改变模板和默认值。声明参与后续漂移检查，但这不代表完整审计所有 live workload 配置。公开部署／恢复差异和快照详情会整体隐藏这些文档，包括可能含凭证的映射键；旧批准没有新范围证明时仍需配置复核，不能自动接纳当前配置。
资源门禁只在能够证明运行时身份时收窄到引擎或集群。同一 Docker 引擎的 SDK、Portainer 和 SSH 入口共享范围；同一 Kubernetes 集群的 Helm 和 workload 仍相互约束。无法证明身份、原生 Podman 和旧格式记录继续使用保守范围。
Helm 3 的 status -o json 不包含 Chart 信息，部署版本与修订号统一从 helm get metadata 读取，helm list --all 仅在没有可用元数据时回退。所有读取经过同一入口，并核对 release、namespace、状态和 revision；读取期间发生升级时拒绝混合证据，权限或命令错误不会静默回退。读不到实时 Chart 版本时不使用配置中保存的旧版本，也不生成不可靠的恢复快照。列表回退按完整 SemVer 识别预发布和构建信息，有歧义时保持未知。发现页以实时元数据为准，workload 标签只用于展示回退。
旧版 Helm 纳管身份若包含 Chart 版本或摘要，系统只在旧审批写入记录、目标坐标、运行时和当前部署标记一致时允许 历史身份复核。刷新只生成计划，不改纳管记录；人工批准后转换身份，保留旧基线直到新部署核验。缺少历史证据或目标真实变化时继续阻断。
Helm 的 app_version 是 Chart 的运行元数据，不参与目标身份。若历史身份复核后的升级失败，需先人工确认远端操作已停止且状态已核实；系统仅在原批准链、旧基线、固定坐标和纳管标记均可验证时允许重新复核。重新批准不补记旧任务成功，也不清空基线；新的写入或基线变化会使该复核失效。
在任务详情中核对目标、运行时身份、配置指纹、恢复范围和配置差异（敏感值隐藏），再点击 确认并继续部署。确认有有效期，并绑定当前证据；执行前配置变化需要 刷新计划 重新确认。配置差异未完整显示时不能确认。
目标已被其他实例或执行器纳管、纳管标记冲突或版本不受支持时，部署直接 阻断，不能通过确认绕过，需要先处理归属。
若旧执行器已删除，且本地仍保留与当前运行时、目标及残留标记匹配的已审批写入历史，可按首次纳管重新审核；确认并执行后才替换标记，不会自动接管。缺少可验证历史时仍然阻断。
验证一次更新¶
运行前确认目标版本、镜像策略和服务绑定。运行后在执行历史和 任务队列 中查看状态、目标版本和每个服务的诊断，再检查应用是否可用。