我們發(fā)現(xiàn)分布式是一個(gè)發(fā)展的趨勢(shì)，無論是大型網(wǎng)站的負(fù)載均衡架構(gòu)還是大數(shù)據(jù)框架部署，以及云存儲(chǔ)計(jì)算系統(tǒng)搭建都離不開多臺(tái)服務(wù)器的連續(xù)部署和環(huán)境搭建。
當(dāng)我們的基礎(chǔ)架構(gòu)是分散式或者基于云的，并且我們經(jīng)常需要處理在大部分相同的服務(wù)器上頻繁部署大致相同的服務(wù)時(shí)，我們就應(yīng)該考慮自動(dòng)化配置和維護(hù)了。
讓用戶極容易配置和維護(hù)數(shù)十臺(tái)、數(shù)百臺(tái)、乃至數(shù)千臺(tái)服務(wù)器。
幸運(yùn)的是，現(xiàn)在有很多運(yùn)維管理工具是為此目的而設(shè)計(jì)的，它們能夠讓我們使用配方，模板，劇本（或者其他描述）來簡(jiǎn)化環(huán)境搭建中的自動(dòng)化和編排，以提供標(biāo)準(zhǔn)，一致的部署。
我們現(xiàn)在面臨的問題不是沒有選擇，而是選擇太多。
所以在選擇工具時(shí)，需要明確的是我們的需求，需要集中型的管理還是分布式的管理，還有環(huán)境的組成，一些工具以不同的語言編寫，并且對(duì)特定操作系統(tǒng)或設(shè)置的支持可以不同。 最后確保我們選擇的工具與我們的環(huán)境和我們的團(tuán)隊(duì)的特殊技能很好地融合在一起可以為我們節(jié)省很多精力。
下面我們分別來簡(jiǎn)單了解下這幾種工具并且做對(duì)比。
Ansible
簡(jiǎn)介
官網(wǎng)https://www.ansible.com/
Ansible介紹視頻： https://www.youtube.com/watch?v=iVWmbStE1MM
Ansible是用于在可重復(fù)的方式將應(yīng)用程序部署到遠(yuǎn)程節(jié)點(diǎn)和配置服務(wù)器的開源工具。 它為您提供了使用推送模型設(shè)置推送多層應(yīng)用程序和應(yīng)用程序工件的通用框架，但如果愿意，您可以將其設(shè)置為主客戶端。 Ansible是建立在playbooks，你可以應(yīng)用于各種各樣的系統(tǒng)部署你的應(yīng)用程序。
這是Ansible Tower儀表板。
Ansible極其類似Salt，而不太類似Puppet或Chef。Ansible關(guān)注的重點(diǎn)是力求精簡(jiǎn)和快速，而且不需要在節(jié)點(diǎn)上安裝代理軟件。因此，Ansible通過SSH執(zhí)行所有功能。Ansible基于Python;相比之下，Puppet和Chef基于Ruby。
Ansible可以通過Git軟件庫克隆，安裝到Ansible主服務(wù)器上。安裝完畢后，需要管理的節(jié)點(diǎn)被添加到Ansible配置環(huán)境，SSH授權(quán)密鑰被附加到每個(gè)節(jié)點(diǎn)上，這與運(yùn)行Ansible的用戶有關(guān)。一旦完成了這步，Ansible主服務(wù)器可以通過SSH與節(jié)點(diǎn)進(jìn)行通信，執(zhí)行所有必要的任務(wù)。為了與默認(rèn)情況下不允許根SSH訪問的操作系統(tǒng)或發(fā)行版協(xié)同運(yùn)行，Ansible接受sudo登錄信息，以便在那些系統(tǒng)上以根用戶的身份運(yùn)行命令。
Ansible可以使用Paramiko(基于SSH2協(xié)議的Python實(shí)現(xiàn))或標(biāo)準(zhǔn)SSH用于通信，不過還有一種加速模式，允許更快速、更大規(guī)模的通信。
針對(duì)確保服務(wù)在運(yùn)行，或者觸發(fā)更新和重新啟動(dòng)之類的簡(jiǎn)單任務(wù)，Ansible可以從命令行來運(yùn)行，不需要使用配置文件。至于比較復(fù)雜的任務(wù)，Ansible配置通過名為Playbook的配置文件中的YAML語法來加以處理。Playbook還可以使用模板來擴(kuò)展其功能。
Ansible有一大批模塊，可用于管理各種系統(tǒng)以及亞馬遜彈性計(jì)算云(EC2)和OpenStack等云計(jì)算基礎(chǔ)設(shè)施?？梢杂脦缀跞魏我环N語言來編寫自定義Ansible模塊，只要模塊輸出是有效的JSON。
Ansible的Web用戶界面以AnsibleWorks AWX的形式出現(xiàn)，但AWX與CLI并不直接聯(lián)系在一起。這意味著，除非進(jìn)行了同步過程，否則CLI里面的配置元素不會(huì)出現(xiàn)在Web用戶界面中。你可以使用那個(gè)內(nèi)置的同步工具，讓兩者保持一致，但需要按照預(yù)定計(jì)劃運(yùn)行同步工具。
何時(shí)使用
如果快速運(yùn)行，方便對(duì)你很重要，我們不想把運(yùn)維工具安裝在遠(yuǎn)程節(jié)點(diǎn)或托管服務(wù)器代理商那里，那可以考慮Ansible。 Ansible專注于精簡(jiǎn)和快速，所以如果這些是我們的關(guān)鍵問題，可以考慮一下Ansible。
ansible比較適合做“一次性”的工作，例如，系統(tǒng)部署、應(yīng)用發(fā)布、打補(bǔ)丁等等。
在企業(yè)中使用ansible，要注意以下幾點(diǎn)：
- 安全控制，簡(jiǎn)單來說就是避免用root用戶來執(zhí)行。
- 控制好依賴 在寫playbook的時(shí)候，控制好先后順序和依賴關(guān)系。
- 結(jié)果的收集和分析 因?yàn)橐幌伦訋装倥_(tái)機(jī)器一起干活，所以，就要自己寫外置腳本，更好地收集ansible的操作結(jié)果，并且進(jìn)行直觀的匯總和展現(xiàn)。
價(jià)格
有免費(fèi)的開源版本支持10個(gè)節(jié)點(diǎn)以內(nèi)的集群，付費(fèi)的Ansible Tower在$ 5,000每年（它給你多達(dá)100個(gè)節(jié)點(diǎn)）支付計(jì)劃。
優(yōu)點(diǎn)
基于SSH，因此不需要在遠(yuǎn)程節(jié)點(diǎn)上安裝任何代理。
使用YAML語法易于學(xué)習(xí)。
Playbook結(jié)構(gòu)簡(jiǎn)單，結(jié)構(gòu)清晰。
具有可變注冊(cè)功能，可使任務(wù)為以后的任務(wù)注冊(cè)變量
比一些其他工具更加精簡(jiǎn)的代碼庫
缺點(diǎn)
不如基于其他編程語言的工具強(qiáng)大。
它的邏輯通過它的DSL，這意味著需要經(jīng)常檢查文檔
即使是基本功能，也需要變量注冊(cè)，這使得更簡(jiǎn)單的任務(wù)更復(fù)雜
內(nèi)省很差。 很難看到playbooks里的變量的價(jià)值
輸入，輸出和配置文件的格式之間不一致
性能和速度有待加強(qiáng)
chef
簡(jiǎn)介
官網(wǎng)https://www.chef.io/
Chef介紹視頻：https://www.youtube.com/watch?v=kDeRHgnuDzc
Chef是配置管理的開源工具，專注于開發(fā)方為它的用戶群。 廚師作為主客戶端模型運(yùn)行，具有控制主人所需的單獨(dú)的工作站。 它基于Ruby，用純Ruby編寫的大多數(shù)元素。 廚師的設(shè)計(jì)是透明的，并根據(jù)它給出的說明，這意味著你必須確保你的說明是清楚的。
Chef DashBoard
Chef的總體概念類似Puppet，因?yàn)樵诒还芾淼墓?jié)點(diǎn)上安裝有主服務(wù)器和代理軟件，但實(shí)際部署又不一樣。除了主服務(wù)器外，安裝的Chef環(huán)境還需要工作站來控制主服務(wù)器。代理軟件可以借助使用SSH來部署的knife工具從工作站加以安裝，減輕了安裝負(fù)擔(dān)。之后，被管理的節(jié)點(diǎn)通過使用證書，完成與主服務(wù)器之間的驗(yàn)證。
Chef的配置離不開Git，所以對(duì)Chef運(yùn)作而言，了解Git如何工作是先決條件。與Puppet一樣，Chef同樣基于Ruby，所以還需要了解Ruby。與Puppet一樣，模塊可以下載，也可以從頭開始編寫，可以在所需配置之后部署到被管理的節(jié)點(diǎn)。
與Puppet不一樣，Chef還沒有一項(xiàng)完善的推送功能，不過提供了測(cè)試版代碼。這意味著需要配置代理軟件，以便與主服務(wù)器進(jìn)行聯(lián)系，實(shí)際上不可能立即應(yīng)用變更的內(nèi)容。
企業(yè)版Chef的Web用戶界面很實(shí)用，但不提供更改配置的功能。這個(gè)Web用戶界面不如Puppet企業(yè)版來得全面，缺少報(bào)告及其他功能，但允許庫存控制和節(jié)點(diǎn)組織。
與Puppet一樣，Chef得益于一大批的模塊和配置菜譜，那些模塊和配置菜譜又高度依賴Ruby。由于這個(gè)原因，Chef非常適合注重開發(fā)的基礎(chǔ)設(shè)施。
何時(shí)使用
考慮使用Chef的時(shí)候需要保證你會(huì)使用Git/Ruby，因?yàn)闀鴮懪渲玫臅r(shí)候你會(huì)用到的。 Chef非常適合以開發(fā)為中心的團(tuán)隊(duì)和環(huán)境。 它對(duì)于尋找一個(gè)更加成熟的解決方案的企業(yè)非常適合異構(gòu)環(huán)境。
價(jià)格
有免費(fèi)的開源版本，超出限制數(shù)量的節(jié)點(diǎn)價(jià)格為6/節(jié)點(diǎn)/月或6/節(jié)點(diǎn)/月或 6.75 /節(jié)點(diǎn)/月。
優(yōu)點(diǎn)
豐富的模塊和配置配方集合。
代碼驅(qū)動(dòng)的方法為您的配置提供更多的控制和靈活性。
圍繞Git提供強(qiáng)大的版本控制功能。
“Knife”工具（使用SSH從工作站部署代理）減輕了安裝負(fù)擔(dān)。
缺點(diǎn)
如果你還不熟悉Ruby和過程編碼，學(xué)習(xí)曲線是很陡峭的。
這不是一個(gè)簡(jiǎn)單的工具，這可能導(dǎo)致大的代碼庫和復(fù)雜的環(huán)境。
不支持推送功能。
Fabric
簡(jiǎn)介
官網(wǎng)http://www.fabfile.org/
Fabric介紹視頻：https://www.youtube.com/watch?v=VmcGuKPpWH8
Fabric是在應(yīng)用程序部署精簡(jiǎn)SSH一個(gè)基于Python的工具。 它主要用于跨多個(gè)遠(yuǎn)程系統(tǒng)運(yùn)行任務(wù)，但也可以使用插件擴(kuò)展以提供更高級(jí)的功能。 Fabric將配置您的系統(tǒng)，執(zhí)行系統(tǒng)/服務(wù)器管理，并自動(dòng)部署您的應(yīng)用程序。
何時(shí)使用
如果你只是剛剛接觸部署自動(dòng)化領(lǐng)域，F(xiàn)abric是一個(gè)很好的起點(diǎn)。 如果你的環(huán)境涉及至少一點(diǎn)點(diǎn)Python，它是有幫助的。
價(jià)格
免費(fèi)
優(yōu)點(diǎn)
擅長(zhǎng)部署以任何語言編寫的應(yīng)用程序。 它不依賴于系統(tǒng)架構(gòu)，而是OS和包管
理器。
比這個(gè)領(lǐng)域的其他工具更簡(jiǎn)單，更容易部署
與SSH進(jìn)行廣泛集成，實(shí)現(xiàn)基于腳本的精簡(jiǎn)
缺點(diǎn)
Fabric是單點(diǎn)故障設(shè)置（通常是您運(yùn)行部署的機(jī)器）
雖然它是用于在大多數(shù)語言中部署應(yīng)用程序的一個(gè)很好的工具，但它需要Python運(yùn)行，因此您的Fabric環(huán)境中必須至少有一個(gè)Python。
Puppet
簡(jiǎn)介
官網(wǎng)https://puppet.com/
Puppet介紹視頻：https://www.youtube.com/watch?v=j8ImF23jZAg
Puppet是在全面配置管理空間長(zhǎng)期工具之一。 它是一個(gè)開源工具，但考慮到它已經(jīng)存在多久，它已經(jīng)被良好的審查和部署在一些最大和最苛刻的環(huán)境中。 Puppet基于Ruby，但是使用更接近JSON的定制的域腳本語言（DSL）來在其中工作。 它作為主客戶端設(shè)置運(yùn)行，并使用模型驅(qū)動(dòng)方法。 Puppet代碼設(shè)計(jì)作為依賴關(guān)系列表，這可以使事情更容易或更混亂，這取決于您的設(shè)置。
Puppet企業(yè)儀表板
Puppet也許是四款工具中最深入人心的。就可用操作、模塊和用戶界面而言，它是最全面的。Puppet呈現(xiàn)了數(shù)據(jù)中心協(xié)調(diào)的全貌，幾乎涵蓋每一個(gè)運(yùn)行系統(tǒng)，為各大操作系統(tǒng)提供了深入的工具。初始設(shè)置比較簡(jiǎn)單，只需要在需要加以管理的每個(gè)系統(tǒng)上安裝主服務(wù)器和客戶端代理軟件。
命令行接口(CLI)簡(jiǎn)單直觀，允許通過puppet命令下載和安裝模塊。然后，需要對(duì)配置文件進(jìn)行更改，好讓模塊適合所需的任務(wù);應(yīng)接到指令的客戶端與主服務(wù)器聯(lián)系時(shí)，會(huì)更改配置文件，或者客戶端通過立即觸發(fā)更改配置文件的推送(push)來進(jìn)行更改。
還有一些模塊可以提供和配置云服務(wù)器實(shí)例和虛擬服務(wù)器實(shí)例。所有模塊和配置都使用基于Ruby的Puppet專屬語言或者Ruby本身構(gòu)建而成，因而除了系統(tǒng)管理技能外，還需要編程專業(yè)知識(shí)。
Puppet企業(yè)版擁有最全面的Web用戶界面，允許使用主服務(wù)器上的預(yù)制模塊和菜譜(cookbook)，實(shí)時(shí)控制被管理的節(jié)點(diǎn)。Web用戶界面很適合用于管理，但是不允許對(duì)模塊進(jìn)行諸多配置。報(bào)告工具非常完善，提供了詳細(xì)信息，以便了解代理軟件運(yùn)行如何、已做出什么樣的變更。
何時(shí)使用
Puppet是一個(gè)不錯(cuò)的選擇，穩(wěn)定性和成熟是你選擇的關(guān)鍵因素。 它對(duì)于DevOps團(tuán)隊(duì)具有異構(gòu)環(huán)境和技能范圍的大型企業(yè)很有好處。
價(jià)格
Puppet可以使用免費(fèi)開源版本，同時(shí)也提供收費(fèi)企業(yè)版每年每節(jié)點(diǎn)$ 112與批量折扣付費(fèi)商業(yè)企業(yè)版本。
優(yōu)點(diǎn)
通過Puppet Labs建立良好的支持社區(qū)。
它有最成熟的接口，幾乎在每個(gè)操作系統(tǒng)上運(yùn)行。
簡(jiǎn)單的安裝和初始設(shè)置。
在這個(gè)空間中最完整的Web UI。
強(qiáng)大的報(bào)告功能。
缺點(diǎn)
對(duì)于更高級(jí)的任務(wù)，您將需要使用基于Ruby的CLI（這意味著您必須理解Ruby）。
支持純Ruby版本（而不是使用Puppet的定制DSL）正在縮減。
由于DSL和一個(gè)不專注于簡(jiǎn)單性的設(shè)計(jì)，Puppet代碼庫可能會(huì)變得龐大，笨重，難以在更高規(guī)模的組織中接納新用戶。
與代碼驅(qū)動(dòng)方法相比，模型驅(qū)動(dòng)方法意味著更少的控制。
SaltStack
簡(jiǎn)介
官網(wǎng)https://saltstack.com/
SaltStack（或Salt）是一個(gè)基于命令行的工具，可以設(shè)置一個(gè)主客戶端模式還是非集中模式。 Salt基于Python，提供了一種推送方法和一種與客戶端通信的SSH方法。 Salt允許對(duì)客戶端和配置模板進(jìn)行分組，以簡(jiǎn)化對(duì)環(huán)境的控制。
Salt類似Ansible，因?yàn)樗彩腔贑LI的工具，采用了推送方法實(shí)現(xiàn)客戶端通信。它可以通過Git或通過程序包管理系統(tǒng)安裝到主服務(wù)器和客戶端上?？蛻舳藭?huì)向主服務(wù)器提出請(qǐng)求，請(qǐng)求在主服務(wù)器上得到接受后，就可以控制該客戶端了。
Salt可以通過普通的SSH與客戶端進(jìn)行通信，但如果使用名為minion的客戶端代理軟件，可以大大增強(qiáng)可擴(kuò)展性。此外，Salt含有一個(gè)異步文件服務(wù)器，可以為客戶端加快文件服務(wù)速度，這完全是Salt注重高擴(kuò)展性的一個(gè)體現(xiàn)。
與Ansible一樣，你可以直接通過CLI，向客戶端發(fā)出命令，比如啟動(dòng)服務(wù)或安裝程序包;你也可以使用名為state的YAML配置文件，處理比較復(fù)雜的任務(wù)。還有“pillar”，這些是放在集中地方的數(shù)據(jù)集，YAML配置文件可以在運(yùn)行期間訪問它們。
你可以直接通過CLI，向客戶端請(qǐng)求配置信息，比如內(nèi)核版本或網(wǎng)絡(luò)接口方面的詳細(xì)信息。只要使用名為“grain”的庫存元素，就可以描述客戶端;這樣一來，管理員可以輕松向某一種類型的服務(wù)器發(fā)出命令，不需要依賴已配置群組。比如說，只要使用一個(gè)CLI命令，你就可以向運(yùn)行某個(gè)內(nèi)核版本的每個(gè)客戶端發(fā)送命令。
與Puppet、Chef和Ansible一樣，Salt也提供了大量的模塊，以處理特定的軟件、操作系統(tǒng)和云服務(wù)。自定義模塊可以用Python或PyDSL來編寫。除了Unix管理外，Salt的確提供Windows管理功能，但它還是更擅長(zhǎng)管理Unix和Linux系統(tǒng)。
Salt的Web用戶界面Halite非常新，功能不如其他系統(tǒng)的Web用戶界面來得全面。它提供了事件日志和客戶端狀態(tài)的視圖，能夠在客戶端上運(yùn)行命令，但除此之外乏善可陳。
Salt的最大優(yōu)點(diǎn)在于可擴(kuò)展性和彈性。你可以有多個(gè)級(jí)別的主服務(wù)器。上游主服務(wù)器可以控制下游主服務(wù)器及其客戶端。另一個(gè)優(yōu)點(diǎn)在于對(duì)等系統(tǒng)，讓客戶端可以向主服務(wù)器提出問題，然后主服務(wù)器從其他服務(wù)器得到答案，提供全面信息。如果需要在實(shí)時(shí)數(shù)據(jù)庫中查詢數(shù)據(jù)，以便完成客戶端的配置，這個(gè)優(yōu)點(diǎn)就很方便。
何時(shí)使用
Salt是一種不錯(cuò)的選擇，它對(duì)系統(tǒng)管理員很有好處，因?yàn)樗目捎眯员容^好。
價(jià)格
免費(fèi)的開源版本，這是基于每年每節(jié)點(diǎn)訂閱的基礎(chǔ)上SaltStack Enterprise版本。 具體定價(jià)不在他們的網(wǎng)站上列出（只有“聯(lián)系我們”鏈接），但其他人報(bào)告每個(gè)節(jié)點(diǎn)每年150美元起。
優(yōu)點(diǎn)
一旦您完成設(shè)置階段，即可輕松組織和使用。
他們的DSL是功能豐富，并不是邏輯和狀態(tài)所必需的。
輸入，輸出和配置非常一致 - 所有YAML。
內(nèi)省是非常好的。 很容易看到Salt內(nèi)發(fā)生了什么。
強(qiáng)大的社區(qū)。
在主模型中具有minions和層級(jí)層次的高可擴(kuò)展性和彈性。
缺點(diǎn)
很難設(shè)置和挑選新用戶。
文檔在介紹層面很難理解。
Web UI比空間中的其他工具的Web UI更新，更不完整。
對(duì)非Linux操作系統(tǒng)不是很好的支持。
SaltStack介紹視頻：https://www.youtube.com/watch?v=TQjE2I8CrzQ
Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack
選用Puppet、Chef、Ansible還是Salt，F(xiàn)abric
工具 語言 架構(gòu) 協(xié)議
Puppet Ruby C/S HTTP
Chef Ruby C/S HTTP
Ansible Python 無Client SSH
Saltstack Python C/S(可無Client) SSH/ZMQ/RAET
使用哪種配置管理或部署自動(dòng)化工具將取決于您的環(huán)境的需求和首選項(xiàng)。 Chef和Puppet是一些較老的，更成熟的選擇，使它們適合于那些重視成熟度和穩(wěn)定性而不是簡(jiǎn)單性的大型企業(yè)和環(huán)境。
Ansible和SaltStack是那些尋求快速和簡(jiǎn)單的解決方案，而在不需要支持quirky功能或大量的操作系統(tǒng)的環(huán)境中工作的人的好選擇。
Fabric是小型環(huán)境和那些尋求更低人力和入門級(jí)解決方案的好工具。
Puppet和Chef會(huì)吸引廣大開發(fā)人員和注重開發(fā)的公司，而Salt和Ansible極其適合系統(tǒng)管理員的要求。Ansible的簡(jiǎn)潔界面和可用性非常迎合系統(tǒng)管理員的想法;而在擁有許多Linux和Unix系統(tǒng)的公司，Ansible運(yùn)行起來一開始就快速又輕松。
Salt是四款工具中最漂亮最穩(wěn)健的;與Ansible一樣，它也會(huì)博得系統(tǒng)管理員的芳心。Salt擁有高擴(kuò)展性和強(qiáng)大功能，唯一的軟肋就是Web用戶界面。
Puppet是這四款工具中最成熟的，因?yàn)閣eb管理界面不錯(cuò)從可用性的角度來看恐怕也最容易上手，不過竭力建議你對(duì)Ruby要有深入了解。Puppet不如Ansible或Salt來得精簡(jiǎn)，配置起來有時(shí)會(huì)變得錯(cuò)綜復(fù)雜。對(duì)異構(gòu)環(huán)境來說，Puppet是最穩(wěn)妥的選擇，但是你可能會(huì)發(fā)覺Ansible或Salt比較適合更龐大或更一致的基礎(chǔ)設(shè)施。
Chef擁有穩(wěn)定的、精心設(shè)計(jì)的布局，雖然它在原始功能方面遠(yuǎn)未達(dá)到Puppet的水平，但這是款功能非常強(qiáng)大的解決方案。要是管理員缺乏豐富的編程經(jīng)驗(yàn)，Chef學(xué)起來可能最困難，但它也許最適合注重開發(fā)的管理員和開發(fā)部門。
Ansible或者Puppet
哪個(gè)最好
存在即是合理，起碼是存在3年以上的；沒有最好的，只有合適的，你說白菜和青菜哪個(gè)最好？
一般來說，有兩種配置管理：
- 推模式
- 拉模式
兩種模式有不同的擅長(zhǎng)點(diǎn)，有不同的使用場(chǎng)景。
拉模式 (puppet)
這種模式主張去中心化的設(shè)計(jì)思路，典型代表 puppet。一般實(shí)現(xiàn)多為在每個(gè)節(jié)點(diǎn)上部署 agent，定時(shí)獲取該節(jié)點(diǎn)的配置信息，根據(jù)配置信息配置本節(jié)點(diǎn)。如果一次配置失敗了，那么下次繼續(xù)嘗試，直到地老天荒。這個(gè)節(jié)點(diǎn)完全不管其他節(jié)點(diǎn)的執(zhí)行情況，一心只顧做好自己的事情。
所以它比較適合這種場(chǎng)景：
對(duì)配置何時(shí)生效不敏感，不關(guān)心的。你知道它總是會(huì)生效的，可能是下一分鐘，也可能是下個(gè)小時(shí)，但是對(duì)你沒什么影響。
節(jié)點(diǎn)和節(jié)點(diǎn)之間不需要協(xié)作的。比如這種 場(chǎng)景就不合適： A 先升級(jí)，然后 B 在升級(jí)。
即使某一次拉取信息失敗了，下一次還能補(bǔ)上，所以比較適合跨地域的大規(guī)模部署。
推模式 (ansible)
推模式有一個(gè)中心節(jié)點(diǎn)，用于將最新的配置信息推到各個(gè)節(jié)點(diǎn)上，典型代表 ansible。很明顯，推模式的瓶頸就在中心節(jié)點(diǎn)，如果同一時(shí)間有 10000 個(gè)節(jié)點(diǎn)需要更新配置，那么中心節(jié)點(diǎn)如何穩(wěn)定的工作就比較有學(xué)問。
它比較適合這種場(chǎng)景：
對(duì)配置生效的時(shí)間敏感，十分關(guān)心。必須讓他們即可生效，如果不生效，立馬要采取行動(dòng)讓他們生效。
配置生效的順序十分關(guān)心和敏感。比如需要這10個(gè)節(jié)點(diǎn)一起生效，或者按照依次生效。
執(zhí)行順序的區(qū)別
配置生效順序在 puppet 和 ansible 之間有很大的不同，理解這些區(qū)別對(duì)于如何選擇配置管理至關(guān)重要。下面舉例說明兩者的區(qū)別：
假設(shè)現(xiàn)在有三個(gè)節(jié)點(diǎn) host1，2，3，它們需要執(zhí)行配置更新的三個(gè)步驟：1，2，3（圓圈表示），我們用圖來表示三個(gè)節(jié)點(diǎn)上的三個(gè)步驟執(zhí)行順序是如何的。
puppet 的執(zhí)行順序如圖所示，因?yàn)槔Ｊ讲还懿活櫰渌?jié)點(diǎn)的執(zhí)行情況，專心致志完成自己的任務(wù)，所以節(jié)點(diǎn)之間的更新步驟完全隨機(jī)。這種更新方法很“分布式”，跑得快的節(jié)點(diǎn)可以很快地跑完全程，不用等其他慢的小伙伴，沒有短板，沒有瓶頸。
ansible 的執(zhí)行順序如上圖所示。由于有一個(gè)中心節(jié)點(diǎn)控制所有機(jī)器的配置更新。只有一個(gè)步驟在 所有 節(jié)點(diǎn)上完成后，才會(huì)繼續(xù)下一個(gè)步驟，所以三個(gè)節(jié)點(diǎn)的執(zhí)行順序會(huì)很整齊。這種更新方法目的很明確，就是要“整齊”，跑的快的節(jié)點(diǎn)需要等待其他小伙伴完成這個(gè)步驟后，大家在進(jìn)行下一個(gè)步，誰都不允許自己先執(zhí)行下一步。
不過 ansible 2.0 中新增加了一種 playbook 的執(zhí)行策略：free strategy，它允許某個(gè) playbook 不再“整齊”的執(zhí)行，而是像 puppet 一樣，每個(gè)節(jié)點(diǎn) try best 的跑到終點(diǎn)，而不用管其他節(jié)點(diǎn)執(zhí)行的情況如何。
如何選擇
雖然 puppet 和 ansible 有一定的功能重疊，比如都支持配置文件模版，裝包，啟動(dòng)服務(wù)，等等，但是仍然有區(qū)別。如何選擇？只能說“視情況而定”。
如果你的團(tuán)隊(duì)已經(jīng)有合適的配置管理，并且已經(jīng)能否覆蓋 90% 的場(chǎng)景，那么很幸運(yùn)，不需要換配置管理工具。
如果如 puppet 順序圖所示的情況你不能接受，那么最好選擇 ansible。
如果一開始選擇了 ansible，并且對(duì)“整齊”不敏感，不關(guān)心，那么可以使用 free strategy，或者用 ansible-pull [3]。
如果已經(jīng)使用 puppet 好多年，并且對(duì)于“不整齊”執(zhí)行沒什么顧慮，不關(guān)心，不敏感，那么繼續(xù)使用 puppet。
如果已經(jīng)使用 puppet 好多年，并且對(duì)于“不整齊”有顧慮，很敏感，但是又不想拋棄已有的 puppet modules，因?yàn)樗鼈円呀?jīng)很穩(wěn)定了，那么可以選擇使用 Mcollective 改造，或者用 ansible 調(diào)用 puppet，或者兩者一起用。
Atlassian 公司（做 Jira 的公司）已經(jīng)給我們介紹了經(jīng)驗(yàn)
我們用 Ansible 創(chuàng)建 AWS 虛擬機(jī)，將它們放進(jìn) DNS，和負(fù)載均衡后面，然后用 Puppet 管理這些虛擬機(jī)的操作系統(tǒng)的配置。當(dāng)它們完成后，再使用 Ansible 管理應(yīng)用層軟件的部署和升級(jí)。
SaltStack或Ansible
SaltStack與Ansible都是Python寫的而且較新，網(wǎng)上評(píng)論也很好。
1、是否需要每臺(tái)機(jī)器部署agent（客戶端）
很多選用ansible的朋友，都是因?yàn)閍gentless這個(gè)原因，覺得要維護(hù)agent很麻煩。
而一些使用saltstack比較順的朋友，覺得這個(gè)問題無所謂，agent出問題的概率有，但不高。
其實(shí)ansible也支持agent的方式，即所謂的“pull”的模式，就是通過一個(gè)客戶端去拉取要執(zhí)行的任務(wù)。
2、大規(guī)模并發(fā)的能力
這方面的對(duì)比已經(jīng)比較多了，因?yàn)閷?shí)現(xiàn)機(jī)制的差異，也導(dǎo)致saltstack在這方面是占優(yōu)的。不過對(duì)于幾十臺(tái)-200臺(tái)規(guī)模的兄弟來講，ansible的性能也可接受。
注：前期調(diào)研的大多數(shù)都是中下企業(yè)，服務(wù)器規(guī)模一般不超過200臺(tái)，所以對(duì)這個(gè)問題不算太看重。如果一次操作的機(jī)器過千臺(tái)，可能還是用saltstack效率更高一些。
ansible的執(zhí)行架構(gòu)已經(jīng)有所優(yōu)化，采用基于MQ的agent機(jī)制，已支持比較大規(guī)模（1000-10000臺(tái)）的服務(wù)器的批量自動(dòng)化運(yùn)維。這樣，在這種存在大規(guī)模運(yùn)維的需求的客戶這里，也可以應(yīng)用豐富的ansible的Playbook了。
3、二次開發(fā)擴(kuò)展的能力
ansible和saltstack都是基于python的，而python在運(yùn)維開發(fā)這個(gè)圈子里接受度還是非常高的，二次開發(fā)的人員相對(duì)也好招。
這也是這兩個(gè)工具相對(duì)于puppet和chef更容易被接受度原因，這兩個(gè)曾經(jīng)的主流工具都是基于ruby，而現(xiàn)在ruby的活躍度越來越低了，要招人也不容易。
ansible和saltstack都具備很好的二次開發(fā)擴(kuò)展能力，可以寫YAML編排。
4、開源社區(qū)的對(duì)接
在github上，ansbile有18300多顆星，salt有6700多顆星。
直接按關(guān)鍵字搜索，ansible的相關(guān)項(xiàng)目也更多一些。
這些指標(biāo)雖然不能直接說明什么，但很多技術(shù)人員會(huì)關(guān)注自己所使用的技術(shù)的活躍度。
一般來說，越活躍的開源項(xiàng)目，得到的關(guān)注會(huì)更高些，功能完善和問題解決的效率也會(huì)更高。
5、學(xué)習(xí)的門檻
從第一次使用來講，ansible的部署配置會(huì)更簡(jiǎn)單一些。
從官方文檔的質(zhì)量來看，saltstack就比ansible要好一些。
從國(guó)內(nèi)的中文資料來說，ansbile和saltstack好像各有2-3本中文書。 這兩家的國(guó)內(nèi)用戶組也分別在做一些技術(shù)資料翻譯的工作。
6、操作界面的友好程度
試用過Ansible的Tower，但實(shí)在是不喜歡這種操作習(xí)慣，只能說勉強(qiáng)可用。 saltstack的沒仔細(xì)用過，但看過朋友搭建的環(huán)境，感覺官方的UI還可以，基本夠用了。Ansible的最初設(shè)計(jì)定位就不是一個(gè)完整的運(yùn)維管理系統(tǒng)，因此官方UI粗糙些也在預(yù)料之中。
7、第三方工具的豐富程度
ansibe有一個(gè)galaxy站點(diǎn)：Ansible Galaxy
這個(gè)站點(diǎn)集合了3000多個(gè)第三方開發(fā)的Role/Playbook。
salt也有一些預(yù)先寫好的Formulas（Formulas are pre-written Salt States）
官方地址：Salt Formulas
github地址：Salt Stack Formulas · GitHub
目前已有的Formulas大概在200個(gè)左右，比ansible galaxy少了一個(gè)數(shù)量級(jí)，不過大部分常用軟件也覆蓋到了。
8、現(xiàn)有用戶使用的規(guī)模
根據(jù)rightscale的調(diào)研報(bào)告：
Ansible在2015年有10%的用戶選用，而2016年有20%的用戶選用。 Saltstack在2015年有6%的用戶選用，而2016年有9%的用戶選用。
9、對(duì)Windows支持的友好程度
ansible對(duì)windows的支持簡(jiǎn)直不忍直視，agentless只是對(duì)于linux的，windows要安裝bug修復(fù)補(bǔ)丁，powershell還要3.0，還要安裝python。還不如salt方便。salt有對(duì)windows的支持，但是也不是很好。
我們自己目前是用的Ansible，但正在結(jié)合我們自己的DevOps平臺(tái)，重新給Ansible開發(fā)一套WEB UI。
前一段時(shí)間用了saltstack，免不得要談一下他們的優(yōu)缺點(diǎn)。兩者都是安裝和使用都非常方便的批量管理軟件。
1、salt要安裝agent；ansible不需要，通過ssh連接，省掉裝agent的事。
2、salt在server端要啟進(jìn)程；ansible不需要，但這都無所謂差不多。
3、salt與ansible都有模塊，可使用任意語言開發(fā)模塊。
4、salt與ansible都使用yaml語言格式編寫劇本。
ansible由于走的是ssh,所以它有認(rèn)證的過程，以及加密碼的過程，這使得ansible非常慢，不適用于大規(guī)模環(huán)境（指上千臺(tái)）。
為什么我放棄salt呢，首先服務(wù)器不多（百臺(tái)左右），其次，salt的master端與minion端TCP連接經(jīng)常斷開，導(dǎo)致有時(shí)執(zhí)行命令時(shí)會(huì)漏機(jī)器，這簡(jiǎn)直讓我忍無可忍。聽說最新版的salt好了很多，但由于公司系統(tǒng)是定制的，安裝軟件特別麻煩（15M的系統(tǒng)，解決依賴就是個(gè)大問題），我還是選擇了ansible。
參考鏈接:
http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/
http://blog.51cto.com/liqilong2010/1850617
https://www.gaott.info/which-one-ansible-or-puppet/
https://www.zhihu.com/question/22707761
https://blog.csdn.net/zzq900503/article/details/80143740
