一个小白的测试环境docker化之路
本文来自网易云社区
作者：叶子
学习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 filestart 启动运行模块
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的资料，在此就不多阐述了，大致过程如下：
创建网桥：在每台云主机上创建docker_gwbridge网桥，注意，必须先创建网桥再创建swarm集群
创建集群：指定一台云主机作为manager，初始化swarm
加入集群：在其他云主机上运行docker swarm join命令，使其加入该swarm集群
创建服务：使用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 swarm mode方式实现了应用模块集群化部署的方式，接下来的目标就是将这些应用模块依赖的其他基础服务拆分出来，如数据库，redis，zookeeper等等，那样子才算完整的一套独立的测试环境。
网易云容器服务为用户提供了无服务器容器，让企业能够快速部署业务，轻松运维服务。
网易云大礼包：https://www.163yun.com/gift
本文来自网易云社区，经作者叶子授权发布。
相关文章：
【推荐】 Lily-一个埋点管理工具
【推荐】 Amazon新一代云端关系数据库Aurora（上）
【推荐】 不再任人欺负！手游安全的进阶之路
