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

由于使用了AIO的包管理方式，Puppet不再使用系統自帶的Ruby解釋器，将直接使用Ruby 2.1.5版本。

重點來了，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

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子產品來找到它。

這裡舉幾個重要的變化：

• 在Puppet3中，若使用者沒有設定allow_virtual屬性，會有廢棄的警告資訊，在Puppet4中該警告會被移除，allow_vritual預設會從false變為true。

這些變化隻會影響到Puppet内部ruby方法和庫的調用接口，對終端使用者的使用沒有任何影響。

Rack和WEBrick Web伺服器被廢棄

Rack和WEBrick Web伺服器過去常用于開發和簡單驗證，目前已在Puppet 4.1中标記為棄用，計劃在5.0中移除。

Puppet4有多達200個配置參數，不過使用者需要關心的參數大約為30個。這裡我們隻是簡單介紹

puppet.conf

中的主要參數。

• 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。

多數參數對于單機模式運作的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

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

None