余兴超：UnitedStack如何进行版本管理

个人简介 余兴超，现任UnitedStack平台架构部负责人，OpenStack社区Puppet Modules项目核心开发者，专注于自动化运维与持续交付领域，之前曾就职于新浪云计算部门。

QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 余老师我想问的第一个问题是， NativeStack基于OpenStack做了很多改进。但是这种改进在公司内部是怎么来实现继续集成、不断改进、版本控制的？在新机器上线时，这个改进过的版本如何应用到生产环境？

余兴超：关于开源，我们有一个跟进社区的 Upstream的策略。你也提到了，如果私有Patch不按照一定的规范写，后期就无法跟社区保持同步。就像我在会上讲的，首先要考虑的是把这个Patch贡献到社区。从目前来看，我们至少有一半的Patch是符合社区规范最终被Merge。另外我们也会保证修改不破坏原有代码逻辑，比如通过扩展、插件的方式。如果实在不得已要破坏原有代码的逻辑，我们会尽量保持代码的可维护性。

   

2. 不破坏代码原有的逻辑，那么在做部署时内部的版本号跟外部社区的版本号怎么做协调和同步呢？

余兴超：是这样的，每次社区发布一个大版本，我们就会以这个大版本为基础，然后在此基础上制订自己的版本。举个例子，比如以Liberty版本为标准，英文发布的版本号是2015 2.1，那么我们就以这个版本号作为L版本的基础版本号。然后在这之后我们会自己维护它的版本号，比如说他最后一位我们在内部定义为beta fix位，倒数第二位是Feature，开发的位，我们不会改动它的第一位major number的。

   

3. 在大版本前提不变的情况下，如果他们又做了一些小版本升级，你们会不会把那些小版本Merge到自己的代码库里？

余兴超：我们会根据情况，如果是一些比较重要的安全性修复，我们会考虑把它合并过来。但如果我们的生产环境没有遇到类似问题的话，我们是不会考虑去合并的。因为这会带来比较大的成本开销。

   

4. 在包管理上，你说会把整个包重新做一遍编译，在这方面你有什么样的经验，或者有哪些成熟的做法，可以给大家借鉴一下的？

余兴超：在软件包这块，我们还是有比较多的经验和想法的。我们从2013年开始维护OpenStack源码，把它制作成IPM包开始，我们针对包管理做了以下改进。第一、所有依赖的公共库和基础库都自己维护。比如Nova依赖的某些Python公共库，我们自己去维护。只有这样才能保证整套原码是可控的。第二、我们对Spark里面的版本依赖做了一些改进。比如有些库，我们修改了里面的一些接口，会用一些特定版本的技术库；另外一点，就是我们对一些服务的启动脚本和一些安装后的策略做了一些调整，使它符合内部的预期。包括刚才你之前问到的那个问题，就说我们还使用了Watch RPM技术保证OpenStack各项目在大版本号不统一的前提下，仍然能在线上正常Work。因为大家都知道OpenStack，每个项目都会用到一些公共的依赖库和基础库。这些库的版本有很强的一致性要求。如果这时，某些项目升到了高版本，而某些项目仍在使用低版本，接口就会不一致。我们就用这种技术把这些技术库都打包到某一个项目内部去，这样，每个项目都独立地使用它自己的依赖库，就不存在所谓的公共库了。

   

5. 接下来的问题是关于敏感数据的。对于敏感数据，怎么去做隔离。如果有家银行，他把一些客户数据放在你们那托管，然后运营。另外可能还有一些其他的公司也会在你们托管的云上面，那么银行业可能会有一些外部的审计工作，那么他会要求你们做信息隔离，如何做这种安全边界的设定。可能云跟云之间会有些防火墙，或者在同一个公司里面，他们会有一些像信用卡数据等非常敏感的数据，会隔离在一个安全的网路里面。那么在外部一些应用，比如一般手机应用，可能访问的时候，就不需要放到加密的环境里。也就说从非加密到加密之间会有防火墙和通信。这样一个带来了一个挑战就是，如果用户它的那些非加密的虚拟机重新被加入之后，怎么让这些防火墙能自动识别新加入的机器，他需要和防火墙之后的机器进行通信，如何来解决这样的防火墙漏洞， United Stack在这方面有什么经验可以分享一下？

余兴超：您刚才提到的金融类客户，首先他不会选择使用公有云；其次他在使用托管云上也非常谨慎。他们不允许有任何外部接入，必须我们的工程师去现场，是完全的二层隔离的环境。

   

6. 等于说每个项目都有自己依赖的一套库环境。但是OpenStack组件和组件之间，它会有一些RPC调用。我们经常碰到的问题是，虽然版本可以强制，但它自己会做版本检查。比较初级的Hack方式是强制修改它的版本号，但是它的API可能会发生变化，所以当组件之间进行通信时，直接就发生RPC错误， WatchPRM可以帮助解决这样的问题吗？

余兴超：这样你就得自己修改代码来解决。比如API层面不兼容，比如某个接口过时了，就必须修改这个项目的接口调用代码。

   

7. 他们是把那些安全环境放在自建的数据中心。将不是非常敏感的数据放到公有云上托管。那么从非敏感的机器访问到敏感数据时，数据就要经过防火墙审核。那在逢年过节，或者特殊活动时，他们需要增加机器，增加的机器可能需要访问防火墙之后的数据， United Stack有没有这方面的经验分享？

余兴超：我们有遇到这样的金融类客户的，他们会给我们一个白名单，来自哪些IP的，基于IP做ACL限制，每个API接口都会要求使用HTTPS方式。

   

8. 那这种加到白名单的操作现在是自动的呢，还是需要手动提交？ 余兴超：目前来说是手动，因为我们只遇到一个这样的Case。如果有大量的这样的客户需求，我们肯定会考虑把它变成自动的。纯手动成本太高了。还有一个问题是说，在Native Cloud，就是你们的KVM的版本，或者说提供给客户的虚拟机的版本，是保持在同一个大版本，还是说会有多种不同的操作系统版本？

余兴超：操作系统的版本我们是统一的。

   

9. 如果系统要从12.04升级到14.04，那么在做这种操作时，应该采取哪些步骤，用什么方法将整个线上的KVM从一个版本升级到另外一个版本？

余兴超：跨操作系统升级是一个比较大的话题，根据我们之前的经验，一般只会在新集群采用新版本的操作系统，而旧集群维持原有版本。这样我们可能需要维护两份不同的RPM包了。

   

10. 你说的很有道理。那么如果老集群版本过时了，你们是把用户都迁到新的集群上，还是说在原有集群上进行升级？

余兴超：我们会建议客户做新版本升级。因为操作系统的大版本升级是一个比较大的话题。红帽、百度、阿里，他们其实也都有大量低版本的操作系统。升级是一个非常谨慎的事情。

   

11. 那若干年后，在老集群的用户没有升级意愿，而老版本OS没有安全补丁等支持的话，对运维的影响会非常大，你们会采用什么方式来克服这方面挑战？

余兴超：出于安全考虑，我们更倾向于去维护两套不同操作系统版本的线上集群。目前我们还没有想到一个比较好的解决方法应对这种问题。

   

12. 可能这也是整个云平台公司的一个共同挑战。

余兴超：我们遇到过那种客户，我们主动说给他做操作系统升级，并保证没有问题。那客户说我没有这样的需求，你为什么要动我的操作系统？

   

13. 那你们现在不光提供KVM hypervisor层面上的支持，你们也会将虚拟机一起提供给客户的，是吧？

余兴超：对，我们提供的其实是一套基础架构的设施。至于客户在上面要创建哪种虚拟资源由客户自己选择，我们提供持续的运维服务。