從執(zhí)行的模型來比較Sat、AnSibluppetPalletOps

本章里我們使用的配置管理系統(tǒng)有很多的相似之處，在客戶端節(jié)點運行代碼的方式有很多的不同：

對于Puppet來說，一個Puppet代理在Puppet服務(wù)器上注冊同時打開一個通信通道來獲取命令。這個過程通常會定期運行，一般每半個小時一次。

30分鐘不算快。你也可以配置一個更短的運行時間間隔。不管什么頻率運行，Puppet主要使用拉模型。客戶端必須檢查之后才知道那些修改可以用了?！?

Ansible通過SSH來推送期望的修改。這是推模式。

Salt使用的是推模式，但是實現(xiàn)的方式不同。它利用了ZeroMQ消息服務(wù)器，客戶端連接到消息服務(wù)器，監(jiān)聽修改的通知。工作原理和Puppet有點像，但是速度更快。

哪種方式最好一直是開發(fā)者社區(qū)爭執(zhí)的一個話題。消息隊列架構(gòu)的支持者認為速度很重要，而且它的速度更快。SSH方法的支持者認為簡單更加重要而且它足夠快。我個人傾向于后面的觀點。事情總會出簍子，復雜度增加時出問題的概率就更大。