Harbor 定时触发Scheduled Trigger复制规则实战指南从 UI 配置到源码原理【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本文围绕 Harbor 复制Replication功能的定时触发模式完整讲解如何在 Harbor 中创建并验证一条定时复制规则并结合tests/testcases/Group7-Replication/7-07-Trigger-scheduled.md测试用例与控制器层源码剖析定时触发的调度链路、Cron 校验规则与执行语义。读完本文你将掌握定时复制规则的 UI 配置方法、验证手段以及 Harbor 内部策略 → 调度器 → JobService → 复制执行的完整实现原理。测试用例背景Test 7-07 在验证什么tests/testcases/Group7-Replication/7-07-Trigger-scheduled.md是 Harbor 复制功能测试套件中的一项功能用例它的目的是验证定时触发scheduled trigger的复制规则能够按预期工作。该用例归属于Group7-Replication系列。从同目录下的姊妹用例可以看出复制规则的触发方式一共有三种分别由三个用例覆盖用例文件触发方式核心验证点7-05-Trigger-manual.md手动触发Manual管理员在 Replications 页面点击REPLICATE按钮手动启动复制7-06-Trigger-immediate.md事件触发Immediate/Event-based推送镜像后自动复制且受删除远程镜像开关影响7-07-Trigger-scheduled.md定时触发Scheduled到达配置的时间点后自动启动复制任务项目下所有镜像被复制到远端仓库本文聚焦 7-07 用例同时结合同一套件的其余用例与源码佐证帮助读者理解定时触发的全貌。测试环境与前置条件要复现 7-07 用例需要准备如下环境至少两个可用的 Harbor 实例一个作为复制源一个作为复制目标远程仓库。这是所有复制类用例的公共前提见 7-05、7-06。新建一条复制规则触发条件设置为定时触发Scheduled不配置任何过滤器no filter。不配置过滤器的意义在于规则会作用于项目下的全部镜像从而让用例的期望结果所有镜像都被复制是确定性的、可完整验证的。项目中至少已推送一个镜像规则应用于该项目后需要存在真实内容可供复制否则即使定时任务触发也无从验证复制效果。用例还引用了 User guide用户指南作为参考文档即定时触发属于 Harbor 对外提供的正式功能而非内部实验特性。测试步骤与期望结果测试步骤以admin 用户登录 Harbor Web UI。进入Administration - Replications管理 - 复制页面。期望结果当规则中配置的定时时间点到来时应该启动若干个复制任务jobs项目下的所有镜像都应该被成功复制到远程 registry。值得注意的是与 手动触发用例 需要在页面点击按钮不同定时触发模式下管理员不需要做任何手动操作——复制由调度器在预设时刻自动发起。这也是定时触发区别于手动触发和事件触发的核心语义。三种触发方式的源码对照从控制器层的数据模型可以印证上述三种触发方式的划分。在 复制策略模型 的Validate方法中触发类型被限定为三类model.TriggerTypeManual手动触发model.TriggerTypeEventBased事件触发model.TriggerTypeScheduled定时触发其中IsScheduledTrigger方法model.go给出了是否为定时触发的严格定义func (p *Policy) IsScheduledTrigger() bool { if !p.Enabled { return false } if p.Trigger nil { return false } return p.Trigger.Type model.TriggerTypeScheduled }即一条规则要被认定为定时触发必须同时满足规则处于启用状态Enabled、Trigger 非空、Trigger 类型为 Scheduled。这也意味着如果一条定时规则被停用调度器将不再触发它。从持久化模型看触发类型与 Cron 表达式以 JSON 字符串形式存放在replication_policy表的trigger字段中见 src/pkg/replication/model/model.go。Cron 表达式的校验规则定时触发依赖 Cron 表达式来定义执行时刻。Harbor 对复制规则的 Cron 做了比通用 Cron 更严格的约束这些约束在 model.go 的校验逻辑中一目了然校验项规则原因/含义Cron 非空定时触发下 Cron 字符串不能为空没有执行时刻就无法调度Cron 可解析必须能被 Harbor 的utils.CronParser()解析语法错误直接拒绝第 1 字段秒必须为0Harbor 定时复制最小粒度到分钟不允许指定秒第 2 字段分钟不允许为*禁止每分钟执行一次避免高频复制产生大量任务校验失败时返回BadRequestCode错误并在 UI 上提示对应的错误信息例如 the 1st field (indicating Seconds of time) of the cron setting must be 0 或 * is not allowed for the Minutes field of the cron setting of replication policy。历史兼容旧版 ScheduleParam 转 CronHarbor 还保留了与旧版本数据的兼容逻辑。在 parseTrigger 中如果策略的 trigger 字段没有type旧格式会依据kind判断触发类型Manual→TriggerTypeManualImmediate→TriggerTypeEventBasedScheduled→TriggerTypeScheduled并通过parseScheduleParamToCronmodel.go把旧的ScheduleParam包含Type、Weekday、Offtime转换为标准 Cronif param.Type Weekly { return fmt.Sprintf(%d %d %d * * %d, second, minute, hour, param.Weekday%7) } return fmt.Sprintf(%d %d %d * * *, second, minute, hour)也就是说旧版每日/每周定时配置在升级后会自动映射为等价的 Cron 表达式无需用户重新配置。定时调度的完整链路源码级当一条定时复制规则创建成功并启用后Harbor 内部会发生什么核心逻辑在 复制策略控制器 中。创建/更新规则时注册调度在CreatePolicypolicy.go和UpdatePolicypolicy.go中只要policy.IsScheduledTrigger()为真就会调用全局调度器c.scheduler.Schedule(ctx, job.ReplicationVendorType, id, , policy.Trigger.Settings.Cron, callbackFuncName, cbParams, map[string]any{})其中job.ReplicationVendorType标识该调度属于复制功能id是复制策略 ID作为VendorIDpolicy.Trigger.Settings.Cron是用户配置的 Cron 表达式callbackFuncName即REPLICATION_CALLBACK是预先注册的回调函数名cbParams携带policy_id与operatorjobservice 用户用于回调时定位具体策略。更新规则时会先调用UnScheduleByVendor删除旧调度再按新 Cron 重新注册保证修改立即生效。删除规则时DeletePolicypolicy.go则会先清理执行记录与调度记录。回调函数定时点到来的那一刻REPLICATION_CALLBACK在包初始化阶段注册policy.gocallbackFunc : func(ctx context.Context, param string) error { // 解析参数取出 policy_id 与 operator policy, err : Ctl.GetPolicy(ctx, policyID) ... _, err Ctl.Start(ctx, policy, nil, task.ExecutionTriggerSchedule) return err }回调函数从参数中解析出policy_id加载对应策略然后以task.ExecutionTriggerSchedule作为触发器标识调用Ctl.Start正式启动一次复制执行。这是定时触发在代码层面的落点——它最终与手动触发ExecutionTriggerManual共用同一条Start入口只是触发来源不同。调度器实现Cron 如何变成周期性任务Harbor 的全局调度器实现在 src/pkg/scheduler/scheduler.go核心是Schedule方法scheduler.go校验Cron 必须可解析回调函数必须已注册落库在事务中依次创建 schedule 记录、执行记录execMgr.Create与任务记录taskMgr.Create提交 JobService任务以JobKind: job.KindPeriodic的周期性 Job 形式提交给 JobServiceCron 表达式作为其调度依据scheduler.go健康检查任务创建后查询任务状态若为ErrorStatus则回滚清理保证调度注册要么完全成功、要么完全失败scheduler.go。由此可见定时复制本质上是JobService 中的一个周期性 Job到点后由 JobService 触发回调回调再驱动复制流程执行。执行入口Start 与执行记录Ctl.Start定义在 src/controller/replication/execution.go其关键行为包括检查策略是否启用未启用则直接返回前置条件错误若策略开启了SingleActiveReplication单活复制会统计当前正在运行的执行数存在运行中的执行时新执行会被标记为Execution skipped: active replication still in progress.避免同一策略并行复制造成资源竞争execution.go创建执行记录execMgr.Create触发来源正是ExecutionTriggerSchedule在 goroutine 中启动复制流程flowCtl.Start复制流程由 src/controller/replication/flow 下的controller.go、copy.go、deletion.go、stage.go等模块协作完成镜像/制品向远端 registry 的同步。由于定时触发与手动触发共用Start其复制行为过滤器、命名空间映射、覆盖策略、删除同步等完全一致区别仅在于由谁在什么时刻发起。实战验证建议结合 7-07 用例与上述源码分析可以按以下思路在真实环境中完成定时复制的验证准备双实例部署两台 Harbor源、目标在目标 Harbor 中为源 Harbor 配置 Registry 端点对应用例 7-12-Endpoints-endpoints-add.md。创建定时规则在Administration - Replications新建规则选择源/目标端点触发方式选 Scheduled填入满足约束的 Cron如0 0 2 * * *表示每天 02:00 执行注意秒字段必须为 0、分钟字段不能为*保持过滤器为空。准备镜像向源 Harbor 对应项目推送至少一个镜像。等待触发到达预设时刻后在Administration - Replications页面查看执行记录对应用例 7-08-Proj-replication-jobs-filter.md确认产生了以 Scheduled 为触发来源的执行。校验结果确认项目下全部镜像已出现在目标 Harbor 的对应命名空间中即用例期望的All the images under the project should be replicated to the remote registry。常见问题排查规则已到点但未触发检查规则是否处于启用状态——IsScheduledTrigger要求Enabled true同时确认 Cron 第 1 字段为0、第 2 字段不为*否则规则创建/更新时就会被校验拦截。执行被跳过若规则开启了SingleActiveReplication且上一次执行尚未结束新触发的执行会被标记为 skipped见 execution.go这属于预期的并发保护行为。需要修改触发时间编辑规则中的 Cron 后保存控制器会先UnScheduleByVendor删除旧调度再注册新调度policy.go无需手动清理。升级自旧版本旧格式的ScheduleParamDaily/Weekly Offtime会在读取时自动转换为标准 Cron无需重新录入model.go。小结Test 7-07 验证了 Harbor 复制功能的定时触发模式管理员只需配置好规则与 Cron 时刻后续的复制将由 Harbor 调度器与 JobService 自动完成无需人工介入。从源码看定时触发的实现高度工程化——严格但合理的 Cron 校验、事务化的调度注册、与手动/事件触发统一的执行入口以及单活复制等并发保护共同保证了定时复制在生产环境中的可靠性与可预期性。读者可结合 Group7-Replication 下的其余用例进一步构建对 Harbor 复制体系规则管理、过滤器、端点管理、任务查看的完整认知。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Harbor 定时触发（Scheduled Trigger）复制规则实战指南：从 UI 配置到源码原理
Harbor 定时触发Scheduled Trigger复制规则实战指南从 UI 配置到源码原理【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本文围绕 Harbor 复制Replication功能的定时触发模式完整讲解如何在 Harbor 中创建并验证一条定时复制规则并结合tests/testcases/Group7-Replication/7-07-Trigger-scheduled.md测试用例与控制器层源码剖析定时触发的调度链路、Cron 校验规则与执行语义。读完本文你将掌握定时复制规则的 UI 配置方法、验证手段以及 Harbor 内部策略 → 调度器 → JobService → 复制执行的完整实现原理。测试用例背景Test 7-07 在验证什么tests/testcases/Group7-Replication/7-07-Trigger-scheduled.md是 Harbor 复制功能测试套件中的一项功能用例它的目的是验证定时触发scheduled trigger的复制规则能够按预期工作。该用例归属于Group7-Replication系列。从同目录下的姊妹用例可以看出复制规则的触发方式一共有三种分别由三个用例覆盖用例文件触发方式核心验证点7-05-Trigger-manual.md手动触发Manual管理员在 Replications 页面点击REPLICATE按钮手动启动复制7-06-Trigger-immediate.md事件触发Immediate/Event-based推送镜像后自动复制且受删除远程镜像开关影响7-07-Trigger-scheduled.md定时触发Scheduled到达配置的时间点后自动启动复制任务项目下所有镜像被复制到远端仓库本文聚焦 7-07 用例同时结合同一套件的其余用例与源码佐证帮助读者理解定时触发的全貌。测试环境与前置条件要复现 7-07 用例需要准备如下环境至少两个可用的 Harbor 实例一个作为复制源一个作为复制目标远程仓库。这是所有复制类用例的公共前提见 7-05、7-06。新建一条复制规则触发条件设置为定时触发Scheduled不配置任何过滤器no filter。不配置过滤器的意义在于规则会作用于项目下的全部镜像从而让用例的期望结果所有镜像都被复制是确定性的、可完整验证的。项目中至少已推送一个镜像规则应用于该项目后需要存在真实内容可供复制否则即使定时任务触发也无从验证复制效果。用例还引用了 User guide用户指南作为参考文档即定时触发属于 Harbor 对外提供的正式功能而非内部实验特性。测试步骤与期望结果测试步骤以admin 用户登录 Harbor Web UI。进入Administration - Replications管理 - 复制页面。期望结果当规则中配置的定时时间点到来时应该启动若干个复制任务jobs项目下的所有镜像都应该被成功复制到远程 registry。值得注意的是与 手动触发用例 需要在页面点击按钮不同定时触发模式下管理员不需要做任何手动操作——复制由调度器在预设时刻自动发起。这也是定时触发区别于手动触发和事件触发的核心语义。三种触发方式的源码对照从控制器层的数据模型可以印证上述三种触发方式的划分。在 复制策略模型 的Validate方法中触发类型被限定为三类model.TriggerTypeManual手动触发model.TriggerTypeEventBased事件触发model.TriggerTypeScheduled定时触发其中IsScheduledTrigger方法model.go给出了是否为定时触发的严格定义func (p *Policy) IsScheduledTrigger() bool { if !p.Enabled { return false } if p.Trigger nil { return false } return p.Trigger.Type model.TriggerTypeScheduled }即一条规则要被认定为定时触发必须同时满足规则处于启用状态Enabled、Trigger 非空、Trigger 类型为 Scheduled。这也意味着如果一条定时规则被停用调度器将不再触发它。从持久化模型看触发类型与 Cron 表达式以 JSON 字符串形式存放在replication_policy表的trigger字段中见 src/pkg/replication/model/model.go。Cron 表达式的校验规则定时触发依赖 Cron 表达式来定义执行时刻。Harbor 对复制规则的 Cron 做了比通用 Cron 更严格的约束这些约束在 model.go 的校验逻辑中一目了然校验项规则原因/含义Cron 非空定时触发下 Cron 字符串不能为空没有执行时刻就无法调度Cron 可解析必须能被 Harbor 的utils.CronParser()解析语法错误直接拒绝第 1 字段秒必须为0Harbor 定时复制最小粒度到分钟不允许指定秒第 2 字段分钟不允许为*禁止每分钟执行一次避免高频复制产生大量任务校验失败时返回BadRequestCode错误并在 UI 上提示对应的错误信息例如 the 1st field (indicating Seconds of time) of the cron setting must be 0 或 * is not allowed for the Minutes field of the cron setting of replication policy。历史兼容旧版 ScheduleParam 转 CronHarbor 还保留了与旧版本数据的兼容逻辑。在 parseTrigger 中如果策略的 trigger 字段没有type旧格式会依据kind判断触发类型Manual→TriggerTypeManualImmediate→TriggerTypeEventBasedScheduled→TriggerTypeScheduled并通过parseScheduleParamToCronmodel.go把旧的ScheduleParam包含Type、Weekday、Offtime转换为标准 Cronif param.Type Weekly { return fmt.Sprintf(%d %d %d * * %d, second, minute, hour, param.Weekday%7) } return fmt.Sprintf(%d %d %d * * *, second, minute, hour)也就是说旧版每日/每周定时配置在升级后会自动映射为等价的 Cron 表达式无需用户重新配置。定时调度的完整链路源码级当一条定时复制规则创建成功并启用后Harbor 内部会发生什么核心逻辑在 复制策略控制器 中。创建/更新规则时注册调度在CreatePolicypolicy.go和UpdatePolicypolicy.go中只要policy.IsScheduledTrigger()为真就会调用全局调度器c.scheduler.Schedule(ctx, job.ReplicationVendorType, id, , policy.Trigger.Settings.Cron, callbackFuncName, cbParams, map[string]any{})其中job.ReplicationVendorType标识该调度属于复制功能id是复制策略 ID作为VendorIDpolicy.Trigger.Settings.Cron是用户配置的 Cron 表达式callbackFuncName即REPLICATION_CALLBACK是预先注册的回调函数名cbParams携带policy_id与operatorjobservice 用户用于回调时定位具体策略。更新规则时会先调用UnScheduleByVendor删除旧调度再按新 Cron 重新注册保证修改立即生效。删除规则时DeletePolicypolicy.go则会先清理执行记录与调度记录。回调函数定时点到来的那一刻REPLICATION_CALLBACK在包初始化阶段注册policy.gocallbackFunc : func(ctx context.Context, param string) error { // 解析参数取出 policy_id 与 operator policy, err : Ctl.GetPolicy(ctx, policyID) ... _, err Ctl.Start(ctx, policy, nil, task.ExecutionTriggerSchedule) return err }回调函数从参数中解析出policy_id加载对应策略然后以task.ExecutionTriggerSchedule作为触发器标识调用Ctl.Start正式启动一次复制执行。这是定时触发在代码层面的落点——它最终与手动触发ExecutionTriggerManual共用同一条Start入口只是触发来源不同。调度器实现Cron 如何变成周期性任务Harbor 的全局调度器实现在 src/pkg/scheduler/scheduler.go核心是Schedule方法scheduler.go校验Cron 必须可解析回调函数必须已注册落库在事务中依次创建 schedule 记录、执行记录execMgr.Create与任务记录taskMgr.Create提交 JobService任务以JobKind: job.KindPeriodic的周期性 Job 形式提交给 JobServiceCron 表达式作为其调度依据scheduler.go健康检查任务创建后查询任务状态若为ErrorStatus则回滚清理保证调度注册要么完全成功、要么完全失败scheduler.go。由此可见定时复制本质上是JobService 中的一个周期性 Job到点后由 JobService 触发回调回调再驱动复制流程执行。执行入口Start 与执行记录Ctl.Start定义在 src/controller/replication/execution.go其关键行为包括检查策略是否启用未启用则直接返回前置条件错误若策略开启了SingleActiveReplication单活复制会统计当前正在运行的执行数存在运行中的执行时新执行会被标记为Execution skipped: active replication still in progress.避免同一策略并行复制造成资源竞争execution.go创建执行记录execMgr.Create触发来源正是ExecutionTriggerSchedule在 goroutine 中启动复制流程flowCtl.Start复制流程由 src/controller/replication/flow 下的controller.go、copy.go、deletion.go、stage.go等模块协作完成镜像/制品向远端 registry 的同步。由于定时触发与手动触发共用Start其复制行为过滤器、命名空间映射、覆盖策略、删除同步等完全一致区别仅在于由谁在什么时刻发起。实战验证建议结合 7-07 用例与上述源码分析可以按以下思路在真实环境中完成定时复制的验证准备双实例部署两台 Harbor源、目标在目标 Harbor 中为源 Harbor 配置 Registry 端点对应用例 7-12-Endpoints-endpoints-add.md。创建定时规则在Administration - Replications新建规则选择源/目标端点触发方式选 Scheduled填入满足约束的 Cron如0 0 2 * * *表示每天 02:00 执行注意秒字段必须为 0、分钟字段不能为*保持过滤器为空。准备镜像向源 Harbor 对应项目推送至少一个镜像。等待触发到达预设时刻后在Administration - Replications页面查看执行记录对应用例 7-08-Proj-replication-jobs-filter.md确认产生了以 Scheduled 为触发来源的执行。校验结果确认项目下全部镜像已出现在目标 Harbor 的对应命名空间中即用例期望的All the images under the project should be replicated to the remote registry。常见问题排查规则已到点但未触发检查规则是否处于启用状态——IsScheduledTrigger要求Enabled true同时确认 Cron 第 1 字段为0、第 2 字段不为*否则规则创建/更新时就会被校验拦截。执行被跳过若规则开启了SingleActiveReplication且上一次执行尚未结束新触发的执行会被标记为 skipped见 execution.go这属于预期的并发保护行为。需要修改触发时间编辑规则中的 Cron 后保存控制器会先UnScheduleByVendor删除旧调度再注册新调度policy.go无需手动清理。升级自旧版本旧格式的ScheduleParamDaily/Weekly Offtime会在读取时自动转换为标准 Cron无需重新录入model.go。小结Test 7-07 验证了 Harbor 复制功能的定时触发模式管理员只需配置好规则与 Cron 时刻后续的复制将由 Harbor 调度器与 JobService 自动完成无需人工介入。从源码看定时触发的实现高度工程化——严格但合理的 Cron 校验、事务化的调度注册、与手动/事件触发统一的执行入口以及单活复制等并发保护共同保证了定时复制在生产环境中的可靠性与可预期性。读者可结合 Group7-Replication 下的其余用例进一步构建对 Harbor 复制体系规则管理、过滤器、端点管理、任务查看的完整认知。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考