### 創建去中心化的分布式 Puppet 架構 > I have the world’s largest collection of seashells. I keep it scattered around the beaches of the world… perhaps you’ve seen it. > > — Steven Wright 某些系統（尤其像 Mafia）在去中心化的分布式架構環境下運行良好。 使用 Puppet 的一個最常見的方法是運行一個 Puppetmaster 服務器， Puppet 客戶端連接這個服務器并從它獲取配置清單。 無論如何，你仍舊可以使用下面的方法直接針對配置清單運行 puppet apply 命令。 （通常會使用 -v 參數開啟冗余輸出模式， 這樣就可以看到詳細的執行過程）： ``` # puppet apply -v manifest.pp info: Applying configuration version '1294313350' ``` 你甚至可以直接在命令行上運行配置清單的代碼片斷： ``` # puppet apply -e "file { '/tmp/test': ensure => present }" notice: /Stage[main]//File[/tmp/test]/ensure: created ``` 換言之，如果能安排合適的配置清單并分發到客戶端，你就可以在 Puppet 客戶端上直接執行它，而不必使用中心化的 Puppetmaster 服務器。 這將消除單臺 Puppetmaster 服務器的性能瓶頸，也消除了單點故障。 與此同時，也避免了新增客戶端時 SSL 證書簽署以及證書交換的步驟。 將配置清單文件推送到客戶端有多種實現方法， 顯然 Git （或者其它版本控制系統，如 Mercurial 或 Subversion）能為你做絕大部分的工作。 你可以在本地編輯 Puppet 配置清單的本地副本，提交到 Git 并將更新推送到中心倉庫， 然后從 Git 中心倉庫自動將配置清單分發到客戶機。 #### 準備工作 如果你的 Puppet 配置清單還沒有納入 Git，請參考本章 [使用版本控制](#ch01sec01) 一節的操作步驟。 #### 操作步驟 1. 在客戶端使用如下命令對 Puppet 倉庫克隆一個裸倉庫（裸倉庫沒有工作區，只包含 .git 目錄中的所有內容）： ``` # git clone --bare ssh://git@repo.example.com/var/git/puppet ``` 2. 使用如下命令檢出裸倉庫內容到 /etc/puppet/ 目錄： ``` # git archive --format=tar HEAD | (cd /etc/puppet && tar xf -) ``` 3. 使用 Puppet 命令執行 site.pp 文件 ``` # puppet apply -v /etc/puppet/manifests/site.pp info: Applying configuration version '1294313353' ``` 一旦完成上面的工作，下一步就是配置倉庫的自動推送將變動推送到客戶端。 使用 Git 的 remote 命令可以實現此功能，即配置本地倉庫的遠程倉庫別名。例如： ``` # git remote add web ssh://git@web1.example.com/etc/puppet ``` 如果你有多個客戶端， 可以為同一個遠程別名添加多個 URL： ``` # git remote set-url --add webs ssh://git@web2.example.com/etc/puppet # git remote set-url --add webs ssh://git@web3.example.com/etc/puppet ... ``` 或者像這樣，簡單編輯 Git 配置文件 (.git/config) ： ``` [remote "web"] url = ssh://git@web1.example.com/etc/puppet url = ssh://git@web2.example.com/etc/puppet url = ssh://git@web3.example.com/etc/puppet ... ``` 4. 現在你可以使用如下命令從 Git 中心倉庫推送更新到任意一臺（或一組）客戶端： ``` # git push web ``` 5. 最后一步，每當客戶端接收到從 Git 中心倉庫的推送就應該更新它自己的 /etc/puppet 目錄。你可以使用 Git 的 postreceive 鉤子來實現此功能。 在你的倉庫中，創建一個名為 hooks/post-receive 的文件并為其設置可執行權限（0755）， 文件內容為： ``` #!/bin/sh git archive --format=tar HEAD | (cd /etc/puppet && tar xf -) ``` #### 工作原理 與連接 Puppetmaster 獲取已經編譯好的客戶端配置清單不同， 使用這種方式每個客戶端都要從本地副本編譯自己的配置清單。 每當 Git 中心服務器推送一次更新（或者從 Git 倉庫 checkout 檢出）就會重新編譯一次。 這大大高了網絡帶寬的利用率，因為客戶端不必每次運行時都連接 Puppetmaster。 同時也消除了單點故障，因為客戶端可以從任何分布式的 Git 倉庫 （這些倉庫的內容是由 Git 中心倉庫自動推送的）獲得更新。 使用基于 Git 的去中心化的分布式 Puppet 架構為你提供了一個非常靈活的處理方式。 你可以使用 SSH 密鑰來配置訪問控制，按需要允許每一個客戶端或一組客戶端的訪問。 例如：用于數據庫服務器的配置清單僅允許數據庫組的機器訪問獲取。 當然還需要一些額外的配置工作，但對于大多數小型組織是沒有必要的， 這種去中心化的 Puppet 部署方式提供了額外的靈活性，同時也適用于更為苛刻的權限控制環境。 #### 更多用法 如果你希望每次中心倉庫推送更新之后 Puppet 立即執行并應用更新， 可以編輯 post-receive 腳本來完成，或者執行你需要的其它的動作。 另外，你也可以手動運行 Puppet，還可以用 [從 cron 運行 Puppet](#ch01sec05) 一節描述的方法使用 cron 調度運行，但要記得是運行 puppet apply ， 而不是運行 puppet agent 。 使用基于 Git 的架構也存在一些缺點：不能使用 Puppet 提供的高級特性， 例如外部節點分類器（external node classifier）以及存儲配置（stored configuration）等。 不管怎樣，當你需要將 Puppet 的部署擴展到大量節點時，這是一種最簡單的實現方式。 你可以在 Stephen Nelson-Smith 的這篇文章里找到更多更詳細的關于這種架構的討論，文章地址是： [http://bitfieldconsulting.com/scaling-puppet-with-distributedversion-control](http://bitfieldconsulting.com/scaling-puppet-with-distributedversion-control) 。 #### 參見本書 * 本章的 [使用 Passenger 擴展 Puppet 的部署規模](#ch01sec09) 一節 * 本章的 [使用版本控制](#ch01sec01) 一節