一个小白的测试环境docker化之路

猪小花1号2018-08-31 12:47
作者:叶子

学习docker搭建测试环境断断续续也有三个多月了,希望记录一下这个过程。常言道,总结过去,展望未来嘛~文章浅显,还望各位大神路过轻拍。
按照国际惯例,先说一下背景:
目前我所处的项目组不断扩大和发展,因此质量保障维度也需要不断扩展。然而多种质量保障维度的开展需要多套测试环境的支持,目前项目组里只有一套测试环境,按照传统方法一步步手工搭建测试环境费时费力,有什么方法可以迅速搭建环境呢?当然是近几年大火的docker啦。可是我是docker小白,之前只是简单地看过几篇docker入门的帖子,去官网上按照tutorial敲了一遍命令,但总感觉是纸上谈兵,一到实战环节,依然无从下手。
中国首富王健林说:“先定一个小目标“。我们的项目里面除了java web应用就是java app应用,java web应用说白了就是tomcat么,以前自己手动部署过,看上去不会太难,那就从这个开始,先用docker部署一个项目中的tomcat应用好了。docker方面的知识是零基础,老大推荐了一本书叫《第一本docker书》。
这本书浅显易懂,适合我这个小白,粗粗读完前4章后,我就感觉自己可以上路了。
测试环境的应用模块部署都是在ndp平台上部署的,先简单了解下ndp平台部署web应用的原理,就是将代码从git上拉下来,编译打包好,找一台云主机,这台云主机上安装了jdk和tomcat,然后把打包好的代码放进tomcat里,设置下端口号,启动起来就好了。那如果用docker怎么部署呢?读完docker书就知道,其实一个docker容器就相当于一台云主机,我们的云主机是linux系统,拉一个linux系统的镜像,启动这个镜像的容器后,我在里面装个jdk和tomcat,这不就和我们的云主机环境一模一样了嘛~
到这里思路就清晰多了,第一步先搞个和云主机环境一样的docker容器,网上搜了一下后,发现直接就有现成的tomcat镜像,tomcat本身也依赖jdk,而且也是基于linux环境的,第一步立马就做完了,这速度杠杠滴。那接下来就是拉取代码,编译打包,然后放进去启动就可以了。于是乎,第一个问题就碰到了,代码是有权限的,不是随便就可以拉取的。回想以前在云主机上拉取代码,是在这台云主机上生成一对ssh密钥,然后把公钥上传到git lab上,这样就能获得拉取代码的权限了。都说实践是检验真理的唯一标准,赶紧在刚刚启动的docker容器里试了一把,恩,行得通!可是这才一个docker容器啊,如果我再来几个docker容器,每个容器都要生成一对ssh密钥,然后上传,岂不累死。 怎么办呢?马克思主义哲学说道过,要透过现象看本质,git识别权限的本质是什么?是在于私钥和公钥的匹配!公钥在git服务器上,那我本地只要有对应的私钥就可以了呀,我在创建容器的时候把一个git已有的公钥所匹配的私钥放进去,这样容器就自带git权限了嘛。
代码拉下来以后,下一步就是编译打包,那先研究下ndp平台是怎么部署我们测试环境的web应用的吧。看了一下,在ndp平台上找到了这个web应用的一个build.xml,咦,这不就是ant工具的执行脚本么,仔细一读,果然是个编译打包的脚本,其中关键的步骤是利用mvn clean install进行编译打包的。ok,那在刚刚启动的容器里安装一下ant和maven工具,然后用ant命令执行下这个build.xml,大功告成!
执行完ant命令以后,发现生成了一个compressed的文件夹,里面主要是编译打包后生成的东西,如下图:
那么这些编译打包好的东西应该放在哪里呢?再一次研究一下ndp部署的tomcat应用的目录层级,心里估摸着我把docker容器中的目录层级弄得和ndp一样应该不会有什么问题。经过对比发现,compressed文件内容和测试环境tomcat应用的webroot文件内容是一样的,吼吼~
此外,其他目录层级不一样的地方罗列了一下,大概有如下几个:
大致读了读,tomcat是个脚本文件,用于启动tomcat服务用的,里面调用了./default/tomcat、init-functions和ratatelogs文件,那就把这些需要的文件都拷贝过来,并确保tomcat脚本里所有的调用路径都正确。
另外还需要修改的server.xml,将docBase地址指定为compressed的绝对路径
将两边目录层级弄的一模一样后,就到了见证奇迹的时刻,运行启动命令:
./tomcat start
查看日志发现正常启动,并无异常报错,这真是个好兆头。再用浏览器试试是否能访问成功,看到预期的网页打开了:)至此,第一个用docker方式部署的web应用模块就完成啦
鉴于项目里有多个不同的web模块,它们所依赖的基础环境都一样,因此打算构建一个基础镜像,将所需要的相同的配置文件都放入基础镜像中,然后各自模块的编译打包过程写成一个Dockerfile,这样就不用在容器里手敲命令进行编译打包了,Dockerfile伪代码如下:
FROM tomcat 基础镜像
git clone 代码
COPY build.xml, 配置文件等到容器里指定的路径
RUN build.xml,生成打包文件
COPY 打包文件 TO destination file
start 启动运行模块
web应用搞定后,接下来就是java app模块了。看了一下环境依赖,只需要装个jdk环境就行,然后ndp上同样有java app的构建脚本build.xml,再研究下npd部署的java app的目录结构,该拷贝的拷贝,该修改的修改,照猫画虎弄一遍,也启动成功了。
接下来就是优化下tomcat和java app这两个基础镜像,然后再写写各自模块的Dockerfile就行了
每个模块都有自己的Dockerfile,这样就能迅速构建模块镜像并启动部署了。至此,利用docker部署项目的应用模块就完成了。
感谢上述过程中提供大力帮助的集美貌与才华于一身的婷婷同学~
--------------------
踩过的坑:
1、在执行build.xml脚本进行构建时,遇到类似如下的报错:
原因是所需要的jar包因为在maven远程仓库中无法找到,首先检查一下在docker容器安装maven后,记得要把settings.xml设置成杭研的maven仓库,如果还遇到这样的错误,可能是杭研maven仓库里没有该jar包,或者因为网络等其他问题,无法下载该jar包。基本上通用的jar包都能下载成功,有一些基于模块之间依赖的jar包无法下载到,如果你本地maven仓库里有这些jar包的话,可以拷贝进容器的maven仓库里,或者在容器里拉取相互依赖模块的代码,通过mvm clean install命令将其打包进容器的maven仓库里。
2、在容器里启动应用后,遇到无法连通redis的问题:
代码里填写的redis地址是云主机的私有ip地址,容器所在的宿主机与redis在不同租户下,因此无法通过私有ip进行连通访问,容器的宿主机与redis同属于一个机房,可通过机房ip进行访问,与开发协商将代码里的依赖服务的ip地址都改为机房地址。
3、在docker容器里拷贝git hub的私钥后,执行git clone命令出现以下情况:
这个提示已经比较清楚了,.ssh/id_rsa 这个私钥文件权限 too open,修改私钥的权限:chmod 0600 id_rsa 后即可git clone代码了。
--------------------
然而好景不长,很快我们就发现针对每个应用模块写Dockerfile这种方式的不足,一是构建的镜像太多,每个模块都要构建镜像,然后启动容器,镜像也比较大,非常占空间;二是由于我们项目的特殊性,有些应用模块在构建时需要依赖别的项目的jar,当时为了图省事把依赖的jar直接放入基础镜像了,当依赖的jar发生变化时,我的基础镜像就要重新弄了,所有其他模块的镜像都要重新弄,这可要了命啊。看来此计不是长久之计,还需另谋出路。
经过之前的探索,我们知道,ndp的部署模式是一盏指路明灯,之前就是照着ndp的部署脚本照葫芦画瓢过来的,那ndp平台是怎么解决不同模块之间的打包依赖问题呢?粗粗研究了一下,发现ndp是统一在一个地方打包,然后将打包好的compressed文件分发到别的云主机上进行部署。那按照这个思路,我们也找一台容器进行统一编译打包,然后分发到不同的容器进行部署呗。
如此一来,我们只需要三个基础镜像,一个是用来编译打包的镜像,只需要安装jdk,maven,ant等编译打包工程所依赖的工具,一个是tomcat镜像,一个是java环境镜像,再写一个脚本,伪代码如下:
get compressed file  #对应模块的打包文件
get config file           #对应模块的部署配置文件
start module            #启动运行模块
如何获取对应的打包文件呢? wget 命令可以从远程服务器上下载文件,前提是不同容器之间的网络需要互通。我们可以自己手动创建一个docker网络,然后把不同的容器都手动加入这个网络里,这样所有容器都在同一个网络里,应该就不存在网络不通的问题了。获取部署配置文件我们采用了git pull方式,在git上维护所有模块的部署配置文件。
如此一来,当部署web模块的时候就以tomcat镜像来启动容器并同时运行脚本,部署java app模块的时候就以java app镜像启动容器并同时运行脚本,如此一来就不用给每个模块写Dockerfile制作镜像了,也节省了不少构建镜像的空间。
不过虽然节省了构建镜像的空间,但容器运行的空间还是要提供的。一台云主机的基本配置是4核 CPU,8GB 内存,而项目的模块多达20几个,全部模块放在一台云主机上可吃不消。肯定要搞多台云主机作为一个集群,把容器部署到这个集群中。这时候就要用到容器编排工具了,编排工具负责以下几点:
  • 选择最适合部署容器的机器,比如拥有最多空闲资源的机器
  • 发生机器故障,能自动把故障机器上的容器部署到其它节点。
  • 如果集群添加了新的机器,重新平衡容器的分配情况。
  • 如果容器故障了,重启它。
  • ...
Docker本身内置了容器编排功能,称为docker swarm mode。网上有很多关于docker swarm mode的资料,在此就不多阐述了,大致过程如下:
  1. 创建网桥:在每台云主机上创建docker_gwbridge网桥,注意,必须先创建网桥再创建swarm集群
  2. 创建集群:指定一台云主机作为manager,初始化swarm
  3. 加入集群:在其他云主机上运行docker swarm join命令,使其加入该swarm集群
  4. 创建服务:使用docker service create来创建service,类似docker run 命令,创建的时候可直接运行脚本,执行部署过程
使用docker service create命令创建服务的时候需要指定大量参数,每次都要敲好长的命令,可以用docker compose yaml模板,类似如下:
version: "3.2"
services:
  compile:
    image: dockercloud/hello-world
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.hostname==docker-test
    ports:
      - "8080:8080"
    networks:
      - overlay_net

networks:
  overlay_net:
    driver: overlay
参考文章:《Docker Compose 配置文件详解》
至此,我们解决了编译打包过程中各个模块相互依赖的问题,通过docker swarm mode方式实现了应用模块集群化部署的方式,接下来的目标就是将这些应用模块依赖的其他基础服务拆分出来,如数据库,redis,zookeeper等等,那样子才算完整的一套独立的测试环境。

网易云大礼包:https://www.163yun.com/gift

本文来自网易实践者社区,经作者叶子授权发布。