2026/9/14 19:17:21
FEATURED · 精选文章 
Keploy 在 macOS 上没有原生拦截路径如何用 Docker 完成 record 和 test【免费下载链接】keployOpen-source platform for creating safe, isolated production sandboxes for API, integration, and E2E testing.项目地址: https://gitcode.com/GitHub_Trending/ke/keployKeploy 通过在底层拦截应用的网络流量来生成 API 测试用例与依赖 mock但它的拦截方式按平台不同而不同Linux 走 eBPFpkg/agent/hooks/linux/Windows (amd64) 走用户态拦截userspace proxy。而 macOSamd64、arm64会落入others桩stub仓库中 AGENTS.md 的平台支持表明确写道there isnonative interception path on macOSKeploy-in-Docker 一栏标注 ✅ Supported (only option)。也就是说macOS 上只能走 Docker 路径且应用本身也必须运行在 Docker 容器里——如果应用不在 Docker 中Keploy 在 macOS 上无法拦截它的流量。这篇文章覆盖的任务路径是在 macOS 上构建 Keploy Docker 镜像 → 启动 Keploy 容器 → 执行keploy record录制测试集 → 执行keploy test回放并确认报告前提是你的 Docker 运行时文档指出 macOS 需要 Colima已可用仓库源代码可访问。平台原生二进制应用运行在宿主机Keploy-in-Docker应用运行在 DockerLinuxx86_64、arm64支持eBPF需要 root支持Windowsamd64支持用户态拦截支持macOSamd64、arm64不支持走others桩支持唯一选项准备条件Docker 运行时就绪。macOS 文档路径是 Colima仓库代码 pkg/platform/docker/util.go 中存在针对colimaDocker 上下文的检测分支会记录 Starting keploy in docker with colima context, as that is the current context.。Keploy CLI 在 macOS 上不会像 Linux 那样重新提权执行 sudoutils/reexec_darwin.go 中ShouldReexecWithSudo恒返回false依赖当前用户可直接访问的 Docker context。有 Keploy 仓库的源代码目录用于本地构建镜像。应用可容器化。-c参数传的是启动应用容器的docker run命令应用跑在宿主机进程里比如直接python main.py时这条路径在 macOS 上不可用。应用容器与 Keploy 容器在同一 Docker 网络中后文的命令统一使用网络名keploy-network可用docker network create keploy-network预先创建若你的应用用 docker compose把网络名替换为你自己的外部网络名即可文档示例中也允许自定义网络。第一步构建 Keploy Docker 镜像在仓库根目录执行sudo docker image build -t ghcr.io/keploy/keploy:v3-dev .这是 AGENTS.md 给出的构建命令ghcr.io/keploy/keploy:v3-dev也是 CI 为开发构建产出、samples 期望使用的镜像 tag。这条命令会编译出包含 keploy 二进制和入口脚本的镜像本地构建时不需要额外的镜像拉取地址。构建过程由 Dockerfile 完成两个阶段都与后文行为直接相关构建阶段基于golang:1.27以CGO_ENABLED1执行go build -tagsviper_bind_struct。AGENTS.md 特别强调viper_bind_structbuild tag 是必须的缺失会导致运行时配置字段无法正确绑定。运行时阶段基于debian:trixie-slim设置ENV KEPLOY_INDOCKERtrue入口为ENTRYPOINT [/app/entrypoint.sh, /app/keploy, agent, --is-docker]。entrypoint.sh 会先检查/sys/kernel/debug是否为挂载点未挂载则以sudo mount -t debugfs debugfs /sys/kernel/debug挂载最后用exec sudo -E把 shell 进程替换为 keploy使 keploy 能直接收到 Docker 发来的 SIGTERM 信号。第二步把 Keploy 镜像跑起来alias 及挂载差异在应用项目根目录-c命令中的$(pwd)都指向这里录制的keploy/目录也会写在这里定义 alias。CLI 自带帮助cli/provider/cmd.go 的Exampleskeploy --help可见给出的是alias keploysudo docker run --name keploy-ebpf -p 16789:16789 --privileged --pidhost -it -v $(pwd):$(pwd) -w $(pwd) -v /sys/fs/cgroup:/sys/fs/cgroup -v /sys/kernel/debug:/sys/kernel/debug -v /sys/fs/bpf:/sys/fs/bpf -v /var/run/docker.sock:/var/run/docker.sock --rm ghcr.io/keploy/keploy西班牙语版 READMEREADMEes-Es.md给出的是另一条 aliastag 与容器名不同alias keploysudo docker run --pull always --name keploy-v2 -p 16789:16789 --privileged --pidhost -it -v $(pwd):$(pwd) -w $(pwd) -v /sys/fs/cgroup:/sys/fs/cgroup -v /sys/kernel/debug:/sys/kernel/debug -v /sys/fs/bpf:/sys/fs/bpf -v /var/run/docker.sock:/var/run/docker.sock --rm ghcr.io/keploy/keploy两条 alias 都保留了因为文档中确实同时存在但要注意其中/sys/fs/bpf、/sys/kernel/debug等挂载点是 eBPF 相关路径文档没有单独给出 macOS 精简版挂载列表。在 Colima 环境下宿主机上未必存在这些路径挂载不存在的路径可能失败或产生空挂载请根据实际 Docker 运行时报错增删挂载项并保留-v $(pwd):$(pwd) -w $(pwd)与-v /var/run/docker.sock:/var/run/docker.sock这两个与当前任务直接相关的挂载。sudo前缀在 Linux 上用于 eBPF 提权macOS 上 Keploy CLI 层面不做 sudo 重新执行见 utils/reexec_darwin.gosudo是否保留取决于你的 docker 命令本身是否需要提权。alias 生效后可执行keploy version之类的基本子命令确认容器可以启动--rm表示容器退出即删除。第三步keploy record 录制测试集在应用根目录执行来自 CLI 帮助与 AGENTS.md 的示例keploy record -c docker run -p 8080:8080 --name containerName --network keploy-network applicationImage --container-name containerName --buildDelay 60需要替换的占位符containerName是应用容器的名字applicationImage是你的应用镜像名-p 8080:8080按你应用实际监听端口调整--buildDelay 60给容器启动预留时间。若用 docker compose 启动应用containerName必须与docker-compose.yaml中服务配置的容器名一致READMEes-Es 的示例与 CLI 帮助均要求这一点。然后从宿主机向应用容器发送流量。READMEes-Es 给出的方式是用 cURL、Postman 或 Hoppscotch 等工具调用应用接口例如针对上面映射的 8080 端口curl http://localhost:8080/your-endpoint/your-endpoint换成你应用真实存在的接口路径。record 结束后停止发送流量并按提示结束会话检查当前目录下是否生成了测试集目录。AGENTS.md 描述的磁盘格式是keploy/ ├── test-set-0/ │ ├── tests/ │ │ ├── test-1.yaml │ │ └── test-2.yaml │ └── mocks.yaml (or mocks/ dir depending on version) ├── test-set-1/ │ └── ...其中tests/test-*.yaml是被捕获的 API 调用转成的测试用例mocks.yaml或mocks/目录是对应依赖的数据 mock。看到这个结构说明录制路径在 macOS Docker 下已经走通。第四步keploy test 回放并读取报告回放命令来自 CLI 根命令示例keploy test -c docker run -p 8080:8080 --name containerName --network keploy-network applicationImage --delay 10 --buildDelay 60--delay 10等待应用就绪后再触发回放containerName和端口与 record 时保持一致。回放时 Keploy 用录制到的 mock 拦截应用的依赖调用不需要真实的外部依赖。结果验证看报告文件。AGENTS.md 说明keploy test会写入./keploy/reports/test-run-*编号最大的目录是最新一次运行每个测试集生成一个报告文件keploy/ └── reports/ └── test-run-0/ (newest run has highest number) ├── test-set-0-report.yaml (top-level field: status: PASSED|FAILED) ├── test-set-1-report.yaml └── coverage.yaml (when coverage is enabled)查看最新一次运行中各测试集的状态ls -1dt ./keploy/reports/test-run-* | head -n1对最新test-run-*目录下的每个test-set-*-report.yaml其顶层字段status:是脚本可以直接 grep 的事实依据AGENTS.md 原话Thestatus:line is the ground truth scripts grep for.。status: PASSED表示该测试集回放通过只要出现status: FAILEDkeploy 进程会以非零退出码结束pkg/service/replay/replay.go负责翻转该退出码。限制与核对项应用必须在 Docker 中。AGENTS.md 明确If the app isnt in Docker, keploy cant intercept its traffic on macOS. 想在 macOS 上对宿主机进程做 eBPF 式拦截没有文档支持的路径。不需要 sudo 提权来跑 keploy CLI。这是 Linux 行为native 模式下sudo ./keploy record ...macOS 的 re-exec 帮助函数是 no-op。别名/挂载以你的 Docker 运行时实际可挂载的路径为准。文档给的两条 alias 都是带 eBPF 挂载的完整形式仓库没有单独维护 macOS 版本/sys/fs/bpf等挂载失败时优先检查 Colima 环境下该路径是否存在。退出码与报告一致。测试失败时进程非零退出可直接用于 CI 判定。进一步核对报告解析的参考脚本位置见 AGENTS.md The on-disk format 一节macOS CI 仅走 Docker 流程的事实见该文件 Run locally 与 CI at a glance 两节prepare_and_run_macos.yml只调用golang_docker_macos.yml。【免费下载链接】keployOpen-source platform for creating safe, isolated production sandboxes for API, integration, and E2E testing.项目地址: https://gitcode.com/GitHub_Trending/ke/keploy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Keploy 在 macOS 上没有原生拦截路径，如何用 Docker 完成 record 和 test？
Keploy 在 macOS 上没有原生拦截路径如何用 Docker 完成 record 和 test【免费下载链接】keployOpen-source platform for creating safe, isolated production sandboxes for API, integration, and E2E testing.项目地址: https://gitcode.com/GitHub_Trending/ke/keployKeploy 通过在底层拦截应用的网络流量来生成 API 测试用例与依赖 mock但它的拦截方式按平台不同而不同Linux 走 eBPFpkg/agent/hooks/linux/Windows (amd64) 走用户态拦截userspace proxy。而 macOSamd64、arm64会落入others桩stub仓库中 AGENTS.md 的平台支持表明确写道there isnonative interception path on macOSKeploy-in-Docker 一栏标注 ✅ Supported (only option)。也就是说macOS 上只能走 Docker 路径且应用本身也必须运行在 Docker 容器里——如果应用不在 Docker 中Keploy 在 macOS 上无法拦截它的流量。这篇文章覆盖的任务路径是在 macOS 上构建 Keploy Docker 镜像 → 启动 Keploy 容器 → 执行keploy record录制测试集 → 执行keploy test回放并确认报告前提是你的 Docker 运行时文档指出 macOS 需要 Colima已可用仓库源代码可访问。平台原生二进制应用运行在宿主机Keploy-in-Docker应用运行在 DockerLinuxx86_64、arm64支持eBPF需要 root支持Windowsamd64支持用户态拦截支持macOSamd64、arm64不支持走others桩支持唯一选项准备条件Docker 运行时就绪。macOS 文档路径是 Colima仓库代码 pkg/platform/docker/util.go 中存在针对colimaDocker 上下文的检测分支会记录 Starting keploy in docker with colima context, as that is the current context.。Keploy CLI 在 macOS 上不会像 Linux 那样重新提权执行 sudoutils/reexec_darwin.go 中ShouldReexecWithSudo恒返回false依赖当前用户可直接访问的 Docker context。有 Keploy 仓库的源代码目录用于本地构建镜像。应用可容器化。-c参数传的是启动应用容器的docker run命令应用跑在宿主机进程里比如直接python main.py时这条路径在 macOS 上不可用。应用容器与 Keploy 容器在同一 Docker 网络中后文的命令统一使用网络名keploy-network可用docker network create keploy-network预先创建若你的应用用 docker compose把网络名替换为你自己的外部网络名即可文档示例中也允许自定义网络。第一步构建 Keploy Docker 镜像在仓库根目录执行sudo docker image build -t ghcr.io/keploy/keploy:v3-dev .这是 AGENTS.md 给出的构建命令ghcr.io/keploy/keploy:v3-dev也是 CI 为开发构建产出、samples 期望使用的镜像 tag。这条命令会编译出包含 keploy 二进制和入口脚本的镜像本地构建时不需要额外的镜像拉取地址。构建过程由 Dockerfile 完成两个阶段都与后文行为直接相关构建阶段基于golang:1.27以CGO_ENABLED1执行go build -tagsviper_bind_struct。AGENTS.md 特别强调viper_bind_structbuild tag 是必须的缺失会导致运行时配置字段无法正确绑定。运行时阶段基于debian:trixie-slim设置ENV KEPLOY_INDOCKERtrue入口为ENTRYPOINT [/app/entrypoint.sh, /app/keploy, agent, --is-docker]。entrypoint.sh 会先检查/sys/kernel/debug是否为挂载点未挂载则以sudo mount -t debugfs debugfs /sys/kernel/debug挂载最后用exec sudo -E把 shell 进程替换为 keploy使 keploy 能直接收到 Docker 发来的 SIGTERM 信号。第二步把 Keploy 镜像跑起来alias 及挂载差异在应用项目根目录-c命令中的$(pwd)都指向这里录制的keploy/目录也会写在这里定义 alias。CLI 自带帮助cli/provider/cmd.go 的Exampleskeploy --help可见给出的是alias keploysudo docker run --name keploy-ebpf -p 16789:16789 --privileged --pidhost -it -v $(pwd):$(pwd) -w $(pwd) -v /sys/fs/cgroup:/sys/fs/cgroup -v /sys/kernel/debug:/sys/kernel/debug -v /sys/fs/bpf:/sys/fs/bpf -v /var/run/docker.sock:/var/run/docker.sock --rm ghcr.io/keploy/keploy西班牙语版 READMEREADMEes-Es.md给出的是另一条 aliastag 与容器名不同alias keploysudo docker run --pull always --name keploy-v2 -p 16789:16789 --privileged --pidhost -it -v $(pwd):$(pwd) -w $(pwd) -v /sys/fs/cgroup:/sys/fs/cgroup -v /sys/kernel/debug:/sys/kernel/debug -v /sys/fs/bpf:/sys/fs/bpf -v /var/run/docker.sock:/var/run/docker.sock --rm ghcr.io/keploy/keploy两条 alias 都保留了因为文档中确实同时存在但要注意其中/sys/fs/bpf、/sys/kernel/debug等挂载点是 eBPF 相关路径文档没有单独给出 macOS 精简版挂载列表。在 Colima 环境下宿主机上未必存在这些路径挂载不存在的路径可能失败或产生空挂载请根据实际 Docker 运行时报错增删挂载项并保留-v $(pwd):$(pwd) -w $(pwd)与-v /var/run/docker.sock:/var/run/docker.sock这两个与当前任务直接相关的挂载。sudo前缀在 Linux 上用于 eBPF 提权macOS 上 Keploy CLI 层面不做 sudo 重新执行见 utils/reexec_darwin.gosudo是否保留取决于你的 docker 命令本身是否需要提权。alias 生效后可执行keploy version之类的基本子命令确认容器可以启动--rm表示容器退出即删除。第三步keploy record 录制测试集在应用根目录执行来自 CLI 帮助与 AGENTS.md 的示例keploy record -c docker run -p 8080:8080 --name containerName --network keploy-network applicationImage --container-name containerName --buildDelay 60需要替换的占位符containerName是应用容器的名字applicationImage是你的应用镜像名-p 8080:8080按你应用实际监听端口调整--buildDelay 60给容器启动预留时间。若用 docker compose 启动应用containerName必须与docker-compose.yaml中服务配置的容器名一致READMEes-Es 的示例与 CLI 帮助均要求这一点。然后从宿主机向应用容器发送流量。READMEes-Es 给出的方式是用 cURL、Postman 或 Hoppscotch 等工具调用应用接口例如针对上面映射的 8080 端口curl http://localhost:8080/your-endpoint/your-endpoint换成你应用真实存在的接口路径。record 结束后停止发送流量并按提示结束会话检查当前目录下是否生成了测试集目录。AGENTS.md 描述的磁盘格式是keploy/ ├── test-set-0/ │ ├── tests/ │ │ ├── test-1.yaml │ │ └── test-2.yaml │ └── mocks.yaml (or mocks/ dir depending on version) ├── test-set-1/ │ └── ...其中tests/test-*.yaml是被捕获的 API 调用转成的测试用例mocks.yaml或mocks/目录是对应依赖的数据 mock。看到这个结构说明录制路径在 macOS Docker 下已经走通。第四步keploy test 回放并读取报告回放命令来自 CLI 根命令示例keploy test -c docker run -p 8080:8080 --name containerName --network keploy-network applicationImage --delay 10 --buildDelay 60--delay 10等待应用就绪后再触发回放containerName和端口与 record 时保持一致。回放时 Keploy 用录制到的 mock 拦截应用的依赖调用不需要真实的外部依赖。结果验证看报告文件。AGENTS.md 说明keploy test会写入./keploy/reports/test-run-*编号最大的目录是最新一次运行每个测试集生成一个报告文件keploy/ └── reports/ └── test-run-0/ (newest run has highest number) ├── test-set-0-report.yaml (top-level field: status: PASSED|FAILED) ├── test-set-1-report.yaml └── coverage.yaml (when coverage is enabled)查看最新一次运行中各测试集的状态ls -1dt ./keploy/reports/test-run-* | head -n1对最新test-run-*目录下的每个test-set-*-report.yaml其顶层字段status:是脚本可以直接 grep 的事实依据AGENTS.md 原话Thestatus:line is the ground truth scripts grep for.。status: PASSED表示该测试集回放通过只要出现status: FAILEDkeploy 进程会以非零退出码结束pkg/service/replay/replay.go负责翻转该退出码。限制与核对项应用必须在 Docker 中。AGENTS.md 明确If the app isnt in Docker, keploy cant intercept its traffic on macOS. 想在 macOS 上对宿主机进程做 eBPF 式拦截没有文档支持的路径。不需要 sudo 提权来跑 keploy CLI。这是 Linux 行为native 模式下sudo ./keploy record ...macOS 的 re-exec 帮助函数是 no-op。别名/挂载以你的 Docker 运行时实际可挂载的路径为准。文档给的两条 alias 都是带 eBPF 挂载的完整形式仓库没有单独维护 macOS 版本/sys/fs/bpf等挂载失败时优先检查 Colima 环境下该路径是否存在。退出码与报告一致。测试失败时进程非零退出可直接用于 CI 判定。进一步核对报告解析的参考脚本位置见 AGENTS.md The on-disk format 一节macOS CI 仅走 Docker 流程的事实见该文件 Run locally 与 CI at a glance 两节prepare_and_run_macos.yml只调用golang_docker_macos.yml。【免费下载链接】keployOpen-source platform for creating safe, isolated production sandboxes for API, integration, and E2E testing.项目地址: https://gitcode.com/GitHub_Trending/ke/keploy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
