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格式的配置管理和编排能力。