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