为什么要基于OpenStack实现精益研发

梁建民首先介绍了他对精益研发和DevOps的理解。“精益”是来自丰田生产方式的一种理念，其核心是更快速的交付和消除生产过程中资源的浪费。

精益研发和此前业界谈及的敏捷开发概念有本质的不同：

.关注点不同，这是最大的差异

。敏捷开发仅仅关注怎么快速地交付一些产品满足客户更快的需求。

。精益研发关注的是在满足客户需求的过程中如何消除各个研发环节的各种浪费，包括资源的浪费、人力的浪费和时间的浪费等。

.实现方式不同

。敏捷开发有一些固定的方法论，比如Scrum。

。精益研发目前没有成型的方法论，一般是以某一种敏捷开发方法论作为起点来逐步实现，但在满足客户更快的需求过程中，精益研发具有更广泛的视角，比如关注在外围的生产、外围的企业合作等过程中消除一些资源的浪费。

.企业需要引入精益研发的动因在于现实的市场需求：

.想要更快地满足客户的需求，需要更快地验证产品的模型。

.想要在激烈的竞争中占据优势，需要超出市场预期的速度把产品推向市场。

.充分利用企业现有的IT和人力资源，实现高质量的研发。

精益研发的一种成功实践是DevOps，后者是从业务角度理解的一个概念，包括开发、运维和测试怎么更好地合作来满足客户的更快速的交付的需求。DevOps理念的实现需要整合一系列的开发工具、运维工具和测试工具来支持，以消除资源的浪费。这同样需要一个更快速更敏捷的基础架构来支撑，而开源的OpenStack平台，在众多技术公司的支持之下，社区和生态不断完善、成熟，经过10多个版本的迭代，OpenStack已成为构建敏捷的云计算基础架构的优选技术。HPE也选择在OpenStack之上构建DevOps实践的技术栈。

基于OpenStack的开发测试平台

Helion平台的目的是交付安全的、可靠的、企业级云平台。社区版OpenStack云平台以免费来降低客户入云门槛，但它们带给客户的却是上云后昂贵的运维成本，以及无保障的服务。

开发测试平台包括两部分：

.HPE Helion Development Platform：支持开发团队更快速更敏捷地利用OpenStack的资源，以更快地满足客户的需求。

.HPE Helion Stackato：如果开发团队有自己的基础设施，Helion Stackato支持更快速敏捷地利用自己的基础设施来满足客户的需求。

OpenStack基础设施

HOS 3.0是基于OpenStack Liberty版本开发的，作为OpenStack社区贡献量巨大的白金会员，HPE在OpenStack社区版的基础上做了很多的增强功能，3.0的特性包括更灵活的配置、操控性更强、易于运用等。开源OpenStack包含的组件非常多，对于企业尤其是小型企业来说，如何很好地运用是非常痛苦的事情，HPE开发了基于Ansible自动化运维的部署工具来实现一键部署、一键平滑升级，对OpenStack做全生命周期的管理操作。

除了社区版本基础之上的一些组件的维护增强以外，HPE也开发了自己的模块来增强这个企业级的平台，和高可用各种工具的集成，包括控制器的高可用(一旦控制器挂掉，整个集群就可不用)，网络方面L2/L3

Agent的高可用、安全的高可用、VM的高可用增强，以及负载均衡(包括F5)集成、SDN/NFV的支持等等。

PaaS构建思路

在OpenStack基础设施之上，HPE还做了PaaS平台的一些工作，通过HPE自己开发的SaaS服务来一键安装部署PaaS平台。PaaS平台目前支持传统应用的开发，如Java、PHP、Python等语言的开发。

PaaS平台基于开源的Cloud Foundry，HPE也在开源的Cloud Foundry之上做了一些增强功能的开发。

.Cloud Foundry原先的后端是Warden，HPE把Warden替换掉以后，实现自己的Docker服务，用Docker来进行APP容器的服务。

.Cloud Foundry的最前端是Router，要响应所有用户的请求，包括PaaS性能的管理组件的请求和流量，以及客户上传APP过程中的请求。HPE针对Router做了一些高可用的操作，通过扩展的方式来实现，以及一些硬件的负载均衡的集成。

.Cloud Controller方面，HPE也做了高可用的增强，包括用户的授权认证，原先是通过UAA的方式来实现，HPE现在改成AOK，并和LDAP认证集成；APP的打包、部署、运行，一切的调度工作也都是通过Cloud

.Controller来做，也做了高可用，通过调度后端的程序DEA模块，通过监控模块监控容器的负载，如果业务量突然爆发，容器会快速地自动扩展来满足业务的需求。

.平台还提供一些managerment和unmanagerment的服务，比如数据库、消息队列、中间件服务等。

在OpenStack上把Cloud Foundry构建出来，可以通过OpenStack提供的RESTful

API的方式——把Cloud Foundry功能模块提前做好构成镜像，通过调用OpenStack API。首先构建一个VM作为构建PaaS平台的构造器，再调用OpenStack的API去把Cloud Foundry集群构建出来，当然中间会用OpenStack的其他一些技术，如Heat编排等。构建出来以后，可以在IaaS平台上通过直接访问到PaaS平台的URL访问PaaS平台。

CI/CD

CI/CD是DevOps的精髓。这方面HPE开发了Code Engine 产品，集成基于Github代码的智能结合，开发满足现在流行的微服务的一些技术要点如12因子(Twelve-Factor)的产品。

有一些企业可能有自己的Git仓库，HPE也开发了单独的组件，通过pull/request探测开发人员提交的代码，如果代码通过评审，HPE有自己的编译的worker和测试的worker，测试worker集成第三方的工具(如LR性能测试工具)，测试以后通过部署的worker，一键部署到PaaS平台上，当然前提是PaaS平台是基于Docker做的。

CI/CD的架构，前端是一个Web，后端是Code Engine的API服务，一切的用户请求都放到API上。包括开发层面的编译、测试、部署、通知、Git/Push五个worker，以及调度的worker(调度前述工作的衔接和运行)。用户首先需要创建环境(最后应用是部署在基于OpenStack的PaaS平台还是其他的CF平台上)，配置好用户环境之后，可以配置第三方工具的集成，然后构建Build，需要和Github集成，在Github上创建project，Code Engine回调的URL配置好，通过探测pull/request自动化测试、编译开发人员提交通过的代码。

具体的流程，Git/Push的worker自动把代码拉下来，容器的worker从容器仓库中拉出一个容器来，把代码放进容器，通过自动化的工具测试并编译，然后部署的worker把容器自动化部署到PaaS平台上。

梁建民分享了一个客户实现DevOps的案例：客户有自己的CI工具和F5负载均衡，HPE帮助构建它构建PaaS平台。PaaS构建好之后，Router做了高可用，通过F5做负载均衡，PaaS和CI进行整合，满足快发开发、快速迭代的需求。

容器技术的选择

从业务角度理解，具体利用什么工具来满足自己的业务需求，每个企业都有不同的工具的选择，根据自己的业务决定；从技术角度来说，Docker是较新的事物，做单独的容器使用是没有问题的，但是如果是作为一个集群的方式，或者跨数据中心的方式，它的调度是一个技术难点。调度管理方面大家还处于探索阶段，所以就有Kubernetes、Mesos等工具来解决，HPE目前是通过开发自己的Fance组件来和Cloud

Foundry做一个集成，来管理Docker服务。

Kubernetes、Mesos等工具纯粹是为了管理容器而产生的，至于这个容器是构建在IaaS之上呢，还是基于构建在裸机之上，是两个层面的东西。如果想基于裸机或者基于IaaS管理容器的编排，可以通过这些工具来做，实现通用的PaaS平台。

HPE走的是另一条道，即和OpenStack高度集成(同时也支持单独部署PaaS)，更快的更敏捷的利用IaaS资源，然后基于Cloud

Foundry开发了自己的Fance工具管理Docker。HPE开发的组件和开源社区的组件是相互兼容的，都可以更好地利用容器来实现更敏捷、更灵活的交付，不排除以后会做一些整合。

总结

通过利用OpenStack、Cloud Foundry和Docker技术来构建开发测试平台，业务层面重新构建开发、测试、运维人员结构，运用DevOps和微服务理念，达到更快的交付高质量的产品，随时可以高效的应对市场和客户需求从面形成闭环，使企业具有较强的竞争力。