内容来源：2017年4月8日，第四范式资深测试开发工程师孙高飞在“饿了么技术沙龙【第四弹】北京研发中心测试专场”进行《docker搭建大规模测试环境的实践》演讲分享。IT大咖说作为独家视频合作方，经主办方和讲者审阅授权发布。
嘉宾分享视频地址：http://t.cn/R9UCnpq
困境
当今互联网行业发展迅速，产品架构逐渐复杂，导致环境搭建困难。
测试环境不一致。
因为搭建环境困难，环境不多，所以一套环境有多人使用，容易造成环境的互相踩踏问题。
随着业务的发展和时间的积累，我们发现case越来越多。我们希望能够用分布式的执行方式在多台机器上并发执行，以提升执行速度。但是测试机器稀缺，速度依然无法提升。
解决方案
自动化
搭建一个环境必须做到一键部署，在迁移、实践和删除环境中也要做到自动化。
标准化
标准化用来解决测试环境不一致的问题。我们希望测试环境、开发环境甚至生产环境都是一致的。
集群化
根据以往的经验发现，测试资源是一种比较稀缺的资源。要把测试环境扩展到一定的量级，使稀缺资源变成普通的、人人都能简单获取的一种资源，这样就省去了复杂的流程和排队等待的过程。
DOCKER
容器技术相较于虚拟机来说还是非常节省资源的。Docker不需要运行完整的操作系统。在一个宿主机上运行的所有容器都是共享宿主机的内核，所以每启动一个容器，都比虚拟机节省了一个内核的空间。
简化了运维成本，极大降低部署环境的学习门槛。
假如公司新进了一批机器，要把环境迁移到某些环境上来，只要把它做成镜像，就可以很方便地进行迁移。而且这些镜像都是一致的，通过制作镜像可以解决标准化的问题。
容器的启动速度和删除速度都是秒级的，有些不是长时间运行的服务在用完后就能将其删除。这样docker的宿主机就始终能保持一个低压力的状态。
把应用程序当成一个个集装箱，全都放在docker里。主要是放基础容器、测试环境和测试执行机器。也可把执行测试机器全部制作成镜像，在需要使用的时候启动它并放进docker里。
网络的玩法
端口映射
在docker默认的启动模式是bridege模式的情况下，docker为我们创建了一个叫docker0的网桥，这个网桥专门负责为容器进行转发。它会给容器分配很多虚拟IP，但这些IP只能在容器内部沟通使用。要是想与容器进行通讯，最常用的方法就是端口映射，把容器端口映射到宿主机上。
这种方式的优点是简单，不用做任何配置。当然它的缺点也很明显，要维护一个很庞大的端口列表，记住每一个环境容器的端口是什么，对外暴露的端口是什么。
固定IP
我们希望这些容器能像虚拟机一样，给它分配真实的IP去访问它。但这个做法会稍微有些麻烦，docker不支持这样做，我们需要利用一些转化规则。
创建一个新的网桥br0，给它分配一个真实的IP，把宿主机的网卡挂到网桥上，同时改变docker的启动参数，默认启动的时候连到br0上。重新划分网段，把所有容器的网段全都分配成和宿主机在相同的网段上。这样启动容器时分配的就是真实IP，并与宿主机相处于同一个网段。
这种方式让外界用户感受不到是在使用容器还是虚拟机，是对测试环境非常友好的一种方式。
但它并不适合在大规模的测试环境中使用。所有环境都有了真实IP，都被放到了真实的网络环境中，如果容器太多就会出现广播风暴的问题。
环境部署
Container模式
Container模式的特点是可以把所有容器绑定到一个IP地址上。
虽然所有模块都装在不同的容器里，但它们都有同样的IP，只是它们用不同的端口对外暴露服务。
它的优点是配置管理，效率高，是对开发最友好的一种模式。
缺点是标准化。因为我们公司产品的一些特性，产品环境并不是这样去部署的，所以可能会出现环境不一致带来的一系列问题。
打包模式
有多少模块就并发启动多少容器，这些容器的网络模式可以用host。Host的特性是把所有容器的网络环境挂载到宿主机上。把这些并发编译后上传到FTP上，然后启动一个或多个部署容器。
打包模式的优点就是标准化。但它的效率不如Container模式高。
存储的玩法
外部存储
把数据库放到容器外面，在容器内部和数据库进行沟通，保证数据库不会造成数据的丢失。
Volume存储
这是docker比较推荐的一种方式。它允许把容器中的某个路径挂载到外部设备上。比如挂载到宿主机上，容器实时向文件中写数据，宿主机上同时也会保存这份数据。
集群
我们想要提供一个统一接口去管理集群上所有节点，所以考虑使用一些开源的分布式框架。目前在业界最火的三种框架就是mesos、Kubernetes、swarm mode。
Mesos诞生的时间非常早，专注于资源调度，后来docker火了之后才兼容了docker。它的调度框架的二次调度，只装一个mesos是不够的，还依赖于很多其它的东西。Mesos发展得越来越复杂，需要专业运维去支持，所以mesos并不适合作为测试环境的框架来使用。
Kubernetes是google内部集群框架block的一个开源版本。它当时是为docker设计的，而现在Kubernetes慢慢开始兼容其它平台。Kubernetes原本应该是最复杂的集群管理框架，google提供了客户端工具，把很多内部细节封装起来，简化了它的使用方式。它最近推行的容器化部署也极大降低了Kubernetes的使用门槛。
Swarmmode是从docker1.12版本开始内置到docker引擎当中的，非常简单。它把所有需要的东西全都内置到了一条命令上。只要运行一次这条命令，所有的服务发现、跨节点沟通等等的负载均衡都已经做好了。Swarm mode是三种框架中最简单的一种，但并不灵活，功能也没有那么强大了。
K8S基本概念
POD
Pod是Kubernetes一个逻辑的概念，是一组容器的组合，是Kubernetes在一个节点上控制的最小的逻辑单元。
Deployment
可以把Deployment看成一个守护进程，如果把一个Pod挂载到Deployment上面，它能保证Pod始终运行。要是监控到定义的这组Pod某一个节点挂了，容器也都挂了，它会利用调度系统找一个合适的节点启这些Pod。Deployment可以关联多组Pod。
Service
Service同样可以关联到多组环境上，帮我们做负载均衡。当有请求过来的时候，Service会自动分配到各种不同的Pod上去。假如出现了运维事故或IT事故，一个节点挂了，它会自动切换到其它几个节点的容器上去运行，不会影响到它的服务，保证了PM的环境是始终存在的。
安装服务
从单点扩展到集群，复杂度就提升了。
首先要关注的就是跨主机通信问题。Docker分配的是虚拟IP，只能在一个节点的容器中互相沟通。扩展到集群之后，要装一个网络插件来解决问题。
容器之间要互相沟通，必须知道对方的IP地址。Docker在每次启动的时候IP地址都会改变，要有一个DNS去注册域名，在配置文件中做通讯的时候执行这个域名就可以了。
要知道容器运行消耗了多少资源，应该再安装一个服务来做容器级的监控。
Docker变向集群化的时候，就面临了镜像如何在每一个节点上进行分发的问题。所以要有一个镜像仓库来存放所有镜像，每个节点都会拉最新镜像进行部署。
以上是我今天分享的内容，感谢聆听！