云的难处——我们为什么需要 CloudEngine？

——我们为什么需要 CloudEngine？
郑昀 创建于2016/7/31
关键词： 容器、Docker、OpenStack、虚拟机、私有云、Mesos、配置管理、部署、发布

2014年年底，我们开始试着将原有的持续集成和持续发布流程，从 OpenStack 迁移到 Docker 上。后来，我整理过两篇文章讲容器私有云和持续发布都要解决哪些基础问题（I，II）。
现在，OpenStack 又回来了，与 Docker 并肩作战。不管是容器化 OpenStack，还是 Docker 集群，做到这一步就解决问题了吗？

Docker+OpenStack，就够了吗？

我们要的不仅仅是容器或虚拟机
我们都知道，Docker 实现的只是镜像内部的小环境的一致性，它保证了一个应用程序在不同机器上运行时的一致性。

就我们之前持续经营了五年之久的 O2O 电商平台而言，首先它存在多条业务线：

• 团购

• POP 平台

• 电影订座

• 网店通

• ……

其次，它打通了供应链管理的全链条，从商机管理，销售行动管理，签约，终端设备铺设，……，到与商户的资金结算，与销售体系的佣金计算，与第三方支付的自动对账，与流量渠道的佣金对账，各种平台收费的核帐和摊销等等，加上外围技术支撑体系（如天机和鹰眼），里里外外大约近百个 Java 和 PHP 工程，每个工程都是集群。
这还不算上那些开源组件所需的集群，如 ZooKeeper，Redis， MyCat，Elastic Search，还不算上商业智能的那套体系。

所以才云科技的张鑫说得对：

然而大中型企业用户很快意识到，真正的难点在于如何保证“大环境”一致，即整个业务系统中众多容器、组件、服务之间如何配置、互联、依赖，如何保证开发、测试、生产环境能相互转化、克隆等。这些环境和配置在容器概念之上，是容器自身无法解决的，只能依赖集群层面的管理工具。

是的，给你一堆虚拟机，给你镜像库和一堆容器，你仍然很难构建出能 Run 起来的业务系统。

累觉不爱的部署

环境维护伤不起
一线互联网公司的技术团队纷纷夸耀自己在生产环境发布的频次。无疑，一天之内发布频次越高，同时发布质量还很稳定，意味着技术管理水平越高超。

好吧，假定我们仅仅是每周发布一个常规版本（少则几个工程，多则几十个工程），每日可能有几次 hotfix。那么在生产环境中，部署时间 30 分钟 还是 2 小时，区别不大，毕竟部署是一次性的工作。
但对于开发联调和测试来说，就完全不一样。如果 1 分钟就能完成一次部署，信手拈来，毫无心理负担，可以测试验证的东西，和几个小时才能完成一次的部署，差异是巨大的。

说白了，分布式系统的线下环境维护，做过的人都知道，伤不起。

你家的业务系统能DRP吗？

如何快速重建
何谓 DRP？
Disaster Recovery Plan，灾难恢复计划是也。

2011年艺龙曾经因为 EMC 存储设备故障而连续 27 个小时无法对外提供服务，在此之后他们做了相应的规范和开发，我去年看到一份资料说，艺龙可以在 30 分钟内异地重建集群。此后适逢著名的携程 5·28 停服 11 个小时的大事件，惊吓之余我们启动了 DRP 计划。
DRP 涵盖的事务有：

• 代码

• 配置

• 数据

DRP 面对的灾难场景：

• 生产机房物理毁灭，或短时间内网络不通（如光缆被挖断）

• 线下机房毁灭

想想看，如果你有一整套研发测试运维流程规范，还有：

• 代码库备份，

• 镜像库（包括了基础镜像）备份，

• 分环境的配置管理（一个环境对应一套持久化配置中心），

• 运维层面的 CMDB 备份，

• 数据库备份（跨机房数据同步），

• 在虚拟机和容器集群之上的集群管理工具

那 DRP 可能真的是水到渠成。

大前提：配置管理规范

配置与代码分离
前面说过，给你 OpenStack 和 Docker，你也很难快速构建出可运行的业务系统，那该怎么办？

首先我们要明白，要做到真正的大环境一致，必须将配置完全与代码分离，这里的配置不仅仅是服务之间的 IP 地址/内部域名/自动发现，还包括不同环境下不同应用的配置参数等。
我们要求的是，线下测试环境测试通过的包（或镜像），可以直接上预发环境，上生产环境，一路穿行没有障碍。
我们不希望看到的是，不同环境需要打不同的包/镜像。

因此，首先我们要一套环境对应一个持久化配置中心，与环境有关的参数都存储在配置中心里。
其次，每个应用都有自己的配置模板，不同环境部署的应用默认继承配置模板，人们可以通过集群管理工具（或配置中心的管理界面）对本环境配置做一些微调。

一定要能管到应用层面

自研的 Java/PHP 工程，中间件，开源组件，这些都叫“应用”。
我们在集群管理工具里，操作的对象是“应用”而不是裸机（当然你也能申请裸虚拟机）。
重要的是，将镜像的构建与代码库的分支构建整合。

想想看，
你自己的应用，应用的元信息里已经指定好了代码仓库地址，你本次只需要指定分支（一套环境对应一个分支，如测试环境对应于测试分支），选择虚拟化技术（虚拟机还是容器），指定节点数量；
开源组件，比如你选择构建一个 Redis 集群，你只需要选择相应的镜像，指定节点数量，微调下配置；
几分钟后一切成为现实，网络已经配置好了，内部域名就位，你能立刻开始联调测试，是不是很美好？

背后对应哪些事情？我们以阿里的 ACP 给应用分配虚拟机资源为例吧：

1. 分配机器

2. 服务器初始化

3. 创建安全扫描黑盒任务

4. 添加监控

5. 添加ssh

6. 安装ccbin

7. 安装httpd/jboss/tomcat/resin等

8. 安装jdk

9. 安装acc

10. 初始化sharedata

11. 下载代码/镜像

12. 下载额外流代码

13. 配置assert

14. 获取antx

15. 初始化template目录

16. 初始化uiweb

17. build

18. 部署前自检

19. deploy

20. checkservice

我们的应用申请容器资源，背后的步骤大致为：

1. 发送容器创建请求

2. 从 iDB（注：自研的数据库自动化运维系统） 获取数据源配置：这样应用访问哪些数据库，用什么工程帐号，都自动解决了；

3. 上传配置（含要注入的环境变量）和 Dockerfile 至 Git

4. 创建 Jenkins Job

5. 从 TouchStone（注：自研的容器私有云管理系统） 获取配置

6. 下载代码

7. 编译

8. 打包

9. 构建 Docker 镜像

10. 镜像上传

11. 部署信息结果处理

12. Haproxy 配置文件生成

13. Marathon 镜像创建

14. DNS 配置

15. checkservice

16. 容器创建结果返回

还要考虑什么？

大致想来，集群管理工具还需要解决：

• 灰度发布；

• 安全管理：如何在虚拟机和容器的基础上做好安全检测，就像上面阿里 ACP 的“创建安全扫描黑盒任务”之类的步骤一样；

• ……

上面说了这么多，这个集群管理工具就是我们的 CloudEngine，之前我在《CloudEngine：大杀器如何炼成》里介绍过。

-EOF-