ARTICLE DETAIL

资讯详情

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

Milvus 测试体系实战指南:E2E 端到端测试与 Python 代码质量(ruff)全解析

Milvus 测试体系实战指南:E2E 端到端测试与 Python 代码质量(ruff)全解析 Milvus 测试体系实战指南E2E 端到端测试与 Python 代码质量ruff全解析【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus本指南以 Milvus 仓库 tests/README.md 为主体系统讲解两条核心测试主线基于 KinD Helm 的E2E 端到端测试以及基于ruffvia uv的 Python 代码质量管控。读完本文你将掌握在本地搭建 Milvus E2E 测试环境的完整流程、e2e-k8s.sh的每个命令行参数的真实含义并能用与 CI 完全一致的方式对tests/下的 Python 代码执行 lint 与格式化。一、tests/ 目录概览两条并行测试主线Milvus 仓库将测试体系集中在 tests/ 目录下从 tests/README.md 可以看到两条明确的主线E2E Test在真实的 KubernetesKinD集群中部署 Milvus再通过 pytest 客户端套件验证完整功能链路Python Code Quality使用 ruff经 uv 提供对 tests/python_client、tests/restful_client、tests/restful_client_v2、benchmark/、tests/scripts 下的全部 Python 代码做 lint 与格式化并与 GitHub Actions 的 CI 流程对齐。目录内还包含 tests/MakefilePython lint 辅助入口、tests/ruff.tomlruff 配置、tests/dockerpytest 测试容器以及各客户端测试套件。下文分别深入展开。二、E2E 测试环境配置要求E2E 测试并非在宿主机直接跑 pytest而是先搭建一套完整的 Kubernetes 测试集群默认使用 KinD再通过 Helm Chart 部署 Milvus。因此对宿主机环境有明确的最低要求原文档给出了三张要求表。2.1 操作系统操作系统版本要求Amazon Linux2023 及以上Ubuntu20.04 及以上Mac10.14 及以上2.2 硬件硬件类型推荐配置CPUx86_64 架构Intel CPU Sandy Bridge 及以上CPU 指令集SSE4_2、AVX、AVX2、AVX512或 arm64 Linux/MacOS内存16 GB 及以上CPU 指令集要求与 Milvus 核心存储引擎internal/core在 CPU 侧向量化计算如 AVX2 优化直接相关Sandy Bridge 之前的架构无法提供所需指令集。2.3 软件依赖软件名称版本要求Docker19.05 及以上Docker Compose1.25.5 及以上jq1.3 及以上kubectl1.14 及以上helm3.0 及以上kind0.10.0 及以上其中jq用于解析kubectl get ... -o json的 JSON 输出详见下文 install_milvus.sh 中对 Pod 重启原因的分析kindKubernetes in Docker负责在 Docker 内拉起整个 Kubernetes 集群。三、E2E 测试依赖安装与 Docker 排障3.1 确认 Docker 守护进程运行 E2E 前首先要确认 Docker Daemon 是否在运行$ docker info原文档给出的排查路径包括确保 Docker 已安装参考官方 Docker CE/EE 安装文档如果 Docker Daemon 未启动请先启动它若希望免 root 运行 Docker可创建名为docker的用户组将当前用户加入该组后重新登录终端$ sudo usermod -aG docker $USER需要注意的是e2e-k8s.sh 在真正开始建集群前会再次校验 Dockerif ! docker info /dev/null 21; then echo KinD need docker to set up cluster - please start docker and try again! exit 1 fi如果 Docker 未就绪脚本会直接报错退出而不是等到建集群时才失败。3.2 检查 Docker Compose 版本$ docker compose version版本信息形如docker compose version 1.25.5, build 8a1c60f6 docker-py version: 4.1.0 CPython version: 3.7.5 OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020Docker Compose 在 E2E 中的用途是拉起 pytest 测试容器详见 tests/docker/docker-compose.yml例如 prepare_e2e.sh 中的docker compose pull pytest。3.3 安装 jq、kubectl、helm、kindjq从官方 jq 下载页获取用于 JSON 解析kubectl参考 Kubernetes 官方工具安装文档helm参考 Helm 官方安装文档Helm 3 系列kind参考 KinD 官方 Quick Start 安装文档。值得注意的是e2e-k8s.sh 内置了工具自举逻辑当kubectl或kind不在 PATH 中时会自动下载并安装指定版本默认kubectl v1.20.2、kind v0.11.1到${HOME}/tool_cache/下并加入 PATHhelm 缺失时同理默认helm v3.5.4。这意味着即使本机未预装这些工具脚本也能尽量自动补齐但推荐仍按原文档先手动装好。四、E2E 测试运行与参数全解析4.1 基本运行方式原文档给出的启动命令非常简洁$ cd tests/scripts $ ./e2e-k8s.sh获取帮助$ ./e2e-k8s.sh --help4.2 完整参数清单源码级解析通过阅读 e2e-k8s.sh 的--help输出我们可以得到脚本支持的全部参数这是原文档未展开但极具实战价值的部分参数说明默认值--node-imageKinD 节点镜像用于运行嵌套容器、systemd 与 Kubernetes 组件的 Docker 镜像可在 KinD releases 中查找kindest/node:v1.20.2--kind-config启用不同 Kubernetes 特性的 KinD 配置空--build-command指定构建 Milvus 的命令CPUmake install use_disk_indexONGPUmake gpu-install--install-extra-arg安装 Milvus Helm Chart 的额外配置如--set/--values覆盖 values空--test-extra-arg运行 E2E 测试的额外配置例如--tagsL0空--test-timeoutE2E 测试超时时间秒不设置--topologyKinD 集群拓扑SINGLE_CLUSTER、MULTICLUSTER_SINGLE_NETWORK、MULTICLUSTERSINGLE_CLUSTER--topology-configKinD 集群拓扑配置文件build/config/topology/multicluster.json--skip-setup跳过 KinD 集群搭建未设置--skip-install跳过 Milvus Helm Chart 安装未设置--skip-cleanup跳过 KinD 集群清理未设置--skip-build跳过构建 Milvus 二进制未设置--skip-build-image跳过构建 Milvus 镜像未设置--skip-test跳过 E2E 测试未设置--skip-export-logs跳过 kind 导出日志未设置--manual手动模式测试结束后暂停等待按键才关闭集群未设置--disable-kind不使用/移除 KinD 集群配合外部集群未设置--gpu以 GPU 模式构建与测试MODEgpu、TAGgpu-latestCPU 模式此外脚本还会导出若干可供外部覆盖的环境变量HUB镜像仓库默认milvusdb、TAG镜像标签CPU 为latest、IP_FAMILY默认ipv4、SINGLE_CLUSTER_NAME默认kind等。4.3 脚本执行流水线从集群到测试e2e-k8s.sh 的执行顺序清晰对应着几个阶段可通过--skip-*参数跳过任意环节环境自检与自举校验/安装kubectl、kind、helm确认 Docker 可用搭建 KinD 集群--skip-setup跳过单集群模式调用setup_kind_cluster多集群模式读取拓扑 JSON、为每个集群注入 kubeconfig并导出INTEGRATION_TEST_TOPOLOGY_FILE同时启动本地镜像仓库kind-registrylocalhost:5000供 KinD 节点拉取构建出的镜像构建 Milvus--skip-build跳过执行build/builder.shCPU或builder_gpu.shGPU默认构建命令为make install use_disk_indexON构建并推送镜像--skip-build-image跳过执行build/build_image.sh然后docker push到本地 kind registryHelm 安装 Milvus--skip-install跳过调用 install_milvus.shrelease 名由 get_release_name.sh 生成执行 E2E 测试--skip-test跳过调用 e2e.sh手动模式挂起 / 正常清理退出--manual下等待按键否则脚本结束集群清理由后续流程处理。4.4 Helm 安装细节install_milvus.sh 是安装阶段的核心几个关键行为值得注意默认安装超时MILVUS_INSTALL_TIMEOUT800s注释说明因 Pulsar 多了一个节点而从 500s 上调安装前会先helm uninstall清理同名 release并删除关联的 PVCStandalone 模式MILVUS_CLUSTER_ENABLEDfalse下默认关闭 Pulsarpulsar.enabledfalse、使用独立 MinIOminio.modestandalone、etcd 单副本集群模式下则启用 Pulsar 双副本 broker服务类型按环境选择KinD metallb 时用LoadBalancer否则默认ClusterIP安装失败时会收集异常 Pod 的 events 辅助定位并检查 Pod 重启原因用 jq 解析restartCount与lastState.terminated.reason。4.5 pytest 客户端如何连上 Milvuse2e.sh 负责打通测试容器到 Milvus 服务的网络通过kubectl get service -l app.kubernetes.io/instance...,componentstandalone|proxy解析服务 IP 与端口当服务类型为 ClusterIP 时使用kubectl port-forward将 Pod 端口转发到本机127.0.0.1并在退出时trap清理转发进程在 tests/docker 目录下以docker compose run --rm pytest方式运行测试容器默认并行数PARALLEL_NUM6docker compose run --rm pytest /bin/bash -c pytest -n 6 --host ${MILVUS_SERVICE_IP} --port ${MILVUS_SERVICE_PORT} ...测试容器的工作目录为/milvus/tests/python_clienttests/docker/docker-compose.yml 将仓库根目录挂载进容器../../:/milvus:delegated并设置shm_size: 2G供 pytest-xdist 多进程共享内存使用。而 CI 环境下的 ci_e2e.sh 则不经 Docker 容器直接在 tests/python_client 目录下调用 pytest并通过--minio_host额外传入 MinIO 服务名以服务名而非 IP 访问MILVUS_SERVICE_NAMErelease-milvus.namespace端口 19530日志路径默认为/tmp/ci_logs/test。五、Python 代码质量ruff via uv5.1 配置与作用范围ruff 的配置位于 tests/ruff.toml覆盖 tests/ 下所有 Python 代码包括python_client/、restful_client/、restful_client_v2/、benchmark/、scripts/各子目录继续通过各自的requirements.txt管理运行时依赖。关键配置项line-length 120行宽上限 120 字符target-version py312目标 Python 版本 3.12启用的规则组Epycodestyle errors、Fpyflakes、Wpycodestyle warnings、Iisort、UPpyupgrade忽略项E501行长交给 formatter 处理、E741测试代码中常见的l/I/O歧义变量名、F841测试代码刻意保留调用结果、且缺失断言的场景已修复、UP031printf 风格格式化属纯风格改写27 处% (...)元组用法并不等价per-file-ignores__init__.py忽略F401conftest.py忽略F401、F811格式化风格双引号、空格缩进、line-ending auto。5.2 常用命令原文档给出的核心命令$ cd tests/ $ ruff check . # lint $ ruff check . --fix # lint with auto-fix $ ruff format . # format in place $ ruff format --check . # format check only (CI-friendly)需要说明的是ruff通过uv提供uvx ruffversionuv由 python-env.sh 负责引导——该脚本会根据 tests/.python-version或PYTEST_PYTHON_VERSION默认3.12自动创建位于tests/.venv的虚拟环境缺少uv时会用现有 Python 先安装 uv 再创建环境。5.3 只 lint PR 变更文件与 CI 精确对齐原文档特别强调直接对整个tests/树执行uv run ruff check .是过于粗糙的——大量历史文件的遗留风格早于当前 lint 配置会命中无关规则而失败。因此 CI 只对每次 PR变更的tests/**/*.py执行ruff check与ruff format --check。为在本地精确复现 CI 行为请使用 tests/Makefile 提供的目标$ cd tests/ $ make ci # ruff check format --check on PR-changed *.py (CI equivalent) $ make lint-fix # ruff check --fix on PR-changed *.py $ make format # ruff format on PR-changed *.py $ make help # show all targets and the detected BASE_REF各目标的行为依据 Makefile 源码目标等价命令作用于 PR 变更文件lintruff check changed-filesformat-checkruff format --check --diff changed-filescilintformat-checklint-fixruff check --fix changed-filesformatruff format changed-files变更文件集合通过git diff --name-only --diff-filterACMR $(BASE_REF)...HEAD -- tests/**/*.py三点 diff即从 merge-base 起算计算。ruff 版本由RUFF_VERSION固定默认0.15.11与.github/workflows/python-lint.yaml工作流保持一致保证本地与 CI 使用同一版本。5.4 BASE_REF 自动检测与手动指定BASE_REF是 diff 基准分支Makefile 会尝试从当前分支的已开启 PR自动推导通过gh pr view读取 PR URL 与baseRefName从 PR URL 解析出 base 仓库owner/repo与本地git remote -v匹配不假设是origin——fork 场景通常 base 是upstream直接 clone 场景则是origin产出形如upstream/master、upstream/2.x、origin/main的基准。当分支没有关联 PR或gh未认证时BASE_REF为空此时必须显式指定否则make会报错BASE_REF is not set$ make ci BASE_REFupstream/master同时需要uv提供uvx与已通过gh auth status认证的 GitHub CLI。可以先运行make help查看当前检测到的BASE_REF。六、总结与最佳实践综合原文档与源码Milvus 测试体系的使用要点可归纳为E2E 测试是环境密集型流程先满足 tests/README.md 中的 OS/硬件/软件最低要求Docker、Compose、jq、kubectl、helm、kind再运行 e2e-k8s.sh开发调试阶段可善用--skip-build、--skip-install、--skip-test等参数只跑感兴趣的阶段用--manual在测试结束后保留集群便于人工排查测试真正的执行者是 pytest无论是 e2e.sh 的 Docker 容器方式-n 6并行、port-forward转发还是 ci_e2e.sh 的直接方式服务名访问、--minio_host最终都落到 tests/python_client 等套件上Python 质量管控与 CI 强对齐不要对全量文件跑 ruff应使用 tests/Makefile 的make ci自动检测BASE_REF或在无 PR 时显式传入基准分支从而只检查本次变更文件配置即文档ruff 的规则选择与例外都带注释说明意图tests/ruff.toml 本身即是团队代码风格约定的最佳注脚。遵循以上流程你就可以在本地复现 Milvus 官方的 E2E 测试与 Python lint CI 行为让每一次提交在进入 CI 前就获得与线上一致的质量保障。【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表