一、背景介绍
有赞 PaaS 团队自17年7月份开始投入测试资源，测试人员的加入意味着与测试相关的一系列东西产生，比如测试环境、测试工程、测试流程等等，这次分享的内容主要与测试环境有关，刚开始我们把测试环境部署在虚拟机上，从18年7月份开始，我们决定把测试环境从虚拟机迁移到 K8S 上，做这个决定主要出于以下几个方面考虑。
1 公司持续交付系统不支持 PaaS 产品
目前公司的持续交付系统只支持业务产品，不支持 PaaS 产品，由于 PaaS 产品形态多样化、开发语言多样化、部署复杂、小众等原因，持续交付系统暂时也不太可能会支持，所以 PaaS 产品的测试环境需要测试人员自己搭建。
2 成本问题
2.1 资源成本
有赞 PaaS 产品有15+，包括 RDS、KVDS、NSQ、ES、统一接入接出、服务治理、定时任务等等，每个产品又由多个组件构成，加上大大小小组件大概有40+，像 RDS 一个产品就有9个组件，部署一个最简单的集成测试环境需要8台机器。如果把每一个组件部署在 VM 里面，至少需要40多台机器，但是这样的部署方式并不能满足我们的测试场景，我们的产品大多属于分布式系统，考虑到多节点、主备、双机房等等，需要的 VM 可能在70?100之间。需要的机器越多意味着公司花更多的钱，可能有人会说一台虚拟机可以部署多个组件，但是这样会导致资源管理紊乱，测试之间相互干扰。
引入 K8S 后，只需要一个 K8S 集群就可以满足所有 PaaS 产品的部署，产品与产品之间通过 namespace 隔离，组件与组件之间通过 deployment 隔离，相互不干扰，而且升级和扩容也很方便。
2.2 部署成本
使用 VM 做应用部署需要在 jenkins job 里面写大量的 shell 脚本，先在 slave 机器上拉代码、编译、打包，然后把二进制包传到需要部署的机器上，这里会存在两个问题，一是需要把 slave 与所有的应用部署机器打通 ssh 免密通道，如果有100机器，就需要做100次公钥拷贝，更改权限，假如哪天 slave 机器变了或者公钥变更了，又得重新打通通道。二是 shell 脚本不便于维护，shell 脚本并没有做持久化存储，如果 job 被谁给删掉了，那么又需要重新编写,工作量会变大。
引入 K8S 后，编译、打包、部署的脚本都编写在 Dockerfile 里面，Dockerfile 同源码保存在 gitlab 上，不用担心丢失问题，维护起来也很方便。
3 顺势而为
云计算飞速发展，Docker 技术突飞猛进，kubernetes 大势所趋，各大公司都在玩 K8S，PaaS 测试人员需要紧跟时代的步伐。同时 Service Mesh 技术正在悄然兴起，PaaS 的服务化产品后期也会在 K8S 中测试......
二、整体架构
我们的目标是要解决持续集成和持续测试快速、低成本、自动化的问题，整个架构由 Gitlab + Jenkins + Harbor + Kubernetes 集成。
Gitlab 是公司存储代码的仓库，在这个架构中，我们在应用工程里引入了 Dokcerfile，用来定义构建镜像、启动应用的脚本。
Jenkins 是持续集成工具，在这个架构中主要用来从 Gitlab 拉取源码，然后打成镜像推送到 Harbor。
Harbor 是公司的镜像仓库，用来存储打好的镜像。
Kubernetes 是一个容器编排引擎，在这里是替代虚拟机，部署应用的地方。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
