为什么要容器化
作为测试人员，测试系统第一步，就是有个已经部署好的系统，能正常使用。那么如果没有部署好的系统或者没有指定版本的系统，你会怎么做呢？下面以如下场景来进行说明：
场景一：部署与移植
这里的0表示，当前环境是全新的，操作系统是最小化安装。在这样的场景中，这样的环境在部署系统中通常会遇到下面两种应用程序
全新的应用程序，第一次安装到该环境
这样应用程序，遇到这样的环境是最好的配对，只要安装包提供的完毕，系统部署是一个挺顺利的过程，但一旦系统部署失败，要把环境回退到0的状态，如果是实体机这个实体机是比较大的，如果是虚拟机只需要返回到0的快照重新部署就好，那如果是使用容器呢？如果是使用容器技术，只需要删除当前镜像，重新拉取基础镜像部署就好。
但这里要说明，不是所有的应用都适合容器化，如果对内核有依赖，不建议进行容器化。
存在多个版本的应用程序，移植到该环境
如果遇到这样的场景，以虚拟机和实体机为例，你们在对这样的系统，你们是如何进行移植？是类似与升级打怪还是直接复制应用系统目录，然后缺什么补什么呢？
这样的场景，为确保系统的功能正确性，需要进行全面分析，和全面的系统测试，来保证移植过来的系统能正常稳定的对外提供服务。
那如果系统是使用容器化，那只需要在当前拉取最新版本的镜像，运行起来就行，不需要考虑移植之后环境影响，因为系统运行环境由容器本身提供。
场景二：测试环境不充足
应用部署如果有实体机肯定是首选，一套系统独占一套环境，避免环境污染。那现实往往是多项目并行，不可能一个项目独占一套资源，往往是多项目并行，那在多项目并行测试环境不足的情况，但项目都需要上线这个时候会不会头秃？在没使用容器化的时候，这样的情况，只能排优先级，只能先满足高优先的，这时候就有一个项目要刮起。
对应用系统容器化，可以在之前一套测试环境上，运行多套应用系统，让项目可以并行测试，增加项目的并行度。但这就要确保，每一套系统都要维护自己系统本身的镜像。
容器可视化
通过上诉两个场景，能发现容器两大核心优势：
- 在系统移植与部署方面配合脚本能实现一键部署及运行，减少环境依赖
- 不同系统之间拥有自身的镜像，隔绝环境交叉感染，增加项目并行度，硬件环境最大化。
基于上述优势，我们开始了探索容器化技术，万事开头难，这里说下容器化道路上遇到的“妖魔鬼怪”。
如何对已有系统构建镜像?
docker理论知识具备之后，那第一步就是构建系统镜像。那如何选取时候应用系统的镜像呢？在内网中没有基础镜像，但外网的资源与当前应用操作系统版本不一致，那要构建与应用操作系统版本一致的镜像呢？当时的想法是，那有没有一种方法把已有的操作系统打包成一个镜像呢？
通过可以把当前系统打包成镜像：
tar -cvpf /tmp/base.tar --directory=/ --exclude=proc --exclude=sys --exclude=dev --exclude=run --exclude=boot .cat base.tar | docker import --centos:7TIPS：个人推荐使用vm最小化安装操作系统，然后再使用上述命令打包，这样可以使镜像尽可能小。
多项目并行如何管理容器?
早期没有规范容器使用规约，项目成员都可以在宿主机上直接使用docker run就拉取自己容器，使用之后，不进行删除，长期在后台运行，同时成员都是root权限，如果成员误删容器，会影响其他项目测试，那有没有一个好的软件可以可视化管理当前项目容器呢？
基于此问题，我们调研然后可行性研究，选择了Portainer作为容器可视化管理，每个用户只能看到自己创建的容器，管理员可以看到当前系统所有容器。
Portainer可以通过界面创建容器，也可以使用docker-compose模块拉取一套项目环境，当前项目组，维护了对应的yaml文件，用于管理容器及容器的网络。当前项目使用portainer纳入了两个docker服务节点，后续规划纳入三台节点，用于项目安装部署测试。
小结
对容器可视化，基本满足当前团队在项目中的使用。后续阶段学习了K8S，并使用部门rancher对系统web进行容器化，通过应用商店可以直接拉取一套web服务，对应服务也会相应启动，但rancher应用商店对当前项目成员作用不是很大，应为k8s对应用高度封装，但系统测试会涉及安装、回退测试，因此当前项目团队更偏向于使用Portainer。
个人喜欢一句话：“能落地的技术才是好技术”，至于为什么能坚持容器化主要有以下几点:
其一、能落地并能给团队赋能，提升测试效率，提升团队技术；
其二、容器化为以后“一键测试”提供技术支撑；
其三、容器化属于当前主流技术，能增加自身核心竞争力；
其四、项目团队对系统不同使用场景，在解决各种场景的过程中会遇到各种问题，为解决这些问题，需要不停的学习实验，倒逼自己进步。
