深刻SaltStack

時間 2019-11-05

標籤深刻 saltstack 简体版

原文原文鏈接

[譯者注] 這是一篇發表在opencredo官網的博文，經過比較流行的Puppet和新發展起來的Salt，詳細地介紹了Salt的功能。在徵得原做者的贊成後，翻譯出來，與你們分享。初次翻譯長文，請你們指點。原文連接node

深刻SaltStack

Maartens Lourens.
於1月10日發表在opencredo.python

對系統工程師來講，配置管理已經向前躍進了一大步. 系統配置的自動化不只可預測,可重複, 還具備可管理性. 配置管理工具一般使用版本控制化的配置模板來描述基礎設施的目標狀態。憑藉版本控制化的配置，能夠將環境回滾（或前滾）到前面（或後序）狀態；環境配置文件的自動化管理也是持續性交付管道的必要特性。mysql

CFEngine, Puppet和Chef(按年齡降序)是開源領域流行的配置管理工具。我是一個Puppet的長期用戶, 與自定義的配置腳本相比，它在系統自動化的組織性和可靠性方面帶來了巨大的提高。(我是在2009年做出這一次飛躍，與此相比, 之前的日子簡直是混亂不堪…).linux

雖然配置管理工具精於描述並達到想要的狀態, 但並不擅長動態地查詢或設置狀態. 這一點在狀態資源尚未被歸入配置管理時特別明顯。Llinux系統管理員的傳統解決辦法是ssh循環登錄節點列表並執行一堆命令。這不只容易出錯, 且每一次循環都要打開新的ssh會話，效率低下。想像一下要在1000臺機器上順序執行命令！更不用說網絡安全，ssh密鑰和命令執行權限的問題。這固然是一種可行的辦法,但缺乏一種可管理的框架。nginx

這就是命令編排工具產生的緣由。這些工具旨在大量的節點上並行執行命令和實時操做。CFEngine, Puppet和Chef各自用不一樣的方法來解決命令編排問題。Puppet使用MCollective做爲其武器,並將其集成到商業版中。git

近來，我開始探索使用SaltStack來解決配置管理和命令編排這兩個問題。SaltStack開始於2011年，是一個相對較新的項目，但在系統管理員和DevOps工程師中擁有愈來愈多的粉絲。我將在本文中探討Salt做爲前途光明的替代者，並與Puppet做比較以探索其特性。github

安裝

創世之初，盡是空白和無序，黑暗籠罩着整個系統……而後神安裝了配置管理器，因而陽光普照！惟一的麻煩是，咱們還須要安裝依賴……而後配置管理器自己還得被配置……而且有時事情會有那麼一點醜陋。redis

Salt在Ubuntu和CentOS上的安裝過程異常簡單,我相信在有安裝指南的別的系統也同樣 (Arch Linux, Debian, Fedora, RedHat, CentOS, FreeBSD, Gentoo, Windows, Solaris). YMMV. 典型安裝過程隱藏了沒必要要的細節配置，除非你須要修改他們。首先安裝salt master，而後安裝salt minions, 將minions指向master，安裝完成。若是salt master的主機名是"salt"，都不須要將minions指向master，直接就能夠運行。sql

然而, 若是你不是使用上面提到的發行版或操做系統, 你極可能須要捲起袖子本身手動安裝一些依賴。包括Python (>= 2.6 < 3.0), ZeroMQ, pyzmq, PyCrypto, msgpack-python和YAML的Python綁定.mongodb

另外一方面, Puppet在多數基礎安裝時只依賴Ruby和Facter, 依賴帶來的麻煩顯著減小. 然而，Puppet的依賴列表能夠進一步增長，包括augeas-libs, dmidecode, hiera, libselinux-ruby, pciutils, ruby-augeas, ruby-irb, ruby-rdoc, rubygem-json, ruby-shadow, rubygems. 這取決於Puppet的版本和你想要使用的功能。

我喜歡Salt包安裝的簡單明瞭。For the cases mentioned it is trivial to set up and get going. 若是你想親自安裝和配置的繁過程, 跟着安裝指南作便可。

If you are like me though and you prefer your provisioning and configuration all in one gift wrapped package, que Vagrant to the rescue and download this project by elasticdog on github.

配置管理

配置狀態

配置管理對Puppet來講是小菜一疊，對Salt又如何呢。讓我（高興的）驚訝的是，這件事簡單到使人髮指。和Puppet同樣，在Salt中能夠描述系統的目標狀態。. Salt將其稱之爲一個state, 配置模塊是state模塊。Salt的State模塊文件用YAML寫成，以.sls結尾。它們從功能上等同於Puppet模塊的manifest文件，後者用Puppet DSL寫成，以.pp結尾。

Salt在master的配置文件中指定"file roots", 相似於Puppet的"module path", 但同時包含了模塊根目錄和環境類型。舉例來講，在Salt中咱們能夠分別指定development和test環境配置文件路徑. 注意base環境是必須存在的。

file_roots:
base:
- /srv/salt/
dev:
- /srv/salt/dev
prod:
- /srv/salt/prod

base環境必須包含Salt的入口top文件(叫作top.sls).base定義了一個或多個環境，用正則來匹配節點，而後引用相應的Salt states. top文件與Puppet的nodes文件類似。(Puppet入口點是site文件,在Salt中不須要).

假設有一個Salt master和兩個minions (由Elasticdog github提供)，我想要在兩個minions上安裝mongodb。若是在默認的軟件倉庫中有mongodb包，只須要3步便可。

1, 在top.sls中指定節點。

dev:
'minion*.example.com':
- mongodb

2, 在dev/mongodb.sls中描述狀態:

mongodb:
pkg:
- installed

3, 傳遞狀態到salt minions:

# salt 'minion*' state.highstate -v
Executing job with jid 20121218102842533621
-------------------------------------------

minion1.example.com:
----------
State: - pkg
Name: mongodb
Function: installed
Result: True
Comment: Package mongodb installed
Changes: libicu: {'new': '3.6-5.16.1', 'old': ''}
mongodb: {'new': '1.6.4-1.el5', 'old': ''}
boost: {'new': '1.33.1-15.el5', 'old': ''}
js: {'new': '1.70-8.el5', 'old': ''}

minion2.example.com:
----------
State: - pkg
Name: mongodb
Function: installed
Result: True
Comment: Package mongodb installed
Changes: libicu: {'new': '3.6-5.16.1', 'old': ''}
mongodb: {'new': '1.6.4-1.el5', 'old': ''}
boost: {'new': '1.33.1-15.el5', 'old': ''}
js: {'new': '1.70-8.el5', 'old': ''}

配置描述文件與Puppet很是類似。但格式差異很大。這是由於Puppet使用本身的ruby-like DSL, 而Salt使用YAML. 正是因爲這點不一樣，造就了Salt state配置文件在視覺上的簡潔性。YAML對人類可讀也容易被映射到數據結構, 很是適合作配置管理中的資源描述。這不是說Puppet DSL不清晰或不結構化- it is neither - 但很難賽過YAML. YAML能夠快速寫成，在個人經驗看，比Puppet DSL要容易生成.

注意: 配置管理社區關於聲明配置的最佳方式一直存在爭論。部分人青睞於利用編程語言（好比說Ruby）的靈活性。Chef是其中的表明。Puppet處於中間地段。當使用現成的功能時，Puppet DSL很是強大。但要給配置開發者更大的能力，就必須使用內部的Ruby DSL。在波譜的另外一端，Salt的簡單YAML狀態描述很是結構化。然而，Salt也支持渲染諸如JSON, Mako, Wempy和Jinja來擴展其能力, 在未來還會支持XML,原生Python及其餘。

內置的state模塊

我知道Salt是比Puppet近的項目，我徹底能夠預料到不會有太多可用的內置模塊。我錯了: Salt有大量的內置模塊，包含Puppet中的大部分必要模塊好比 cron, exec (Salt是cmd), file, group, host, mount, package (Salt中是pkg), service, ssh_authorized_key (Salt是ssh_auth)和user。

儘管如此, Puppet仍然具備部分優點。好比, 我很是喜歡Puppet的Augeas模塊。Augeas把內容看成value樹，容許你修改(而不是覆蓋)一個已存在的配置文件。

雖然Salt有一個Augeas execution模塊，但很不幸貌似沒有Augeas的state模塊。雖然這樣，Salt也有一些本身特有的東西，好比針對git, hg和svn的內置state模塊.

模板

Puppet具備開盒即用的模板系統。Puppet有file資源和template資源的概念，這些資源分佈在模塊目錄結構的不一樣路徑下。在Salt中, files和templates在同一個位置。經過爲template指令指定type來區分是template仍是普通文件資源, type能夠是jinja, mako或wempy。好處是能夠很容易爲file資源增長邏輯。state文件可能看起來像下面這樣：

/etc/myapp.conf:
file.managed:
- source: salt://files/myapp.conf
- mode: 644
- owner: root
- group: root
- template: jinja

注意最後一行, 指明被管理的文件是一個jinja模板。

配置文件可使用jinja的語法來增長邏輯。舉例來講, 假設你的應用程序配置文件中用到了主機名。再假設在Ubuntuh 只須要短主機名（hostname），在CentOS須要FQDN。這能夠很容易地在模板文件myapp.conf中指定:

{% if grains['os'] == 'Ubuntu' %}
host: {{ grains['host'] }}
{% elif grains['os'] == 'CentOS' %}
host: {{ grains['fqdn'] }}
{% endif %}

在CentOS節點minion1上結果文件/etc/myapp.conf將包含如下內容

host: minion1.example.com

變量

Salt中的全局變量不能在使用時定義。在對變量的支持方面Puppet更加直觀和靈活。在Salt中, 全部的變量保存在單獨的位置。這樣作不夠靈活，但優點是更有秩序。用Salt的話講，變量叫作"pillars"。pillars的位置在salt master的配置文件中指定:

pillar_roots:
base:
- /srv/salt/pillar

和state文件同樣, 首先建立一個top文件，在其中能夠引用相關的pillar模塊。

base:
'*':
- packages

這個top文件引用了名爲packages.sls的state文件, 其中包含將要安裝的軟件包的版本號的變量，以下所示:

mongodb: mongodb-1.6.4-1
httpd: httpd-2.2.3-65

聲明瞭兩個pillar, mongodb和httpd, 而後能夠在state文件中用以下方式引用:

pillar['mongodb']
pillar['httpd']

模擬執行(Dry run)

管理系統有點像駕駛飛機。若是不當心謹慎，將會是高風險的事情。假設我是一個雙翼飛機的駕駛員，將作一個危險的aerial manoeuvre, 我多半會但願可以先模擬飛行。除非我像Red Baron同樣無所畏懼。不管如何，還好在執行Salt以前能夠先作測試。你須要作的僅僅是將Test設置爲True。

# salt 'minion1.example.com' state.highstate -v test=True

minion1.example.com:
----------
State: - file
Name: /etc/myapp.conf
Function: managed
Result: None
Comment: The following values are set to be changed:
newfile: /etc/myapp.conf

Changes:

總結

在配置管理方面，Salt在Puppet面前仍是可以站穩腳跟的。Salt安裝很是簡單，屬於簡單主義的開發風格, 功能豐富。總的來講，不須要過多的操做就能夠完成事情。我發現的惟一問題是salt-master和minion之間的鏈接有時會無端斷掉。搜索一番後，我發現其餘人在Salt 0.10.5這個版本上也遇到了一樣的問題。但願這個問題在下一個版本中獲得解決。

命令編排和遠程執行

MCollective

MCollective是 Puppet的命令編排解決方案。由R.I.Pienaar在PuppetLabs那幫人引發重視以前獨立開發完成。MCollective使用message broker (好比ActiveMQ)經過pub-sub總線來傳遞消息, 能夠並行通訊，這比用ssh快得多。這是一能夠理解特定消息併產生響應的框架。Puppet和MCollective如今能夠在同一個框架下工做，同時提供完成配置管理和命令編排的功能。

先無論MCollective的優點，有兩個負擔可以打擊你的激情。第一，MCollective只是和Puppet鬆散集成，至少對社區版原本講是這樣。MCollective有單獨的安裝包，獨立的配置文件。另外你還須要安裝配置broker(好比ActiveMQ)，來與MCollective一塊兒工做. 雖然不難，但很繁瑣。最後，你還不得不本身解決生產環境中通訊渠道的安全問題。不幸的是，這個就有點困難。

MCollective的第二個問題是相對來說缺乏一些自帶的功能。有不少現成的插件能夠下載安裝(https://github.com/puppetlabs/mcollective-plugins), 用Ruby寫本身的插件也不是很複雜－不過想要當即使用的話，障礙比想像得要大。Nevertheless, given that the framework is solid and extensible, dabbling in Ruby plugins soon makes the real power of MCollective apparent.

Salt

另外一方面，Salt生來就有命令編排的功能。最早設想的就是遠程執行技術，而後才添加的配置管理管理。Salt使用輕量的ZeroMQ來處理消息。結果就是不須要單獨的安裝。裝好Salt後，配置管理和命令編排就能夠工做了。絕不驚奇,Salt state模塊和execution模塊的命令在語法上相似，因此很直觀。再看Puppet和MCollective組合,各自使用不一樣的工具和語法結構，須要額外的時間去學習。

Salt遠程執行功能的可用性使人印象深入。當前的在線文檔列出了超過100個不一樣的內置excution模塊－包括augeas！(因此augeas成爲state模塊只是時間上的問題).

舉個簡單的例子，看看通用的"cmd.run"模塊和指令。這在你知道想要執行的命令卻又沒有現成的模塊可用時很是有用，- 或者你僅僅想要快速地遠程執行命令。假設我想在全部節點上檢查運行的內核版本號：

[root@salt salt]# salt '*' cmd.run "uname -r"
minion1.example.com: 2.6.18-274.18.1.el5
minion2.example.com: 2.6.18-274.18.1.el5
salt.example.com: 2.6.18-274.18.1.el5

或者我想看看磁盤使用狀況:

salt '*' cmd.run "df -h"

順便說一下, Salt有一個模塊用來查看磁盤用量以及其餘磁盤相關的查詢:

salt '*' disk.usage

使用內置模塊而不用cmd.run發送shell命令的好處是，模塊一般返回固定結構的數據。可以以編程的方式用在自動化處理上。

有不少現成的execution模塊來知足通用的管理任務，好比apt, at, cp, cron, disk, extfs, file, hosts, iptables, mount, network, pam, parted, pkg, ps, selinux, shadow, ssh, and test. 也有大量的模塊用於指定的軟件包和應用程序，好比apache, cassandra, djangomod, git, mongodb, mysql, nginx, nova, postgres, solr, sqlite3, 和tomcat.

甚至支持執行Puppet程序。

總結

毫無疑問，Salt遠程執行比Puppet加MCollective更優雅，附帶可用的功能更多。支持動態查詢和大規模的服務編排。要查看完整的功能，請參考salt execution模塊的文檔。

附加功能

Dashboard

Puppet使用Puppet dashboard. Salt目前沒有圖形化的界面。我知道，咱們都大愛命令行。不過，有時看到滿屏幕的綠色或是點點按鈕也是很愜意的。認真的講，dashboard是得到你所管理的節點網絡state概覽的好工具。Salt的路線圖中沒有圖形界面，但願最終會出現。

Returners

Returners是minion向master返回數據時調用的模塊。不將返回數據傳遞給salt master，而是調用Returner模塊來將數據發給其餘服務，一般是數據庫。Salt目前支持的returner，能夠鏈接cassandra, mongo, redis和mysql. 也能夠很容易的用Python腳本爲其餘服務寫一個returner。

Salt Syndic

Salt文檔將Salt Syndic描述爲"一個能夠構建Salt命令拓撲的強大工具「。實際意義上，Salt Syndic可讓一個運行Syndic服務的Salt master鏈接到更高層的master。

假設你有多個不一樣的Salt環境，每一個環境都有一個master。這些環境多是特的雲或是有防火牆的網絡。假設你想同時控制這幾個環境中的minions。你能夠在想要控制的master主機上安裝Salt Syndic。Salt Syndic建立了傳輸接口，在最頂層的master看來，就像是控制了不少的minion,但配置狀態其實是傳遞給了多個master。能夠將其想像爲軍隊的命令傳遞系統。