Docker容器化部署LoadRunner负载生成器，是实现按需创建、快速扩展、资源隔离和动态回收的现代化弹性压测体系的重要方案。能彻底改变传统根据物理机/虚拟机的笨重、静态的压测方式。
一、架构设计和优势
传统LoadRunner部署中，负载生成器（Load Generator, LG）是静态的，而容器化方案的重要是将每个LG及其依赖封装为一个轻量级、不可变的Docker容器。通过容器编排平台（如Kubernetes）进行动态管理，实现真正的弹性。
相比传统部署方式的四大优势：
极致弹性和速度：秒级启动数十上百个负载生成器，压测结束后立即销毁，资源零闲置。
环境一致：镜像封装了操作系统、依赖库、LG二进制文件，彻底杜绝“环境差别”导致的脚本执行问题。
资源利用率高：单台物理机可运行多个LG容器，根据脚本需求（如VUser内存占用）灵活分配CPU/内存资源限制。
版本可追溯：LG镜像版本和测试脚本、场景版本绑定，保证任何历史压测均可准确复现。
二、创建LoadRunner负载生成器Docker镜像
这是最重点的步骤。由于LoadRunner是商业软件，其安装介质需你自行准备。
1. 准备文件
创建一个创建目录，包含以下文件：
loadrunner-docker/ Dockerfile install.sh response.ini hp_loadrunner_2024_installer.bin # LoadRunner安装程序（需自行获取） license.dat # LoadRunner许可证文件2. 创建自动安装响应文件 (response.ini)
用于静默安装，避免交互。
[LGInstall] ; 安装方式： 仅安装负载生成器组件 InstallType=LG_ONLY ; 安装途径 INSTALLDIR=/opt/HP/LoadRunner ; 接受许可协议 ACCEPT_LICENSE_AGREEMENT=YES3. 创建辅助安装脚本 (install.sh)
处理安装过程中的依赖和配置。
#!/bin/bash set -e echo "正在安装必要的依赖库..." # 根据基础镜像不同调整包管理器，这里以apt为例 apt-get update && apt-get install -y --no-install-recommends \ lib32z1 libc6-i386 libxext6 libxrender1 libxtst6 \ libgtk2.0-0 libcanberra-gtk-module \ && rm -rf /var/lib/apt/lists/* echo "正在安装LoadRunner负载生成器..." # 使安装程序可执行并静默安装 chmod +x /tmp/hp_loadrunner_2024_installer.bin /tmp/hp_loadrunner_2024_installer.bin -i silent -f /tmp/response.ini echo "安装完成，清理临时文件..." rm -f /tmp/hp_loadrunner_2024_installer.bin /tmp/response.ini echo "配置运行环境..." # 设置必要的环境变量 echo 'export PATH=$PATH:/opt/HP/LoadRunner/bin' >> /etc/profile echo 'export LD_LIBRARY_PATH=/opt/HP/LoadRunner/bin:/opt/HP/LoadRunner/lib:$LD_LIBRARY_PATH' >> /etc/profile文章来源：卓码软件测评
精彩推荐：点击蓝字即可
▲软件负载测试▲API自动化测试▲软件测试▲第三方软件测试▲软件性能测试▲软件测试机构
4. 编写Dockerfile
# .dockerfile # 使用一个较新的、轻量级Linux发行版作为基础 FROM ubuntu:22.04 # 设置工作目录 WORKDIR /tmp # 复制安装文件到镜像中 COPY hp_loadrunner_2024_installer.bin . COPY response.ini . COPY install.sh . COPY license.dat /opt/HP/LoadRunner/license.dat # 执行安装 RUN chmod +x install.sh && ./install.sh # 默认暴露LoadRunner Agent端口（一般为54345、54346等，请根据实际版本确定） EXPOSE 54345 54346 # 配置容器健康检查，确定Agent进程是不是存活 HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \ CMD pgrep -f m_agent_daemon || exit 1 # 设置容器启动时自动运行LoadRunner Agent进程 CMD ["/opt/HP/LoadRunner/bin/m_agent_daemon"]5. 创建镜像
# 在build目录下执行 docker build -t loadrunner-lg:2024.0.1 . # 运行一个测试容器 docker run -d --name test-lg --hostname lg-test-01 loadrunner-lg:2024.0.1 # 查看日志和状态 docker logs test-lg docker inspect --format='{{.State.Health.Status}}' test-lg三、配置容器化负载生成器和Controller的连接
LoadRunner Controller需要和容器内的Agent通信。这里有两种主流网络方式：
方式：使用Host网络（最简单适合单机测试）
# 容器直接使用宿主机网络栈，Agent端口直接暴露在宿主机上 docker run -d \ --network host \ # 重点参数 --name lg1 \ loadrunner-lg:2024.0.1优点：Controller像连接另一台物理机一样，使用宿主机IP即可连接。
缺点：端口冲突风险，且容器网络未隔离。
方式：使用桥接网络 + 端口映射（推荐通用）
# 将容器内部端口映射到宿主机随机或指定端口 docker run -d \ -p 54345:54345 \ -p 54346:54346 \ --name lg2 \ loadrunner-lg:2024.0.1此时，Controller需要连接宿主机的IP和映射后的端口。
方式：在K8s中部署并使用Service暴露
创建Kubernetes Deployment和Service YAML文件：
# loadrunner-lg-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: loadrunner-lg spec: replicas: 3 # 初始启动3个LG Pod selector: matchLabels: app: loadrunner-lg template: metadata: labels: app: loadrunner-lg spec: containers: - name: lg image: your-registry/loadrunner-lg:2024.0.1 ports: - containerPort: 54345 - containerPort: 54346 resources: limits: memory: "2Gi" cpu: "1" requests: memory: "1Gi" cpu: "0.5" --- # loadrunner-lg-service.yaml apiVersion: v1 kind: Service metadata: name: loadrunner-lg-service spec: selector: app: loadrunner-lg ports: - name: agent-port port: 54345 # Service端口 targetPort: 54345 # 容器端口 type: NodePort # 或LoadBalancer，便于Controller从集群外访问四、弹性压测动态扩缩容
根据压测场景需求，动态调整负载生成器数量。
1. 根据Kubernetes HPA的简单弹性（根据CPU/内存）
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: loadrunner-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: loadrunner-lg minReplicas: 1 maxReplicas: 50 # 最大可自动扩展到50个Pod metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # 当平均CPU利用率超过70%时扩容2. 根据自定义标准的智能弹性
更合理的思路是根据虚拟用户（VUser）总数或队列长度来扩缩容。这需要：
一个监控服务，从Controller或测试脚本收集当前运行的VUser数。
将自定义标准暴露给K8s Metrics Server。
配置HPA根据该标准进行伸缩。
3. 和CI/CD和压测平台集成的全自动化流程
#!/bin/bash # 示例：在Jenkins Pipeline或GitLab CI中运行压测 stage('性能测试') { steps { script { // 1. 根据本次压测规模，计算需要的LG数量（如每5000VUser需1个LG） def neededReplicas = calculateReplicas(params.VUSER_COUNT) // 2. 更新K8s Deployment的副本数，触发扩容 sh "kubectl scale deployment loadrunner-lg --replicas=${neededReplicas}" // 3. 等待所有LG Pod就绪 sh "kubectl wait --for=condition=ready pod -l app=loadrunner-lg --timeout=300s" // 4. 获取所有LG Pod的IP地址，动态生成Controller的负载生成器列表文件 def lgIps = sh(script: "kubectl get pods -l app=loadrunner-lg -o jsonpath='{.items[*].status.podIP}'", returnStdout: true).trim() generateControllerConfig(lgIps) // 5. 启动Controller，运行压测情形 sh "start_load_test.scenario" // 6. 压测结束，清理：缩容到0，以释放资源 sh "kubectl scale deployment loadrunner-lg --replicas=0" } } }五、生产环境优化
许可证管理：LoadRunner按VUser或LG数量收费。在弹性部署中，必须保证动态创建的LG总数不超过许可证限制。可在启动脚本中加入许可证检查思路。
网络性能：容器网络开销可能影响负载生成器性能。对于超高并发（十万级VUser）压测，考虑使用性能优化的CNI插件（如Calico的IPIP方式）或将LG部署在专用性能节点上。
数据持久化：压测结果和日志需要持久化存储。配置容器将%LoadRunner_Home%\results目录挂载到持久卷（PVC）或网络存储（NFS）上。
镜像安全：私有化部署镜像仓库，定期扫描镜像漏洞。在镜像中仅安装最小必需组件，非root用户运行进程。
混合云部署：为模拟真实全球用户，可在不同地域的云服务商K8s集群中部署LG容器，通过一个中心Controller协调，进行全球化分布式压测。
将LoadRunner负载生成器Docker化，并集成到K8s编排体系中，创建了一个声明式、可编程、弹性伸缩的现代化压测基础设施。
从技术实施途径分三步走：
容器化：先成功创建LG镜像，并在单机Docker中证实和Controller的连接。
编排化：将容器部署到K8s，实现基本的副本控制和网络暴露。
自动化：将压测情形的编排、执行、扩缩容和CI/CD管道或内部压测平台集成，实现一键触发、全自动化的弹性压测。
