Dozzle 容器名称自定义dev.dozzle.name 标签、Coolify 集成与名称解析优先级【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 默认直接从 Docker 获取容器名称用于界面展示但当你无法或不想修改容器本身的名称时可以通过dev.dozzle.name标签为容器指定一个自定义显示名称如果你使用 Coolify 部署平台Dozzle 还会自动识别coolify.serviceName与coolify.projectName作为备用值实现零额外配置的即插即用。本文以 docs/zh/guide/container-names.md 为骨架结合 internal/docker/client.go、internal/docker/client_test.go、internal/container/container_store.go 等源码讲解标签配置方法、完整的名称解析优先级以及这些标签在 Swarm、Docker rename 场景下如何保持生效读完后你可以在自己的 Dozzle 部署中精准控制每一个容器的显示名与分组。默认行为名称来自 Docker 本身默认情况下Dozzle 直接从 Docker 获取容器名称这通常已经够用因为你可以通过两种原生途径自定义名称使用docker run的--name参数显式指定在 Docker Compose 服务的container_name字段中指定。从源码看internal/docker/client.go 中newContainer的名称解析路径为先检查dev.dozzle.name标签再检查 Coolify 名称最后才回退到c.Names[0]Docker 名称并去掉前导/当名称完全缺失时兜底为no name。也就是说默认名称是名称解析链中的最后一级回退值。自定义名称添加dev.dozzle.name标签如果无法修改容器名称本身可以给容器添加dev.dozzle.name标签来覆盖它。下面是 Docker Compose 与 Docker CLI 两种方式的示例docker run --label dev.dozzle.namehello hello-worldservices: dozzle: image: hello-world labels: - dev.dozzle.namehello标签值会直接作为该容器在 Dozzle 界面中的显示名称适用于容器列表、侧边栏、日志页标题栏等所有展示名称的位置。类似的标签体系还包含dev.dozzle.group自定义分组、dev.dozzle.url显示链接、dev.dozzle.icon指定应用图标整套dev.dozzle.*标签的用法汇总可参考 CLAUDE.md 中的说明。实战案例sidecar 日志容器的命名一个常见的实战场景是使用 sidecar 容器跟踪宿主机上的日志文件详见 docs/zh/guide/log-files-on-disk.mdsidecar 的名字与文件内容没有关系但通过dev.dozzle.name可以给它一个可读的名称docker run -d \ --name system-log \ --label dev.dozzle.namesystem-log \ --network none \ --restart unless-stopped \ --log-opt max-size10m --log-opt max-file3 \ -v /var/log:/logs:ro \ alpine tail -n 1000 -F /logs/system.logservices: system-log: container_name: system-log image: alpine volumes: - /var/log:/logs:ro command: - tail - -n - 1000 - -F - /logs/system.log labels: dev.dozzle.name: system-log logging: options: max-size: 10m max-file: 3 network_mode: none restart: unless-stopped标签解析的源码实现名称优先级链在 Dozzle 后端容器名称是在构造container.Container对象时解析的。以 internal/docker/client.go 中newContainer处理docker ps列表场景为例name : no name if c.Labels[dev.dozzle.name] ! { name c.Labels[dev.dozzle.name] } else if n : coolifyName(c.Labels); n ! { name n } else if len(c.Names) 0 { name strings.TrimPrefix(c.Names[0], /) }对应的newContainerFromJSON处理docker inspect场景见 internal/docker/client.go采用完全相同的优先级逻辑只是数据来源不同c.Config.Labels与c.Name。由此可以得到完整的名称解析优先级dev.dozzle.name标签——最高优先级coolify.serviceName标签经coolifyName处理可能附加 PR 前缀——备用值Docker 原生名称--name/container_name——最终回退全部缺失时显示no name。这一优先级被单元测试Test_newContainer_labelPriority与Test_newContainerFromJSON_labelPriority完整覆盖见 internal/docker/client_test.go 与 internal/docker/client_test.go测试用例验证了 dozzle labels take prioritydozzle 标签优先于 coolify 标签、coolify labels as fallbackcoolify 标签作为回退、docker name as final fallbackDocker 名称为最后回退等全部场景。分组Group的解析同样参与优先级名称之外分组也遵循一套平行的优先级dev.dozzle.group优先其次coolify.projectName否则为空。前端模型 assets/models/Container.ts 的namespacegetter 展示了另一条分组推断链从高到低dev.dozzle.group → coolify.projectName → com.docker.stack.namespace → com.docker.compose.project也就是说dev.dozzle.name与dev.dozzle.group是一对配套标签前者解决叫什么后者解决归到哪一组自定义分组的完整配置方法见 docs/zh/guide/container-groups.md。Coolify 集成零配置识别部署平台标签如果你使用 Coolify 部署应用Dozzle 会自动识别 Coolify 的标签作为备用值无需任何额外配置coolify.serviceName→ 未设置dev.dozzle.name时用作容器名称coolify.projectName→ 未设置dev.dozzle.group时用于分组。这意味着一个由 Coolify 管理的容器只要其自带coolify.serviceName标签在 Dozzle 界面中就会直接显示 Coolify 的服务名而不是一串随机的容器哈希名。PR 预览部署的智能命名Coolify 的 PR preview 部署场景比较特殊同一个应用及其所有 PR 预览共享相同的coolify.serviceName如果不加区分所有预览在 Dozzle 中会难以辨认。为此 internal/docker/client.go 中的coolifyName函数在检测到coolify.pullRequestId且不为0时会自动附加 PR 编号func coolifyName(labels map[string]string) string { name : labels[coolify.serviceName] if name { return } if pr : labels[coolify.pullRequestId]; pr ! pr ! 0 { return PR pr · name } return name }例如coolify.serviceNamecoolify-name且coolify.pullRequestId1241的容器最终显示名为PR 1241 · coolify-name而pullRequestId0表示正式部署而非预览名称不加前缀。这一行为同样有测试用例覆盖见 internal/docker/client_test.go 中的 coolify preview includes PR id 与 coolify pullRequestId 0 is not a preview。深层机制自定义名称在运行时如何保持生效标签不只是构造阶段生效一次Dozzle 在容器生命周期事件中也特意维护了自定义名称的稳定性。Docker rename 事件保留标签派生的名称当容器被docker rename时Dozzle 会收到rename事件。在 internal/container/container_store.go 中可以看到如果容器带有dev.dozzle.name或coolify.serviceName标签Dozzle 会忽略这次 renameignoring rename: container has a custom name label因为显示名来自标签而非 Docker 名称只有当名称真正来自 Docker 时rename 才会同步更新界面中的名称。从源码结构看这样设计是为了让标签派生的自定义名在任何运行时操作下都保持稳定。Swarm 模式服务标签回读在 Docker Swarm 中deploy.labels写在服务上而不是任务容器上。若不做处理写在服务标签里的dev.dozzle.name会被静默忽略。为此 internal/docker/service_labels.go 实现了mergeServiceLabels通过com.docker.swarm.service.id关联服务把服务标签合并回每个任务容器并重新按同一优先级执行名称与分组的派生容器自身标签优先于服务标签。这就是 docs/zh/guide/container-links.md 所描述的行为——dev.dozzle.name、dev.dozzle.group、dev.dozzle.icon、dev.dozzle.url都可以写在deploy.labels中生效。需要留意的是列出服务是仅限 Swarm 管理节点的 API调度到工作节点的 agent 容器只能看到自身标签看不到服务标签。K8s 等其他运行时的表现上述dev.dozzle.name/coolify.serviceName的解析逻辑位于 Docker 适配层internal/docker标签解析的前提是 Docker 容器体系。对于 K8s、Podman 等运行时Dozzle 使用各自的适配器如internal/k8s标签体系的表现以对应运行时文档为准本文的配置示例适用于 Docker 与 Docker Swarm 场景。配置速查与小结目的标签优先级说明自定义显示名称dev.dozzle.name最高优先级覆盖 Coolify 名与 Docker 名自定义分组dev.dozzle.group最高优先级覆盖 Coolify 项目名Coolify 名称回退coolify.serviceName无dev.dozzle.name时生效PR 预览自动加前缀Coolify 分组回退coolify.projectName无dev.dozzle.group时生效Docker 名称--name/container_name名称解析的最终回退值配置dev.dozzle.name标签后无需重启 Dozzle容器下一次刷新即会使用新名称该标签在 Docker、Swarm经deploy.labels回读场景下均保持生效并由单元测试持续验证。如果需要进一步了解配套能力可继续阅读 docs/zh/guide/container-groups.md自定义分组与 docs/zh/guide/container-links.mddev.dozzle.url链接标签获取完整实践指引。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考