Dozzle 接入 Podman 完整指南Docker 兼容 Socket、Agent 远程监控与 Quadlet 部署实战【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 通过 Podman 提供的 Docker 兼容 socket 接口实现对 Podman 容器的实时日志查看是少数能在不改动 Podman 架构的前提下直接接入的容器日志工具。本文以仓库中的 Podman 官方指南 为主体结合internal/container/host_id.go、internal/support/cli/args.go、internal/support/cli/agent_command.go等源码实现完整覆盖 Standalone 本地监控与 Agent 多主机集中监控两种模式并深入解析 rootless 模式下内存统计缺失、健康检查失效、跨用户容器可见性三大常见坑的成因与解决方案。读完本文你将能够在 rootful / rootless / Quadletsystemd 原生容器三种环境下手动部署 Dozzle并理解其 host ID 推导与 gRPC Agent 通信的底层原理。Podman 支持概述一次对接两种模式Dozzle 本身面向 Docker API 编程Podman 通过其Docker-compatible socket 接口即podman.socket暴露的/info、容器列表等兼容端点无缝接入。由于 Podman 是 daemonless 架构无守护进程与 Docker 存在一个关键差异会影响部署内存统计memory stats在 rootless / Quadlet 部署中经常缺失根因是 cgroup 委派cgroup delegation未开启而不是 Dozzle 的问题。具体排查与修复见文末 FAQ。基于此Dozzle 官方提供两种部署模式模式适用场景部署复杂度Standalone独立模式单主机本地日志查看简单Agent代理模式多主机集中监控中等Standalone 模式下 Dozzle 直接读取本机 Podman socketAgent 模式下远程主机各自运行一个 Dozzle Agent主 Dozzle 服务器通过gRPC与各 Agent 通信详见 agent_command.go 中agent.NewServer与server.Serve(listener)的服务端实现。三种启动方式对比Podman 提供了 CLI、podman-compose、Quadlet 三种启动容器的方式Dozzle 官方对它们的支持程度并不相同选择前务必看清下表启动方式开机自启内存统计Healthcheck最佳场景CLIpodman run手动✓✓开发调试podman-compose✗✓✗测试Quadletsystemd✓✗*✓生产* 内存统计在 rootless 模式下通常不可用除非启用 cgroup v2 内存委派详见本文末尾 FAQ。其中 Healthcheck 一列的差异值得注意Quadlet 会自动为容器生成 systemd timer 来周期性执行健康检查而podman-compose不会因此后者环境下健康检查不会按计划执行需要手动触发podman healthcheck run container_id。Standalone 模式本地单主机监控Standalone 模式即直接在本机运行一个 Dozzle 容器让它读取本机的 Podman socket从而监控本机所有当前命名空间内的Podman 容器。Rootful 配置系统级 Podman如果你的 Podman 以系统级rootful方式运行socket 位于/run/podman/podman.sock# 启用并启动 Podman socket sudo systemctl enable podman.socket sudo systemctl start podman.socket # Dozzle 通过 Docker socket 路径挂载 Podman socket 并连接 podman run -v /run/podman/podman.sock:/var/run/docker.sock:ro \ -p 3000:8080 \ ghcr.io/amir20/dozzle:latestDozzle 容器内部期望在/var/run/docker.sock找到 socket因此这里把 Podman socket 以只读方式:ro映射到该路径即可。Web 界面默认暴露在宿主机的3000端口容器内 Dozzle 监听8080与 Dockerfile 中的EXPOSE 8080一致。Rootless 配置用户级 PodmanRootless Podman 将容器隔离在独立的用户命名空间user namespace中socket 位于/run/user/uid/podman/podman.sock# 启动用户级 socket随用户登录会话自动运行 systemctl --user enable podman.socket systemctl --user start podman.socket # 假设用户名为 appuserDozzle 通过其用户级 socket 连接 podman run -v /run/user/$(id -u appuser)/podman/podman.sock:/var/run/docker.sock:ro \ -p 3000:8080 \ ghcr.io/amir20/dozzle:latest重要限制绑定到某用户 rootless socket 的 Dozzle只能看到该用户的容器。其他用户的 rootless 容器位于各自独立的命名空间中不会出现在日志列表里。解决跨用户可见性问题的方案见文末 FAQ。Quadlet 部署systemd 原生容器管理推荐生产Quadlet 是 Podman 与 systemd 深度集成的产物写一个.container文件systemd 即会自动生成对应的 service 与 timer 单元来管理容器生命周期。将以下内容保存为~/.config/containers/systemd/dozzle.container[Unit] DescriptionDozzle Log Viewer Afternetwork-online.target Wantsnetwork-online.target [Container] Imageghcr.io/amir20/dozzle:latest PublishPort3000:8080 Volume/run/user/%U/podman/podman.sock:/var/run/docker.sock:ro HealthCmd/dozzle healthcheck HealthInterval5s HealthTimeout10s HealthRetries5 HealthStartPeriod15s [Service] Restarton-failure RestartSec10 [Install] WantedBydefault.target关键点说明%U是 systemd 的单元说明符展开为当前用户的 UID因此Volume会自动指向对应用户的 socket 路径HealthCmd/dozzle healthcheck调用 Dozzle 内置的健康检查子命令。从 Dockerfile 可以看到镜像入口为ENTRYPOINT [/dozzle]/dozzle healthcheck即执行该子命令健康检查参数间隔 5s、超时 10s、重试 5 次、启动宽限 15s覆盖了容器冷启动期间的探活场景。启用并启动systemctl --user daemon-reload systemctl --user enable --now dozzle.service多用户系统将同一份.container文件放入每个用户的~/.config/containers/systemd/目录并为每个用户分配不同的主机端口如PublishPort3001:8080。每个实例只能看到对应用户的 rootless 容器——这是命名空间隔离的必然结果。注意Quadlet 会为健康检查生成 systemd timerpodman-compose则不会因此podman-compose环境下健康检查不会定时执行如需验证可手动执行podman healthcheck run NAME。Agent 模式多主机集中监控当需要跨多台 Podman 主机统一查看日志时在每个远端主机上以agent 子命令运行 Dozzle主服务器通过 gRPC 聚合所有 Agent 的数据。Agent 前置条件在 Agent 主机上开放 TCP 端口7007Agent 默认监听端口见 agent_command.go 中Addr string \arg:--agent-addr,env:DOZZLE_AGENT_ADDR default::7007可用--agent-addr或DOZZLE_AGENT_ADDR 修改主服务器与 Agent 之间网络互通。启动 Dozzle Agent在远端 Podman 主机上运行# Rootful Agent podman run -d \ --name dozzle-agent \ -v /run/podman/podman.sock:/var/run/docker.sock:ro \ -p 7007:7007 \ ghcr.io/amir20/dozzle:latest agent# Rootless Agent用户为 appuser sudo -u appuser podman run -d \ --name dozzle-agent \ -v /run/user/$(id -u appuser)/podman/podman.sock:/var/run/docker.sock:ro \ -p 7007:7007 \ ghcr.io/amir20/dozzle:latest agent注意agent是追加在镜像名后的子命令。结合 args.go 可以看到agent是 Dozzle 的一个独立子命令Agent *AgentCmd \arg:subcommand:agent而非独立二进制Agent 启动后会加载内嵌 TLS 证书shared_key.pem/shared_cert.pem见 Dockerfile建立 gRPC 服务。Quadlet Agent 部署创建dozzle-agent.container文件# dozzle-agent.container [Unit] DescriptionDozzle Agent Afternetwork-online.target Wantsnetwork-online.target [Container] Imageghcr.io/amir20/dozzle:latest PublishPort7007:7007 Volume/run/user/%U/podman/podman.sock:/var/run/docker.sock:ro Execagent HealthCmd/dozzle healthcheck HealthInterval5s HealthTimeout10s HealthRetries5 HealthStartPeriod15s [Service] Restarton-failure RestartSec10 [Install] WantedBydefault.target注意Dozzle 镜像的入口是/dozzle因此 agent 子命令要写在Exec即容器要执行的命令中而不是Entrypoint里。若写成Entrypointagent会覆盖整个入口导致启动失败。启用并启动systemctl --user daemon-reload systemctl --user enable dozzle-agent.service systemctl --user start dozzle-agent.service主服务器连接远程 Agent在主服务器上配置各远端 Agent 的地址即可聚合监控。命令行方式podman run -d \ --name dozzle \ -p 3000:8080 \ ghcr.io/amir20/dozzle:latest \ --remote-agent host1.example.com:7007 \ --remote-agent host2.example.com:7007环境变量方式podman run -d \ --name dozzle \ -e DOZZLE_REMOTE_AGENThost1.example.com:7007,host2.example.com:7007 \ -p 3000:8080 \ ghcr.io/amir20/dozzle:latest从 args.go 可以看到该参数的定义为RemoteAgent []string \arg:env:DOZZLE_REMOTE_AGENT,--remote-agent,separate——separate标记说明参数支持逗号分隔列表两种写法等价解析阶段还会对每个值执行strings.TrimSpace 去除空白。Quadlet 主服务器配置# dozzle-server.container [Unit] DescriptionDozzle Server with Remote Agents Afternetwork-online.target Wantsnetwork-online.target [Container] Imageghcr.io/amir20/dozzle:latest PublishPort3000:8080 EnvironmentDOZZLE_REMOTE_AGENThost1.example.com:7007,host2.example.com:7007 HealthCmd/dozzle healthcheck HealthInterval5s HealthTimeout10s HealthRetries5 HealthStartPeriod15s [Service] Restarton-failure RestartSec10 [Install] WantedBydefault.target注意WantedBymulti-user.target仅适用于系统级system单元。对systemctl --user用户级单元必须使用default.target否则单元不会被正常启用。Agent 地址的高级格式Agent 地址并不局限于host:7007。从 agent/client_test.go 的测试用例可以确认地址支持地址|名称|分组三段式host:7007—— 仅地址host:7007|web-1—— 地址 显示名称host:7007|web-1|prod—— 地址 名称 分组段数超过三段如host:7007|web-1|prod|extra会被拒绝too many segments rejected。这让多主机场景下的界面组织更清晰Agent 在主机列表中可按组归类、按名称显示。附加配置Host IDs 与源码级解析为什么 Podman 的 Host ID 需要特殊处理本小节在原文中标注为早期版本让你创建一个文件、但从未生效的遗留澄清其背后是 Docker 与 Podman 在引擎标识上的本质差异值得从源码层面讲透Docker守护进程首次启动时把 UUID 写入/var/lib/docker/engine-id该标识长期稳定可直接用作主机身份Podman无守护进程、不跟踪任何引擎身份。其 Docker 兼容/info接口为满足字段要求在每次调用时都生成一个全新的随机 UUID。你可以用下面的命令亲眼验证——连续两次请求拿到的是两个不同的 IDcurl -s --unix-socket /run/user/$(id -u)/podman/podman.sock http://d/v1.40/info | jq .ID curl -s --unix-socket /run/user/$(id -u)/podman/podman.sock http://d/v1.40/info | jq .ID而手动创建/var/lib/docker/engine-id也毫无作用因为 Podman 根本不会读取它。Dozzle 如何推导稳定 IDDozzle 在 internal/container/host_id.go 中专门实现了针对 Podman 的身份推导逻辑。核心流程如下客户端连接后上报一个EngineIdentity包含Runtimedocker/podman/k8s、EngineID、SwarmNodeID、Hostname、StorageRoot等字段DerivedHostID.Resolve()按优先级取用Swarm 节点 ID → Podman 推导 ID → 引擎自身 ID → 回退值当Runtime podman时podmanHostID()用固定命名空间 UUIDcb6c32a9-acb9-454b-8427-014fe9bc073c对hostname \x00 storageRoot计算 SHA1uuid.NewSHA1得到一个可复现的稳定 ID。这一设计有两个关键考量源码注释中明确说明跨重启稳定Podman 每次调用返回的 EngineID 都在变若直接使用会导致主机 ID 每次重启都变化破坏所有书签 URL 与路由区分同机多用户同机两个 rootless 用户共享 hostname但存储路径必然不同如/home/alice/.local/share/containers/storage与/home/bob/...哈希结果因此不同不会互相混淆。这些行为在 host_id_test.go 中有完整测试佐证TestDerivedHostID_PodmanIsStableAcrossRestarts验证同一主机 EngineID 变化而推导 ID 不变TestDerivedHostID_SeparatesRootlessUsersOnOneMachine验证同机两用户得到不同 ID。当 ID 发生冲突时两个 Podman 主机若同时共享相同的主机名和存储路径典型场景克隆虚拟机、从未设置 hostname 的机器群会推导出相同 IDDozzle 会把其中一个当作重复主机丢弃。正常环境 hostname 各异不会触发此问题。解决办法是在其中一个主机上设置DOZZLE_HOST_ID强制指定# dozzle-agent.container [Container] EnvironmentDOZZLE_HOST_IDweb-01该值的合法字符为字母、数字、短横线、下划线和点对应 args.go 中的校验正则^[A-Za-z0-9_.-]$validHostID。违规字符如斜杠或空格会导致启动参数解析失败因为 host ID 会作为/api/hosts/{host}/...路由的路径段使用。它必须在整个集群内唯一且在主机整个生命周期内保持不变。警告如果之前按旧版本文档在 Podman 主机上创建过/var/lib/docker/engine-id现在可以安全删除——Podman 从不读取它。常见问题 FAQ1. Rootless 模式下内存统计缺失在 rootless 部署中memorycgroup 控制器默认不会委派给用户 sliceuser slice因此 Dozzle 拿不到内存统计。先检查实际委派情况cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/cgroup.controllers若输出中不包含memory则通过 drop-in 文件开启委派sudo mkdir -p /etc/systemd/system/user.service.d sudo tee /etc/systemd/system/user.service.d/delegate.conf EOF [Service] Delegatecpu cpuset io memory pids EOF sudo systemctl daemon-reload然后注销重新登录或重启让用户 slice 重新加载新的委派配置。委派范围同时放开cpu cpuset io memory pids可满足多数监控需求。2. 健康检查报告为 unhealthypodman-compose场景健康检查即使手动执行通过也被报告为 unhealthy。这是 Podman 的行为特性——没有 systemd timerQuadlet 会自动生成时健康检查不会被自动评估。手动运行一次即可# 手动触发健康检查 podman healthcheck run container_idQuadlet 场景HealthCmd接收的是普通命令行字符串不是 Docker 风格的CMD [...]JSON 数组形式应写作HealthCmd/dozzle healthcheck旧版podman-compose 1.5.0所有健康检查都经由sh执行而 Dozzle 镜像是基于scratch构建的见 Dockerfile不包含任何 shell因此健康检查必然失败。请升级到当前版本。3. 跨用户容器不可见Rootless Podman 只能访问同一用户命名空间内的容器。若以用户 A 运行 Dozzle则看不到用户 B 的 rootless 会话中的容器。解决方案让 Dozzle 与目标容器运行在同一个用户下或改用 rootful系统级模式。延伸阅读深入理解 Podman 身份推导与 Docker 的差异internal/container/host_id.go 及其测试 host_id_test.go全部命令行参数与环境变量定义含--remote-agent、--host-id、agent子命令internal/support/cli/args.goAgent 子命令的完整启动流程与 gRPC 服务建立internal/support/cli/agent_command.go健康检查子命令的双模式实现Agent 走 gRPC RPC、服务器走 HTTPinternal/support/cli/health_command.go 与 internal/web/healthcheck.goAgent 地址host:port|name|group格式的解析与校验用例internal/agent/client_test.go。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Dozzle 接入 Podman 完整指南：Docker 兼容 Socket、Agent 远程监控与 Quadlet 部署实战
Dozzle 接入 Podman 完整指南Docker 兼容 Socket、Agent 远程监控与 Quadlet 部署实战【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 通过 Podman 提供的 Docker 兼容 socket 接口实现对 Podman 容器的实时日志查看是少数能在不改动 Podman 架构的前提下直接接入的容器日志工具。本文以仓库中的 Podman 官方指南 为主体结合internal/container/host_id.go、internal/support/cli/args.go、internal/support/cli/agent_command.go等源码实现完整覆盖 Standalone 本地监控与 Agent 多主机集中监控两种模式并深入解析 rootless 模式下内存统计缺失、健康检查失效、跨用户容器可见性三大常见坑的成因与解决方案。读完本文你将能够在 rootful / rootless / Quadletsystemd 原生容器三种环境下手动部署 Dozzle并理解其 host ID 推导与 gRPC Agent 通信的底层原理。Podman 支持概述一次对接两种模式Dozzle 本身面向 Docker API 编程Podman 通过其Docker-compatible socket 接口即podman.socket暴露的/info、容器列表等兼容端点无缝接入。由于 Podman 是 daemonless 架构无守护进程与 Docker 存在一个关键差异会影响部署内存统计memory stats在 rootless / Quadlet 部署中经常缺失根因是 cgroup 委派cgroup delegation未开启而不是 Dozzle 的问题。具体排查与修复见文末 FAQ。基于此Dozzle 官方提供两种部署模式模式适用场景部署复杂度Standalone独立模式单主机本地日志查看简单Agent代理模式多主机集中监控中等Standalone 模式下 Dozzle 直接读取本机 Podman socketAgent 模式下远程主机各自运行一个 Dozzle Agent主 Dozzle 服务器通过gRPC与各 Agent 通信详见 agent_command.go 中agent.NewServer与server.Serve(listener)的服务端实现。三种启动方式对比Podman 提供了 CLI、podman-compose、Quadlet 三种启动容器的方式Dozzle 官方对它们的支持程度并不相同选择前务必看清下表启动方式开机自启内存统计Healthcheck最佳场景CLIpodman run手动✓✓开发调试podman-compose✗✓✗测试Quadletsystemd✓✗*✓生产* 内存统计在 rootless 模式下通常不可用除非启用 cgroup v2 内存委派详见本文末尾 FAQ。其中 Healthcheck 一列的差异值得注意Quadlet 会自动为容器生成 systemd timer 来周期性执行健康检查而podman-compose不会因此后者环境下健康检查不会按计划执行需要手动触发podman healthcheck run container_id。Standalone 模式本地单主机监控Standalone 模式即直接在本机运行一个 Dozzle 容器让它读取本机的 Podman socket从而监控本机所有当前命名空间内的Podman 容器。Rootful 配置系统级 Podman如果你的 Podman 以系统级rootful方式运行socket 位于/run/podman/podman.sock# 启用并启动 Podman socket sudo systemctl enable podman.socket sudo systemctl start podman.socket # Dozzle 通过 Docker socket 路径挂载 Podman socket 并连接 podman run -v /run/podman/podman.sock:/var/run/docker.sock:ro \ -p 3000:8080 \ ghcr.io/amir20/dozzle:latestDozzle 容器内部期望在/var/run/docker.sock找到 socket因此这里把 Podman socket 以只读方式:ro映射到该路径即可。Web 界面默认暴露在宿主机的3000端口容器内 Dozzle 监听8080与 Dockerfile 中的EXPOSE 8080一致。Rootless 配置用户级 PodmanRootless Podman 将容器隔离在独立的用户命名空间user namespace中socket 位于/run/user/uid/podman/podman.sock# 启动用户级 socket随用户登录会话自动运行 systemctl --user enable podman.socket systemctl --user start podman.socket # 假设用户名为 appuserDozzle 通过其用户级 socket 连接 podman run -v /run/user/$(id -u appuser)/podman/podman.sock:/var/run/docker.sock:ro \ -p 3000:8080 \ ghcr.io/amir20/dozzle:latest重要限制绑定到某用户 rootless socket 的 Dozzle只能看到该用户的容器。其他用户的 rootless 容器位于各自独立的命名空间中不会出现在日志列表里。解决跨用户可见性问题的方案见文末 FAQ。Quadlet 部署systemd 原生容器管理推荐生产Quadlet 是 Podman 与 systemd 深度集成的产物写一个.container文件systemd 即会自动生成对应的 service 与 timer 单元来管理容器生命周期。将以下内容保存为~/.config/containers/systemd/dozzle.container[Unit] DescriptionDozzle Log Viewer Afternetwork-online.target Wantsnetwork-online.target [Container] Imageghcr.io/amir20/dozzle:latest PublishPort3000:8080 Volume/run/user/%U/podman/podman.sock:/var/run/docker.sock:ro HealthCmd/dozzle healthcheck HealthInterval5s HealthTimeout10s HealthRetries5 HealthStartPeriod15s [Service] Restarton-failure RestartSec10 [Install] WantedBydefault.target关键点说明%U是 systemd 的单元说明符展开为当前用户的 UID因此Volume会自动指向对应用户的 socket 路径HealthCmd/dozzle healthcheck调用 Dozzle 内置的健康检查子命令。从 Dockerfile 可以看到镜像入口为ENTRYPOINT [/dozzle]/dozzle healthcheck即执行该子命令健康检查参数间隔 5s、超时 10s、重试 5 次、启动宽限 15s覆盖了容器冷启动期间的探活场景。启用并启动systemctl --user daemon-reload systemctl --user enable --now dozzle.service多用户系统将同一份.container文件放入每个用户的~/.config/containers/systemd/目录并为每个用户分配不同的主机端口如PublishPort3001:8080。每个实例只能看到对应用户的 rootless 容器——这是命名空间隔离的必然结果。注意Quadlet 会为健康检查生成 systemd timerpodman-compose则不会因此podman-compose环境下健康检查不会定时执行如需验证可手动执行podman healthcheck run NAME。Agent 模式多主机集中监控当需要跨多台 Podman 主机统一查看日志时在每个远端主机上以agent 子命令运行 Dozzle主服务器通过 gRPC 聚合所有 Agent 的数据。Agent 前置条件在 Agent 主机上开放 TCP 端口7007Agent 默认监听端口见 agent_command.go 中Addr string \arg:--agent-addr,env:DOZZLE_AGENT_ADDR default::7007可用--agent-addr或DOZZLE_AGENT_ADDR 修改主服务器与 Agent 之间网络互通。启动 Dozzle Agent在远端 Podman 主机上运行# Rootful Agent podman run -d \ --name dozzle-agent \ -v /run/podman/podman.sock:/var/run/docker.sock:ro \ -p 7007:7007 \ ghcr.io/amir20/dozzle:latest agent# Rootless Agent用户为 appuser sudo -u appuser podman run -d \ --name dozzle-agent \ -v /run/user/$(id -u appuser)/podman/podman.sock:/var/run/docker.sock:ro \ -p 7007:7007 \ ghcr.io/amir20/dozzle:latest agent注意agent是追加在镜像名后的子命令。结合 args.go 可以看到agent是 Dozzle 的一个独立子命令Agent *AgentCmd \arg:subcommand:agent而非独立二进制Agent 启动后会加载内嵌 TLS 证书shared_key.pem/shared_cert.pem见 Dockerfile建立 gRPC 服务。Quadlet Agent 部署创建dozzle-agent.container文件# dozzle-agent.container [Unit] DescriptionDozzle Agent Afternetwork-online.target Wantsnetwork-online.target [Container] Imageghcr.io/amir20/dozzle:latest PublishPort7007:7007 Volume/run/user/%U/podman/podman.sock:/var/run/docker.sock:ro Execagent HealthCmd/dozzle healthcheck HealthInterval5s HealthTimeout10s HealthRetries5 HealthStartPeriod15s [Service] Restarton-failure RestartSec10 [Install] WantedBydefault.target注意Dozzle 镜像的入口是/dozzle因此 agent 子命令要写在Exec即容器要执行的命令中而不是Entrypoint里。若写成Entrypointagent会覆盖整个入口导致启动失败。启用并启动systemctl --user daemon-reload systemctl --user enable dozzle-agent.service systemctl --user start dozzle-agent.service主服务器连接远程 Agent在主服务器上配置各远端 Agent 的地址即可聚合监控。命令行方式podman run -d \ --name dozzle \ -p 3000:8080 \ ghcr.io/amir20/dozzle:latest \ --remote-agent host1.example.com:7007 \ --remote-agent host2.example.com:7007环境变量方式podman run -d \ --name dozzle \ -e DOZZLE_REMOTE_AGENThost1.example.com:7007,host2.example.com:7007 \ -p 3000:8080 \ ghcr.io/amir20/dozzle:latest从 args.go 可以看到该参数的定义为RemoteAgent []string \arg:env:DOZZLE_REMOTE_AGENT,--remote-agent,separate——separate标记说明参数支持逗号分隔列表两种写法等价解析阶段还会对每个值执行strings.TrimSpace 去除空白。Quadlet 主服务器配置# dozzle-server.container [Unit] DescriptionDozzle Server with Remote Agents Afternetwork-online.target Wantsnetwork-online.target [Container] Imageghcr.io/amir20/dozzle:latest PublishPort3000:8080 EnvironmentDOZZLE_REMOTE_AGENThost1.example.com:7007,host2.example.com:7007 HealthCmd/dozzle healthcheck HealthInterval5s HealthTimeout10s HealthRetries5 HealthStartPeriod15s [Service] Restarton-failure RestartSec10 [Install] WantedBydefault.target注意WantedBymulti-user.target仅适用于系统级system单元。对systemctl --user用户级单元必须使用default.target否则单元不会被正常启用。Agent 地址的高级格式Agent 地址并不局限于host:7007。从 agent/client_test.go 的测试用例可以确认地址支持地址|名称|分组三段式host:7007—— 仅地址host:7007|web-1—— 地址 显示名称host:7007|web-1|prod—— 地址 名称 分组段数超过三段如host:7007|web-1|prod|extra会被拒绝too many segments rejected。这让多主机场景下的界面组织更清晰Agent 在主机列表中可按组归类、按名称显示。附加配置Host IDs 与源码级解析为什么 Podman 的 Host ID 需要特殊处理本小节在原文中标注为早期版本让你创建一个文件、但从未生效的遗留澄清其背后是 Docker 与 Podman 在引擎标识上的本质差异值得从源码层面讲透Docker守护进程首次启动时把 UUID 写入/var/lib/docker/engine-id该标识长期稳定可直接用作主机身份Podman无守护进程、不跟踪任何引擎身份。其 Docker 兼容/info接口为满足字段要求在每次调用时都生成一个全新的随机 UUID。你可以用下面的命令亲眼验证——连续两次请求拿到的是两个不同的 IDcurl -s --unix-socket /run/user/$(id -u)/podman/podman.sock http://d/v1.40/info | jq .ID curl -s --unix-socket /run/user/$(id -u)/podman/podman.sock http://d/v1.40/info | jq .ID而手动创建/var/lib/docker/engine-id也毫无作用因为 Podman 根本不会读取它。Dozzle 如何推导稳定 IDDozzle 在 internal/container/host_id.go 中专门实现了针对 Podman 的身份推导逻辑。核心流程如下客户端连接后上报一个EngineIdentity包含Runtimedocker/podman/k8s、EngineID、SwarmNodeID、Hostname、StorageRoot等字段DerivedHostID.Resolve()按优先级取用Swarm 节点 ID → Podman 推导 ID → 引擎自身 ID → 回退值当Runtime podman时podmanHostID()用固定命名空间 UUIDcb6c32a9-acb9-454b-8427-014fe9bc073c对hostname \x00 storageRoot计算 SHA1uuid.NewSHA1得到一个可复现的稳定 ID。这一设计有两个关键考量源码注释中明确说明跨重启稳定Podman 每次调用返回的 EngineID 都在变若直接使用会导致主机 ID 每次重启都变化破坏所有书签 URL 与路由区分同机多用户同机两个 rootless 用户共享 hostname但存储路径必然不同如/home/alice/.local/share/containers/storage与/home/bob/...哈希结果因此不同不会互相混淆。这些行为在 host_id_test.go 中有完整测试佐证TestDerivedHostID_PodmanIsStableAcrossRestarts验证同一主机 EngineID 变化而推导 ID 不变TestDerivedHostID_SeparatesRootlessUsersOnOneMachine验证同机两用户得到不同 ID。当 ID 发生冲突时两个 Podman 主机若同时共享相同的主机名和存储路径典型场景克隆虚拟机、从未设置 hostname 的机器群会推导出相同 IDDozzle 会把其中一个当作重复主机丢弃。正常环境 hostname 各异不会触发此问题。解决办法是在其中一个主机上设置DOZZLE_HOST_ID强制指定# dozzle-agent.container [Container] EnvironmentDOZZLE_HOST_IDweb-01该值的合法字符为字母、数字、短横线、下划线和点对应 args.go 中的校验正则^[A-Za-z0-9_.-]$validHostID。违规字符如斜杠或空格会导致启动参数解析失败因为 host ID 会作为/api/hosts/{host}/...路由的路径段使用。它必须在整个集群内唯一且在主机整个生命周期内保持不变。警告如果之前按旧版本文档在 Podman 主机上创建过/var/lib/docker/engine-id现在可以安全删除——Podman 从不读取它。常见问题 FAQ1. Rootless 模式下内存统计缺失在 rootless 部署中memorycgroup 控制器默认不会委派给用户 sliceuser slice因此 Dozzle 拿不到内存统计。先检查实际委派情况cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/cgroup.controllers若输出中不包含memory则通过 drop-in 文件开启委派sudo mkdir -p /etc/systemd/system/user.service.d sudo tee /etc/systemd/system/user.service.d/delegate.conf EOF [Service] Delegatecpu cpuset io memory pids EOF sudo systemctl daemon-reload然后注销重新登录或重启让用户 slice 重新加载新的委派配置。委派范围同时放开cpu cpuset io memory pids可满足多数监控需求。2. 健康检查报告为 unhealthypodman-compose场景健康检查即使手动执行通过也被报告为 unhealthy。这是 Podman 的行为特性——没有 systemd timerQuadlet 会自动生成时健康检查不会被自动评估。手动运行一次即可# 手动触发健康检查 podman healthcheck run container_idQuadlet 场景HealthCmd接收的是普通命令行字符串不是 Docker 风格的CMD [...]JSON 数组形式应写作HealthCmd/dozzle healthcheck旧版podman-compose 1.5.0所有健康检查都经由sh执行而 Dozzle 镜像是基于scratch构建的见 Dockerfile不包含任何 shell因此健康检查必然失败。请升级到当前版本。3. 跨用户容器不可见Rootless Podman 只能访问同一用户命名空间内的容器。若以用户 A 运行 Dozzle则看不到用户 B 的 rootless 会话中的容器。解决方案让 Dozzle 与目标容器运行在同一个用户下或改用 rootful系统级模式。延伸阅读深入理解 Podman 身份推导与 Docker 的差异internal/container/host_id.go 及其测试 host_id_test.go全部命令行参数与环境变量定义含--remote-agent、--host-id、agent子命令internal/support/cli/args.goAgent 子命令的完整启动流程与 gRPC 服务建立internal/support/cli/agent_command.go健康检查子命令的双模式实现Agent 走 gRPC RPC、服务器走 HTTPinternal/support/cli/health_command.go 与 internal/web/healthcheck.goAgent 地址host:port|name|group格式的解析与校验用例internal/agent/client_test.go。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
