Dozzle 容器分组机制默认分组、Swarm 服务分组与 dev.dozzle.group 自定义标签【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 会自动按 Stack 名称或 Swarm 服务名把容器归组你也可以通过dev.dozzle.group标签创建自己的分组。本文以 Dozzle 官方文档的容器分组为主题完整覆盖默认分组规则与自定义标签用法并结合仓库源码深入讲解分组标签的解析优先级、Swarm 服务级标签合并机制以及分组日志流的 API 实现链路。一、分组的基本原理Dozzle 的分组逻辑核心就是一条容器上的 label 决定了它属于哪个分组。官方文档 docs/guide/container-groups.md 给出的规则有两条默认分组在主机host模式下容器默认按其 stack 名称分组如果容器带有com.docker.swarm.service.name标签Dozzle 会自动进入Swarm 模式把所有服务名相同的容器合并到同一组自定义分组给容器打上dev.dozzle.group组名标签所有同组名的容器会在界面中合并显示。例如组名为myapp时所有带dev.dozzle.groupmyapp标签的容器会被归到一组。从源码结构看分组结果最终体现在 internal/container/types.go 中Container结构体的Group字段上——这是后端与前端共享的契约也是后面所有分组行为列表归组、分组日志流、分组页面的数据源头。二、默认分组Stack、Compose 与 Swarm 三种场景2.1 主机模式按 stack / compose 项目名分组在普通 Docker 主机模式下分组依据来自两个由 Docker 自动写入的标签com.docker.stack.namespacedocker stack deploy部署时写入和com.docker.compose.projectdocker compose up时写入。这一机制在 docs/guide/swarm-mode.md 中也有明确说明com.docker.stack.namespaceandcom.docker.compose.projectlabels are used for grouping containers. For services, Dozzle uses the service name as the group name which iscom.docker.swarm.service.name.前端模型 assets/models/Container.ts 中的namespace计算属性完整呈现了这条标签读取链含自定义分组在内的完整回退顺序get namespace() { return ( this.labels[dev.dozzle.group] || this.labels[coolify.projectName] || this.labels[com.docker.stack.namespace] || this.labels[com.docker.compose.project] ); }即dev.dozzle.group优先其后依次回退到coolify.projectName、com.docker.stack.namespace、com.docker.compose.project。测试用例 assets/models/Container.spec.ts 用一组断言锁定了这个回退顺序falls back through coolify, stack, then compose。2.2 Swarm 模式按服务名合并当容器带有com.docker.swarm.service.name标签时意味着它由某个 Swarm service 调度。此时 Dozzle 将该标签的值作为分组名把同一 service 的所有 task 容器合并展示——这正是文档中所说的自动启用 Swarm 模式。前端 assets/stores/swarm.ts 通过遍历容器标签中的com.docker.swarm.service.name来构建服务列表而分组日志流的订阅则直接按标签过滤见第四节useServiceStream。三、自定义分组dev.dozzle.group 标签3.1 用法示例给容器添加dev.dozzle.group标签即可创建自定义分组标签值就是组名。以下示例来自官方文档可直接复制使用。使用 Docker CLIdocker run --label dev.dozzle.groupmyapp hello-world使用 Docker Composedocker-compose.ymlservices: dozzle: image: hello-world labels: - dev.dozzle.groupmyapp打上该标签后所有dev.dozzle.groupmyapp的容器会在 Dozzle 界面中合并为一个分组入口点击后即可查看整组的聚合日志。3.2 后端如何解析分组标签后端在把 Docker API 返回的原始容器数据转换为Container对象时解析分组逻辑位于 internal/docker/client.gogroup : if c.Labels[dev.dozzle.group] ! { group c.Labels[dev.dozzle.group] } else if c.Labels[coolify.projectName] ! { group c.Labels[coolify.projectName] }两个关键事实优先级dev.dozzle.group优先于coolify.projectName后者是对 Coolify 平台的适配作为无 dozzle 标签时的兜底两条构建路径共用同一套规则newContainer来自 list summaryinternal/docker/client.go#L610-L654与newContainerFromJSON来自 inspectinternal/docker/client.go#L666-L671都执行相同的dev.dozzle.group→coolify.projectName回退逻辑保证增量推送与完整检查两条数据路径的分组结果一致。这一优先级由单元测试 internal/docker/client_test.go 中的Test_newContainer_labelPriority明确锁定其中dozzle labels take priority用例验证了当dev.dozzle.group与coolify.projectName同时存在时取 dozzle 标签的值docker name as final fallback用例则验证了无任何分组标签时Group为空字符串容器不入组。3.3 命名与分组标签的配套dev.dozzle.group常与同族标签dev.dozzle.name自定义显示名配合使用两者在同一优先级体系中并列处理dev.dozzle.name→coolify.serviceName→ 容器名。相关标签的完整说明可参考 docs/guide/container-names.md 与 docs/guide/container-links.md。四、Swarm 下的进阶服务级 deploy.labels 的合并这是文档未展开、但实际使用中非常关键的细节。Swarm 会把 compose 文件中deploy.labels写下的标签打在service上而不是打在 task 容器上——直接 inspect 容器根本看不到这些标签。Dozzle 的解决方案在 internal/docker/service_labels.goserviceLabelCache以30 秒 TTLserviceLabelTTL缓存一次ServiceList调用结果把每个容器一次 API 调用摊薄为每次刷新一次缓存刷新失败时会保留旧值避免瞬时错误导致标签在界面上消失mergeServiceLabels通过com.docker.swarm.service.id标签把 service 标签合并到其 task 容器上容器自身的标签更具体、永远优先maps.Copy(merged, serviceLabels)先铺底maps.Copy(merged, c.Labels)再覆盖合并后重新推导Name与Groupinternal/docker/service_labels.go#L97-L108沿用与newContainer相同的优先级dev.dozzle.group优先于coolify.projectName该合并仅在 manager 节点Swarm.ControlAvailable为真执行worker 节点上的 agent 会跳过其容器仅保留自身标签。由此得到一个实用结论在 Swarm 环境下dev.dozzle.group既可以写在docker service create --label上也可以写在 compose 的deploy.labels中后者由 service 继承合并而来。这一点由 internal/docker/service_labels_test.go 中Test_mergeServiceLabels_redoes_name_and_group用例验证service 上带dev.dozzle.groupcloud时task 容器的Group会被重算为cloud。五、分组日志流的 API 链路分组不只是列表上的视觉归组更重要的是整组日志合并查看。其实现链路贯穿前后端路由层分组日志流端点注册在 internal/web/routes.go——r.Get(/groups/{group}/logs/stream, h.streamGroupedLogs)前端订阅assets/composable/logs/eventStreams.ts 中useGroupedStream通过EventSource连接/api/groups/{group}/logs/stream服务端将组内所有容器的日志按时间交错排序后以 SSE 推给浏览器同类端点stack 分组走标签过滤/api/labels/com.docker.stack.namespace:{name}/logs/streamuseStackStreamSwarm 服务走/api/labels/com.docker.swarm.service.name:{name}/logs/streamuseServiceStream多容器任意合并走/api/hosts/{host}/logs/mergedStream/{ids}useMergedStream——四种入口最终复用同一套带搜索过滤、级别过滤、断线重连的useLogStream底座页面入口分组详情页为 assets/pages/group/[name].vue路由形如/group/{组名}与dev.dozzle.group的标签值直接对应。六、适用前提与小结分组标签对 Docker、Swarm 与 Kubernetes 场景通用其中 Swarm 场景依赖 service 标签合并worker 节点上的远程 agent 容器只有自身标签可参与分组dev.dozzle.group的优先级高于coolify.projectName且都高于com.docker.stack.namespace/com.docker.compose.project的自动回退该回退链定义在前端 assets/models/Container.ts一个容器只能归属一个分组Group为单值字符串需要更细的合并视图时可用多容器 merged stream 或按标签过滤。小结Dozzle 的分组体系 自动标签stack/compose/swarm service 自定义dev.dozzle.group标签。给容器打一个标签就能完成归组而分组的解析优先级、Swarm service 标签的 30 秒缓存合并、以及/api/groups/{group}/logs/stream日志流端点共同构成了这一机制从容器标签到合并日志界面的完整实现链路。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Dozzle 容器分组机制：默认分组、Swarm 服务分组与 dev.dozzle.group 自定义标签
Dozzle 容器分组机制默认分组、Swarm 服务分组与 dev.dozzle.group 自定义标签【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 会自动按 Stack 名称或 Swarm 服务名把容器归组你也可以通过dev.dozzle.group标签创建自己的分组。本文以 Dozzle 官方文档的容器分组为主题完整覆盖默认分组规则与自定义标签用法并结合仓库源码深入讲解分组标签的解析优先级、Swarm 服务级标签合并机制以及分组日志流的 API 实现链路。一、分组的基本原理Dozzle 的分组逻辑核心就是一条容器上的 label 决定了它属于哪个分组。官方文档 docs/guide/container-groups.md 给出的规则有两条默认分组在主机host模式下容器默认按其 stack 名称分组如果容器带有com.docker.swarm.service.name标签Dozzle 会自动进入Swarm 模式把所有服务名相同的容器合并到同一组自定义分组给容器打上dev.dozzle.group组名标签所有同组名的容器会在界面中合并显示。例如组名为myapp时所有带dev.dozzle.groupmyapp标签的容器会被归到一组。从源码结构看分组结果最终体现在 internal/container/types.go 中Container结构体的Group字段上——这是后端与前端共享的契约也是后面所有分组行为列表归组、分组日志流、分组页面的数据源头。二、默认分组Stack、Compose 与 Swarm 三种场景2.1 主机模式按 stack / compose 项目名分组在普通 Docker 主机模式下分组依据来自两个由 Docker 自动写入的标签com.docker.stack.namespacedocker stack deploy部署时写入和com.docker.compose.projectdocker compose up时写入。这一机制在 docs/guide/swarm-mode.md 中也有明确说明com.docker.stack.namespaceandcom.docker.compose.projectlabels are used for grouping containers. For services, Dozzle uses the service name as the group name which iscom.docker.swarm.service.name.前端模型 assets/models/Container.ts 中的namespace计算属性完整呈现了这条标签读取链含自定义分组在内的完整回退顺序get namespace() { return ( this.labels[dev.dozzle.group] || this.labels[coolify.projectName] || this.labels[com.docker.stack.namespace] || this.labels[com.docker.compose.project] ); }即dev.dozzle.group优先其后依次回退到coolify.projectName、com.docker.stack.namespace、com.docker.compose.project。测试用例 assets/models/Container.spec.ts 用一组断言锁定了这个回退顺序falls back through coolify, stack, then compose。2.2 Swarm 模式按服务名合并当容器带有com.docker.swarm.service.name标签时意味着它由某个 Swarm service 调度。此时 Dozzle 将该标签的值作为分组名把同一 service 的所有 task 容器合并展示——这正是文档中所说的自动启用 Swarm 模式。前端 assets/stores/swarm.ts 通过遍历容器标签中的com.docker.swarm.service.name来构建服务列表而分组日志流的订阅则直接按标签过滤见第四节useServiceStream。三、自定义分组dev.dozzle.group 标签3.1 用法示例给容器添加dev.dozzle.group标签即可创建自定义分组标签值就是组名。以下示例来自官方文档可直接复制使用。使用 Docker CLIdocker run --label dev.dozzle.groupmyapp hello-world使用 Docker Composedocker-compose.ymlservices: dozzle: image: hello-world labels: - dev.dozzle.groupmyapp打上该标签后所有dev.dozzle.groupmyapp的容器会在 Dozzle 界面中合并为一个分组入口点击后即可查看整组的聚合日志。3.2 后端如何解析分组标签后端在把 Docker API 返回的原始容器数据转换为Container对象时解析分组逻辑位于 internal/docker/client.gogroup : if c.Labels[dev.dozzle.group] ! { group c.Labels[dev.dozzle.group] } else if c.Labels[coolify.projectName] ! { group c.Labels[coolify.projectName] }两个关键事实优先级dev.dozzle.group优先于coolify.projectName后者是对 Coolify 平台的适配作为无 dozzle 标签时的兜底两条构建路径共用同一套规则newContainer来自 list summaryinternal/docker/client.go#L610-L654与newContainerFromJSON来自 inspectinternal/docker/client.go#L666-L671都执行相同的dev.dozzle.group→coolify.projectName回退逻辑保证增量推送与完整检查两条数据路径的分组结果一致。这一优先级由单元测试 internal/docker/client_test.go 中的Test_newContainer_labelPriority明确锁定其中dozzle labels take priority用例验证了当dev.dozzle.group与coolify.projectName同时存在时取 dozzle 标签的值docker name as final fallback用例则验证了无任何分组标签时Group为空字符串容器不入组。3.3 命名与分组标签的配套dev.dozzle.group常与同族标签dev.dozzle.name自定义显示名配合使用两者在同一优先级体系中并列处理dev.dozzle.name→coolify.serviceName→ 容器名。相关标签的完整说明可参考 docs/guide/container-names.md 与 docs/guide/container-links.md。四、Swarm 下的进阶服务级 deploy.labels 的合并这是文档未展开、但实际使用中非常关键的细节。Swarm 会把 compose 文件中deploy.labels写下的标签打在service上而不是打在 task 容器上——直接 inspect 容器根本看不到这些标签。Dozzle 的解决方案在 internal/docker/service_labels.goserviceLabelCache以30 秒 TTLserviceLabelTTL缓存一次ServiceList调用结果把每个容器一次 API 调用摊薄为每次刷新一次缓存刷新失败时会保留旧值避免瞬时错误导致标签在界面上消失mergeServiceLabels通过com.docker.swarm.service.id标签把 service 标签合并到其 task 容器上容器自身的标签更具体、永远优先maps.Copy(merged, serviceLabels)先铺底maps.Copy(merged, c.Labels)再覆盖合并后重新推导Name与Groupinternal/docker/service_labels.go#L97-L108沿用与newContainer相同的优先级dev.dozzle.group优先于coolify.projectName该合并仅在 manager 节点Swarm.ControlAvailable为真执行worker 节点上的 agent 会跳过其容器仅保留自身标签。由此得到一个实用结论在 Swarm 环境下dev.dozzle.group既可以写在docker service create --label上也可以写在 compose 的deploy.labels中后者由 service 继承合并而来。这一点由 internal/docker/service_labels_test.go 中Test_mergeServiceLabels_redoes_name_and_group用例验证service 上带dev.dozzle.groupcloud时task 容器的Group会被重算为cloud。五、分组日志流的 API 链路分组不只是列表上的视觉归组更重要的是整组日志合并查看。其实现链路贯穿前后端路由层分组日志流端点注册在 internal/web/routes.go——r.Get(/groups/{group}/logs/stream, h.streamGroupedLogs)前端订阅assets/composable/logs/eventStreams.ts 中useGroupedStream通过EventSource连接/api/groups/{group}/logs/stream服务端将组内所有容器的日志按时间交错排序后以 SSE 推给浏览器同类端点stack 分组走标签过滤/api/labels/com.docker.stack.namespace:{name}/logs/streamuseStackStreamSwarm 服务走/api/labels/com.docker.swarm.service.name:{name}/logs/streamuseServiceStream多容器任意合并走/api/hosts/{host}/logs/mergedStream/{ids}useMergedStream——四种入口最终复用同一套带搜索过滤、级别过滤、断线重连的useLogStream底座页面入口分组详情页为 assets/pages/group/[name].vue路由形如/group/{组名}与dev.dozzle.group的标签值直接对应。六、适用前提与小结分组标签对 Docker、Swarm 与 Kubernetes 场景通用其中 Swarm 场景依赖 service 标签合并worker 节点上的远程 agent 容器只有自身标签可参与分组dev.dozzle.group的优先级高于coolify.projectName且都高于com.docker.stack.namespace/com.docker.compose.project的自动回退该回退链定义在前端 assets/models/Container.ts一个容器只能归属一个分组Group为单值字符串需要更细的合并视图时可用多容器 merged stream 或按标签过滤。小结Dozzle 的分组体系 自动标签stack/compose/swarm service 自定义dev.dozzle.group标签。给容器打一个标签就能完成归组而分组的解析优先级、Swarm service 标签的 30 秒缓存合并、以及/api/groups/{group}/logs/stream日志流端点共同构成了这一机制从容器标签到合并日志界面的完整实现链路。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考