本文根据UnitedStack有云研发总监 & PuppetOpenstack项目核心开发者余兴超《奔跑吧，OpenStack! ——UnitedStack与您面对面•深圳站•奥斯汀OpenStack峰会分享专场》 的活动中的演讲整理而成。点击PuppetOpenstack Meetup深圳站可下载本次演讲的PPT。

部署工具的发展现状

从Austin再次回到Austin，在过去的6年时间里，Openstack部署已经从简单的集群初始化安装配置演变成为持续部署的工作。现在，用户不仅关注集群的初次安装，更注重集群后期的运维、变更、升级等诸多环节。从第一次Openstack社区用户调查开始到OpenStack基金会在4月26号发布的第7次用户调查结果表明：PuppetOpenstack项目始终保持在第一的位置上。

其他热门的部署项目，如TripleO和Packstack等，其部署逻辑均使用了PuppetOpenstack。Puppet在当前整个Openstack部署市场上占据了近一半的用户，其中30%用户选择用于生产环境，它的影响力显而易见。

Puppet在Mitaka版本中的成果

那么PuppetOpenStack项目在Mitaka版本中的主要工作有哪些？大致分为三点：

第一点是CI方面的改进。

社区为什么要花那么多精力去改进CI（持续集成），有什么好处？

• Puppet可以大量的用于生产环境，这是生产环境的客观要求。
• Puppet有大量的工程师参与了社区开发，那么它的代码必须要得到保证。
• PuppetOpenStack相比三年前刚诞生时候，演化成为一个非常庞大的项目，当前有三十多个子模块。也就是说，去管理这个庞大的项目体系，需要做大量的基础工作去保障代码质量。

改进CI具体做了哪些工作？

➤ 更多的测试场景和服务支持。比如说我们现在的集成测试支持有四种的测试场景，每种场景下有不同的服务和配置。也就是说你每提交一次代码，这些集成测试都会被自动调用，自动去创建集群，自动地去运行。我们可能看到，除了OpenStack核心项目之外，其他在孵化中的热门项目都被涵盖到了。

➤ 支持TripleO等工具的相关测试。我们每提交一个patch，都会触发这些工具相对应的一些测试，从而确保我们刚合并到代码仓库里的这些代码，是稳定的、可靠的。

➤ 跟OpenStack Infra Team的对接。OpenStack在上一个版本中推出了OpenStack-health项目，其作用是监控整个CI过程中测试作业的健康情况，有利于去及时地判断和了解一个项目的集成测试，或者单元测试和其他相关测试当前的健康状况。

从下图中可以看到，puppet-nova项目在4月底到5月份这段时间里运行了哪些测试，有哪些是失败的。点进去，还可以看到在哪些测试场景下失败了，测试用例失败的原因等。可以通过数据分析，提高对项目质量的监控粒度。

第二点，在Mitaka版本中发布了将近三十个稳定模块，覆盖了几乎所有热门的OpenStack服务，以及一些基础服务。也可以看到，它在每个版本都有一些正式的发布。如果用户希望将PuppetOpenstack使用于生产环境，可以在Puppet官方Forge源或者Openstack官方源下载对应的项目。

第三点，模块之间一致性的提高。重点有两个项目，一个是Puppet-oslo，是UnitedStack有云在2016年1月份向社区贡献的项目，这个项目就是管理跟oslo相关的公共库的配置。这个模块引入以后，把这些配置都集中到Puppet-oslo里面去。截止5月28日晚，这个模块大概减少了三千行冗余代码。第二个项目是OpenStack-spec-helper，这是一个统一测试框架。例如在测试代码中，有很多的公共冗余代码。该项目的目的跟Puppet-oslo项目一样，就是为了减少冗余代码的存在。

在Newton版本中Puppet的工作重心？

在N版本中， Puppet-OpenStack项目经过了将近有三年发展时间，从功能上来说，已经非常稳定了。接下来的工作包括：

一，对接更多、更新的操作系统，或者对接一些新的技术。例如容器、TripleO等，还需要去对接Ubuntu 16.04。从今年开始，如果你要在Ubuntu上部署Mitaka版本，那你的选择只有Ubuntu 16.04，以及比如说你要支持接下来的N版本，那你也可能选择Ubuntu 16.04。因此社区的主要的工作重点，就是对于Ubuntu 16.04的一些支持和测试。最主要体现在三点：

• 就说是对Mitaka版本的一些相关测试。
• 集中在对Puppet4上的一些支持。
• 假如说这些工作都完成的话，社区会考虑到把接下来默认支持的操作系统从Ubuntu 14.04切到Ubuntu 16.04。包括从Puppet也会从Puppet3切到Puppet4等这些细节。

二，对OpenStack项目发布周期管理进行更细粒度的控制。OpenStack每6个月发一次新版本，比如Mitaka版本，在实际的很多项目中，并不是非常适用的。比如软件包，或者跟部署相关的项目其实是有依赖的。像PuppetOpenStack项目，或者Ansible项目，其实是依赖于社区发布的最终稳定版本。因此社区针对发布模型，设立了以下五种分支模型。我们最主要就讲第四种cycle-training。它的意思就是说，每当社区发布比如说以Nova为例，它发布了最终的稳定版本之后，只要有这个标签的这些项目，它们会在两周之后才去发布它的一个最终稳定版本。在这个周期内，它有一些非常严格，或者细粒度的一些约束来说明。

三，文档和wiki的改进。PuppetOpenStack发展至今，代码已经非常成熟，从刚开始简单的代码逻辑到后来复杂的代码逻辑，从使用角度来看，它越来越难以学习和入门了。所以社区在Newton版本中一项重要的工作，就是对文档的改进。目前有一个Puppet OpenStack Guide文档项目，主要是给一些刚接触PuppetOpenStack的工程师提供一个入门指导。其中会介绍比如说如何入门、怎么参与社区、如何写测试等等。

UnitedStack有云自动化部署发展路线图

UnitedStack有云的DevOps团队最近发布了《深入理解Openstack自动化部署》，把过去三年对于Openstack项目上积累的部署和运维经验分享出来，该书详细介绍了基础服务模块，例如消息队列、数据库、MC这些服务怎么去管理和配置以及有哪些使用技巧；也会讲到OpenStack服务里面核心项目中的重要概念和架构；还有PuppetOpenstack的公共库和工具类模块。可以通过微信扫描二维码即可获取这本名为《深入理解OpenStack自动化部署》的电子书。

UniedStack有云Devops 团队同时关注当前热门部署项目的现状和趋势。重要的关注内容包括：

TripleO项目。这个项目目前主要由红帽维护，它以OpenStack服务为基础平台来提供部署Openstack集群的能力，但是它的部署逻辑比较复杂，目前这个项目成熟度还不够，但是值得去关注。

还有当前热门的容器技术，称为容器配置管理系统，目前社区有两个非常热门的项目，一个叫Kolla，它是基于Ansible+Docker的，另外一个项目叫OpenStack Ansible（OSA），它是基于Python+Ansible+LXC来做的。每一种部署工具，它都有自己的适用场景，比如基于Python的技术团队，用Ansible的话，那就非常得心应手。而做应用开发的团队，非常适合用Docker来做业务变更。如果希望管理你的基础设施，例如管理OpenStack，同时还管理了基础服务，例如交换机、操作系统等，那么Puppet就非常合适。

UnitedStack有云的部署工具Ctask基于Ansible+Puppet，其中Ansible的主要作用为Orchestration（编排），我们在下一个阶段，会考虑怎么把日常的变更和扩容操作纳入到工具中，具体还包括其他几点：

• 如何将集成测试、性能测试和破坏性测试工具进行集成，以保证产品的质量，提高平台稳定性。
• 提高部署的灵活性。因为大家知道，在私有云领域里，用户跟云计算公司之间，其实是没有非常明确的界限的。就是很多需求，或者说很多功能，我们都需要临时地，或者非常灵活地去支持。也就是我们需要异常强大的管理能力。
• 最后就是结合一些检查工具，比如说由UnitedStack有云SDN团队开发网络检测工具Steth进行网络连通性的检查，以确保在部署的前期能够及时发现一些问题防患于未然。