OpenStack本身是一个非常复杂的软件栈，存在大量的服务，每个服务下又细分很多小的服务，每个小服务都是由一个软件包及其多个配置文件组成，手动管理需要消耗大量的人力和时间。PuppetLabs于2013年发起了Puppet-Openstack项目，并最终演变成了OpenStack Offical项目，对于Openstack软件的部署和管理带来了极大的方便。

1 Puppet OpenStack 简介

Puppet-Openstack项目是由PuppetLabs公司于2013年发起的开源项目，最初托管在Github上，半年后移入OpenStackCI体系。最初只有Keystone，Nova，Glance，Cinder等几个核心项目的modules，随后得到了RedHat，Cisco，Mirantis等公司的广泛支持，在社区贡献者的持续努力下，Puppet-Openstack项目从Stackforge孵化项目演变成了OpenStack Offical项目，目前隶属于Openstack Goverance项目。目前已构成了一套庞大而复杂的部署体系。目前Openstack 最新版本为15.z.y Train。

2 为什么要选择Puppet Openstack?

目前用于部署OpenStack的工具已非常广泛，为什么要选择它呢？或者说从技术角度来看，OpenStack自动化部署工具应该如何做技术选型？

1.Puppet-Openstack项目诞生于2013年，诞生时间早，社区参与贡献者众多，使得Puppet-Openstack项目非常成熟和稳定，这对于自动化运维来说是十分重要的考虑因素。
2.欧洲原子能机构CERN使用Puppet管理着世界上规模最为庞大的OpenStack集群，总计超过了一万台服务器。这从用户角度证明了Puppet-Openstack可以支持大规模Openstack集群的部署。
3.目前市场上存在大量的Openstack 相关的配置管理工具，比如：Ansible、Chef、K8s，下图是基于2017年的各配置工具市场占用率。

图中Fuel 和 Packstack 同样也使用Puppet openstack项目，可以看出大多数项目中Puppet的占用率，同时我们在实践过程中发现 Puppet 本生非常适合做大规模的集群配置管理，管理接近4000+ 云服务配置文件、软件迭代、变更发布等工作。

3 Puppet OpenStack 在云计算中的实践

在我们的日常运维工作中，Puppet openstack 包含几乎整个运维周期的配置、服务、软件包的管理，目前有如下项目的服务通过此项目管理：OpenStack 社区Nova、Neutron、Cinder、Glance、Trove CEPH 社区的块存储RBD。
下来我们看看Nova项目中puppet代码结构。
puppet-nova 模块用于配置和管理Nova服务，包括服务，软件包，配置文件，flavor，nova，cells等等。其中 nova，flavor, cell 等资源的管理是使用自定义的resource type来实现的。

代码逻辑

1）class nova
数据库、消息队列、日志、SSL的配置。
2）class nova::keystone::auth
管理Nova与Keystone 相关的认证相关的配置，包含创建用户、密码、 Endpoint 相关。

3）class nova::api
管理Nova API 服务配置。

Nova_config: 通过传参的方式去控制配置文件中参数。
Nova_paste_api_ini<| |> ~> Service[‘nova-api’] ：当有配置文件更新时，我们会自动触发对应的服务。

4）class nova::conductor
管理 Nova Conductor 服务配置。

nova::generic_service { 'conductor': enabled => $enabled, manage_service => $manage_service, package_name => $::nova::params::conductor_package_name, service_name => $::nova::params::conductor_service_name, ensure_package => $ensure_package, }

ensure_package：安装conductor 服务包。
manage_service：是否管理服务。
package_name ：管理 conductor包名称，即版本号管理

5）class nova::compute
管理计算VNC服务配置。

nova_config { 'DEFAULT/vnc_enabled': value => $vnc_enabled; 'DEFAULT/vncserver_proxyclient_address': value => $vncserver_proxyclient_address; 'DEFAULT/vnc_keymap': value => $vnc_keymap; }

nova_config：通过create_resource

函数去管理每台计算节点的VNC配置。

总结：Puppet-nova 模块中使用的资源整合的配置逻辑，并且通过角色耦合方式对单个服务进行管理，而对于公共服务通过入口文件 nova.pp 进行管理，这种方式组合不仅可以覆盖至每个配置文件参数，增强管理灵活度，也增加了代码可阅读性及松藕性。

数据管理

既然有了逻辑，那数据管理在Puppet openstack中是如何做到的呢？首先我们介绍一个Puppet openstack 组合项目叫做Hieradata，它是基于键值查询的数据配置工具，Hiera是一个可选工具，它的目标是：Hiera makes Puppet better by keeping site-specific data out of your manifests 它的出现使得代码逻辑和数据可以分离管理。
Hieradata 树形结构：

我们通过文件名来区分赋值与对应的服务应该使用哪些数据，那他们是怎么在文件中是使用的呢？

compute.yaml 计算服务数据

Puppet-nova 中我们提到过VNC 配置。

通过直接引用puppet-nova中的common类下面的变量给代码块中逻辑传输对应值。这样Puppet 在服务端编译成Catalog 日志后，发送给客户端转换成JSON文件后应用在每台机器上。

4 总结

OpenStack 本身是一个非常复杂的软件栈，大量的配置、每个服务下细分很多小的服务、而每个小服务都一个软件包，人工管理需要消耗大量人力和时间，选择一个适合当前环境的配置管理工具是非常必要的。

本文转载自公众号360云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/n9MoSTzMSKLbMrEOuZ70YA

创作场景

Puppet OpenStack 介绍