云的难处——我们为什么需要 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 给应用分配虚拟机资源为例吧：
分配机器
服务器初始化
创建安全扫描黑盒任务
添加监控
添加ssh
安装ccbin
安装httpd/jboss/tomcat/resin等
安装jdk
安装acc
初始化sharedata
下载代码/镜像
下载额外流代码
配置assert
获取antx
初始化template目录
初始化uiweb
build
部署前自检
deploy
checkservice
我们的应用申请容器资源，背后的步骤大致为：
发送容器创建请求
从 iDB（注：自研的数据库自动化运维系统） 获取数据源配置：这样应用访问哪些数据库，用什么工程帐号，都自动解决了；
上传配置（含要注入的环境变量）和 Dockerfile 至 Git
创建 Jenkins Job
从 TouchStone（注：自研的容器私有云管理系统） 获取配置
下载代码
编译
打包
构建 Docker 镜像
镜像上传
部署信息结果处理
Haproxy 配置文件生成
Marathon 镜像创建
DNS 配置
checkservice
容器创建结果返回
还要考虑什么？
大致想来，集群管理工具还需要解决：
灰度发布；
安全管理：如何在虚拟机和容器的基础上做好安全检测，就像上面阿里 ACP 的“创建安全扫描黑盒任务”之类的步骤一样；
……
上面说了这么多，这个集群管理工具就是我们的 CloudEngine，之前我在《CloudEngine：大杀器如何炼成》里介绍过。
-EOF-
关键字：docker, openstack, mesos, 容器
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！