漫談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