返回介绍

Puppet4 的新特性和变化

发布于 2025-02-18 00:20:50 字数 12624 浏览 0 评论 0 收藏 0

激动人心的改进

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-agentPuppet, Facter, Hiera, MCollective, pxp-agent, root certificates, Ruby, Augeas
puppetserverPuppet Server,依赖 puppet-agent
puppetdbPuppetDB
puppetdb-terminiPuppetServer 与 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 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 服务
  • couchDB facts terminus
  • ActiveRecord stored config
  • puppet.conf 中 master section

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 令人激动人心,但配置管理系统的升级一定要谨慎对待,提前做好计划和回滚方案,充分测试,分步骤操作。

参考文档

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文