Kubo 三节点集成测试3nodetest实战基于 Docker 的 bootstrap/server/client 端到端内容分发验证【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo本文以 test/3nodetest/README.md 为核心深入讲解 KuboIPFS 的 Go 实现仓库内置的三节点集成测试如何使用 Docker 编排一个「bootstrap 引导节点 server 提供节点 client 拉取节点」的最小内容分发网络并自动完成文件添加、CID 共享与跨节点取回校验。读完本文你将掌握这套测试的完整拓扑、四个容器的职责划分、make setup/fig build/fig up的完整执行链路以及它与 Go 单元级集成测试TestThreeLeggedCatTransfer的对应关系可用于复现和改造自己的多节点 IPFS 测试环境。一、测试目标最小化的“三腿猫”内容分发场景该测试的本质是一个three-legged cat三腿猫场景由三个节点构成一条完整的数据传递链路——数据从 providerserver出发经由 bootstrap 完成节点发现与路由最终被 requesterclient取回并校验字节一致。三个节点的角色划分如下节点容器目录监听端口职责bootstraptest/3nodetest/bootstrap4011 (TCP) / 4012 (UDP)空 bootstrap 列表的引导节点仅作为对端发现的锚点servertest/3nodetest/server4021 (TCP) / 4022 (UDP)启动 daemon、执行ipfs add添加测试文件、把 CID 写入共享卷clienttest/3nodetest/client4031 (TCP) / 4032 (UDP)从共享卷读取 CID通过ipfs cat跨节点取回数据并做完整性校验datatest/3nodetest/data无纯数据卷容器挂载/data为 server/client 共享测试文件与 CIDbootstrap 节点的固定 PeerID 为QmNXuBh8HFsWq68Fid8dMbGNQTh7eG6hV9rr1fQyfmfomE见 bootstrap/configserver 与 client 的启动脚本都通过环境变量拼装出指向该 PeerID 的 multiaddr 并执行ipfs bootstrap add从而把三个独立 daemon 连接进同一张网络。二、环境需求与镜像前提关联文档明确列出了四项前置条件Docker容器运行时负责构建与隔离各节点fig服务编排工具Docker Compose 的前身通过fig.yml描述多容器拓扑Go用于构建生成随机测试数据所需的辅助工具make setup会通过make -C ./../../ test/bin/random编译随机数据生成器名为zaqwsx_ipfs-test-img的 ipfs 镜像所有节点的Dockerfile都以该镜像为基底FROM zaqwsx_ipfs-test-img因此必须先构建或导入一个内含ipfs二进制的基础镜像。启动测试的三条命令是make setup fig build fig up其中make setup完成两件事见 test/3nodetest/GNUmakefile一是构建基础镜像docker_ipfs_image目标名IMAGE_NAME ipfs-test-latest二是生成测试数据文件data/filetiny直接复制Makefile体积小与data/filerand由../bin/random 50000000生成 50 MB 随机字节。fig build按各子目录的Dockerfile构建四个服务镜像fig up一次性启动整个拓扑。三、fig.yml 拓扑编排详解test/3nodetest/fig.yml 是整个测试的编排核心四个服务的关键配置如下data: build: ./data volumes: - /data command: sleep 1000000 bootstrap: build: ./bootstrap command: daemon --debug --init expose: - 4011 - 4012/udp environment: GOLOG_LOG_LEVEL: debug server: build: ./server links: - bootstrap volumes_from: - data expose: - 4021 - 4022/udp environment: GOLOG_LOG_LEVEL: debug client: build: ./client links: - bootstrap volumes_from: - data expose: - 4031 - 4032/udp environment: GOLOG_LOG_LEVEL: debug要点解读data 容器声明VOLUME [/data]见 data/Dockerfile启动命令为sleep 1000000保持存活仅作为卷的载体links: - bootstrapserver 与 client 通过链接获得 bootstrap 容器的网络可达信息fig 会自动注入形如BOOTSTRAP_PORT_4011_TCP_ADDR、BOOTSTRAP_PORT_4011_TCP_PORT的环境变量这正是 server/run.sh 与 client/run.sh 拼装 bootstrap multiaddr 的依据volumes_from: - dataserver 与 client 共享 data 容器的/data卷CID 与测试文件经由该卷在两者间传递GOLOG_LOG_LEVEL: debug所有节点以 debug 级别输出 Go 日志便于排查 DHT 发现与块交换细节command: daemon --debug --initbootstrap 直接以 daemon 模式启动--init确保仓库已初始化server/client 则通过各自Dockerfile的ENTRYPOINT [/bin/bash]CMD [run.sh]执行自定义脚本。四、自动化执行链路run-test-on-img.sh除手动三步外仓库还提供了全自动执行脚本 test/3nodetest/run-test-on-img.sh其执行流程为以参数指定的镜像引用默认ipfs-test-latest在docker images中查找镜像 ID并docker tag为各 Dockerfile 期望的zaqwsx_ipfs-test-img执行fig build --no-cache强制重新构建执行fig up --no-color | tee build/fig.log把全量输出落入日志依次执行make save_logs与make save_profiling_data收集调试产物失败不阻断由于fig up本身不返回可用的退出码脚本用tail build/fig.log | grep exited with code 0判断测试是否真正成功。其中IPFS_PROFtrue各 Dockerfile 均设置会使 daemon 输出 profiling 数据配合make save_profiling_data调用 test/3nodetest/bin/save_profiling_data.sh保存供性能分析使用。五、server提供数据的一侧server/run.sh 的流程完整展示了“提供者”节点的行为ipfs bootstrap add /ip4/$BOOTSTRAP_PORT_4011_TCP_ADDR/tcp/$BOOTSTRAP_PORT_4011_TCP_PORT/p2p/QmNXuBh8HFsWq68Fid8dMbGNQTh7eG6hV9rr1fQyfmfomE ipfs bootstrap # list bootstrap nodes for debugging ipfs daemon --debug sleep 3 cd /tmp ipfs add -q /data/filetiny tmptiny mv tmptiny /data/idtiny ipfs add -q /data/filerand tmprand mv tmprand /data/idrand sleep 10000000关键细节先ipfs bootstrap add指向 bootstrap 节点再启动 daemon保证节点入网可被发现ipfs add -q只输出 CID-q/--quiet并把 CID 写入共享卷/data/idtiny、/data/idrand——这是 server 与 client 之间的“信令通道”cd /tmp后再执行 add 命令是刻意为之避免 client 侧的命令 profiling 数据覆盖 daemon 自身的 profiling 数据脚本注释明确说明末尾sleep 10000000保持容器存活等待 client 拉取完成。六、client取回并校验数据的一侧client/run.sh 实现了“请求者”节点的完整校验逻辑ipfs bootstrap add /ip4/$BOOTSTRAP_PORT_4011_TCP_ADDR/tcp/$BOOTSTRAP_PORT_4011_TCP_PORT/p2p/QmNXuBh8HFsWq68Fid8dMbGNQTh7eG6hV9rr1fQyfmfomE ipfs daemon --debug sleep 3 cd /tmp while [ ! -f /data/idtiny ] do echo 3nodetest waiting for server to add the file... sleep 1 done ipfs cat $(cat /data/idtiny) filetiny diff -u filetiny /data/filetiny if (($? 0)); then printf %s\n files did not match 2 exit 1 fi # ...对 filerand 重复同样流程... echo 3nodetest success要点采用轮询而非硬编码 sleepwhile [ ! -f /data/idtiny ]循环等待 server 完成 add 并写入 CID避免时序竞态ipfs cat $(cat /data/idtiny)依据 CID 从网络中取回文件覆盖 DHT 发现 → 连接 provider → Bitswap 取块的完整链路diff -u与原始测试文件逐字节比对任一文件不一致即以非零退出码失败全部一致则输出3nodetest success这也是前文 fig.log 中exited with code 0判定成功的数据来源校验先小文件filetiny后大文件filerand50 MB 随机数据可同时验证小对象与大对象的传输正确性。七、节点配置与固定身份各节点的config文件展示了测试环境的定制要点见 bootstrap/config 与 client/config固定 PeerID 与私钥Identity.PeerID与Identity.PrivKey预置server/client 脚本据此构造固定的 bootstrap multiaddr测试可重复、可预期空 Bootstrap 列表Bootstrap: []——bootstrap 节点本身不依赖任何外部引导节点形成一个自包含的隔离网络独立 Swarm 端口Addresses.Swarm分别绑定 4011/4021/4031 的 TCP 端口配合EXPOSE 4012/udp等声明三节点在同一容器网络中互不冲突DatastoreType: leveldb路径/root/.ipfs/datastore镜像构建各 Dockerfile 均执行RUN ipfs init -b2048初始化仓库随后用预置 config 覆盖生成的配置mv -f并设置ENV GOLOG_LOG_FMT nocolor便于日志阅读。bootstrap 子目录的 README.md 也明确说明这是一个bootstrap list 为空的引导节点仅监听 4011/4012。八、与 Go 层集成测试的对应关系这套 Docker 化测试的场景在 Go 单元集成测试中同样存在test/integration/three_legged_cat_test.go中的TestThreeLeggedCatTransfer实现了同一“三腿猫”验证只是改用 libp2p 的 mocknet 而非真实容器func TestThreeLeggedCatTransfer(t *testing.T) { conf : testutil.LatencyConfig{...} if err : RunThreeLeggedCat(RandomBytes(1*unit.MB), conf); err ! nil { t.Fatal(err) } }RunThreeLeggedCat见 test/integration/three_legged_cat_test.go的流程与容器版一一对应创建bootstrap、adder对应 server、catter对应 client三个 mock 节点 →adder与catter通过BootstrapConfigWithPeers接入 bootstrap →adderAPI.Unixfs().Add添加数据 → 显式Provide根 CID 到 DHT →catterAPI.Unixfs().Get取回 →bytes.Equal逐字节比对。该文件还包含多个退化场景变体TestThreeLeggedCatDegenerateSlowBlockstore、...SlowNetwork、...SlowRouting、100MBMacbookCoastToCoast分别注入块存储延迟、网络延迟、路由延迟验证极端条件下的数据完整性——这为理解 3nodetest 覆盖的基础能力提供了 Go 层的对照实现。九、运行与排查建议首次运行务必先make setup它同时完成基础镜像构建与测试数据生成跳过会导致docker build因缺少data/filetiny而失败fig为 Docker Compose 的前身工具其fig.yml语法与现代docker-compose.yml基本兼容可直接将文件重命名后使用docker-compose build/docker-compose up运行仓库内 test/integration/GNUmakefile 等也保留了相关测试入口排查失败时优先查看build/fig.log测试成功与否取决于其中是否出现exited with code 0各节点均以GOLOG_LOG_LEVELdebug输出日志配合make save_logs收集的日志可定位 DHT 发现、连接与 Bitswap 传输环节的问题若需复现单节点行为可直接进入容器执行ipfs bootstrap list查看引导配置、ipfs swarm peers查看已连接对端、ipfs bitswap stat观察块交换状态。【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubo 三节点集成测试3nodetest实战基于 Docker 的 bootstrap/server/client 端到端内容分发验证【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo本文以 test/3nodetest/README.md 为核心深入讲解 KuboIPFS 的 Go 实现仓库内置的三节点集成测试如何使用 Docker 编排一个「bootstrap 引导节点 server 提供节点 client 拉取节点」的最小内容分发网络并自动完成文件添加、CID 共享与跨节点取回校验。读完本文你将掌握这套测试的完整拓扑、四个容器的职责划分、make setup/fig build/fig up的完整执行链路以及它与 Go 单元级集成测试TestThreeLeggedCatTransfer的对应关系可用于复现和改造自己的多节点 IPFS 测试环境。一、测试目标最小化的“三腿猫”内容分发场景该测试的本质是一个three-legged cat三腿猫场景由三个节点构成一条完整的数据传递链路——数据从 providerserver出发经由 bootstrap 完成节点发现与路由最终被 requesterclient取回并校验字节一致。三个节点的角色划分如下节点容器目录监听端口职责bootstraptest/3nodetest/bootstrap4011 (TCP) / 4012 (UDP)空 bootstrap 列表的引导节点仅作为对端发现的锚点servertest/3nodetest/server4021 (TCP) / 4022 (UDP)启动 daemon、执行ipfs add添加测试文件、把 CID 写入共享卷clienttest/3nodetest/client4031 (TCP) / 4032 (UDP)从共享卷读取 CID通过ipfs cat跨节点取回数据并做完整性校验datatest/3nodetest/data无纯数据卷容器挂载/data为 server/client 共享测试文件与 CIDbootstrap 节点的固定 PeerID 为QmNXuBh8HFsWq68Fid8dMbGNQTh7eG6hV9rr1fQyfmfomE见 bootstrap/configserver 与 client 的启动脚本都通过环境变量拼装出指向该 PeerID 的 multiaddr 并执行ipfs bootstrap add从而把三个独立 daemon 连接进同一张网络。二、环境需求与镜像前提关联文档明确列出了四项前置条件Docker容器运行时负责构建与隔离各节点fig服务编排工具Docker Compose 的前身通过fig.yml描述多容器拓扑Go用于构建生成随机测试数据所需的辅助工具make setup会通过make -C ./../../ test/bin/random编译随机数据生成器名为zaqwsx_ipfs-test-img的 ipfs 镜像所有节点的Dockerfile都以该镜像为基底FROM zaqwsx_ipfs-test-img因此必须先构建或导入一个内含ipfs二进制的基础镜像。启动测试的三条命令是make setup fig build fig up其中make setup完成两件事见 test/3nodetest/GNUmakefile一是构建基础镜像docker_ipfs_image目标名IMAGE_NAME ipfs-test-latest二是生成测试数据文件data/filetiny直接复制Makefile体积小与data/filerand由../bin/random 50000000生成 50 MB 随机字节。fig build按各子目录的Dockerfile构建四个服务镜像fig up一次性启动整个拓扑。三、fig.yml 拓扑编排详解test/3nodetest/fig.yml 是整个测试的编排核心四个服务的关键配置如下data: build: ./data volumes: - /data command: sleep 1000000 bootstrap: build: ./bootstrap command: daemon --debug --init expose: - 4011 - 4012/udp environment: GOLOG_LOG_LEVEL: debug server: build: ./server links: - bootstrap volumes_from: - data expose: - 4021 - 4022/udp environment: GOLOG_LOG_LEVEL: debug client: build: ./client links: - bootstrap volumes_from: - data expose: - 4031 - 4032/udp environment: GOLOG_LOG_LEVEL: debug要点解读data 容器声明VOLUME [/data]见 data/Dockerfile启动命令为sleep 1000000保持存活仅作为卷的载体links: - bootstrapserver 与 client 通过链接获得 bootstrap 容器的网络可达信息fig 会自动注入形如BOOTSTRAP_PORT_4011_TCP_ADDR、BOOTSTRAP_PORT_4011_TCP_PORT的环境变量这正是 server/run.sh 与 client/run.sh 拼装 bootstrap multiaddr 的依据volumes_from: - dataserver 与 client 共享 data 容器的/data卷CID 与测试文件经由该卷在两者间传递GOLOG_LOG_LEVEL: debug所有节点以 debug 级别输出 Go 日志便于排查 DHT 发现与块交换细节command: daemon --debug --initbootstrap 直接以 daemon 模式启动--init确保仓库已初始化server/client 则通过各自Dockerfile的ENTRYPOINT [/bin/bash]CMD [run.sh]执行自定义脚本。四、自动化执行链路run-test-on-img.sh除手动三步外仓库还提供了全自动执行脚本 test/3nodetest/run-test-on-img.sh其执行流程为以参数指定的镜像引用默认ipfs-test-latest在docker images中查找镜像 ID并docker tag为各 Dockerfile 期望的zaqwsx_ipfs-test-img执行fig build --no-cache强制重新构建执行fig up --no-color | tee build/fig.log把全量输出落入日志依次执行make save_logs与make save_profiling_data收集调试产物失败不阻断由于fig up本身不返回可用的退出码脚本用tail build/fig.log | grep exited with code 0判断测试是否真正成功。其中IPFS_PROFtrue各 Dockerfile 均设置会使 daemon 输出 profiling 数据配合make save_profiling_data调用 test/3nodetest/bin/save_profiling_data.sh保存供性能分析使用。五、server提供数据的一侧server/run.sh 的流程完整展示了“提供者”节点的行为ipfs bootstrap add /ip4/$BOOTSTRAP_PORT_4011_TCP_ADDR/tcp/$BOOTSTRAP_PORT_4011_TCP_PORT/p2p/QmNXuBh8HFsWq68Fid8dMbGNQTh7eG6hV9rr1fQyfmfomE ipfs bootstrap # list bootstrap nodes for debugging ipfs daemon --debug sleep 3 cd /tmp ipfs add -q /data/filetiny tmptiny mv tmptiny /data/idtiny ipfs add -q /data/filerand tmprand mv tmprand /data/idrand sleep 10000000关键细节先ipfs bootstrap add指向 bootstrap 节点再启动 daemon保证节点入网可被发现ipfs add -q只输出 CID-q/--quiet并把 CID 写入共享卷/data/idtiny、/data/idrand——这是 server 与 client 之间的“信令通道”cd /tmp后再执行 add 命令是刻意为之避免 client 侧的命令 profiling 数据覆盖 daemon 自身的 profiling 数据脚本注释明确说明末尾sleep 10000000保持容器存活等待 client 拉取完成。六、client取回并校验数据的一侧client/run.sh 实现了“请求者”节点的完整校验逻辑ipfs bootstrap add /ip4/$BOOTSTRAP_PORT_4011_TCP_ADDR/tcp/$BOOTSTRAP_PORT_4011_TCP_PORT/p2p/QmNXuBh8HFsWq68Fid8dMbGNQTh7eG6hV9rr1fQyfmfomE ipfs daemon --debug sleep 3 cd /tmp while [ ! -f /data/idtiny ] do echo 3nodetest waiting for server to add the file... sleep 1 done ipfs cat $(cat /data/idtiny) filetiny diff -u filetiny /data/filetiny if (($? 0)); then printf %s\n files did not match 2 exit 1 fi # ...对 filerand 重复同样流程... echo 3nodetest success要点采用轮询而非硬编码 sleepwhile [ ! -f /data/idtiny ]循环等待 server 完成 add 并写入 CID避免时序竞态ipfs cat $(cat /data/idtiny)依据 CID 从网络中取回文件覆盖 DHT 发现 → 连接 provider → Bitswap 取块的完整链路diff -u与原始测试文件逐字节比对任一文件不一致即以非零退出码失败全部一致则输出3nodetest success这也是前文 fig.log 中exited with code 0判定成功的数据来源校验先小文件filetiny后大文件filerand50 MB 随机数据可同时验证小对象与大对象的传输正确性。七、节点配置与固定身份各节点的config文件展示了测试环境的定制要点见 bootstrap/config 与 client/config固定 PeerID 与私钥Identity.PeerID与Identity.PrivKey预置server/client 脚本据此构造固定的 bootstrap multiaddr测试可重复、可预期空 Bootstrap 列表Bootstrap: []——bootstrap 节点本身不依赖任何外部引导节点形成一个自包含的隔离网络独立 Swarm 端口Addresses.Swarm分别绑定 4011/4021/4031 的 TCP 端口配合EXPOSE 4012/udp等声明三节点在同一容器网络中互不冲突DatastoreType: leveldb路径/root/.ipfs/datastore镜像构建各 Dockerfile 均执行RUN ipfs init -b2048初始化仓库随后用预置 config 覆盖生成的配置mv -f并设置ENV GOLOG_LOG_FMT nocolor便于日志阅读。bootstrap 子目录的 README.md 也明确说明这是一个bootstrap list 为空的引导节点仅监听 4011/4012。八、与 Go 层集成测试的对应关系这套 Docker 化测试的场景在 Go 单元集成测试中同样存在test/integration/three_legged_cat_test.go中的TestThreeLeggedCatTransfer实现了同一“三腿猫”验证只是改用 libp2p 的 mocknet 而非真实容器func TestThreeLeggedCatTransfer(t *testing.T) { conf : testutil.LatencyConfig{...} if err : RunThreeLeggedCat(RandomBytes(1*unit.MB), conf); err ! nil { t.Fatal(err) } }RunThreeLeggedCat见 test/integration/three_legged_cat_test.go的流程与容器版一一对应创建bootstrap、adder对应 server、catter对应 client三个 mock 节点 →adder与catter通过BootstrapConfigWithPeers接入 bootstrap →adderAPI.Unixfs().Add添加数据 → 显式Provide根 CID 到 DHT →catterAPI.Unixfs().Get取回 →bytes.Equal逐字节比对。该文件还包含多个退化场景变体TestThreeLeggedCatDegenerateSlowBlockstore、...SlowNetwork、...SlowRouting、100MBMacbookCoastToCoast分别注入块存储延迟、网络延迟、路由延迟验证极端条件下的数据完整性——这为理解 3nodetest 覆盖的基础能力提供了 Go 层的对照实现。九、运行与排查建议首次运行务必先make setup它同时完成基础镜像构建与测试数据生成跳过会导致docker build因缺少data/filetiny而失败fig为 Docker Compose 的前身工具其fig.yml语法与现代docker-compose.yml基本兼容可直接将文件重命名后使用docker-compose build/docker-compose up运行仓库内 test/integration/GNUmakefile 等也保留了相关测试入口排查失败时优先查看build/fig.log测试成功与否取决于其中是否出现exited with code 0各节点均以GOLOG_LOG_LEVELdebug输出日志配合make save_logs收集的日志可定位 DHT 发现、连接与 Bitswap 传输环节的问题若需复现单节点行为可直接进入容器执行ipfs bootstrap list查看引导配置、ipfs swarm peers查看已连接对端、ipfs bitswap stat观察块交换状态。【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
