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)

用于静默安装，避免交互。

ini

[LGInstall]

; 安装方式： 仅安装负载生成器组件

InstallType=LG_ONLY

; 安装途径

INSTALLDIR=/opt/HP/LoadRunner

; 接受许可协议

ACCEPT_LICENSE_AGREEMENT=YES

3. 创建辅助安装脚本 (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

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. 创建镜像

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通信。这里有两种主流网络方式：

方式A：使用Host网络（最简单，适合单机测试）

bash

# 容器直接使用宿主机网络栈，Agent端口直接暴露在宿主机上

docker run -d \

  --network host \           # 重点参数

  --name lg1 \

  loadrunner-lg:2024.0.1

优点：Controller像连接另一台物理机一样，使用宿主机IP即可连接。

缺点：端口冲突风险，且容器网络未隔离。

方式B：使用桥接网络 + 端口映射（推荐，更通用）

bash

# 将容器内部端口映射到宿主机随机或指定端口

docker run -d \

  -p 54345:54345 \

  -p 54346:54346 \

  --name lg2 \

  loadrunner-lg:2024.0.1

此时，Controller需要连接宿主机的IP和映射后的端口。

方式C：在K8s中部署并使用Service暴露

创建Kubernetes Deployment和Service YAML文件：

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/内存）

yaml

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管道或内部压测平台集成，实现一键触发、全自动化的弹性压测。