基于 Docker 快速部署多需求 Spark 自动化测试环境-2

look_w

我们使用 docker-compose 启动 container 来保证整个 Spark Cluster 工作为一个整体，其主要使用文件为                docker-compose.yml，如图 6 所示。图中还可以添加其他节点，本处为了简化只使用 namenode 一个节点。
图 6.                    docker-compose.yml 片段
Shell 脚本创建 Spark Cluster 镜像以及启动 container 的命令如图 7 所示，$spark_version                和$java_version 来决定切换到对应的 Spark 文件夹进行某个版本的创建，使用"docker build –t spark-2.1.1                ."命令创建 spark-2.1.1 的镜像，执行"docker-compose up -d"用于在后台启动 spark-2.1.1 的                container。
图 7. Spark                    Cluster 镜像和启动脚本Test                ClientClient 端只需要启动一个系统为 Linux、带有所需软件的 Container，所以与 Server 端相比 Client 端的 Docker                脚本要简单的多，只需要一个 Dockerfile 文件用于创建 Client 镜像即可，针对各种 Spark 版本的 Dockerfile                文件按照"dockerfile-$spark_version-$java_version"的方式命名存放，执行时根据 Spark                版本信息将对应的文件拷贝成 dockerfile 的文件来创建镜像，文件内容包括安装 JDK、Scala、Spark、Ant 等。此处仍然以                Spark-2.1.1 为例，如图 8 所示，在此脚本中我们下载安装了 scala-2.11.8、spark-2.1.1-bin-hadoop2.7                以及 Ant，并且配置了部分所需要的环境变量。
图 8. Client                    Dockerfile 脚本
Client 端镜像的创建命令为"docker build -t client:v1 ."，为了使得 Client 端和 Server                端的通信更加通畅可以通过在上节 docker-compose.yml 中加入 Client 。如图 9 所示，client1 表示我们只启动一个                Client 端，没有并行。如果需要启动两个 Client 端并行，在脚本后继续添加 client2 对应代码即可，与 client1                类似，client 数目的控制由 shell 脚本通过 model 信息确定。
图 9.                    添加 client 的 docker-compose.yml
在 Spark Cluster 和 Client 镜像创建完成后，通过"docker-compose up -d"启动对应的                Container，Container 运行情况如图 10 所示。
图 10.                    namenode 和 client container
Test环境部署完毕后接下来就是要利用代码进行实际的测试，即 Test 阶段。
Test Configuration 主要是利用 Jenkins 上指定的配置信息对代码进行特定的配置，比如通过 wget 命令从远端下载                Jenkins 上所指定的 build 版本，在此 build 上对代码进行编译等。本机上通过 Git                维护一套代码，并且进行实时更新以获取最新代码。如上节图 10 所示 Client 启动时已通过 volumes 命令将本机的 dockerShare                文件夹共享进 Client 的 docker container 内部，以便于在 docker 内部进行编译测试。
Test 和 Report 为测试的主题阶段，依据代码进行编译测试和报告生成，这一阶段是通过 Apache Ant 实现的，我们先来看一下 Ant                的构建文件 build.xml。build.xml 的内容主要包括以下几部分：代码编译所依赖的 jar 包、编译命令、测试命令、创建 report                命令。
如图 11 所示，"build"指定了编译依赖于"clean，prebuild"，以及要编译文件的目录和文件后缀（.scala                文件）。"run"指定了要执行的文件即实际测试的文件（.class 文件），"showoutput"指定是否输出所有的 log                日志，"printsummary"指定是否输出每个文件执行完毕后的总结（即总共多少个                case，成功失败数目各为多少），"haltonfailure"指定是否遇到错误就停止，"include name="用于控制要测试的 scope                和模块（分别从 buildScope.prop 和 model.props 中获取），如此处 scope 为"MiniSmoke"，模块为                aa，新增一个模块则新加一行"include name="，可通过 Shell                控制。"report"指定利用测试完毕后所生成的所有名称为"TEST-*.xml"的文件生成 report。
图 11. build.xml                    片段
编译、测试、Report 阶段依次执行命令为"ant build"、"ant run"和"ant report"，测试并生成 report                之后将生成的 report 文件全部放入 Apache Tomcat 特定目录中并且启动 Tomcat，即可通过 Tomcat 的端口访问                report 内容。为了完全实现自动化，我们将此访问链接通过邮件系统发送到指定的邮箱中，可以通过 Linux 系统下的 sendmail                功能发送，也可以通过 Jenkins 的 mail 功能发送，即流程中的 Mail Notification 阶段。
如图 12 所示，邮件所收到的 report 链接是以"ip:端口/目录/build 号_scope/index.xml"的样式存在，Tomcat                默认端口是 8080，可以自行修改（apache-tomcat-7.0.77/conf/server.xml 中），本系统中我们改成了                8888，build 号_scope 保证了多个 report 并存互不影响从而使得我们可以同时管理很多历史 report 以便于后续查看。
图 12. report                    页面
总结基于 Docker 的环境部署及测试涉及大量细节，如各个软件的安装配置、整个系统各个部分是如何通过 shell                脚本一一串联起来以完成整个流程、report                页面上各种信息的显示、代码编译出错后停止后续流程自动发送邮件将错误信息通知维护人员等等，由于内容过于繁琐且文章篇幅有限在此不能一一介绍，在实际环境部署测试过程中大家可以具体体会。文中所涉及的软件技术均为当今业界比较流行的技术，参考资料也相对较多，网络或官网上均可以查找到相关帮助，有兴趣的可以做进一步深入研究。