首先说一下我们都用容器做什么。主要三大类，第一种是诸如testlink，jenkins这种基础服务。第二种是产品的测试环境，这是占比最多的。然后就是我们的测试执行机器了。例如UI自动化，我们采取的是分别将selenium hub和node docker化的做法。如下图：
当UI自动化的case增多的时候，分布式运行往往是最好的解决方案。 目前我们通过这种方式容器化了20个浏览器进行并发测试。这些镜像都有官方的版本，使用起来还是蛮方面的。
然后说一下比较关键的网络解决方案，我们从单机到集群，中途历经了集中网络模型的变化。从一开始的端口映射，到利用路由规则给容器分配真实的ip，再到给每个容器在DHCP和DNS服务器上注册和续租。到最后我们演进出了下面这个k8s的网络模型。
我们知道每个docker宿主机都会自己维护一个私有网络。如果想让容器跨主机通讯或者外部访问容器。一般就是通过三种方式： 端口映射，路由规则以及overlay网络。我们选择在k8s中引入的overlay网络是weave，以解决夸主机通信问题。安装kube-dns实现服务发现。之后为了能让外部访问容器服务， 使用了k8s提供的ingress机制来实现。这个ingress网络其实就是在集群中启动一个容器，这个容器既能访问容器网络的同是还监听了宿主机的80端口。容器里是一个nginx，它会负责帮忙转发请求。nginx负责转发的有servicename和path，这里我们是无法使用路径进行转发的。所以我们在公司内部的DNS上做了泛域名解析。所有testenv为后缀的域名都会解析成集群的master节点的ip。这样我们的请求就能命中nginx中固定的servicename并做转发了。通过这种机制我们就可以很方面的访问容器提供的服务。当然ingress的缺点是暂时还无法做4层转发。如果要访问4层协议的服务暂时还是只能暴露node port。
我们这个测试环境的管理平台主要的架构是这样的：
集群中所有的镜像都过公司内部搭建的镜像仓库进行共享，我们在集群之上安装了各种服务来满足测试环境的需要。例如使用NFS做数据持久化，Heapster+Grafana+InfluxDB做性能监控，kube-DNS做服务发现，dashboard提供web管理界面，weave做集群网络，ingress做服务的转发。并且我们在这个整体上针对k8s的APIserver做了一层cli的封装。我们尝试过脚本管理，web服务管理，但是发现大家对这些方式的接受度都不高。我们面对的大多数都是一帮做梦都在写代码的人，所以我们换做提供一个cli的方式可以让使用者更灵活来定制自己需要的服务。通过这种形式，我们在公司内部搭建了一个可以提供测试资源的私有云，配合jenkins我们可以很方便的一键部署我们需要的环境并执行UT,接口,UI自动化测试等等，并提供一个详细的测试报告。下面是我们的部署一个环境后所提供的测试报告。
