DBX 测试环境实战ZooKeeper 3.9 的 Digest ACL 初始化与addauth认证验证【免费下载链接】dbx15MB轻量级跨平台数据库客户端、数据库管理工具。支持 MySQL、PostgreSQL、SQLite、Redis、MongoDB、DuckDB、ClickHouse、SQL Server 等。15MB, lightweight, cross-platform database client. Supports MySQL, PostgreSQL, SQLite, Redis, MongoDB, DuckDB, ClickHouse, SQL Server and more.项目地址: https://gitcode.com/t8y2/dbx本文围绕 DBX 仓库中 ZooKeeper 3.9 版本数据库测试环境的初始化文档 init/README.md 展开食谱recipe运行器如何用 Digest ACL 创建受保护的/dbx节点以及 ZooKeeper 没有全局账号/密码登录开关这一事实对客户认证方式的决定性影响。读完本文你将掌握 ZooKeeper Digest ACL 的节点级保护机制、DBX 食谱的 bootstrap/smoke 验证流程以及zkCli.sh下addauth digest的完整实操用法。初始化文档的核心结论ZooKeeper 3.9 环境的初始化文档原文非常精炼但它给出了两条关键事实食谱运行器会创建/dbx节点并为其挂上root用户的 Digest ACL密码默认为123456可通过环境变量DB_PASSWORD覆盖ZooKeeper 没有全局的“启用账号密码登录”开关。这一点与 MySQL、etcd 等服务不同——那些产品可以“开启认证”后强制所有连接携带凭据而 ZooKeeper 的 ACL 是节点级别的属性只对挂了该 ACL 的 znode 生效。因此客户端必须在访问这个受保护节点之前先执行addauth digest root:password完成会话级认证否则将被拒绝。这两点共同解释了该环境“为什么这样初始化”以及“连接时为什么必须带 digest 凭据”。以下各节结合同目录下的 recipe.json 与 compose.yaml 源码级展开。环境文件布局与约定按照 deploy/database/README.md 与 RECIPE_TEMPLATE.md 的食谱规范每个版本目录遵循统一布局deploy/database/zookeeper/3.9/ ├── recipe.json # 连接字段、bootstrap 与 smoke 命令 ├── compose.yaml # Docker Compose 环境定义 └── init/ # 环境初始化说明本文主角 README.md └── README.md模板规范还要求镜像必须固定版本、宿主绑定默认${DB_BIND_ADDRESS:-127.0.0.1}、容器名统一为dbx-product-version、默认密码123456、默认数据库dbx且每个产品独占101xx–115xx中的一个宿主端口段。这些约定在scripts/database-env.mjs中可得到印证ZooKeeper 被分配在 zookeeper 端口段10800–10899而食谱的connection.port与 Compose 的DB_PORT回退值都必须等于hostPorts.DB_PORT。Compose 环境镜像、端口与健康检查compose.yaml 定义了一个单服务 standalone 环境要点如下services: database: image: docker.cnb.cool/znb/images/zookeeper:3.9.5 # 固定到 3.9.5 具体版本 container_name: dbx-zookeeper-3.9 restart: always ports: - ${DB_BIND_ADDRESS:-127.0.0.1}:${DB_PORT:-10800}:2181 volumes: - data:/data - datalog:/datalog healthcheck: test: [CMD-SHELL, zkServer.sh status | grep -q Mode: standalone] interval: 5s timeout: 5s retries: 30 start_period: 15s volumes: data: datalog:结合 recipe.json 中的字段可以读出完整的端口语义配置项值说明defaultPort2181ZooKeeper 原生客户端端口容器内hostPorts.DB_PORT10800宿主默认映射端口落在 zookeeper 的10800–10899段内connection127.0.0.1:10800用户root/ 密码123456authScheme: digest食谱记录的标准连接凭据authScheme明确标记为 digestplatformslinux/amd64、linux/arm64两种架构均受支持跨平台运行无需模拟注意端口映射${DB_BIND_ADDRESS:-127.0.0.1}:${DB_PORT:-10800}:2181默认只绑定回环地址。若确实需要远程访问按 deploy/database/README.md 的说明需显式设置DB_BIND_ADDRESS0.0.0.0、改用强DB_PASSWORD并以防火墙规则保护宿主。健康检查通过zkServer.sh status输出中的Mode: standalone判定服务就绪配合start_period: 15s与 30 次重试足以覆盖 ZooKeeper 的启动窗口。数据目录/data事务快照与/datalog事务日志分离挂载到两个命名卷这是 ZooKeeper 官方推荐的部署形态之一也便于db-reset一键清库。Bootstrap创建带 Digest ACL 的/dbx节点初始化行为在 recipe.json 的bootstrap中落地分为“检查”与“创建”两步bootstrap: { check: { command: [sh, -ec, printf addauth digest root:%s\\nget /dbx\\nquit\\n \$1\ | zkCli.sh -server 127.0.0.1:2181, sh, ${DB_PASSWORD}], expect: DBX smoke }, steps: [{ name: create Digest-protected smoke node, command: [sh, -ec, printf addauth digest root:%s\\ncreate /dbx \DBX smoke\ auth:root:%s:cdrwa\\nquit\\n \$1\ \$1\ | zkCli.sh -server 127.0.0.1:2181, sh, ${DB_PASSWORD}], expect: Created /dbx }] }逐层拆解这段命令认证载荷通过printf管道送入zkCli.shaddauth digest root:密码是非交互模式下认证的唯一途径——zkCli.sh本身没有--user这类全局凭据参数对比 etcd 食谱中etcdctl --user root:${DB_PASSWORD}的写法差异正源于初始化文档强调的“ZooKeeper 没有全局登录开关”。${DB_PASSWORD}由运行器作为位置参数$1传入默认即123456create /dbx DBX smoke auth:root:密码:cdrwa中第三个参数是 ACL 串scheme:acl形式scheme为authacl部分编码为用户:密码摘要:权限。cdrwa依次对应create、delete、read、write、admin五种权限授予root用户对/dbx的全部操作权check步骤以“能用凭据读到DBX smoke”作为幂等判断——节点已存在且可读时跳过创建保证 bootstrap 可重复执行expect字段是运行器的断言锚点创建步骤必须输出Created /dbx否则视为初始化失败。Smoke验证“匿名拒绝 认证可读”两条路径recipe.json 的smoke定义了与该文档结论直接对应的两条断言恰好构成 Digest ACL 保护正确性的正反两面步骤命令管道进zkCli.sh期望输出验证点reject anonymous access to protected nodeprintf get /dbx\nquit\n不带addauthInsufficient permission匿名会话访问/dbx被 ACL 拒绝read protected node with Digest credentialsprintf addauth digest root:%s\nget /dbx\nquit\n $1DBX smoke先认证、后读取返回节点内容第一条命令末尾的|| true允许zkCli.sh以非零码退出权限不足时客户端会报错退出断言只看输出中是否出现Insufficient permission。这两步合起来即初始化文档所说“客户端必须先addauth才能访问受保护节点”的可执行证明。食谱同时声明了交互式shell入口shell: [zkCli.sh, -server, 127.0.0.1:2181]进入该 shell 后手工验证流程就是# 容器内交互式 zkCli.sh 会话 addauth digest root:123456 # 密码为 123456 或 $DB_PASSWORD get /dbx # 输出 DBX smoke ls / # 未认证时 /dbx 会显示为 Noauth启动、验证与连接方式从仓库根目录按 deploy/database/README.md 提供的主目标操作make db-list # 按产品分组列出所有食谱及端口映射 make db DBzookeeper3.9 # 打印一条可直接复制的启动命令 make db-verify DBzookeeper3.9 # 执行 bootstrap smoke 全量校验 make db-down DBzookeeper3.9 # 停止环境 make db-reset DBzookeeper3.9 CONFIRM1 # 删除命名卷必须显式 CONFIRM1对支持 DBX 连接类型的产品make db完成启动后还会打印一条预填凭据的dbx://connection/new深链接在安装了 DBX Desktop 的 macOS 上可用open link打开新建连接对话框该链接可能包含密码文档特别提醒不要将其存入共享的终端历史、日志或工单。DBX 对 ZooKeeper 的连接能力定义在 plugins/connection-types/zookeeper.yamldbType: zookeeper、默认端口 2181、supportLevel: connect并且文件内注释明确说明——ZooKeeper 没有 SQL 引擎其 agent 只暴露kv_*操作因此queryExecution、metadataBrowse、schemaSearch等能力均关闭引用了 issue #8215 中 ZooKeeper 连接误调list-databases报错的背景。这意味着该测试环境面向的场景正是 KV 节点级读写与 ACL 验证而非 SQL 查询。诊断层面pnpm db:env -- info|status|logs|shell product version提供比 Make 目标更细一层的排查手段例如pnpm db:env -- shell zookeeper 3.9直接进入带zkCli.sh的容器 shell。适用前提与边界说明本环境面向Docker Compose 单机 standalone部署健康检查依赖Mode: standalone输出集群模式quorum不在该食谱覆盖范围内ACL 保护是节点级的/dbx之外的路径包括根节点/仍是开放的world:anyone:cdrwa匿名客户端仍可列举树结构只是无法读写/dbx。这是 ZooKeeper Digest 方案的固有边界食谱的 smoke 也只断言了这一点密码经由DB_PASSWORD环境变量注入默认123456bootstrap、smoke 与 connection 字段三者共用同一密码改密只需改一处环境变量宿主端口默认10800可用DB_PORT覆盖但应保持在 zookeeper 的10800–10899专属段内以避免与其他产品食谱的映射冲突见 scripts/database-env.mjs 中的端口段表。综上该 ZooKeeper 3.9 初始化文档虽短却点出了 ZooKeeper 安全模型的关键差异没有全局认证开关保护必须落到具体 znode 的 ACL 上而addauth digest是客户端会话内认证的唯一入口。配合 recipe.json 的 bootstrap 断言与 smoke 正反验证这套食谱构成了一个可重复执行、可自动校验的 Digest ACL 初始化与连接验证基线。【免费下载链接】dbx15MB轻量级跨平台数据库客户端、数据库管理工具。支持 MySQL、PostgreSQL、SQLite、Redis、MongoDB、DuckDB、ClickHouse、SQL Server 等。15MB, lightweight, cross-platform database client. Supports MySQL, PostgreSQL, SQLite, Redis, MongoDB, DuckDB, ClickHouse, SQL Server and more.项目地址: https://gitcode.com/t8y2/dbx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考