核心内容摘要
AIGC时代：LiuJuan20260223Zimage内容生成实战案例
Docker容器化部署LoadRunner负载生成器是实现按需创建、快速扩展、资源隔离和动态回收的现代化弹性压测体系的重要方案。
能彻底改变传统根据物理机/虚拟机的笨重、静态的压测方式。
架构设计和优势传统LoadRunner部署中负载生成器Load Generator, LG是静态的而容器化方案的重要是将每个LG及其依赖封装为一个轻量级、不可变的Docker容器。
通过容器编排平台如Kubernetes进行动态管理实现真正的弹性。
相比传统部署方式的四大优势极致弹性和速度秒级启动数十上百个负载生成器压测结束后立即销毁资源零闲置。
环境一致镜像封装了操作系统、依赖库、LG二进制文件彻底杜绝“环境差别”导致的脚本执行问题。
资源利用率高单台物理机可运行多个LG容器根据脚本需求如VUser内存占用灵活分配CPU/内存资源限制。
版本可追溯LG镜像版本和测试脚本、场景版本绑定保证任何历史压测均可准确复现。
创建LoadRunner负载生成器Docker镜像这是最重点的步骤。
由于LoadRunner是商业软件其安装介质需你自行准备。
准备文件创建一个创建目录包含以下文件loadrunner-docker/ Dockerfile install.sh response.ini hp_loadrunner_2024_installer.bin # LoadRunner安装程序需自行获取 license.dat # LoadRunner许可证文件
创建自动安装响应文件 (response.ini)用于静默安装避免交互。
[LGInstall] ; 安装方式 仅安装负载生成器组件 InstallTypeLG_ONLY ; 安装途径 INSTALLDIR/opt/HP/LoadRunner ; 接受许可协议 ACCEPT_LICENSE_AGREEMENTYES
创建辅助安装脚本 (install.sh)处理安装过程中的依赖和配置。
#!/bin/bash set -e echo 正在安装必要的依赖库... # 根据基础镜像不同调整包管理器这里以apt为例 apt-get update apt-get install -y --no-install-recommends \ lib32z1 libc6-i386 libxext6 libxrender1 libxtst6 \ libgtk
2.
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自动化测试▲软件测试▲第三方软件测试▲软件性能测试▲软件测试机构
编写Dockerfile# .dockerfile # 使用一个较新的、轻量级Linux发行版作为基础 FROM ubuntu:
2
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端口一般为
54346等请根据实际版本确定 EXPOSE 54345 54346 # 配置容器健康检查确定Agent进程是不是存活 HEALTHCHECK --interval30s --timeout10s --start-period60s --retries3 \ CMD pgrep -f m_agent_daemon || exit 1 # 设置容器启动时自动运行LoadRunner Agent进程 CMD [/opt/HP/LoadRunner/bin/m_agent_daemon]
创建镜像# 在build目录下执行 docker build -t loadrunner-lg:
2024.
1 . # 运行一个测试容器 docker run -d --name test-lg --hostname lg-test-01 loadrunner-lg:
2024.
1 # 查看日志和状态 docker logs test-lg docker inspect --format test-lg
配置容器化负载生成器和Controller的连接LoadRunner Controller需要和容器内的Agent通信。
这里有两种主流网络方式方式使用Host网络最简单适合单机测试# 容器直接使用宿主机网络栈Agent端口直接暴露在宿主机上 docker run -d \ --network host \ # 重点参数 --name lg1 \ loadrunner-lg:
2024.
1优点Controller像连接另一台物理机一样使用宿主机IP即可连接。
缺点端口冲突风险且容器网络未隔离。
方式使用桥接网络 端口映射推荐通用# 将容器内部端口映射到宿主机随机或指定端口 docker run -d \ -p 54345:54345 \ -p 54346:54346 \ --name lg2 \ loadrunner-lg:
2024.
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.
1 ports: - containerPort: 54345 - containerPort: 54346 resources: limits: memory: 2Gi cpu: 1 requests: memory: 1Gi cpu:
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/内存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%时扩容
根据自定义标准的智能弹性更合理的思路是根据虚拟用户VUser总数或队列长度来扩缩容。
这需要一个监控服务从Controller或测试脚本收集当前运行的VUser数。
将自定义标准暴露给K8s Metrics Server。
配置HPA根据该标准进行伸缩。
和CI/CD和压测平台集成的全自动化流程#!/bin/bash # 示例在Jenkins Pipeline或GitLab CI中运行压测 stage(性能测试) { steps { script { //
根据本次压测规模计算需要的LG数量如每5000VUser需1个LG def neededReplicas calculateReplicas(params.VUSER_COUNT) //
更新K8s Deployment的副本数触发扩容 sh kubectl scale deployment loadrunner-lg --replicas${neededReplicas} //
等待所有LG Pod就绪 sh kubectl wait --forconditionready pod -l apploadrunner-lg --timeout300s //
获取所有LG Pod的IP地址动态生成Controller的负载生成器列表文件 def lgIps sh(script: kubectl get pods -l apploadrunner-lg -o jsonpath{.items[*].status.podIP}, returnStdout: true).trim() generateControllerConfig(lgIps) //
启动Controller运行压测情形 sh start_load_test.scenario //
压测结束清理缩容到0以释放资源 sh kubectl scale deployment loadrunner-lg --replicas0 } } }
生产环境优化许可证管理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管道或内部压测平台集成实现一键触发、全自动化的弹性压测。