SaltstackAnsible

SaltStack 依靠ZeroMQ速度快	Ansible SSH傳輸速度慢一些
ZeroMQ本身不加密，AES加密，需注意MITM攻擊	SSH安全性高
Master需要守護(hù)進(jìn)程	無額外開支，SSH即可
State語法需要學(xué)習(xí)	playbook語法相對簡單，容易學(xué)習(xí)
excution模塊+state模塊，state會調(diào)用excution模塊	Ansible模塊+playbook
使用topfile?top.sls?使用YAML	playbook使用YAML
圍繞Master輸入命令，首次連接使用加密key，使用ZeroMQ庫不會擁堵，持續(xù)連接速度更快	使用SSH通道，無固定Master，更安全，也有MQ版本
未提及	配置記錄文件，原始vs生產(chǎn)
默認(rèn)本地root，客戶端root	支持多用戶sudo操作
密碼容易保管，命令容易審計(jì)	SSH，公鑰連接
配置模塊化，學(xué)習(xí)成本更高	克隆Ansible Git，語法簡單

---

Ansible vs SaltStack 誰才是自動化運(yùn)維好幫手？

1.概述

互聯(lián)網(wǎng)技術(shù)的發(fā)展，機(jī)房里面機(jī)器的數(shù)量隨之增加，運(yùn)維的難度和復(fù)雜度也在增加，需要投入的運(yùn)維人員和成本也在增加，從而催生了一系列的自動化運(yùn)維工具（Ansible、SaltStack、Puppet）的產(chǎn)生來減少運(yùn)維的成本。
Ansible、SaltStack、Puppet都是目前比較受用戶歡迎的自動化化運(yùn)維工具，其中Ansible和SaltStack使用python 編寫，具有良好的可移植性。Puppet的使用腳本語法復(fù)雜，且可移植性比較差，目前的使用者慢慢變少。本文將對Ansible、SaltStack進(jìn)行 詳細(xì)的比較。

2.Ansible和SaltStack的比較和選型

Ansible和SaltStack都是的目前最流行的自動化運(yùn)維工具，能滿足企業(yè)IT系統(tǒng)的自動化運(yùn)維管理。這兩個工具都是用python開發(fā) 的，可以部署到不同的系統(tǒng)環(huán)境中和具有良好的二次開發(fā)特性。在執(zhí)行的命令的時候,Ansible和SaltStack都支持Ad-hoc操作模式，也可以 支持將命令寫入yaml格式文件中再批量執(zhí)行。在處理返回結(jié)果方面，Ansible和SaltStack的返回結(jié)果格式都是JSON格式，比較易懂和方便 解析。本文主要從響應(yīng)速度、安全、自身運(yùn)維、使用語法等方面對Ansible和SaltStack的不同點(diǎn)進(jìn)行分析：
1.響應(yīng)速度
SaltStack的master和minion主機(jī)是通過ZeroMQ傳輸數(shù)據(jù)，而Ansible是通過標(biāo)準(zhǔn)SSH進(jìn)行數(shù)據(jù)傳輸，SaltStack的 響應(yīng)速度要比Ansible快很多。標(biāo)準(zhǔn)SSH連接的時候比較耗費(fèi)時間，ZeroMQ傳輸?shù)乃俣葧旌芏?#xff0c;所以單單從響應(yīng)速度方面考慮SaltStack 會是更好的選擇。但是在一般的運(yùn)維場景下Ansible的響應(yīng)速度也可以滿足需求。

在表格1 Ansible和SaltStack性能測試中，測試了Ansible和SaltStack在執(zhí)行命令、分發(fā)文件、讀取文件和批量腳本執(zhí)行等自動化運(yùn)維場景下的性能，由耗時數(shù)據(jù)可以看出Ansible的響應(yīng)速度比SaltStack要慢10倍左右。
2.安全
Ansible和SaltStack都需要和遠(yuǎn)程主機(jī)進(jìn)行連接，它們的最大的安全問題就是MITM攻擊，通過偽裝成Master主機(jī)和遠(yuǎn)程主機(jī)進(jìn)行通信，從而進(jìn)行攻擊。
SaltStack使用ZeroMQ進(jìn)行數(shù)據(jù)傳輸，ZeroMQ本身數(shù)據(jù)傳輸不支持加密，SaltStack可以通過使用AES數(shù)據(jù)加密方法來對數(shù)據(jù)進(jìn)行加密傳輸，但是SaltStack的minion主機(jī)以守護(hù)進(jìn)程的方式運(yùn)行在遠(yuǎn)端暴露了很多容易被攻擊的點(diǎn)。
Ansible使用標(biāo)準(zhǔn)SSH連接傳輸數(shù)據(jù)，不需要在遠(yuǎn)程主機(jī)上啟動守護(hù)進(jìn)程，并且標(biāo)準(zhǔn)SSH數(shù)據(jù)傳輸本身就是加密傳輸，這樣遠(yuǎn)程主機(jī)不容易被攻擊。也不是說Ansible就可以完全避免被攻擊，Ansible使用paramiko庫進(jìn)行SSH連接，paramiko是一個有很不錯記錄SSH連接的 python庫。Ansible可以通過配置StrictHostKeyChecking參數(shù)，使得遠(yuǎn)程主機(jī)上的keys和之前連接不一樣的時候 Ansible沒有及時感知和提醒用戶。但是Ansible可以通過修改配置文件和配置一個合適的known_hosts文件來解決這個問題，因此 Ansible在安全方面還是比SaltStack做的好。
3.自身運(yùn)維
SaltStack需要在Master和Minion主機(jī)啟動守護(hù)進(jìn)程，自身需要檢測守護(hù)進(jìn)程的運(yùn)行狀態(tài)，增加運(yùn)維成本。Ansible和遠(yuǎn)端主機(jī)之間的 通信是通過標(biāo)準(zhǔn)SSH進(jìn)行，遠(yuǎn)程主機(jī)上只需要運(yùn)行SSH進(jìn)程就可以進(jìn)行運(yùn)維操作，SSH是機(jī)房主機(jī)中一般都安裝和啟動的進(jìn)程，所以在Ansible進(jìn)行運(yùn) 維的時候只需要關(guān)注Ansible主機(jī)的運(yùn)行狀態(tài)。Ansible對機(jī)房運(yùn)維不會增加過多的運(yùn)維成本。從工具本身的運(yùn)維角度來說，Ansible要比 SaltStack簡單很多。
4.使用語法
Ansible的Playbook語法要比SaltStack的State語法具有更好的可讀性。在使用的過程中發(fā)現(xiàn)Ansible在實(shí)現(xiàn)loop的更加的簡潔，也可以使用相對路徑。舉例說明，SaltStack在備份文件A.txt和B.txt的State語法為：

?

# back up A.txt and B.txt

{% for remote_target %}

/backup/{{ filename}}:

file.managed:

‐ source: salt://remote-host/{{ filename }}

‐ require:

‐ cmd: A.txt

‐ cmd: B.txt

{% endfor %}

?

Ansible的Playbook語法實(shí)現(xiàn)同樣的功能如下：

?

-name: back up A.txt and B.txt

copy: src ={{item}}

Dest=/backup/{{item}}

with_items:

- A.txt

- B.txt

?

同樣Ansible的Notify模塊和Handler模塊實(shí)現(xiàn)的功能和SaltStack的watch和module.wait的模塊實(shí)現(xiàn)功能也類似，也比SaltStack要簡潔明了。
總之，Ansible的安全性能比SaltStack好，自身運(yùn)維簡單，使用語法可讀性更強(qiáng)，雖然在響應(yīng)速度方面不如SaltStack，但是在大部分應(yīng)用場景下Ansible的響應(yīng)速度能滿足需求。因此，在金融行業(yè)的自動化運(yùn)維系統(tǒng)，Ansible工具是最好的選擇。

3.微服務(wù)化架構(gòu)設(shè)計(jì)

自動化運(yùn)維系統(tǒng)的主要運(yùn)維操作場景有腳本執(zhí)行、文件的上傳下載、啟動項(xiàng)管理、用戶密碼修改、系統(tǒng)軟件包管理、定時任務(wù)管理等，在云計(jì)算的機(jī)房里面需 要管理1000余臺主機(jī)，而Ansible執(zhí)行任務(wù)最高并發(fā)數(shù)約200個，所以系統(tǒng)中需要部署多個Ansible工具來滿足系統(tǒng)的應(yīng)用需求。運(yùn)維操作需要 經(jīng)歷連接主機(jī)，執(zhí)行并返回結(jié)果的過程，這個過程需要異步執(zhí)行且實(shí)時返回執(zhí)行結(jié)果。

圖1 展示的是自動化運(yùn)維平臺總體設(shè)計(jì)，便于自動化運(yùn)維系統(tǒng)管理大規(guī)模主機(jī)、實(shí)時反饋運(yùn)維結(jié)果的一套系統(tǒng)。
自動化運(yùn)維平臺：自動化運(yùn)維平臺包含有CMDB、圖形化界面、權(quán)限管理等核心功能，后端采用REST API調(diào)用Worker模塊和監(jiān)聽執(zhí)行結(jié)果。
服務(wù)注冊中心：服務(wù)注冊中心提供服務(wù)的注冊和服務(wù)發(fā)現(xiàn)的功能，在開源界有Etcd、Consul、Apache Zookeeper、Eureka等組件來實(shí)現(xiàn)服務(wù)注冊中心的功能。Worker模塊向網(wǎng)關(guān)以IP地址和端口的方式注冊到服務(wù)注冊中心中，自動化運(yùn)維平臺 發(fā)現(xiàn)Worker后調(diào)度選擇Worker執(zhí)行運(yùn)維操作。

• Etcd：一個高可用，分布式，一致的key-value存儲，用來共享配置和服務(wù)發(fā)現(xiàn)。Kubernetes和Cloudfoundry都使用了etcd。
• Consul：一個發(fā)現(xiàn)和配置服務(wù)的工具?？蛻舳丝梢岳盟峁┑腁PI，注冊和發(fā)現(xiàn)服務(wù)。Consul可以執(zhí)行監(jiān)控檢測來實(shí)現(xiàn)服務(wù)的高可用
• Apache Zookeeper：一個常用的，為分布式應(yīng)用設(shè)計(jì)的高可用協(xié)調(diào)服務(wù)，最開始Zookeeper是Hadoop的子項(xiàng)目，現(xiàn)在已經(jīng)成為頂級項(xiàng)目了。
• Eureka: 是一個基于 REST 的服務(wù)，它主要是用于定位服務(wù)，以實(shí)現(xiàn)服務(wù)注冊和服務(wù)發(fā)現(xiàn)功能，本身具有服務(wù)健康檢測的功能。
  Worker集群：Worker模塊的核心是Ansible，Worker模塊啟動的時候使用IP地址和端口向服務(wù)注冊中心注冊一個地址，自動化運(yùn)維平臺 會主動發(fā)現(xiàn)Worker模塊。圖2 Worker模塊設(shè)計(jì)，Ansible本身沒有提供REST API,通過使用Flask將Ansible API封裝給自動化運(yùn)維平臺調(diào)用，在啟動REST API的時候?qū)P地址和端口注冊到服務(wù)注冊中心中。運(yùn)維操作請求到達(dá)REST API后，發(fā)送給異步調(diào)度celery模塊，celery后端對接的是消息中心，實(shí)現(xiàn)任務(wù)的異步分布式調(diào)度。Ansible拿到執(zhí)行任務(wù)，連接遠(yuǎn)程主機(jī)執(zhí) 行運(yùn)維操作，然后將執(zhí)行結(jié)果發(fā)送消息中心。這個自動化運(yùn)維平臺實(shí)時監(jiān)聽消息中心每臺主機(jī)的執(zhí)行結(jié)果，達(dá)到遠(yuǎn)程主機(jī)上的運(yùn)維操作結(jié)果能實(shí)時的反饋到自動化運(yùn) 維平臺中。
  
  消息中心:消息中心采用的是消息隊(duì)列，開源消息隊(duì)列中間件有RabbitMQ、ActiveMQ、kafka。采用消息隊(duì)列的好處就是能實(shí)時的返回執(zhí)行結(jié)果。

4.總結(jié)

在金融領(lǐng)域中，安全是最重要的考慮因素，在眾多自動化運(yùn)維工具種，Ansible的安全性能最好，是目前最適合金融領(lǐng)域的自動化運(yùn)維工具。本文通過將Ansible微服務(wù)化，集成到自動化運(yùn)維平臺中，實(shí)現(xiàn)自動化運(yùn)維平臺高并發(fā)執(zhí)行運(yùn)維操作場景和實(shí)時收集執(zhí)行結(jié)果。

5.參考

1.http://jensrantil.github.io/salt-vs-ansible.html
2.http://www.tuicool.com/articles/3UjQNn

總結(jié)

以上是生活随笔為你收集整理的saltstack与ansible对比的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。