Docker容器化部署LoadRunner负载生成器，是实现按需创建、快速扩展、资源隔离和动态回收的现代化弹性压测体系的重要方案。能彻底改变传统根据物理机/虚拟机的笨重、静态的压测方式。
一、架构设计和优势
传统LoadRunner部署中，负载生成器（Load Generator, LG）是静态的，而容器化方案的重要是将每个LG及其依赖封装为一个轻量级、不可变的Docker容器。通过容器编排平台（如Kubernetes）进行动态管理，实现真正的弹性。
相比传统部署方式的四大优势：
极致弹性和速度：秒级启动数十上百个负载生成器，压测结束后立即销毁，资源零闲置。
环境一致：镜像封装了操作系统、依赖库、LG二进制文件，彻底杜绝"环境差别"导致的脚本执行问题。
资源利用率高：单台物理机可运行多个LG容器，根据脚本需求（如VUser内存占用）灵活分配CPU/内存资源限制。
版本可追溯：LG镜像版本和测试脚本、场景版本绑定，保证任何历史压测均可准确复现。
二、创建LoadRunner负载生成器Docker镜像
这是最重点的步骤。由于LoadRunner是商业软件，其安装介质需你自行准备。
1. 准备文件
创建一个创建目录，包含以下文件：
bash
loadrunner-docker/
Dockerfile
install.sh
response.ini
hp_loadrunner_2024_installer.bin # LoadRunner安装程序（需自行获取）
license.dat # LoadRunner许可证文件- 创建自动安装响应文件 (response.ini)
用于静默安装，避免交互。
bash
[LGInstall]
; 安装方式： 仅安装负载生成器组件
InstallType=LG_ONLY
; 安装途径
INSTALLDIR=/opt/HP/LoadRunner
; 接受许可协议
ACCEPT_LICENSE_AGREEMENT=YES3. 创建辅助安装脚本 (install.sh)
处理安装过程中的依赖和配置。
bash
#!/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
bash
# .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"]- 创建镜像
bash
# 在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网络（最简单适合单机测试）
bash
# 容器直接使用宿主机网络栈，Agent端口直接暴露在宿主机上
docker run -d \
--network host \ # 重点参数
--name lg1 \
loadrunner-lg:2024.0.1优点：Controller像连接另一台物理机一样，使用宿主机IP即可连接。
缺点：端口冲突风险，且容器网络未隔离。
方式：使用桥接网络 + 端口映射（推荐通用）
bash
# 将容器内部端口映射到宿主机随机或指定端口
docker run -d \
-p 54345:54345 \
-p 54346:54346 \
--name lg2 \
loadrunner-lg:2024.0.1此时，Controller需要连接宿主机的IP和映射后的端口。
方式：在K8s中部署并使用Service暴露
创建Kubernetes Deployment和Service YAML文件：
bash
# 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从集群外访问四、弹性压测动态扩缩容
根据压测场景需求，动态调整负载生成器数量。
- 根据Kubernetes HPA的简单弹性（根据CPU/内存）
bash
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和压测平台集成的全自动化流程
bash
#!/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管道或内部压测平台集成，实现一键触发、全自动化的弹性压测。