容器运行时云原生【免费下载链接】docker-ce:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:项目地址https://gitcode.com/gh_mirrors/do/docker-ce点击查看免费下载docker service rollback是 Docker Swarm 集群管理命令家族中的关键成员用于将某个服务的配置一键回退到最近一次docker service update之前的状态是线上发布出现异常时快速止损的标配操作。本指南以 service_rollback.md 官方参考文档为主体结合本仓库中 CLI 与 engine 的源码实现从命令语法、执行原理、参数细节到真实测试用例为你完整拆解服务回滚的来龙去脉读完即可在 Swarm 集群中安全、精准地执行回滚。命令概览与语法参考文档给出了该命令最基础的用法与可用选项Usage: docker service rollback SERVICE Revert changes to a services configuration Options: -d, --detach Exit immediately instead of waiting for the service to converge (default true) --help Print usage -q, --quiet Suppress progress output对应参数说明如下选项简写默认值说明--detach-d参考文档标注 default true立即退出命令不再等待服务收敛完成--help——打印命令用法帮助--quiet-qfalse抑制滚动收敛过程中的进度输出在源码层面该命令定义于 rollback.goUse为rollback [OPTIONS] SERVICEArgs: cli.ExactArgs(1)强制要求恰好传入一个服务参数多了少了都会报错并通过Annotations标注了version: 1.31表明该命令对应的 API 版本能力。需要注意一个细节参考文档标注--detach默认值为true而当前仓库代码中addDetachFlag注册的默认值为false见 opts.go即默认会等待服务收敛实际行为取决于 CLI 构建版本与连接 daemon 的 API 版本。要立即返回时请显式加--detach。使用前提必须在 Swarm Manager 节点执行docker service rollback属于集群管理命令参考文档明确提示This is a cluster management command, and must be executed on a swarm manager node.在源码中也有对应佐证service命令族在 cmd.go 处统一设置了swarm: 注解rollback命令正是通过newRollbackCommand(dockerCli)注册进该命令族下的 9 个子命令之一。因此只有Swarm manager 节点才能执行该命令worker 节点上执行会因缺乏管理权限而失败若集群尚未初始化docker swarm init或未加入任何集群同样无法使用。工作原理从 CLI 到 Swarm 控制面的完整调用链理解回滚到底做了什么需要从 CLI 一路追到 daemon 与 swarmkit 控制面。整个链路可以分为三步。第一步CLI 侧组装服务端回滚请求docker service rollback的核心逻辑在 rollback.go 的runRollback函数中通过apiClient.ServiceInspectWithRaw(ctx, serviceID, ...)查询目标服务的当前规格service.Spec与版本号service.Version构造types.ServiceUpdateOptions并显式设置Rollback: previous调用apiClient.ServiceUpdate(ctx, service.ID, service.Version, *spec, updateOpts)把回滚到上一个版本的指令下发给 daemon将响应中的Warnings非致命警告打印到 stderr服务 ID 打印到 stdout若指定了--detach或 daemon 的 API 版本低于 1.29则立即返回否则调用waitOnService等待服务收敛。也就是说service rollback本质上是对service update的一种语法糖封装同样走的是服务更新接口但更新指令是回滚到 previous。第二步daemon 把 Rollback 翻译成 swarmkit 指令engine 侧在 services.go 中处理ServiceUpdateOptions.Rollback字段将其映射为 swarmkit 的UpdateServiceRequest_Rollback枚举或none→UpdateServiceRequest_NONE普通更新previous→UpdateServiceRequest_PREVIOUS服务端回滚其他值 → 直接返回unrecognized rollback option错误。同时API 层对ServiceUpdateOptions.Rollback的合法取值也有明确约束见 client.go 中的注释valid values arepreviousandnone。第三步服务端依据 PreviousSpec 恢复旧配置Swarm 的 service 对象会保留一份上一次成功应用的规格即PreviousSpec。engine 在 convert/service.go 中把 grpc Service 转换回 API 类型时同时解析s.Spec当前规格与s.PreviousSpec上一个规格并填入service.PreviousSpec字段。当 daemon 收到PREVIOUS回滚指令后就会用这份PreviousSpec替换当前规格并重新调度任务。补充客户端回滚的旧路径在 CLI 的 update.go 中还保留了一条历史兼容路径当 daemon API 版本低于 1.28 时--rollback采用客户端回滚——CLI 直接读取service.PreviousSpec并把它作为新的 spec 提交若该字段为 nil则报错service does not have a previous specification to roll back to。API 版本较新时则统一走服务端回滚updateOpts.Rollback previous这样 swarmkit 会完整遵守服务的 rollback 参数并行度、间隔、失败策略等。完整实战示例副本数从 1 → 3 → 1参考文档给出了一组端到端的操作示例这里完整复现并加注说明。1. 创建一个单副本服务并发布端口$ docker service create --name my-service -p 8080:80 nginx:alpine2. 确认服务以单副本运行$ docker service ls ID NAME MODE REPLICAS IMAGE PORTS xbw728mf6q0d my-service replicated 1/1 nginx:alpine *:8080-80/tcp3. 将副本数更新为 3$ docker service update --replicas3 my-service $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS xbw728mf6q0d my-service replicated 3/3 nginx:alpine *:8080-80/tcp4. 执行回滚并确认副本数恢复为 1$ docker service rollback my-service $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS xbw728mf6q0d my-service replicated 1/1 nginx:alpine *:8080-80/tcp可以看到回滚让服务重新回到了最近一次docker service update之前的配置。需要注意回滚的目标是上一次成功应用的规格若服务从未被更新过没有PreviousSpec则回滚会因缺少历史规格而失败。该行为在 engine 的集成测试中有直接验证docker_api_swarm_service_test.go 先创建 5 个实例的服务把镜像从busybox:latest更新到busybox:test再执行service update --detach --rollback随后分批次断言任务镜像逐步回到image1最终恢复为{image1: instances}。回滚参数详解--rollback-*系列服务回滚并非一刀切的粗暴操作其节奏与容错策略由一组--rollback-*参数控制。这些参数定义在 opts.go结构体updateOptionsopts.go承载了这些值并通过rollbackConfig()opts.go组装成swarm.UpdateConfig写入服务规格的RollbackConfig字段参数说明取值范围/格式API 版本--rollback-parallelism同时回滚的最大任务数0表示全部同时回滚uint1.28--rollback-delay每个任务回滚之间的间隔ns\|us\|ms\|s\|m\|h1.28--rollback-monitor每个任务回滚后用于监控失败的时长ns\|us\|ms\|s\|m\|h1.28--rollback-failure-action回滚失败时的动作pause/continue1.28--rollback-max-failure-ratio回滚过程中可容忍的失败率float如0.51.28--rollback-order回滚顺序start-first/stop-first1.29这些参数的默认值取自 swarmkit 的defaults.Service.Rollback见 opts.go 的buildServiceDefaultFlagMapping函数。rollbackConfig()只有在上述参数任一被显式修改时才会非 nil对 job 类服务replicated-job/global-jobopts.go 会直接拒绝设置回滚配置报错update and rollback configuration is not supported for jobs。单元测试 opts_test.go 验证了这些参数的完整映射例如同时设置rollback-parallelism12、rollback-delay23s、rollback-monitor12345ns、rollback-failure-actioncontinue、rollback-max-failure-ratio0.5、rollback-orderstart-first后生成的service.RollbackConfig与期望值完全一致。使用方式一service update --rollback即时回滚除独立的docker service rollback外service update也支持--rollback标志API 1.25 起效果等价$ docker service update --rollback web需要注意CLI 会禁止--rollback与其他改动类参数混用见 update.go 中other flags may not be combined with --rollback的校验逻辑--detach、--quiet除外。使用方式二更新失败时自动回滚服务还可以被预先配置为更新失败自动回滚这样无需人工介入。在创建或更新服务时设置$ docker service update \ --update-failure-actionrollback \ --update-max-failure-ratio0.5 \ my-service其语义为当更新失败的任务占比超过--update-max-failure-ratio设定的阈值时自动触发回滚。自动回滚与手动--rollback都会遵循服务上配置的--rollback-*参数节奏。engine 侧在 convert/service.go 将UpdateFailureActionRollback与 swarmkit 的UpdateConfig_ROLLBACK互相映射确保该策略能在 swarmkit 调度器中生效。集成测试 docker_api_swarm_service_test.go 也覆盖了这一场景更新到busybox:badtag并设置--update-max-failure-ratio0.25后服务先进入UpdateStatePaused随后执行--detach --rollback恢复为全部image1任务。等待收敛与进度输出--detach/--quiet默认情况下docker service rollback会像service update一样等待服务收敛实时展示任务滚动回滚的进度。这部分由 helpers.go 的waitOnService驱动非--quiet时通过progress.ServiceProgress采集进度并通过jsonmessage.DisplayJSONMessagesToStream渲染到终端--quiet时进度输出被丢弃io.Copy(ioutil.Discard, pipeReader)只等待收敛结果--detach时立即返回进度跟踪交给后台 swarmkit 调度器完成。进度监控逻辑见 progress/progress.go它会轮询服务状态并识别UpdateStatus.State的各个阶段。这些状态常量定义于 swarm/service.go包括updating、paused、completed、rollback_started、rollback_paused、rollback_completed。当回滚暂停时CLI 会返回形如service rollback paused: message的错误并结束等待。docker service inspect也可以用来查看服务当前生效的回滚配置格式化模板见 formatter.go其中会输出RollbackConfig下的Parallelism、Delay、On failure、Monitoring Period、Max failure ratio、Rollback order等字段。错误场景与容错边界参考文档之外的错误行为在单元测试 rollback_test.go 中有清晰刻画场景行为不传参数或传多个参数报错requires exactly 1 argument服务不存在ServiceInspectWithRaw返回no such services: id服务更新请求失败原样透传底层错误回滚返回非致命警告警告写入 stderr命令仍以成功退出TestRollback中验证了两条 warning 的输出格式相关命令联动docker service rollback与下述命令共同构成 Swarm 服务的完整运维闭环对应参考文档中的 Related commands 部分service create创建服务回滚的历史基准由此而来service inspect查看当前规格、PreviousSpec与RollbackConfigservice update修改服务配置也是--rollback与自动回滚策略的入口service ls查看服务副本数与收敛状态service ps查看单个任务级别的滚动情况service rm删除服务service scale快速调整副本数service logs回滚前后排查任务日志。小结docker service rollback的实战价值在于发布即安全它把服务配置原子性地还原到上一个稳定版本并完全复用--rollback-*参数控制的滚动节奏从而在线上故障时实现快速、可控、可观测的止损。从源码视角看它复用服务更新链路通过Rollback: previous触发服务端回滚由 swarmkit 依据PreviousSpec完成调度回退从运维视角看它可以与service update的--update-failure-actionrollback搭配让集群在更新失败时自动完成自我修复。掌握这一命令及其参数细节是管理任何 Swarm 生产集群的必修课。赞分享容器运行时云原生【免费下载链接】docker-ce:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:项目地址https://gitcode.com/gh_mirrors/do/docker-ce点击查看免费下载相关推荐Docker CLI 实战使用 docker service rollback 将 Swarm 服务回滚到上一版本Docker CLI 实战使用 docker service rollback 将 Swarm 服务回滚到上一版本 导读 docker service rolCLI开发工具Docker CLI 的 docker service 命令族Swarm 服务的创建、调度、更新与回滚全指南Docker CLI 的 docker service 命令族Swarm 服务的创建、调度、更新与回滚全指南 docker service 是 DockerCLI开发工具VDO.Ninja高级功能WHIP/WHEP流媒体技术实战VDO.Ninja高级功能WHIP/WHEP流媒体技术实战 VDO.Ninja是一款强大的WebRTC工具可将远程视频源引入OBS或其他工作室软件。其中WH音视频直播即时通讯上一篇czsc 信号体系解析coo_td_V221110 TD 神奇九转信号的计数机制、参数配置与源码实现下一篇Apache Arrow Crossbow 构建状态 PR 评论模板解析crossbow-success-message 与 CommentReport 源码实现创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考