Puppet4新特性和变化

  1. 激动人心的改进
  2. “不变”的agent
  3. 不兼容的改动
  4. 被废弃的特性
  5. 主要配置参数
  6. 总结和建议
  7. 参考文档

激动人心的改进

Puppet4的第一个正式版本于2015年4月15日发布,截止到2016年9月22日,Puppet已正式发布了4.7.0版本。

Puppet4与3.x版本相比有两点不同:很多的变化,很大的变化。毫不夸张地说Puppet4是一个全新的项目!

速度,速度,还是速度

Puppet4使用函数式编程语言Clojure对Puppet Master进行了重写,Puppetlabs公司并为此新建了一个项目:puppetserver。此外,PuppetDB也使用Clojure进行了重写。

如此脱胎换骨的变化,最主要的目的是为了提升性能,官方给出的数据是:

相比Puppet3,Puppet4有2~3倍的性能提升。

这是一个非常吸引人的提升!要知道从Puppet2到Puppet3所带来约50%的性能提升,就让我们感动不已了!

在以往的实际生产中,我们遇到过多次来自于master端的性能瓶颈,在一个数千台规模有近百个Openstack集群规模的环境中,我们使用了多台物理+虚拟服务器来作为puppet master节点,管理着大量的服务,一旦遇到高并发的编排任务时,master端的CPU几乎处于100%的状态,超时时间设置为120秒的情况下,仍然会出现不少由于编译catalog超时而导致agent报错的情况。即使我们通过改进代码,水平扩展,组件拆分,参数调优,更换硬件等多种组合办法,但是受Puppet本身的语言性能瓶颈,对于Puppetmaster的性能我们并不满意。而Puppet4从根本上改进了性能问题。

PuppetDB也是主要瓶颈之一,像resource export,virtual resource等高级特性,以及facts,catalog的缓存都会使用到PuppetDB,虽然这些高级特性很炫酷而且也很实用,但是非常非常消耗资源。这使得我们在过去非常地谨慎甚至刻意去削减像Puppet高级特性的使用,这也是PuppetOpenstack社区禁止提交含有这些高级特性的代码的原因之一(另一个原因是有些高级特性无法再单机模式下使用)。

稳定性和鲁棒性的提升

此外,Puppet4一开始就拥有面向服务的架构:

  • 由于Clojure语言的天生优势,拥有良好的并发和互斥控制能力,而且可以使用丰富的Java Library,是作为后端服务开发的理想选择。
  • Puppetlabs公司开发了一个Clojure框架Trapperkeeper framework:为了支撑长期运行的应用和服务而生,从而保证Puppet服务的稳定性和鲁棒性。

全新的Parser

  • 新的Parser支持lambdas和iteraion!再也不用使用tricky的creates_resources函数了:
  1. $a = [1,2,3] each($a) |$value| { notice $value }
  • 全新的parser还直接支持数据类型检查,再也不用stdlib里的validate_string等函数了:
  1. class ntp (
  2. Boolean $service_manage = true,
  3. Boolean $autoupdate = false,
  4. String $package_ensure = 'present',
  5. # ...
  6. ) {
  7. # ...
  8. }
  • 另外一个亮点是直接支持插值式函数调用:
  1. notice "This is a random number: ${fqdn_rand(30)}
  • 支持链式赋值,代码可以变得更简洁了:
  1. $a = $b = 10

除了以上几点,还有其他诸多特性,受篇幅限制,不再一一举例。

“不变”的agent

目前,puppet-agent仍然使用Ruby来维护。不过JVM可以支持Ruby的Java版本:JRuby。因此在未来,puppet-agent不排除可能会从JRuby过渡到Clojure。

不兼容的改动

Puppet4既然做了重写,因此有大量与Puppet3不兼容的变化。这些细节对于Puppet3用户来说是最关心的地方。

包管理方式的变化

过去,我们需要在服务器上单独安装Puppet,Facter,Hiera,Mcollective等多个组件才能获得相应的功能和特性。

在Puppet4中,安装Puppet不再需要安装多个软件包,而是采用AIO(All-in-One)的方式来简化软件包的管理,例如puppet-agent中包含以下组件:

  • Facter 3.4.x
  • CFacter 0.4
  • Hiera 1.3.x
  • Mcollective 2.9.x
  • Ruby 2.1.5
  • OpenSSL 1.0.0r

Puppetlabs将这种AIO的包管理方式称之为Puppet Collections(PC),每个PC其实对应着一个软件仓库(repo),为用户提供了Facter/Ruby/Puppet等组件的匹配矩阵。
下表给出了PC中主要软件包中整合的组件。

软件包名 包含组件
puppet-agent Puppet, Facter, Hiera, MCollective, pxp-agent, root certificates, Ruby, Augeas
puppetserver Puppet Server,依赖puppet-agent
puppetdb PuppetDB
puppetdb-termini PuppetServer与PuppetDB交互的Plugin

要在服务器上启用新版本的Puppet4,只需要执行一行简单的命令:

  • 在基于RPM的系统下使用以下命令:

    1. yum localinstall http://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm
  • 在基于Deb的系统下使用以下命令:

    1. # curl -O http://apt.puppetlabs.com/puppetlabs-release-pc1-wheezy.deb ; dpkg -i puppetlabs-release-pc1-wheezy.deb

通过这种集中式的软件仓库管理方式,用户可以移除过去puppetlabs-release中的production,dependencies,devel等多个仓库。

注意 puppet-agent不会自动升级老版本的puppet软件包(建议使用deb或rpm来管理软件包的升级)

配置文件/目录的路径变化

  1. 软件包的安装目录变更为/opt/puppetlabs
  2. 可执行文件已移动到/opt/puppetlabs/bin
  3. confdir/etc/puppet/变为/etc/puppetlabs/puppet
  4. ssldir$vardir/ssl变为$confdir/ssl
  5. puppetserver的配置文件放置在/etc/puppetlabs/puppetserver
  6. mcollective的配置文件放置在/etc/puppetlabs/mcollective
  7. 所有的module/manifest/data从confdir移到codedir
    • codedir默认路径是/etc/puppetlabs/code
    • 包含environments目录
    • 包含全局的modules目录(可选)
    • 包含hiera.yaml配置文件
    • 包含hieradata目录

其他路径变化

  • puppet agentvardir已经移动到/opt/puppetlabs/puppet/cache
  • rundir已经移动到/var/run/puppetlabs

Directory Environment正式启用

过去多年的Config File Environment将被正式移除。默认的environmentpath是$codedir/environments

以新建一个production环境为例:

  • 将modules放置到$codedir/environments/production/modules
  • 将main manifest放置到$codedir/environments/production/manifests

你仍然可以使用$codedir/modules作为全局modules,并用default_manifest设置来配置一个全局的main manifest

不再使用Ruby1.8.7

由于使用了AIO的包管理方式,Puppet不再使用系统自带的Ruby解释器,将直接使用Ruby 2.1.5版本。

下一代Puppet语言的改动

重点来了,Puppet4最重要的变化是重写了parser和evaluator,在Puppet 3.x中可以通过在puppet配置文件中开启Future Parser来使用,在Puppet4中该parser已经成为”present parser“,那么过去的parser正式退出舞台

新parser包含了迭代,变量类型检查等诸多新特性。并且,新parser对于数值,空字符串和’udenf/nil’比较提供更好的检查机制。

除了核心模块的变动以外,还有一些炫酷的特性。

  • 在PuppetMaster加载新的Puppet代码不再需要重启server服务
  • EPP(Embeded Puppet)将支持直接使用Puppet来编写inline和基于文件模,不再需要使用ERB,避免用户在Puppet和Ruby之间来回切换。
  • 支持使用Puppet来编写functions。

Puppet Kick等将被移除

所有的项目在历史发展过程中,都会有很多的妥协和不良设计,Puppet项目从2到3很多旧有的特性只是被标记为废弃,并没有从代码库中移除,借助Puppet4版本的重构,大约60000行”technical debt”类型的代码被移除。
较为熟知的有以下:

  • puppet kick命令
  • inventory服务
  • couchDBfacts terminus
  • ActiveRecordstored config
  • puppet.conf中mastersection

HTTP API的变化

Puppet4中的另一个重要变化是master和agent通讯的URLs发生了变化。因此Puppet3的agent将无法和Puppet4的server端通信。例如:

puppet doctagmail被移除

由于puppet doc命令依赖RDoc,而RDoc与最新版本的ruby不兼容,因此在Puppet4代码中被移除,如果要继续使用,可以通过puppetlabs-strings模块来提供类似的功能。

同理,tagmail被移除,可以通过puppetlabs-tagmail模块来找到它。

Resource Type/Providers的变化

这里举几个重要的变化:

  • 在Puppet3中,若用户没有设置allow_virtual属性,会有废弃的警告信息,在Puppet4中该警告会被移除,allow_vritual默认会从false变为true。

内部API和实现的变化

这些变化只会影响到Puppet内部ruby方法和库的调用接口,对终端用户的使用没有任何影响。

被废弃的特性

Rack和WEBrick Web服务器被废弃

Rack和WEBrick Web服务器过去常用于开发和简单验证,目前已在Puppet 4.1中标记为弃用,计划在5.0中移除。

主要配置参数

Puppet4有多达200个配置参数,不过用户需要关心的参数大约为30个。这里我们只是简单介绍puppet.conf中的主要参数。

Agent端

基础参数

  • server: Puppet Master的地址,默认值是puppet
    • ca_server: Puppet CA的地址,仅在多master模式使用
    • report_server: Puppet report server的地址,仅在多master模式使用
  • certname:node的证书名称,默认使用FQDN
  • environment:agent向master端请求的environment。默认是prodcution

运行相关

  • noop: agent仅在模拟运行并输出运行结果
  • nice: 指定agent运行的nice值,防止agent在应用catalog时占用过多的CPU资源
  • report: 是否发生report,默认为true。
  • tags: 限制Puppet只运行含有指定tags的resources。
  • trace, profile, graph,show_diff:用于debug agent运行结果
  • usecacheonfailure: 在master端无法返回一个正确的catalog时,是否回退执行上一个正确的catalog。默认是true,如果是开发环境,建议修改为false。
  • prerun_commandpostrun_command:在Puppet执行前后运行的命令,若返回值非0,则Puppet执行失败。

服务相关

  • runinterval: Puppet的运行间隔
  • waitforcert: Puppet请求证书签名的频率。当agent端第一次启动时,agent会提交一个CSR(certificate signing request)到ca server,该证书可能是自动签名(autosign),或者需要人工批准,而这段时间无法预估,因此需要设置一个时间段,默认是2m。
  • splaysplaylimit:为每次Agent的定时执行添加一个随机数时间,用于避免惊群效应的发生。
  • daemonize:是否以进程方式运行,配合cron使用时,应设置为false。
  • onetime: 是否执行完成后退出,配合cron使用时,应设置为true。

Server端

多数参数对于单机模式运行的Puppet同样适用。在CS模式下,这些参数应该放置在[master]下;在单机模式下,这些参数应该放置在[main]下。

主要参数

  • dns_alt_names: Puppet Master可以使用的DNS主机名列表(alt表示a list)。agent用到的server参数值必须和此参数或者server端的certname匹配。

    • 注:该参数仅适用于初始化生成Puppet master证书阶段。
  • environment_timeout: master从environment加载数据的缓存时长。设置为0,禁用缓存,为了更好的性能,可以将其设置为unlimited,直到下次重启master才会重新加载environment配置。

  • enviromentpath: environment的查找路径,默认值:$codedir/environments
  • basemodulepath: 所有环境的模块路径,会被所有的环境使用,默认值是:
    $codedir/modules:/opt/puppetlabs/puppet/modules
  • reports: 选择处理report的hander,默认值是store

Server其他配置

pupept server除了puppet.conf之外,还有拥有其他的配置文件,其默认的配置文件路径是:/etc/puppetlabs/puppetserver/conf.d。这些配置文件使用HOCON格式,可以在保留JSON语义格式的前提下,提高可读性。在conf.d目录下包含以下配置文件:

  • global.conf
  • webserver.conf
  • web-routes.conf
  • puppetserver.conf
  • auth.conf
  • master.conf (deprecated)
  • ca.conf (deprecated)

例如,常见的几个参数配置有以下:

  • puppet-admin:授权可以访问admin接口的client
  • jruby-puppet: 调优JRuby时提供更多细节信息
  • JAVA_ARGS: 设置Puppet Server的内存分配。

总结和建议

相比Puppet2到Puppet3的版本升级,Puppet4不仅是纯粹的新功能和性能提升,更像是对Puppet的全新重构,摒弃了过去留下来的历史负担和诟病。但是,Puppet4所带来的不兼容性,导致对于Puppet3用户,尤其是Puppet 3.3版本之前的用户,若想要把线上的业务代码升级到Puppet4,需要花费不少的精力。

分享我们的升级经验:约在16年初,我们将线上的Puppet版本从3.3升级到了3.7,并提前使用了future parser特性(Puppet4中的parser)。16年9月,我们使用了半周时间完成了对Puppet4升级调研并给出调研报告,在Jira上列出计划和任务分工,实际使用了一周时间完成了96 Puppet Module代码更新和测试,并在生产环境上线。

因此我们的建议是:即使Puppet4令人激动人心,但配置管理系统的升级一定要谨慎对待,提前做好计划和回滚方案,充分测试,分步骤操作。

参考文档