ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Dozzle Swarm 模式:在 Docker Swarm 集群中聚合多节点容器日志与统计

Dozzle Swarm 模式:在 Docker Swarm 集群中聚合多节点容器日志与统计 Dozzle Swarm 模式在 Docker Swarm 集群中聚合多节点容器日志与统计【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 是一款专注于容器日志实时查看的开源工具支持 Docker、Docker Swarm 与 Kubernetes。本文围绕官方文档 Swarm 模式指南英文原版见 docs/guide/swarm-mode.md展开讲解如何在 Docker Swarm 集群中启用 Dozzle 的swarm模式实现跨节点自动发现、容器分组与统计合并并涵盖简单认证、独立 Agent 接入等实战配置。读完本文你将掌握 Dozzle 在 Swarm 环境下的部署原理、Stack 编排文件写法以及从源码层面理解其节点发现与标签分组机制。Swarm 模式的核心能力与适用边界在默认的server模式下Dozzzle 只连接本机的 Docker 守护进程而启用DOZZLE_MODEswarm后Dozzzle 会自动发现 Swarm 集群中的服务与自定义分组并将同一分组内所有容器的日志与统计信息合并到单一视图中展示。官方文档明确标注了该功能的适用范围为Solo Docker仅 Docker不支持 Kubernetes。同时需要特别留意由于每个节点都需要访问本机容器运行时集群中的每个节点都必须部署一份 Dozzle 实例这正是官方示例中使用deploy.mode: global的根本原因。一个值得注意的设计决策是Dozzzle并未使用 Swarm 自身的 API 进行分组原因是官方认为其能力存在限制。取而代之的是Dozzzle 直接读取容器上的 Swarm 标签自行实现分组逻辑这一设计在源码 internal/docker/service_labels.go 的注释中也有印证。工作原理安全网状网络与标签分组mTLS 加密的节点间通信当 Dozzle 以 Swarm 模式部署时它会在集群所有节点之间建立一张安全网状网络mesh network。该网络用于各 Dozzle 实例之间的相互通信并通过mTLS双向 TLS 私有 TLS 证书加密因此所有实例间通信都是加密的可以安全地部署在任何环境。从源码 internal/support/docker/swarm_client_manager.go 可以看到其实现细节启动时读取HOSTNAME环境变量通过本地 Docker 客户端找到自身容器再读取com.docker.swarm.service.name标签获得当前服务名在 RetryAndList 中通过 DNS 查询tasks.服务名解析出集群中该服务的所有副本 IP逐一跳过本地 IP 与已连接端点后用 TLS 证书在7007 端口创建 Agent 客户端完成节点互联。基于标签的分组规则Dozzzle 通过以下三类标签将容器聚合为日志组分组来源使用的标签组名取值Docker Stackcom.docker.stack.namespaceStack 命名空间Compose 项目com.docker.compose.project项目名Swarm 服务com.docker.swarm.service.name服务名前端侧的分组逻辑同样依赖这些标签例如 assets/stores/swarm.ts 中通过container.labels[com.docker.swarm.service.name]按服务组织容器视图。另一个容易踩坑的细节在 internal/docker/service_labels.go 中有所说明Compose 文件中的deploy.labels会被 Docker 写到service 而非 task 容器上因此直接 inspect 任务容器永远看不到这些标签。为此 Dozzle 实现了mergeServiceLabels按com.docker.swarm.service.id将服务标签合并回任务容器容器自身标签优先。这也意味着像 Traefik 生态常用的dev.dozzle.group、dev.dozzle.name等标签在 Swarm 模式下不会被静默忽略。启用 Swarm 模式Docker Stack 部署示例要启用 Swarm 模式核心是设置环境变量DOZZLE_MODEswarm。官方文档给出的完整 Stack 编排文件如下services: dozzle: image: amir20/dozzle:latest environment: - DOZZLE_MODEswarm volumes: - /var/run/docker.sock:/var/run/docker.sock - /opt/dozzle/data:/data ports: - 8080:8080 networks: - dozzle deploy: mode: global networks: dozzle: driver: overlay逐项解读这份编排DOZZLE_MODEswarm告诉 Dozzle 自动发现 Swarm 中其他 Dozzle 实例。该参数在 internal/support/cli/args.go 中定义默认值为server可选值为server与swarm。/var/run/docker.sock挂载Dozzle 需要与本地 Docker 守护进程通信以读取容器、日志与统计信息。/opt/dozzle/data:/data数据卷持久化 Dozzle 的本地配置通知规则、Cloud 设置、自定义 Stack 等。由于 Dozzle 以global模式部署在每个节点上每个节点挂载各自的主机路径从而保证每个实例重启后本地状态不丢失。deploy.mode: global让 Dozzle 以副本方式在 Swarm 的每个节点上各运行一个实例这是节点间发现与网状网络形成的前提。overlay网络用于在各 Dozzle 实例之间建立网状网络。tasks.服务名的 DNS 解析正是基于 overlay 网络的 swarm 服务发现机制实现的。Swarm 模式下的已知限制不支持 socket-proxy[!WARNING]socket-proxy 无法在 Docker Swarm 模式下使用。这一限制源于 Docker 自身而非 DozzleSwarm 模式下服务只能与其他服务通信而 Dozzle 需要直接连接到每个代理实例这一需求 Docker 并不支持。官方文档表示如果你有在 Swarm 模式使用 socket-proxy 的解决方案欢迎反馈。在 Swarm 模式配置简单认证当集群中部署多节点 Dozzle 后通常需要开启认证。官方推荐的方案是将users.yml存入Docker Secret避免敏感信息直接写入编排文件services: dozzle: image: amir20/dozzle:latest environment: - DOZZLE_LEVELdebug - DOZZLE_MODEswarm - DOZZLE_AUTH_PROVIDERsimple volumes: - /var/run/docker.sock:/var/run/docker.sock - /opt/dozzle/data:/data secrets: - source: users target: /data/users.yml ports: - 8080:8080 networks: - dozzle deploy: mode: global networks: dozzle: driver: overlay secrets: users: file: users.yml关键点DOZZLE_AUTH_PROVIDERsimple启用简单认证。该参数同样定义于 internal/support/cli/args.go支持none、simple、oidc、forward-proxy等取值其中github与google是simple的别名。DOZZLE_LEVELdebug将日志级别调整为debug便于排查集群部署问题默认级别为info。Secret 挂载通过target: /data/users.yml将名为users的 Secret 映射为/data/users.yml正好落在/data持久化卷中。users.yml的生成方式与简单认证文档中介绍的dozzle generate命令一致——该命令会为后续写入users.yml的每行输出 bcrypt 哈希格式为username:hash。[!TIP] 在 Swarm 的 global 模式下同一份 Secret 会自动分发到所有节点并挂载到每个 Dozzle 副本因此无需在每个节点手工放置users.yml。为 Swarm 模式添加独立 AgentDozzzle 支持在 Swarm 模式下额外添加独立 Agent例如托管非 Swarm 节点或远程主机的日志。在 Swarm 的 Compose 编排中加入DOZZLE_REMOTE_AGENT即可配置方式与常规 Agent 接入完全一致services: dozzle: image: amir20/dozzle:latest environment: - DOZZLE_MODEswarm - DOZZLE_REMOTE_AGENTagent:7007 volumes: - /var/run/docker.sock:/var/run/docker.sock - /opt/dozzle/data:/data ports: - 8080:8080 networks: - dozzle deploy: mode: global networks: dozzle: driver: overlay配置完成后远程 Agent 会与其他 Swarm 节点一同显示在 Dozzle 的主机列表中。需要区分两类远程连接远程 Agent支持通过DOZZLE_REMOTE_AGENT或 CLI 参数--remote-agent见 internal/support/cli/args.go接入的独立 Agent 在 Swarm 模式下完全受支持多个 Agent 可用逗号分隔列出远程主机/socket-proxy不支持远程 socket 代理连接在 Swarm 模式下不可用即上一节提到的 Docker 自身限制。从源码结构看SwarmClientManager在内部组合了一个RetriableClientManagerinternal/support/docker/swarm_client_manager.go专门管理这些远程 Agent在 List 与 Hosts 等方法中都会把 Agent 列表与 Swarm 节点列表合并后统一返回给上层。Swarm 模式下的统计与配置同步机制除了日志聚合Swarm 模式还带来两项值得了解的实现细节统计合并同一分组内所有容器的统计信息CPU、内存等会被合并展示使运维人员可以在单一视图中观察整个服务或 Stack 的资源消耗而无须逐个容器切换。全局配置广播由于 Swarm 模式下每个节点各自运行 Dozzle 副本通知规则、Cloud 配置等必须保持一致。internal/support/docker/multi_host_service.go 中的SwarmNotificationHandler实现了副本间的配置同步任一副本收到其他副本广播的通知配置或 Cloud 配置后都会落盘到本地的/data卷并刷新本机通知管理器与 Cloud 客户端同时通过broadcastNotificationConfig/broadcastCloudConfiginternal/support/docker/multi_host_service.go在 Agent 重新连接时推送最新配置。这也解释了为何/data卷的持久化在 Swarm 部署中如此关键。常见问题与排错指引现象排查方向日志中提示error looking up swarm service tasks确认服务已加入 overlay 网络、DNS 解析tasks.服务名可用且deploy.mode: global已生效节点间无法互联检查 7007 端口连通性确认 mTLS 证书已正确生成并分发看不到其他节点的容器确认所有节点均部署了 Dozzleglobal 模式且各实例通过 overlay 网络互通远程 Agent 未出现在主机列表核对DOZZLE_REMOTE_AGENT地址与端口Agent 进程需处于可连接状态标签分组未生效确认标签写在deploy.labels服务标签而非仅容器标签Dozzle 会自动合并服务标签到任务容器启用DOZZLE_LEVELdebug可以获取最详细的诊断日志官方文档也将其作为排查集群问题的标准手段。小结Dozzzle 的 Swarm 模式通过DOZZLE_MODEswarmdeploy.mode: global overlay 网络借助 mTLS 加密的网状网络与基于 Docker 标签的自研分组逻辑将 Swarm 集群内所有节点的容器日志与统计统一呈现。配合 Docker Secret 实现简单认证、通过DOZZLE_REMOTE_AGENT接入独立 Agent即可构建一套完整的 Swarm 集群日志观测方案。相关的深入实现可继续阅读 internal/support/docker/swarm_client_manager.go、internal/docker/service_labels.go 与 assets/stores/swarm.ts官方文档还提供了 Swarm 模式英文版 及其他语言的翻译版本供对照参考。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表