漫谈Puppet4

1. 激动人心的改进
   • 速度，速度，仍是速度
   • 稳定性和鲁棒性的提高
   • 全新的Parser
2. “不变"的agent
3. 不兼容的改动
   • 包管理方式的变化
   • 配置文件/目录的路径变化
   • 其余路径变化
   • Directory Environment正式启用
   • 再也不使用Ruby1.8.7
   • 下一代Puppet语言的改动
   • Puppet Kick等将被移除
   • HTTP API的变化
   • puppet doc和tagmail被移除
   • Resource Type/Providers的变化
   • 内部API和实现的变化
4. 被废弃的特性

5. 主要配置参数

   • Agent端
     • 基础参数
     • 运行相关
     • 服务相关
   • Server端
     • 主要参数
     • Server其余配置

6. 参考文档

 

注：本文同步更新到《深刻理解Openstack自动化部署》最佳实践章节： https://pom.nops.cloud/bestpractice/puppet4.html

 

激动人心的改进

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函数了：

$a = [1,2,3] each($a) |$value| { notice $value } 

• 全新的parser还直接支持数据类型检查，不再用stdlib里的validate_string等函数了:

class ntp ( 
    Boolean $service_manage = true, 
    Boolean $autoupdate     = false, 
    String  $package_ensure = 'present', 
    # ... 
) { 
   # ... 
}

• 另一个亮点是直接支持插值式函数调用:

notice "This is a random number: ${fqdn_rand(30)} 

• 支持链式赋值，代码能够变得更简洁了：

$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的系统下使用如下命令：

  yum localinstall http://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

• 在基于Deb的系统下使用如下命令：

  # 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 agent的vardir已经移动到/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端通讯。例如：

• 在Puppet3中url是"http://localhost:8140/production/node/foo"
• 在Puppet4中url变成了"http://localhost:8140/puppet/v3/node/foo?environment=production"。

puppet doc和tagmail被移除

因为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_command和postrun_command：在Puppet执行先后运行的命令，若返回值非0，则Puppet执行失败。

服务相关

• runinterval: Puppet的运行间隔
• waitforcert: Puppet请求证书签名的频率。当agent端第一次启动时，agent会提交一个CSR(certificate signing request)到ca server，该证书多是自动签名(autosign)，或者须要人工批准，而这段时间没法预估，所以须要设置一个时间段，默认是2m。
• splay和splaylimit：为每次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的内存分配。

参考文档

• https://docs.puppet.com/puppet/4.0/reference/whered_it_go.html
• https://docs.puppet.com/puppet/4.0/reference/release_notes.html
• https://puppet.com/blog/welcome-to-puppet-collections
• http://www.infoworld.com/article/2687553/devops/puppet-server-drops-ruby-for-clojure.html
• https://docs.puppet.com/puppet/latest/reference/puppet_collections.html