原创:陈斌张少华
本期导读
为提升部署效率持续集成测试环境从胖docker向深度容器化的改进；架构采用Rancher+Harbor，网络采用pipework为容器配置固定的IP地址；
一、物理架构
在测试环境建设过程中由于模块数量快速增加，为了提高部署效率和稳定性我们在容器化的基础上进行了深度容器化的探索，深度容器化采用了Rancher+Harbor的架构，该架构有非常优良的性能，非常适合以pod为单位进行子系统级别测试环境建设。
（1）网络配置
如上图所示，每一个Node节点对应现在的一套测试环境，拥有独立的ip。
其实现原理为Node节点是Dind生成容器，创建后使用pipework为容器配置固定的IP地址，之后可在Node中启动多个Pod，分享使用Node的IP地址。
（2）对比Cattle和K8S使用过程中的差异
由于我们测试需求的特殊性，目前Rancher上面的服务群并不需要频繁的做升级，而是会频繁的创建和释放。Cattle的稳定性和易用性要优于K8S，但是K8S提供了更加强大的周边功能包括资源管理、监控、配置管理等。
Cattle：
（1）多服务应用，每个项目都作为独立的服务受Rancher管理，升级比较方便。缺点是需要以应用（stack）为单位进行扩展和调度，因为我们其实是把一个应用里的多个容器包在一起对外提供服务。
扩展方式：stack-copy、或者通过模板创建（效率略低于主从容器方式）。
（2）主从容器，一个容器作为主容器，添加多个从容器，耦合关系更紧密，优点是以服务（service）为单位进行扩展和调度。
扩展方式：由于资源对象的编号，直接scale即可。
缺点：
当需要对该服务做升级时，会重启所有容器，从容器越多，升级越慢。因为升级的最小操作单元就是服务。
当在服务中使用负载均衡时，而该服务又拥有从服务的时候，你需要使用主服务作为负载均衡器的目标。从服务不能成为目标。
从服务不能使用links/external_links来创建服务别名。
内部访问：Cattle提供了内部DNS解析，直接以容器名访问。
K8S:
多容器Pod
以Pod为单位进行调度，一个Pod里面启动多个容器，类似于Cattle的主从容器方式，但是差异在于网络。
扩展方式：scale（效率不高）。
内部访问：Pod内的所有容器共享网络namespace，其实就是都通过-net=container（Pod创建时有一个sleep容器）共享了同一个网络，所以端口不能冲突，容器直接以localhost（或者.0.0.1）访问。
扩展效率低下。
容器之间的相互通信不是十分稳定。
优点：有一系列的强大的利于编排的功能，比如initContainer、HPA、PV等都是非常好的特性。
（3）CI工作流
（4）数据库组件容器化
Mysql容器化
我们测试环境使用的mysql版本是5.6.41，所以我们制作mysql-5.6.41的镜像，制作过程比较简单
（1）拉取官方镜像启动，环境变量必须要设置。
dockerrun-p:--namemysql-eMYSQL_ROOT_PASSWORD=root-ddocker.io/mysql:5.6.41
（2）利用dockercp将我们的配置文件复制到该容器中
dockercp${PWD}/my.cnfmysql:/etc/mysql/
（3）利用docker