Puppetlabs的Dan Bode在社区发起了一个项目叫做puppet-openstack

原文:

Puppetlabs的Dan Bode在社区发起了一个项目叫做puppet-openstack

NanShan 即时通讯 在这个时候,Puppetlabs的Dan Bode在社区发起了一个项目叫做puppet-openstack,目的是使用puppet来完成openstack的部署,最初这个项目大约由8个相关的module组成,参与人员有cisco,red hat等公司的工程师。这个过程中,我学会了如何使用这些模块来管理现有的集群,掌握了如何使用收集器,配置的存储和导出等等一些高级用法。

在此同时,我又发现其实这些模块并不完美,存在很多的bug,于是我对代码进行了修改,并在本地进行验证后,发送pull request到了puppet社区。社区的人很快就给我回复了,态度很nice,但指出了我非常低级的错误,老外很严谨,小到多一个多行,少一个空格都会在那标记。 
我在此过程中,逐渐熟悉了puppet的代码风格,学习了在提交代码前如何对puppet代码和erb模板做语法检查,使用puppet-lint对代码风格进行检查。时至今日,我每看到新人写的代码明显带有其他语言引入的奇怪风格时,都会严格地纠正,即使只是一个空格。 

因为openstack是一个迭代频繁的项目,因此配置文件的管理一直是让我们头疼的地方。从最初的模板到后来的concat方式来拼接配置文件,一直没有找到一个可以灵活管理配置文件的方法。后来iweb的magne提了一个patch,使用了自定义resource可以做到对每个选项灵活地管理。在这个过程中,我开始学习如何编写自定义resource,自定义function,自定义facter。 

当时又来了一个新任务,部署一个multi region的openstack集群(6个IDC)。我当时兴冲冲地使用site.pp开始定义每个机房的每台服务器的角色。当我写到第2个机房的时候,site.pp已经突破500行了。于是我开始对site.pp进行分割,使用import函数将每个机房节点的配置划分到一个文件中去。但我很快发现这仍然不适合做大规模的管理,于是我开始拿起这本书研究起ENC来,我编写了一个python脚本使用yaml格式的文件来管理节点的配置。现在仍然存在一个问题,那就是节点的配置和数据都存在一起,并不方便管理,并且好多参数的值其实是相同的,何必要重复定义呢?于是我又开始研究了hiera。 

那时,我是通过中心的一台puppet master节点来管理所有机房,有时会因为cpu跑满,导致complie catalog失败的情况,于是我又拿起了这本开始研究如何做HA。多台puppet master前面加个LB+KeepAlived解决了这个问题。在这个过程中,我掌握了如何解决多master节点的证书配置和证书同步。 

在此过程中,我把对于puppet-openstack的bug修复反馈到了社区,并且开始积极参与社区的ML和IRC中的讨论,涉及puppet的技术细节和openstack业务逻辑的抽象,这对我后来在开发内部项目puppet模块的影响很大。 


你可能感兴趣的:(集群,服务器,社区,工程师,即时通讯)