金玲：大家下午好，我是来自陆金所测试部金玲，大家知道陆金所是做什么的吗？请举手示意一下。有在陆金所投资过的举手示意一下？陆金所是针对用户的个人投资理财平台，开始的时候是针对P2P起家，后来整个业务进行了扩展，包括活期产品、资管产品、私募、银行性结构性存款，保险，还有最近上的帮助大家避免个税的个税年金。我为什么讲这个？这是对我们整个测试环境有很大影响的，在整个业务扩张的时候，对测试环境的压力和对它的调整是什么样的，我们要怎么应对的呢？
金玲
我今天从三个方面给大家分享，首先是传统的环境在互金，第二个寻找适合互金的管理方案，第三我们效果是如何？
我们先回到2016年，2016年对陆金所是一个很大的调整，因为这个时候正好是业务进行迅速扩容的时期，陆金所的应用依赖性和关联趋势越来越复杂，所以当时我们做了一个很大决定--对我们整个架构进行分层分域管理，就是我们当时很有名的“火凤凰”项目这个项目对我们影响很大，我们经历了两年可以看得出来从2016年我们应用子系统个数100个，2018扩展500之多，这么多测试系统如何管理？这是2016年测试框架大家可以看到非常简单，首先是部署中心，部署中心下有10套管理，应该不到10套。每套环境很简单，每一个物理机就是一套环境，一套物理机里面部署着我们LXC虚拟机，每个虚拟机上部署着我们应用，我们称之为子系统，我们当时有一百个应用，那么一套环境里有100个LXC应用，这会带来什么样困难呢？
首先测试人员，测试人员发现测试环境不可用，查了半天原因是什么？上线这个配置在我们这套环境上并没有配置影响了我的测试进度，还有应用假死，测试人员看一个Log时没有进行参数过滤，整个Lxc的内存就爆掉了。还有一个情况同一个接口，昨天测试OK，今天就报了404，原来这套测试该子系统今天被其他的测试人员部署成了其他的版本，所以2016年对我们来讲是非常困难的一年，当时需求特别多环境特别差，10套环境能用的寥寥无几。回到2018年，目前陆金所的测试环境已增长到78套这样环境，如果以当时的老方式管理，没有办法达到的。我们刚刚说了我们进行分层分域，我们进行脚本化，脚本管理本身就是一个很大的问题，另外Lxc需要绑定IP，这么多环境，这么多套应用子系统也是很难管理的，说到IP，对于基础设施服务提供方来讲，他们有两个困难，一个要提供大量IP，第二保证宿主机的稳定性和容量。这些种种问题，最后受到影响就是需求测试不完全，上线风险很大。2016年我们转型的时候，这些问题我们必须要解决。
2016年我们听到三方抱怨，我们需要更加轻便，占用资源更少，资源隔离性更好，方便我们迁移，这个放在一起是什么解决方案呢？就是Docker+K8S，从图中可以看到Docker关注程度，也是2016年进行了迅速增长，我想了解一下在座测试环境进行容器化的是否有同学？这还是不少的，所以容器化Docker优点我不想多说了，Docker几乎就满足我们需求了。这是我们改造后的架构，一个树线一列就是一套环境，就是一套物理机制，这些进行了水平扩展，图中的整个这一套是一套环境，每人环境有独立的DB，独立的缓存，独立的文件系统等，环境与环境之间是完成隔离的。这些虚拟机，是用Vcenter或是陆金所Cloud创建。
还有一些没有进行容器华化的，如Oracle, MySQL, ES等等，这些也是后期容器化的方向，这是我们的一套环境。大家想想刚才两个架构图，从简单架构图已经到水平进行拓展，已经基本满足我们很多的要求了，但是这些够了吗？还有什么问题没有解决？大家是否记得Nginx配置的问题，有做K8S的知道，Nginx配置都是文件,很难进行管理。还有应用增加，新规则增加这也需要管理的，另外我们修改配置以后，如果发现配置有问题我需要回滚，待配置上线后需要全测试环境应用，那应该怎么做？第一，修改所有规则配置文件在一个文件里，第二，做配置版本化。我们要在一个测试环境上应用规则A，比如说WWW.lu.com，规则是XXX，这个模板是之前上线模板a1，模板上进行开发需要修改配置，这个时候版本还是a1模板，但是版本升为1了，再修改，版本变成2，如果发现修改不正确，可以直接回归到前面的任何一个版本，因为所有版本信息都在数据库存储，可以任意跳转和回归。如果在开发时发现有新的模板a2，也可以进行模板切换，这就是我们做配置化管理的一个方案。大家从图中看可以下，这个规则有两个模板，这个打标的部分就是这个规则线上版本，这样我们解决配置管理化，不会出现线上、线下配置的混乱情况。
这是我们BROOD里的配置管理页面，这个配置当前模板是11，版本是1，如果你修改版本就变成了，最新模板是12，没有应用最新模板说明这个模板还没有上线。
我们又解决了一个问题，我们还有一个大问题，如果78套环境人工做是很大的工程，每个环境有300子系统，所以我们必须做自动化。期间，其实我们有一个中间版本，底层Lxc虚拟机，再进行编排，但是还是有问题，问题在于我没有办法进行自动搭建。后面我们使用了Docker+k8s自动搭建。环境自动大件，我们要先解决两个问题：镜像自动创建和任务调度。先看镜像问题，陆金所的镜像分为测试镜像和生产镜像，底层是系统环境，上面是我们应用所依赖的基础服务，比如JDK，JAVA，PHP，再上层是我们开发的war包，或者Zip文件，还有我们配置。再上层只有测试镜像才有的，这个是针对测试环境上要部署的证书， Jacoco，还有sshd等等工具，这是我们镜像结构。
下面看镜像自动打包，搭建环境时候要部署版本，先去私有库看有没有版本，如果有就直接部署，如果没有去打包机自助打包，打包产物进行校验，校验比如说war包是否生成，zip文件是否生成然后处理静态文件。
再往下就是额外资源处理，最后生成一个Docker文件，最后放到私有库里使用。还有一个扫描，看是否有病毒，一般不会有的，因为一般都是内部网络。 这个是我们镜像的自动打包。
第二个解决任务调度，我们使用的是现成第三方celcery，并没有自主开发，celery大概框架有四层，我们用到的是前三层，这个工具我不详细介绍了，我说一下缺点。有什么是满足不了我们的，第一没有并发控制，另外没有对不同Takes依赖性和周期性进行管理，所以这个不能完全我们满足需求。因此，我们在celcery之前做了封装，底层是take层（用的是celcery），上一层是job层，主要是对takes进行编排与管理，再上一层是mission层，主要是对job进行编排和管理。自动化环境搭建的任务分为三层：mission, Job, takes。
我们准备差不多了，下面就是自动化环境搭建，图中整个是Mission，蓝色框是job，申请基础服务虚拟机与申请应用虚拟机两个job可以同时执行的，完成后进行初始化，自动搭建K8S环境，创建宿主机，一步步进行Nignx配置、DNS部署，最后部署应用，这边我们刚刚说了300个应用，完成后整个环境搭建完成。这是整个环境自动搭建的主要流程。
这个图是环境搭建的时间图，前几个就是申请机器的，也是占用时间比较长的，后面比较短的是配置K8s，配置DNS这些，不知道大家有没有手动配置K8S环境，相当复杂，尤其配置文件非常烦琐，如果你漏了一个整个环境就是不通过的，而且难查到什么原因。自动化以后可以看到这个时间非常短，这就是优势所在。
这个红色部分是部署子系统的，时间长短是看子系统部署的个数，这里例子部署了两个，如果部署300个子系统会长一点，300个子系统整个体环境部署，从头到尾环境自动搭建需要两个小时多，不到三个小时就可以完成，如果完全手动搭建的话一周都非常困难的。
我们又解决一个大问题。我们还有什么没有解决呢？答案是健康检查。我们为什么需要健康检查？原因一大家都是希望环境真正出问题前就能提前知道，提前去解决问题。第二当我们在测试环境进行一些性能测试时CPU突然增高，是环境问题，还是子系统有问题，如果是子系统，300个子系统中哪个高呢？我们希望有一个机制去判断它。所以健康检查是重要的，陆金所测试环境的健康检查分为三个层次：第一个虚拟机层次，我们用的是Zabbix，主要对磁盘、内存CPU进程监控。第二层用的是promethues，针对每一个Docker资源进行监控。大家看左边的图是Zabbix监控图，右图为promethues监控的情况，每一个子系统的数据都是可见的。
另外，之前我们还想了一个Docker自动化修复的方案，当监控到Docker不可用时，让它自己修复，比如说简单例子我这个应用， Docker无法连接，检测到以后自动帮助它重新启动可以吗？技术可以做到，但是没有实施这个方案，因为有可能测试时候就需要测试挂掉Docker异常的情况，所以这个方案没有加到健康检查里。但是我们真的需要一些环境能够自我修复的能力，所以我们引入第三层特殊逻辑的校验，我们自己开发了一个子系统部署到我们每个环境上，叫做Brood-agent，使用场景举个例子：发现某个消息很久没有被消费，是什么原因呢？我们线上500个子系统而环境上只有300个，这个有消息一直发，但没有消费，因为相关的子系统不在，但消息一直在列表中重试，尽管重试有次数限制，但消息本身就很多，导致后面正常的消息没有办法消费，每次都是人工排查，所以这个我们需要自己修复这个问题，这个时候会要求测试开发给环境管理人员一个规则。发现这种问题我需要指定表里，指定条件数据进行删除，或者是一些数据修改的操作。让我正常的消息可以正常处理，这是我们第三种特殊逻辑的健康检查。
我们回顾下，从一个物理机环境到K8S的搭建，各种改变来满足我们的需求，来看一下整体的架构。最低层是70多套测试环境；这些环境是由Docker容器化进行管理；这层是任务调度，任务调度我们说了几点，第一个环境自动搭建用到任务调度，还有镜像自动打包用到了任务调度，还有我们环境部署也有用到，之前部署版本时候一次只能部署一个，目前可以同时进行多个子系统的部署；再上一层是应用环境，镜像构建，环境健康检查等等；最上层是cmd tool、页面管理、还有API。API很有必要，70多个环境，测试自动化用例用哪一套环境，需要用API来获得环境的信息。这是我们大概的架构图。
我们看一下效果，效果刚刚说了一些，从之前10套不到环境到后来78套每套300个Docker，容器18000个，累计部署106万次，用户手工部署33万次，为什么累计部署与手工部署有差值？70多套环境我们需要保证和线上版本最新，每套环境300应用，要和线上最新系统保持一致，我们会每两个小时检查一下每套环境的每个子系统和线上版本是否一致，每天凌晨时候进行自动部署线上版本。
镜像打包18万次+，下面图是8月和7月份部署的情况，这个是陆金所环境自动搭建的过程。后面有一些问题，这是测试的公众号，里面是这个叫“海阔天空 ”里面有一些问题，大家可以在文章后面留言，如果打开以后没有办法修留言，可以在任何一篇文章在写留言的地方写问题，我们可以看到，并在三个工作日内会回答大家问题。这就是今天给大家分享的基于容器的自动化环境管理实践，谢谢大家！
大家有什么问题吗？
提问：我想问一下镜像打包会不会跟Jenkins打包一样，有时候我们会遇到上传不成功，或者重复内容。
金玲：私有库有的镜像不会打包，没有才打包，所有不会有重复的问题，如果要重新打包，要在私有库删除镜像，再重新打包。上传不成功是可能会有的，但是这种情况非常的少。
提问：打包失败有详细日志吗？
金玲：有的，但是页面来看没有特别详细的，除非进入系统里查，因为这个情况发生非常少，所以没有把详细日志暴露出来。
提问：我刚刚看那个版本可以实时同步的是吗？就是Nginx，线上线下配置差别好像挺大的。这线上线下怎么同步的？
第二个问题是说这个应用版本控制，每天晚上往下拉，每天凌晨把线上的版本拉到跟线下同步，数据怎么同步的？比如数据库里面数据怎么同步？需要不需要同步？
金玲：我先说第一个问题，Nginx的话我们后面还需要进行改版，现在Nginx修改走签报，我们做同步时候根据签报同步的，默认签报里内容就是线上的，这个是不准确的，因为有时候特别紧急需求需要线上直接改，不走签报，这种配置很难同步到测试环境，所以后面大概今年下半年，明年年初要做改版，我们希望线上修改配置时候同时在两个地方保存，一是数据库记录所有改动，二是真正修改线上配置，这样就可以在线下直接读数据库而不是看签报了。
而应用系统我们可以从线上的接口获得线上每一个用户的版本，与线下的进行对比。
希望回答了你的问题。
本文来自：2018中国首届云测试峰会，举办方：Testin 云测
Testin，让应用更有价值：www.testin.cn
关注公众号“Testin”，了解更多测试行业动态和测试知识。
网友评论