Puppet的能与不能

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不适合使用以下场景：

  • 源码文件管理

    有人可能会使用fileresource来管理一些项目的脚本，比如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 synccli接口。

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

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

  • 服务状态的监控和恢复

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

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

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

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