Docker应用实践

最近几年，先有OpenStack引领云计算风潮，后有Docker来添砖加瓦，目前在国内云计算十分的火爆，多家IT巨头公司与创业公司等都选择云计算为新的发展方向。但事实上，很多企业只是因为Docker火爆才开始研究与测试，至于真正使用Docker解决某些问题或者提高工作效率，还未实现。

本文主要结合我自己互联网行业的工作实际向大家介绍我对Docker的认识，包括Docker真正适合做什么、如何使用Docker提高工作效率，供传统企业的运维人员参考。

一、Dcoker应用场景

总体来说，Docker适合轻量级应用比如web或者测试环境。我认为Docker的定位可以归纳为以下三点：

1、运维测试：使用Docker做沙箱，方便运维测试新软件或脚本测试;

2、快速开发：方便开发人员快速地测试代码，使用Docker完成代码提交，并可以一键化测试；开发人员不需要关心如何部署服务、上传代码、打包等操作；

3、集群应用：使用Docker+etcd+confd+haproxy等做集群，能快速进行auto_scale，保证了单点故障不影响整体服务，并且多主机资源能更多程度的利用。

二、Docker企业平台化需求

目前互联网技术发展日新月异，基本每天都有很多新的技术或者工具被研发出来。到底是否研究这个新的技术，需要理性判断。我一般研究新的技术，都是先整理好需求，然后过滤出满足我需求的软件，再进行细致的对比、分析和测试。在此过程中会查看软件是否有专门的社区、完整的文档，是不是处于不断的开发与维护bug中。当满足了这些需求我才会研究一门新技术，这样既能节省时间，也能快速找到合适的软件。

如果企业想应用Docker，无论是在测试环境还是在生产环境，建议都先整理好需求，然后再看Docker本身是否有这些功能。即使Docker不具备某些功能，也可以看看是否可以通过插件或者自己开发来解决。只有当该产品能满足大部分需求，不能满足的部分也可以通过其他方法解决时，才是最适合自己使用，可以深入研究。

以下是我整理出Docker企业应用平台的需求：

1、能WEB化进行容器操作，如创建、停止、开启、删除、详情查看、修改节点容器等操作；

2、能动态的添加与删除容器的防火墙，不需要容器创建时使用-p功能；

3、能为容器动态的绑定与解绑公网IP；

4、能对容器镜像进行管理，可以进行镜像打包、镜像发布与镜像删除操作；

5、能对宿主机节点进行管理，可以查看宿主机容器使用数据并进行资源分配控制；

6、能动态对容器进行卷组的绑定与解绑；

7、能对容器资源使用情况（如CPU使用率、内存使用量、网络使用量）进行监控与图形化显示；

8、能实现区域管理；

9、能实现半自动化代码自动部署，满足研发快速测试需求；

10、使用auto_scale创建集群，能最大程度利用主机资源、高可用。

上面10点就是我整理出Docker能实现的需求。虽然有一些需求Docker不直接支持，但可以通过自行开发程序来满足，所以我们才选择了深入研究Docker，并真正的在测试、生产环境使用起来。

三、Docker平台功能介绍

我从2014年5月开始研究Docker，同年9月完成1.0版本的Docker平台web化，11月份正式在生产环境使用，2015年5月2.0版本完成，实现研发半自动化持续部署与集群auto scale功能，可以说使用Docker时间比较长。以下简单图文介绍一下我所在企业的Docker平台功能。

1、容器管理
主要能实现运维沙箱测试，可以web端创建容器，并进行cpu、内存、网络资源控制，以及ssh访问设置。

2、防火墙管理

主要是可以动态的对现有的容器新增或者删除防火墙信息。

3、公网IP管理

容器可以通过绑定公网IP来让外边直接访问。此方法和Openstack绑定公网IP类似，是把公网IP绑定到计算节点，然后通过iptables的dnat与snat设置访问权限。

4、镜像管理

主要是对私有库镜像查看、删除与推送（把已经在研发模式提交的镜像推送给集群节点）。

以下是某个镜像详情：

宿主机管理

可以查看当前区域宿主机信息（比如品牌、硬件型号、sn、ip等）以及容器数量。

6、卷组管理

默认容器使用dm存储引擎，根分区10g，如果不满足需求，可以通过动态的绑定卷组来解决此问题。

但如果想使用动态卷组，需要宿主机分区是ext4格式，否则不能实现。

7、资源监控管理

可以查看容器的cpu、内存、网络资源使用信息。主要是使用Docker的api stats获取数据，然后写入到平台Mysql数据库里，然后前端通过ajax获取数据并使用highchart显示。

8、密钥管理

主要是让容器可以使用ssh进行登录，所以ssh使用密钥验证。可以新增rsa与dss的key，也可以自己上传key。

9、项目开发管理

主要是让研发可以快速的半自动化持续化部署与测试。

下面是创建界面：

新建开发项目，只需要输入对应信息后，就可以直接创建业务来测试，不需要部署服务与上次代码，更新的话，也可以点击一下鼠标来进行。如下：

默认是latest版本，直接选择确定机是更新，输入版本号就是回滚。

10、集群管理

主要是包括负载均衡、高可用与auto scale。负载均衡是通过haproxy+keepalived实现，高可用是如果某节点的容器挂了，可以通过Docker自动启动；如果Docker挂了，可以通过systemctl自动启动；如果节点挂了，节点的容器ip会自动从lb里去除。

可以看到有2个实例在运行，最大可以扩容到5个。

PS：扩容与缩减的调整就是依赖cpu阀值与内存阀值，当此项目容器监控资源大于阀值就开始操作。

集群更新的话，我这里是直接选择镜像来更新，回滚也一样，还可以直接选择回滚到上个版本。更新后前端会有1-2s中断，原因是新容器ip信息会发给前端lb，替换后用户会连接新的后端。

四、Docker使用心得

上述平台很多功能都不是Docker原生，都是通过程序结合Docker实现。我总结了一些Docker的使用心得，供大家参考。

1、持久化固定ip

Docker默认使用bridge，给予容器的网络设备是eth0，然后此IP是通过dhcp获取的，当容器意外重启或挂掉后启动，容器的IP会重新获取。这种情况对于很多应用，比如数据库服务部署到Docker里，web应用连接因为容器IP变化导致无法连接，还有很多其他场景都要求使用固定IP。

所以，我通过pipework+etcd+程序实现了持久化固定ip。主要通过自研脚本实现，在创建容器时候网络模式选择none模式，然后通过openvswitch创建网桥，通过pipework设置容器固定ip并存入etcd里；如果容器重启程序会从etcd获取ip并通过pipework重新分配此ip给容器。

如下图：

2、动态防火墙

默认Docker是允许修改宿主机iptables的nat链，这样你在创建容器的时候，通过-p参数来指导nat信息，但这样有个缺点，不能对已经运行的容器修改防火墙信息，如果想修改只能先把当前宿主机防火墙策略保存，然后在去修改。

所以我通过自研程序来进行动态修改防火墙功能，做法就是不允许Docker修改宿主机iptables，想做什么防火墙策略都是通过我的程序来修改宿主机iptables实现。

3、绑定公网IP

测试环境不需要公网IP，但如果是生产环境，肯定有场景需求，比如一个宿主机里n个容器，但有3个容器都想把自己80端口对公网，并且是80对80，但通过iptables只能满足一个容器80对80，所以得需要绑定额外的公网IP解决。

4、资源监控

我使用的资源监控就是通过Docker本身的api stats来获取数据，然后存入数据库，之前通过highchart进行图像展示。

另外如果想通过zabbix监控也可以，能在zatree查看当前所有容器监控，如下图：

5、半自动化持续部署与回滚

以上介绍都是运维使用Docker进行测试，但怎么让研发也能加入进来，享受Docker带来的福利？这就是半自动化持续部署与回滚。

使用Docker结合自定义程序，在配合jenkins或者直接使用maven打包，封装好了这些，配合web平台的界面，大大减少了研发与运维的交互，以及繁重的流程，让研发就开发即可。

可以参考下图，是分析传统研发模式与Docker工作模式：

可以看到Docker模式比传统模式减少了很多人力参与流程，节省更多时间，相应效率就会更高。

用户创建完成项目后，后端会进行以下操作：

启动容器=》分配固定ip=》资源限制=》下载代码

之后就可以直接访问。

6、集群高可用与auto scale

生产环境使用，必须是高可用与负载均衡的，否则某个容器或其宿主机挂了，就会影响业务。

以下是集群架构：

用户通过绑定的IP来访问负载均衡后面的容器，如果某节点挂了，IP会自动剔除。

五、对传统行业应用Docker的建议

随着传统行业拥抱互联网，有些传统企业也开始尝试互联网技术包括Docker。以上介绍希望帮助大家对Docker的企业应用有一些了解。

现在传统行业的IT厂商比如IBM正在全面支持Docker，推出Linux onPower服务器，利用Power服务器本身高性能和高RAS特性，来帮助传统企业更好地享受Docker带来的好处。综合历史积累、成本、人员等因素，选择商用产品和服务可能更适合现在传统行业的实际情况。

在最后再次强调一下，如果企业想使用Docker，无论是用于测试还是生产环境，一定要先明确需求，判断其是否适用，然后再进行测试、研发或使用。如果有需求Docker满足不了，也无法通过插件或者自定义程序解决，不如选择其他软件。Docker并非万能，解决实际问题才是我们真正需要做的。