Question

Openstack 云平台是一个复杂的软件栈，涉及到大量的配置，服务，软件包等等多种系统资源的管理，人工管理的方式必然带来最终不可维护，人工失误等诸多问题。因此，我们需要使用一套统一框架解决配置管理上的问题。我们在过去发现了一点就是，工程师们通常喜欢在一个系统/工具上去套所有的应用场景。

首先，我们要明白任何一个工具/语言/系统都不是万能的。我们在使用一个工具/语言/系统前，必须深刻理解它的能力和局限。我们既然选择了 Puppet 作为配置管理系统，就应知道它能做什么，不能做什么。

什么场景下选择使用 Puppet?

Puppet 适合用于以下场景：

• network,host,dns 等文件的配置管理
• ssh,ntp,nscd 等服务的状态管理
• MySQL,Apache,RabbitMQ 等软件的包管理
• Openstack 软件的包安装，配置文件管理以及服务状态的管理
• Puppet 原生 resource type，如 ssh,host 等
• Puppet 第三方模块中的扩展 resource，如 keystone_user,mysql_database 等

什么场景下不选择使用 Puppet?

Puppet 不适合使用以下场景：

• 源码文件管理

  有人可能会使用 file resource 来管理一些项目的脚本，比如 zabbix 的 plugin scripts，这些代码文件通常作为静态文件放置在 files/目录下，在 agent 应用 catalog 的阶段，从 puppetserver 下载到各个服务器上。这样做有好多缺点：

  • 首先，每次代码文件的更新必须要更新相应模块，业务代码和部署代码完全耦合。
  • 其次，所有线上业务没统一的代码管理方式，在我们内部，所有项目必须使用 RPM 包的方式进行统一管理
  • 最后，每次执行 Puppet Agent 都会对每个文件单独计算 hash 值，并在服务器端做 hash 值比较，且会把旧文件备份到备份文件目录下，此操作会消耗客观的 CPU 和 IO 资源。
• 软件包的依赖管理

  例如在计算节点上，nova-compute 依赖 bridge-utils 包，有些工程师喜欢在 nova::compute 里去添加一个 package 资源来确保在计算节点上安装此包。正确的做法是在 nova 的 spec 文件里，对 openstack-nova-compute 组件新增一条包依赖关系。 我们应该明确包的依赖管理应该交给软件包管理工具去做。

• 二进制文件的管理

  我们可能会为一个业务系统添加一下方便管理，查询，统计或者清理的脚本，一些工程师的做法是将这些二进制可执行文件也丢到了 puppet module 的 file/目录下，随着项目的发展会出现大量的二进制文件，那么它们的归宿，要么放到该项目的 tools 目录，或者单独作为一个项目存在，例如 openstack_tools。

• 服务的初始化操作

  Puppet 中有个 exec 资源，有些工程师拿它来写非常复杂的 bash 脚本。这就类似使用 Python 的 subprocess 去写非常复杂的 bash 脚本一样，实现方式非常丑陋，而且低效。例如 Nova 服务的 db sync 操作，复杂的实现逻辑已经封装到了 Python 脚本中，Puppet 只是通过 exec{'nova-db-sync'}去调用 nova-manage db sync cli 接口。

  因此在遇到业务逻辑非常复杂或者代价太大就应该交给项目去实现，对外提供操作简单的接口，然后交给 Puppet 去调用，而不是由 Puppet 去实现。

 exec { 'nova-db-sync':
    command => "/usr/bin/nova-manage ${extra_params} db sync",
    refreshonly => true,
    logoutput => on_failure
 }

• 服务状态的监控和恢复

  有些工程师认为可以把 Puppet 的 runinterval 改成 60s，这样就可以使用 Puppet 做频繁的状态收敛来确保服务一直是处于运行状态，虽然在一定程度上，可以确保服务的运行状态，但这里有两个问题：

  • Puppet 既不是监控系统也不是专业的服务状态管理，60s 的执行间隔对于服务来说，简直是太长了
  • Server 端每次编译 catalog 会消耗大量资源，在集群数量增长或者 Puppet 代码逻辑复杂度提高后，你将会发现 catalog 的编译时间都已经超过了 60s 的执行间隔。

• 角色间或节点间的依赖管理处理

  Puppet 本身没有编排能力，只能处理同个节点内类之间或者服务之间的依赖关系，这是 Puppet 最大的硬伤。因此，Puppet 公司后来就收购了 Mcollective 来弥补编排的短板。我们这里推荐使用 Ansible 来做集群编排，Ansible 作为后起之秀，提供了基于 YAML 格式的配置管理和编排能力。