我們發(fā)現(xiàn)分布式是一個發(fā)展的趨勢汤善，無論是大型網(wǎng)站的負載均衡架構還是大數(shù)據(jù)框架部署，以及云存儲計算系統(tǒng)搭建都離不開多臺服務器的連續(xù)部署和環(huán)境搭建票彪。
當我們的基礎架構是分散式或者基于云的红淡，并且我們經(jīng)常需要處理在大部分相同的服務器上頻繁部署大致相同的服務時，我們就應該考慮自動化配置和維護了降铸。
讓用戶極容易配置和維護數(shù)十臺锉屈、數(shù)百臺、乃至數(shù)千臺服務器垮耳。
幸運的是颈渊，現(xiàn)在有很多運維管理工具是為此目的而設計的，它們能夠讓我們使用配方终佛，模板俊嗽，劇本（或者其他描述）來簡化環(huán)境搭建中的自動化和編排，以提供標準铃彰，一致的部署绍豁。
我們現(xiàn)在面臨的問題不是沒有選擇，而是選擇太多牙捉。
所以在選擇工具時竹揍，需要明確的是我們的需求，需要集中型的管理還是分布式的管理邪铲，還有環(huán)境的組成芬位，一些工具以不同的語言編寫，并且對特定操作系統(tǒng)或設置的支持可以不同带到。 最后確保我們選擇的工具與我們的環(huán)境和我們的團隊的特殊技能很好地融合在一起可以為我們節(jié)省很多精力昧碉。
下面我們分別來簡單了解下這幾種工具并且做對比。
Ansible
簡介
官網(wǎng)https://www.ansible.com/
Ansible介紹視頻： https://www.youtube.com/watch?v=iVWmbStE1MM
Ansible是用于在可重復的方式將應用程序部署到遠程節(jié)點和配置服務器的開源工具。 它為您提供了使用推送模型設置推送多層應用程序和應用程序工件的通用框架被饿，但如果愿意四康，您可以將其設置為主客戶端。 Ansible是建立在playbooks狭握，你可以應用于各種各樣的系統(tǒng)部署你的應用程序闪金。
這是Ansible Tower儀表板。
Ansible極其類似Salt论颅，而不太類似Puppet或Chef毕泌。Ansible關注的重點是力求精簡和快速，而且不需要在節(jié)點上安裝代理軟件嗅辣。因此撼泛，Ansible通過SSH執(zhí)行所有功能。Ansible基于Python;相比之下澡谭，Puppet和Chef基于Ruby愿题。
Ansible可以通過Git軟件庫克隆，安裝到Ansible主服務器上蛙奖。安裝完畢后潘酗，需要管理的節(jié)點被添加到Ansible配置環(huán)境，SSH授權密鑰被附加到每個節(jié)點上雁仲，這與運行Ansible的用戶有關仔夺。一旦完成了這步，Ansible主服務器可以通過SSH與節(jié)點進行通信攒砖，執(zhí)行所有必要的任務缸兔。為了與默認情況下不允許根SSH訪問的操作系統(tǒng)或發(fā)行版協(xié)同運行，Ansible接受sudo登錄信息吹艇，以便在那些系統(tǒng)上以根用戶的身份運行命令惰蜜。
Ansible可以使用Paramiko(基于SSH2協(xié)議的Python實現(xiàn))或標準SSH用于通信，不過還有一種加速模式受神，允許更快速抛猖、更大規(guī)模的通信。
針對確保服務在運行鼻听，或者觸發(fā)更新和重新啟動之類的簡單任務财著，Ansible可以從命令行來運行，不需要使用配置文件撑碴。至于比較復雜的任務撑教，Ansible配置通過名為Playbook的配置文件中的YAML語法來加以處理。Playbook還可以使用模板來擴展其功能灰羽。
Ansible有一大批模塊驮履，可用于管理各種系統(tǒng)以及亞馬遜彈性計算云(EC2)和OpenStack等云計算基礎設施×溃可以用幾乎任何一種語言來編寫自定義Ansible模塊玫镐，只要模塊輸出是有效的JSON。
Ansible的Web用戶界面以AnsibleWorks AWX的形式出現(xiàn)怠噪，但AWX與CLI并不直接聯(lián)系在一起恐似。這意味著，除非進行了同步過程傍念，否則CLI里面的配置元素不會出現(xiàn)在Web用戶界面中矫夷。你可以使用那個內置的同步工具，讓兩者保持一致憋槐，但需要按照預定計劃運行同步工具双藕。
何時使用
如果快速運行，方便對你很重要阳仔，我們不想把運維工具安裝在遠程節(jié)點或托管服務器代理商那里忧陪，那可以考慮Ansible漱受。 Ansible專注于精簡和快速琉朽，所以如果這些是我們的關鍵問題瞬沦，可以考慮一下Ansible胧卤。
ansible比較適合做“一次性”的工作撰洗，例如汉规，系統(tǒng)部署包斑、應用發(fā)布摘昌、打補丁等等斥杜。
在企業(yè)中使用ansible虱颗，要注意以下幾點：
- 安全控制，簡單來說就是避免用root用戶來執(zhí)行蔗喂。
- 控制好依賴 在寫playbook的時候上枕，控制好先后順序和依賴關系。
- 結果的收集和分析 因為一下子幾百臺機器一起干活弱恒，所以辨萍，就要自己寫外置腳本，更好地收集ansible的操作結果返弹，并且進行直觀的匯總和展現(xiàn)锈玉。
價格
有免費的開源版本支持10個節(jié)點以內的集群，付費的Ansible Tower在$ 5,000每年（它給你多達100個節(jié)點）支付計劃义起。
優(yōu)點
基于SSH拉背，因此不需要在遠程節(jié)點上安裝任何代理。
使用YAML語法易于學習默终。
Playbook結構簡單椅棺，結構清晰犁罩。
具有可變注冊功能，可使任務為以后的任務注冊變量
比一些其他工具更加精簡的代碼庫
缺點
不如基于其他編程語言的工具強大两疚。
它的邏輯通過它的DSL床估，這意味著需要經(jīng)常檢查文檔
即使是基本功能，也需要變量注冊诱渤，這使得更簡單的任務更復雜
內省很差丐巫。 很難看到playbooks里的變量的價值
輸入，輸出和配置文件的格式之間不一致
性能和速度有待加強
chef
簡介
官網(wǎng)https://www.chef.io/
Chef介紹視頻：https://www.youtube.com/watch?v=kDeRHgnuDzc
Chef是配置管理的開源工具勺美，專注于開發(fā)方為它的用戶群递胧。 廚師作為主客戶端模型運行，具有控制主人所需的單獨的工作站赡茸。 它基于Ruby缎脾，用純Ruby編寫的大多數(shù)元素。 廚師的設計是透明的占卧，并根據(jù)它給出的說明赊锚，這意味著你必須確保你的說明是清楚的。
Chef DashBoard
Chef的總體概念類似Puppet屉栓，因為在被管理的節(jié)點上安裝有主服務器和代理軟件舷蒲，但實際部署又不一樣。除了主服務器外友多，安裝的Chef環(huán)境還需要工作站來控制主服務器牲平。代理軟件可以借助使用SSH來部署的knife工具從工作站加以安裝，減輕了安裝負擔域滥。之后纵柿，被管理的節(jié)點通過使用證書，完成與主服務器之間的驗證启绰。
Chef的配置離不開Git昂儒，所以對Chef運作而言，了解Git如何工作是先決條件委可。與Puppet一樣渊跋，Chef同樣基于Ruby，所以還需要了解Ruby着倾。與Puppet一樣拾酝，模塊可以下載，也可以從頭開始編寫卡者，可以在所需配置之后部署到被管理的節(jié)點蒿囤。
與Puppet不一樣，Chef還沒有一項完善的推送功能崇决，不過提供了測試版代碼材诽。這意味著需要配置代理軟件底挫，以便與主服務器進行聯(lián)系，實際上不可能立即應用變更的內容脸侥。
企業(yè)版Chef的Web用戶界面很實用建邓，但不提供更改配置的功能。這個Web用戶界面不如Puppet企業(yè)版來得全面湿痢，缺少報告及其他功能涝缝，但允許庫存控制和節(jié)點組織扑庞。
與Puppet一樣譬重，Chef得益于一大批的模塊和配置菜譜，那些模塊和配置菜譜又高度依賴Ruby罐氨。由于這個原因臀规，Chef非常適合注重開發(fā)的基礎設施。
何時使用
考慮使用Chef的時候需要保證你會使用Git/Ruby栅隐，因為書寫配置的時候你會用到的塔嬉。 Chef非常適合以開發(fā)為中心的團隊和環(huán)境。 它對于尋找一個更加成熟的解決方案的企業(yè)非常適合異構環(huán)境租悄。
價格
有免費的開源版本谨究，超出限制數(shù)量的節(jié)點價格為6/節(jié)點/月或6/節(jié)點/月或 6.75 /節(jié)點/月。
優(yōu)點
豐富的模塊和配置配方集合泣棋。
代碼驅動的方法為您的配置提供更多的控制和靈活性胶哲。
圍繞Git提供強大的版本控制功能。
“Knife”工具（使用SSH從工作站部署代理）減輕了安裝負擔潭辈。
缺點
如果你還不熟悉Ruby和過程編碼鸯屿，學習曲線是很陡峭的。
這不是一個簡單的工具把敢，這可能導致大的代碼庫和復雜的環(huán)境寄摆。
不支持推送功能。
Fabric
簡介
官網(wǎng)http://www.fabfile.org/
Fabric介紹視頻：https://www.youtube.com/watch?v=VmcGuKPpWH8
Fabric是在應用程序部署精簡SSH一個基于Python的工具修赞。 它主要用于跨多個遠程系統(tǒng)運行任務婶恼，但也可以使用插件擴展以提供更高級的功能。 Fabric將配置您的系統(tǒng)柏副，執(zhí)行系統(tǒng)/服務器管理熙尉，并自動部署您的應用程序。
何時使用
如果你只是剛剛接觸部署自動化領域搓扯，F(xiàn)abric是一個很好的起點检痰。 如果你的環(huán)境涉及至少一點點Python，它是有幫助的锨推。
價格
免費
優(yōu)點
擅長部署以任何語言編寫的應用程序铅歼。 它不依賴于系統(tǒng)架構公壤，而是OS和包管
理器。
比這個領域的其他工具更簡單椎椰，更容易部署
與SSH進行廣泛集成厦幅，實現(xiàn)基于腳本的精簡
缺點
Fabric是單點故障設置（通常是您運行部署的機器）
雖然它是用于在大多數(shù)語言中部署應用程序的一個很好的工具，但它需要Python運行慨飘，因此您的Fabric環(huán)境中必須至少有一個Python确憨。
Puppet
簡介
官網(wǎng)https://puppet.com/
Puppet介紹視頻：https://www.youtube.com/watch?v=j8ImF23jZAg
Puppet是在全面配置管理空間長期工具之一。 它是一個開源工具瓤的，但考慮到它已經(jīng)存在多久休弃，它已經(jīng)被良好的審查和部署在一些最大和最苛刻的環(huán)境中。 Puppet基于Ruby圈膏，但是使用更接近JSON的定制的域腳本語言（DSL）來在其中工作塔猾。 它作為主客戶端設置運行，并使用模型驅動方法稽坤。 Puppet代碼設計作為依賴關系列表丈甸，這可以使事情更容易或更混亂，這取決于您的設置尿褪。
Puppet企業(yè)儀表板
Puppet也許是四款工具中最深入人心的睦擂。就可用操作、模塊和用戶界面而言杖玲，它是最全面的顿仇。Puppet呈現(xiàn)了數(shù)據(jù)中心協(xié)調的全貌，幾乎涵蓋每一個運行系統(tǒng)天揖，為各大操作系統(tǒng)提供了深入的工具夺欲。初始設置比較簡單，只需要在需要加以管理的每個系統(tǒng)上安裝主服務器和客戶端代理軟件今膊。
命令行接口(CLI)簡單直觀些阅，允許通過puppet命令下載和安裝模塊。然后斑唬，需要對配置文件進行更改市埋，好讓模塊適合所需的任務;應接到指令的客戶端與主服務器聯(lián)系時，會更改配置文件恕刘，或者客戶端通過立即觸發(fā)更改配置文件的推送(push)來進行更改缤谎。
還有一些模塊可以提供和配置云服務器實例和虛擬服務器實例。所有模塊和配置都使用基于Ruby的Puppet專屬語言或者Ruby本身構建而成褐着，因而除了系統(tǒng)管理技能外坷澡，還需要編程專業(yè)知識。
Puppet企業(yè)版擁有最全面的Web用戶界面含蓉，允許使用主服務器上的預制模塊和菜譜(cookbook)频敛，實時控制被管理的節(jié)點项郊。Web用戶界面很適合用于管理，但是不允許對模塊進行諸多配置斟赚。報告工具非常完善着降，提供了詳細信息，以便了解代理軟件運行如何拗军、已做出什么樣的變更任洞。
何時使用
Puppet是一個不錯的選擇，穩(wěn)定性和成熟是你選擇的關鍵因素发侵。 它對于DevOps團隊具有異構環(huán)境和技能范圍的大型企業(yè)很有好處交掏。
價格
Puppet可以使用免費開源版本，同時也提供收費企業(yè)版每年每節(jié)點$ 112與批量折扣付費商業(yè)企業(yè)版本器紧。
優(yōu)點
通過Puppet Labs建立良好的支持社區(qū)耀销。
它有最成熟的接口楼眷，幾乎在每個操作系統(tǒng)上運行铲汪。
簡單的安裝和初始設置。
在這個空間中最完整的Web UI罐柳。
強大的報告功能掌腰。
缺點
對于更高級的任務，您將需要使用基于Ruby的CLI（這意味著您必須理解Ruby）张吉。
支持純Ruby版本（而不是使用Puppet的定制DSL）正在縮減齿梁。
由于DSL和一個不專注于簡單性的設計，Puppet代碼庫可能會變得龐大肮蛹，笨重勺择，難以在更高規(guī)模的組織中接納新用戶。
與代碼驅動方法相比伦忠，模型驅動方法意味著更少的控制省核。
SaltStack
簡介
官網(wǎng)https://saltstack.com/
SaltStack（或Salt）是一個基于命令行的工具，可以設置一個主客戶端模式還是非集中模式昆码。 Salt基于Python气忠，提供了一種推送方法和一種與客戶端通信的SSH方法。 Salt允許對客戶端和配置模板進行分組赋咽，以簡化對環(huán)境的控制旧噪。
Salt類似Ansible，因為它也是基于CLI的工具脓匿，采用了推送方法實現(xiàn)客戶端通信淘钟。它可以通過Git或通過程序包管理系統(tǒng)安裝到主服務器和客戶端上∨阏保客戶端會向主服務器提出請求米母，請求在主服務器上得到接受后袱瓮，就可以控制該客戶端了。
Salt可以通過普通的SSH與客戶端進行通信爱咬，但如果使用名為minion的客戶端代理軟件尺借，可以大大增強可擴展性。此外精拟，Salt含有一個異步文件服務器燎斩，可以為客戶端加快文件服務速度，這完全是Salt注重高擴展性的一個體現(xiàn)蜂绎。
與Ansible一樣栅表，你可以直接通過CLI，向客戶端發(fā)出命令师枣，比如啟動服務或安裝程序包;你也可以使用名為state的YAML配置文件怪瓶，處理比較復雜的任務。還有“pillar”践美，這些是放在集中地方的數(shù)據(jù)集洗贰，YAML配置文件可以在運行期間訪問它們。
你可以直接通過CLI陨倡，向客戶端請求配置信息敛滋，比如內核版本或網(wǎng)絡接口方面的詳細信息。只要使用名為“grain”的庫存元素兴革，就可以描述客戶端;這樣一來绎晃，管理員可以輕松向某一種類型的服務器發(fā)出命令，不需要依賴已配置群組杂曲。比如說庶艾，只要使用一個CLI命令，你就可以向運行某個內核版本的每個客戶端發(fā)送命令擎勘。
與Puppet咱揍、Chef和Ansible一樣，Salt也提供了大量的模塊货抄，以處理特定的軟件述召、操作系統(tǒng)和云服務。自定義模塊可以用Python或PyDSL來編寫蟹地。除了Unix管理外积暖，Salt的確提供Windows管理功能，但它還是更擅長管理Unix和Linux系統(tǒng)怪与。
Salt的Web用戶界面Halite非常新夺刑，功能不如其他系統(tǒng)的Web用戶界面來得全面。它提供了事件日志和客戶端狀態(tài)的視圖，能夠在客戶端上運行命令遍愿，但除此之外乏善可陳存淫。
Salt的最大優(yōu)點在于可擴展性和彈性。你可以有多個級別的主服務器沼填。上游主服務器可以控制下游主服務器及其客戶端桅咆。另一個優(yōu)點在于對等系統(tǒng)，讓客戶端可以向主服務器提出問題坞笙，然后主服務器從其他服務器得到答案岩饼，提供全面信息。如果需要在實時數(shù)據(jù)庫中查詢數(shù)據(jù)薛夜，以便完成客戶端的配置籍茧，這個優(yōu)點就很方便。
何時使用
Salt是一種不錯的選擇梯澜，它對系統(tǒng)管理員很有好處寞冯，因為它的可用性比較好。
價格
免費的開源版本晚伙，這是基于每年每節(jié)點訂閱的基礎上SaltStack Enterprise版本吮龄。 具體定價不在他們的網(wǎng)站上列出（只有“聯(lián)系我們”鏈接），但其他人報告每個節(jié)點每年150美元起撬腾。
優(yōu)點
一旦您完成設置階段螟蝙，即可輕松組織和使用恢恼。
他們的DSL是功能豐富民傻，并不是邏輯和狀態(tài)所必需的。
輸入场斑，輸出和配置非常一致 - 所有YAML漓踢。
內省是非常好的。 很容易看到Salt內發(fā)生了什么漏隐。
強大的社區(qū)喧半。
在主模型中具有minions和層級層次的高可擴展性和彈性。
缺點
很難設置和挑選新用戶青责。
文檔在介紹層面很難理解挺据。
Web UI比空間中的其他工具的Web UI更新，更不完整脖隶。
對非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
工具 語言 架構 協(xié)議
Puppet Ruby C/S HTTP
Chef Ruby C/S HTTP
Ansible Python 無Client SSH
Saltstack Python C/S(可無Client) SSH/ZMQ/RAET
使用哪種配置管理或部署自動化工具將取決于您的環(huán)境的需求和首選項。 Chef和Puppet是一些較老的，更成熟的選擇王暗，使它們適合于那些重視成熟度和穩(wěn)定性而不是簡單性的大型企業(yè)和環(huán)境悔据。
Ansible和SaltStack是那些尋求快速和簡單的解決方案，而在不需要支持quirky功能或大量的操作系統(tǒng)的環(huán)境中工作的人的好選擇俗壹。
Fabric是小型環(huán)境和那些尋求更低人力和入門級解決方案的好工具科汗。
Puppet和Chef會吸引廣大開發(fā)人員和注重開發(fā)的公司，而Salt和Ansible極其適合系統(tǒng)管理員的要求绷雏。Ansible的簡潔界面和可用性非常迎合系統(tǒng)管理員的想法;而在擁有許多Linux和Unix系統(tǒng)的公司肛捍，Ansible運行起來一開始就快速又輕松。
Salt是四款工具中最漂亮最穩(wěn)健的;與Ansible一樣之众，它也會博得系統(tǒng)管理員的芳心拙毫。Salt擁有高擴展性和強大功能，唯一的軟肋就是Web用戶界面棺禾。
Puppet是這四款工具中最成熟的缀蹄，因為web管理界面不錯從可用性的角度來看恐怕也最容易上手，不過竭力建議你對Ruby要有深入了解膘婶。Puppet不如Ansible或Salt來得精簡缺前，配置起來有時會變得錯綜復雜。對異構環(huán)境來說悬襟，Puppet是最穩(wěn)妥的選擇衅码，但是你可能會發(fā)覺Ansible或Salt比較適合更龐大或更一致的基礎設施。
Chef擁有穩(wěn)定的脊岳、精心設計的布局逝段，雖然它在原始功能方面遠未達到Puppet的水平，但這是款功能非常強大的解決方案割捅。要是管理員缺乏豐富的編程經(jīng)驗奶躯，Chef學起來可能最困難，但它也許最適合注重開發(fā)的管理員和開發(fā)部門亿驾。
Ansible或者Puppet
哪個最好
存在即是合理嘹黔，起碼是存在3年以上的；沒有最好的莫瞬，只有合適的儡蔓，你說白菜和青菜哪個最好？
一般來說疼邀，有兩種配置管理：
- 推模式
- 拉模式
兩種模式有不同的擅長點喂江，有不同的使用場景。
拉模式 (puppet)
這種模式主張去中心化的設計思路檩小，典型代表 puppet开呐。一般實現(xiàn)多為在每個節(jié)點上部署 agent，定時獲取該節(jié)點的配置信息，根據(jù)配置信息配置本節(jié)點筐付。如果一次配置失敗了卵惦，那么下次繼續(xù)嘗試，直到地老天荒瓦戚。這個節(jié)點完全不管其他節(jié)點的執(zhí)行情況沮尿，一心只顧做好自己的事情。
所以它比較適合這種場景：
對配置何時生效不敏感较解，不關心的畜疾。你知道它總是會生效的，可能是下一分鐘印衔，也可能是下個小時啡捶，但是對你沒什么影響。
節(jié)點和節(jié)點之間不需要協(xié)作的奸焙。比如這種 場景就不合適： A 先升級瞎暑，然后 B 在升級。
即使某一次拉取信息失敗了与帆，下一次還能補上了赌，所以比較適合跨地域的大規(guī)模部署。
推模式 (ansible)
推模式有一個中心節(jié)點玄糟，用于將最新的配置信息推到各個節(jié)點上勿她，典型代表 ansible。很明顯阵翎，推模式的瓶頸就在中心節(jié)點逢并，如果同一時間有 10000 個節(jié)點需要更新配置，那么中心節(jié)點如何穩(wěn)定的工作就比較有學問贮喧。
它比較適合這種場景：
對配置生效的時間敏感筒狠，十分關心。必須讓他們即可生效箱沦，如果不生效，立馬要采取行動讓他們生效雇庙。
配置生效的順序十分關心和敏感谓形。比如需要這10個節(jié)點一起生效，或者按照依次生效疆前。
執(zhí)行順序的區(qū)別
配置生效順序在 puppet 和 ansible 之間有很大的不同寒跳，理解這些區(qū)別對于如何選擇配置管理至關重要。下面舉例說明兩者的區(qū)別：
假設現(xiàn)在有三個節(jié)點 host1竹椒，2童太，3，它們需要執(zhí)行配置更新的三個步驟：1，2书释，3（圓圈表示）翘贮，我們用圖來表示三個節(jié)點上的三個步驟執(zhí)行順序是如何的。
puppet 的執(zhí)行順序如圖所示爆惧，因為拉模式不管不顧其他節(jié)點的執(zhí)行情況狸页，專心致志完成自己的任務，所以節(jié)點之間的更新步驟完全隨機扯再。這種更新方法很“分布式”芍耘，跑得快的節(jié)點可以很快地跑完全程，不用等其他慢的小伙伴熄阻，沒有短板斋竞，沒有瓶頸。
ansible 的執(zhí)行順序如上圖所示秃殉。由于有一個中心節(jié)點控制所有機器的配置更新窃页。只有一個步驟在 所有 節(jié)點上完成后，才會繼續(xù)下一個步驟复濒，所以三個節(jié)點的執(zhí)行順序會很整齊脖卖。這種更新方法目的很明確，就是要“整齊”巧颈，跑的快的節(jié)點需要等待其他小伙伴完成這個步驟后畦木，大家在進行下一個步，誰都不允許自己先執(zhí)行下一步砸泛。
不過 ansible 2.0 中新增加了一種 playbook 的執(zhí)行策略：free strategy十籍，它允許某個 playbook 不再“整齊”的執(zhí)行，而是像 puppet 一樣唇礁，每個節(jié)點 try best 的跑到終點勾栗，而不用管其他節(jié)點執(zhí)行的情況如何。
如何選擇
雖然 puppet 和 ansible 有一定的功能重疊盏筐，比如都支持配置文件模版围俘，裝包，啟動服務琢融，等等界牡，但是仍然有區(qū)別。如何選擇漾抬？只能說“視情況而定”宿亡。
如果你的團隊已經(jīng)有合適的配置管理，并且已經(jīng)能否覆蓋 90% 的場景纳令，那么很幸運挽荠，不需要換配置管理工具克胳。
如果如 puppet 順序圖所示的情況你不能接受，那么最好選擇 ansible圈匆。
如果一開始選擇了 ansible漠另，并且對“整齊”不敏感，不關心臭脓，那么可以使用 free strategy酗钞，或者用 ansible-pull [3]。
如果已經(jīng)使用 puppet 好多年来累，并且對于“不整齊”執(zhí)行沒什么顧慮砚作，不關心，不敏感嘹锁，那么繼續(xù)使用 puppet葫录。
如果已經(jīng)使用 puppet 好多年，并且對于“不整齊”有顧慮领猾，很敏感米同，但是又不想拋棄已有的 puppet modules，因為它們已經(jīng)很穩(wěn)定了摔竿，那么可以選擇使用 Mcollective 改造面粮，或者用 ansible 調用 puppet，或者兩者一起用继低。
Atlassian 公司（做 Jira 的公司）已經(jīng)給我們介紹了經(jīng)驗
我們用 Ansible 創(chuàng)建 AWS 虛擬機熬苍，將它們放進 DNS，和負載均衡后面袁翁，然后用 Puppet 管理這些虛擬機的操作系統(tǒng)的配置柴底。當它們完成后，再使用 Ansible 管理應用層軟件的部署和升級粱胜。
SaltStack或Ansible
SaltStack與Ansible都是Python寫的而且較新柄驻，網(wǎng)上評論也很好。
1焙压、是否需要每臺機器部署agent（客戶端）
很多選用ansible的朋友鸿脓，都是因為agentless這個原因，覺得要維護agent很麻煩冗恨。
而一些使用saltstack比較順的朋友答憔，覺得這個問題無所謂，agent出問題的概率有掀抹，但不高。
其實ansible也支持agent的方式心俗，即所謂的“pull”的模式傲武，就是通過一個客戶端去拉取要執(zhí)行的任務蓉驹。
2、大規(guī)模并發(fā)的能力
這方面的對比已經(jīng)比較多了揪利，因為實現(xiàn)機制的差異态兴，也導致saltstack在這方面是占優(yōu)的。不過對于幾十臺-200臺規(guī)模的兄弟來講疟位，ansible的性能也可接受瞻润。
注：前期調研的大多數(shù)都是中下企業(yè)，服務器規(guī)模一般不超過200臺甜刻，所以對這個問題不算太看重绍撞。如果一次操作的機器過千臺，可能還是用saltstack效率更高一些得院。
ansible的執(zhí)行架構已經(jīng)有所優(yōu)化傻铣，采用基于MQ的agent機制，已支持比較大規(guī)模（1000-10000臺）的服務器的批量自動化運維祥绞。這樣非洲，在這種存在大規(guī)模運維的需求的客戶這里，也可以應用豐富的ansible的Playbook了蜕径。
3两踏、二次開發(fā)擴展的能力
ansible和saltstack都是基于python的，而python在運維開發(fā)這個圈子里接受度還是非常高的兜喻，二次開發(fā)的人員相對也好招梦染。
這也是這兩個工具相對于puppet和chef更容易被接受度原因，這兩個曾經(jīng)的主流工具都是基于ruby虹统，而現(xiàn)在ruby的活躍度越來越低了弓坞，要招人也不容易。
ansible和saltstack都具備很好的二次開發(fā)擴展能力车荔，可以寫YAML編排渡冻。
4、開源社區(qū)的對接
在github上忧便，ansbile有18300多顆星族吻，salt有6700多顆星。
直接按關鍵字搜索珠增，ansible的相關項目也更多一些超歌。
這些指標雖然不能直接說明什么，但很多技術人員會關注自己所使用的技術的活躍度蒂教。
一般來說巍举，越活躍的開源項目，得到的關注會更高些凝垛，功能完善和問題解決的效率也會更高懊悯。
5蜓谋、學習的門檻
從第一次使用來講，ansible的部署配置會更簡單一些炭分。
從官方文檔的質量來看桃焕，saltstack就比ansible要好一些。
從國內的中文資料來說捧毛，ansbile和saltstack好像各有2-3本中文書观堂。 這兩家的國內用戶組也分別在做一些技術資料翻譯的工作。
6呀忧、操作界面的友好程度
試用過Ansible的Tower师痕，但實在是不喜歡這種操作習慣，只能說勉強可用荐虐。 saltstack的沒仔細用過七兜，但看過朋友搭建的環(huán)境，感覺官方的UI還可以福扬，基本夠用了腕铸。Ansible的最初設計定位就不是一個完整的運維管理系統(tǒng)，因此官方UI粗糙些也在預料之中铛碑。
7狠裹、第三方工具的豐富程度
ansibe有一個galaxy站點：Ansible Galaxy
這個站點集合了3000多個第三方開發(fā)的Role/Playbook。
salt也有一些預先寫好的Formulas（Formulas are pre-written Salt States）
官方地址：Salt Formulas
github地址：Salt Stack Formulas · GitHub
目前已有的Formulas大概在200個左右汽烦，比ansible galaxy少了一個數(shù)量級涛菠，不過大部分常用軟件也覆蓋到了。
8撇吞、現(xiàn)有用戶使用的規(guī)模
根據(jù)rightscale的調研報告：
Ansible在2015年有10%的用戶選用俗冻，而2016年有20%的用戶選用。 Saltstack在2015年有6%的用戶選用牍颈，而2016年有9%的用戶選用迄薄。
9、對Windows支持的友好程度
ansible對windows的支持簡直不忍直視煮岁，agentless只是對于linux的讥蔽，windows要安裝bug修復補丁，powershell還要3.0画机，還要安裝python冶伞。還不如salt方便。salt有對windows的支持步氏，但是也不是很好响禽。
我們自己目前是用的Ansible，但正在結合我們自己的DevOps平臺，重新給Ansible開發(fā)一套WEB UI金抡。
前一段時間用了saltstack瀑焦，免不得要談一下他們的優(yōu)缺點腌且。兩者都是安裝和使用都非常方便的批量管理軟件梗肝。
1、salt要安裝agent铺董；ansible不需要巫击，通過ssh連接，省掉裝agent的事精续。
2坝锰、salt在server端要啟進程；ansible不需要重付，但這都無所謂差不多顷级。
3、salt與ansible都有模塊确垫，可使用任意語言開發(fā)模塊弓颈。
4、salt與ansible都使用yaml語言格式編寫劇本删掀。
ansible由于走的是ssh,所以它有認證的過程翔冀，以及加密碼的過程，這使得ansible非常慢逾苫，不適用于大規(guī)模環(huán)境（指上千臺）便脊。
為什么我放棄salt呢恶迈，首先服務器不多（百臺左右），其次控硼，salt的master端與minion端TCP連接經(jīng)常斷開，導致有時執(zhí)行命令時會漏機器艾少，這簡直讓我忍無可忍卡乾。聽說最新版的salt好了很多，但由于公司系統(tǒng)是定制的姆钉，安裝軟件特別麻煩（15M的系統(tǒng)说订，解決依賴就是個大問題），我還是選擇了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
