身邊有很多運維工程師，做了幾年的運維自動化，但依然不能確定選擇哪個工自動化工作？還有，怎樣更優雅的實施運維自動化和避免事實當中的坑？
馬哥教育大咖講堂-175期特別邀請了一線資深工程師張強為我們帶來了一場《saltstack在自動化運維實踐》的分享，嘗試帶著他對工作問題的思考以及部署自動化工具的經驗給大家一些幫助和啟發。
————————————
作者介紹：
張強，馬哥教育Linux大咖講堂金牌講師，現就職于伙伴智慧運維工程師，負責主線業務平臺，3年Linux一線經驗，擅長shell腳本、自動化_發布、web應用等，現在關注自動化運維、分布式數據庫，虛擬化技術。

---

自動化工具比較

Puppet也許是四款工具中最深入人心的。就可用操作、模塊和用戶界面而言，它是最全面的。Puppet呈現了數據中心協調的全貌，幾乎涵蓋每一個運行系統，為各大操作系統提供了深入的工具。初始設置比較簡單，只需要在需要加以管理的每個系統上安裝主服務器和客戶端代理軟件。命令行接口(CLI)簡單直觀，允許通過puppet命令下載和安裝模塊。然后，需要對配置文件進行更改，好讓模塊適合所需的任務;應接到指令的客戶端與主服務器聯系時，會更改配置文件，或者客戶端通過立即觸發更改配置文件的推送(push)來進行更改。

Ansible關注的重點是力求精簡和快速，而且不需要在節點上安裝代理軟件。因此，Ansible通過SSH執行所有功能。需要管理的節點被添加到Ansible配置環境，SSH授權密鑰被附加到每個節點上，這與運行Ansible的用戶有關。一旦完成了這步，Ansible主服務器可以通過SSH與節點進行通信，執行所有必要的任務。Ansible可以使用Paramiko(基于SSH2協議的Python實現)或標準SSH用于通信，不過還有一種加速模式，允許更快速、更大規模的通信。

Salt類似Ansible，因為它也是基于CLI的工具，采用了推送方法實現客戶端通信。它可以通過Git或通過程序包管理系統安裝到主服務器和客戶端上。客戶端會向主服務器提出請求，請求在主服務器上得到接受后，就可以控制該客戶端了。Salt可以通過普通的SSH與客戶端進行通信，但如果使用名為minion的客戶端代理軟件，可以大大增強可擴展性。此外，Salt含有一個異步文件服務器，可以為客戶端加快文件服務速度，這完全是Salt注重高擴展性的一個體現。與Ansible一樣，你可以直接通過CLI，向客戶端發出命令，比如啟動服務或安裝程序包;你也可以使用名為state的YAML配置文件，處理比較復雜的任務。還有“pillar”，這些是放在集中地方的數據集，YAML配置文件可以在運行期間訪問它們。

總結：個人觀點puppet最大缺點就是默認情況下Agent每隔30分鐘向master同步狀態，master主動推送功能比較薄弱(2.7版本），ansible基于SSH服務執行，如果服務器過多不建議使用，他是使用輪訓的方式。Salt基于消息隊列。性能相當好，適合大量生產環境。

SaltStack簡介與特性

SaltStack 是一種基于 C/S 架構的服務器基礎架構集中化管理平臺，管理端稱為 Master，客戶端稱為 Minion。SaltStack 具備配置管理、遠程執行、監控等功能，一般可以理解為是簡化版的 Puppet 和加強版的 Func。SaltStack 本身是基于 Python 語言開發實現，結合了輕量級的消息隊列軟件 ZeroMQ 與 Python 第三方模塊（Pyzmq、PyCrypto、Pyjinjia2、Python-msgpack 和 PyYAML 等）構建。

通過部署 SaltStack 環境，運維人員可以在成千上萬臺服務器上做到批量執行命令，根據不同的業務特性進行配置集中化管理、分發文件、采集系統數據及軟件包的安裝與管理等。

SaltStack 具有以下特性：

1、部署簡單、方便；

2、支持大部分UNIX/Linux及Windows環境；

3、主從集中化管理；

4、配置簡單、功能強大、擴展性強；

5、主控端（master）和被控端（minion）基于證書認證，安全可靠。

6、支持API及自定義模塊，可通過Python輕松擴展。

SaltStack 的工作原理

SaltStack 采用 C/S 結構來對云環境內的服務器操作管理及配置管理。為了更好的理解它的工作方式及管理模型，將通過圖形方式對其原理進行闡述。

SaltStack 客戶端（Minion）在啟動時，會自動生成一套密鑰，包含私鑰和公鑰。之后將公鑰發送給服務器端，服務器端驗證并接受公鑰，以此來建立可靠且加密的通信連接。同時通過消息隊列 ZeroMQ 在客戶端與服務端之間建立消息發布連接。具體通信原理圖，如圖 1 所示，命令執行如圖 2 所示：

專業術語說明：

Minion 是 SaltStack 需要管理的客戶端安裝組件，會主動去連接 Master 端，并從 Master 端得到資源狀態信息，同步資源管理信息。

Master 作為控制中心運行在主機服務器上，負責 Salt 命令運行和資源狀態的管理。

ZeroMQ 是一款開源的消息隊列軟件，用于在 Minion 端與 Master 端建立系統通信橋梁。

Daemon 是運行于每一個成員內的守護進程，承擔著發布消息及通信端口監聽的功能。

原理圖說明：

Minion 是 SaltStack 需要管理的客戶端安裝組件，會主動去連接 Master 端，并從 Master 端得到資源狀態信息，同步資源管理信息。

Master 作為控制中心運行在主機服務器上，負責 Salt 命令運行和資源狀態的管理。

Master 上執行某條指令通過隊列下發到各個 Minions 去執行，并返回結果。

SaltStack 的架構設計

為了讓大家更好的理解 SaltStack 集中化管理方面的優勢，因此，根據項目的實際情況繪制了部署架構圖，并在文中對架構圖進行了詳細說明。如圖 3 所示：

說明：

SaltStack 的所有被管理客戶端節點（如圖 3 所示 DB 和 Web），都是通過密鑰進行加密通信，使用端口為 4506。客戶端與服務器端的內容傳輸，是通過消息隊列完成，使用端口為 4505。Master 可以發送任何指令讓 Minion 執行，salt 有很多可執行模塊，比如說 CMD 模塊，在安裝 minion 的時候已經自帶了，它們通常位于你的 Python 庫中，locate salt | grep /usr/?可以看到 salt 自帶的所有東西。

為了更好的理解架構用意，以下將展示主要的命令發布過程：

SaltStack 的 Master 與 Minion 之間通過 ZeroMq 進行消息傳遞，使用了 ZeroMq 的發布訂閱模式，連接方式包括 TCP 和 IPC。

Salt 命令，將 cmd.run ls 命令從 salt.client.LocalClient.cmd_cli 發布到 Master，獲取一個 Jodid，根據 jobid 獲取命令執行結果。

Master 接收到命令后，將要執行的命令發送給客戶端 minion。

Minion 從消息總線上接收到要處理的命令，交給 minion._handle_aes 處理。

Minion._handle_aes 發起一個本地線程調用 cmdmod 執行 ls 命令。線程執行完 ls 后，調用 Minion._return_pub 方法，將執行結果通過消息總線返回給 master。

Master 接收到客戶端返回的結果，調用 master.handle_aes 方法將結果寫的文件中。

Salt.client.LocalClient.cmd_cli 通過輪詢獲取 Job 執行結果，將結果輸出到終端。

SaltStack 的安裝與配置

對 SaltStack 有了一個初步的了解之后，通過實際案例操作進一步了解 SaltStack。

一、安裝Salt

Salt需要epel源支持，所有安裝前需要先安裝epel源包。

1、salt-master

# yum -y install salt-master

2、salt-minion

# yum -y install salt-minion

二、配置Salt

1、master(/etc/salt/master)

# salt運行的用戶，影響到salt的執行權限

user: root

#salt的運行線程，開的線程越多一般處理的速度越快，但一般不要超過CPU的個數

worker_threads: 10

# master的管理端口

publish_port : 4505

# master跟minion的通訊端口，用于文件服務，認證，接受返回結果等

ret_port : 4506

# 如果這個master運行的salt-syndic連接到了一個更高層級的master,那么這個參數需要配置成連接到的這個高層級master的監聽端口

syndic_master_port : 4506

# 指定pid文件位置

pidfile: /var/run/salt-master.pid

# saltstack 可以控制的文件系統的開始位置

root_dir: /

# 日志文件地址

log_file: /var/log/salt_master.log

# 分組設置

nodegroups:

group_all: '*'

# salt state執行時候的根目錄

file_roots:

base:

- /etc/salt/

# 設置pillar 的根目錄

pillar_roots:

base:

- /etc/pillar

2、配置minion(/etc/salt/minion)

master: mail? #這塊的mail指的是在/etc/hosts文件中所定義的主機名

id: node1

3、啟動salt

service salt-master start

service salt-minion start

# saltstack 是使用Python2的語言編寫，對Python3的兼容性不好，請使用Python2的環境

4、認證命令介紹

salt-key #證書管理

# salt-key –L ? ? ? #查看所有minion-key

# salt-key –a ? ? ?#接受某個minion-key

# salt-key –A ? ? ?#接受所有minion-key

# salt-key –d ? ? ? #刪除某個minion-key

# salt-key –D ? ? ? #刪除所有minion-key

5、salt命令介紹

命令格式：salt [options] [arguments]

例：salt \* cmd.run 'uptime'

SaltStack minion匹配方式

1、 Glob（salt默認的target類型，使用shell的通配符來指定一個或多個Minion ID）

# salt \* test.ping 或 salt ‘*’ test.ping

2、pcre兼容正則表達式

# salt –E ‘^[m|M]in.[e|o|u]n$’ test.ping

3、Subnet(通過指定一個IPv4地址或一個CIDR的IPv4子網)

# salt –S 192.168.0.42 test.ping

# salt –s 192.168.0.0/16 test.ping

4、Grains(salt可以通過操作系統、CPU架構及自定義信息等機器特征進行target Minion)

# salt –G ‘os:Ubuntu’ test.ping

# Salt –G ‘os_family:Debian’ test.ping

5、pillar（salt支持通過pillar數據進行匹配）

# Salt –I ‘my_val:my_val’ test.ping

6、混合（compound)

# Salt –C ‘web* or G@os:Arch’ test.ping

7、節點組（Nodegroup）

節點組需要事先定義，配置方法如下：

# vim /etc/salt/master

nodegroups:

node: 'L@node1,node2’

# salt -N node test.ping

SaltStack常用模塊

1、status模塊（查看系統信息）

# salt "*" status.diskstats? ? #查看磁盤信息

# salt "*" status.meminfo? ? ? #查看內存信息

# salt "*" status.w? ? ? ? ? ? #w命令返回信息

2、查看所有module列表

3、查看指定module的所有function方法

4、查看指定module用法

5、具體模塊的使用（例子）

同時到指定機器查看

cmd.run模塊的使用

Grains

Static bits of information that a minion collects about the system when the minion first starts.

The grains interface is made available to Salt modules and components so that the right salt minion commands are automatically available on the right systems.

以上是官方的解釋，大致意思是說grains是minion第一次啟動的時候采集的靜態數據，可以用在salt的模塊和其他組件中。例如，當os_family的Grain數據為Centos時，則會使用yum工具組件來進行軟件包管理。Grains會在Minion進程啟動時加載，并緩存在內存中。這樣salt-minion進程就無須每次操作都重新檢索系統來獲取Grain，極大的提高了Minion的性能。

1、我們這里簡單做一個輸出測試，可以看到minion節點的一些信息如下：

查看具體每一項信息

2、應用場景：

grains的特性–每次啟動匯報、靜態決定了它沒有pillar靈活，要知道pillar是隨時可變的，只要在master端修改了那一般都會立刻生效的。所以grains更適合做一些靜態的屬性值的采集，例如設備的角色(role)，磁盤個數(disk_num），操作系統版本等諸如此類非常固定的屬性。簡單總結起來grains的用途如下：

（1），grains可以在state系統應用中，用戶配置管理模塊。

（2），grains可以在target中使用，用來匹配minion，比如os，用-G。

（3），grains可以用于信息查詢，grains保存著收集到的客戶端的信息。

那么我們就可以得到一個大致的判斷，如果你想定義的屬性值是經常變化的，那請采用pillar，如果是很固定、不易變的那請用grains。

3、grains優先級

grains可以保持在minion端、通過master端下發等多個方式來分發。但不同的方法有不同的優先級的(由低到高)：

（1）. /etc/salt/grains

（2） /etc/salt/minion

（3）./srv/salt/_grains/? master端_grains目錄下

優先級順序依次為存在在minion端/etc/salt/minion配置文件中的同名grains會覆蓋/etc/salt/grains文件中的值，而通過master端_grains目錄下grains文件下發的值可以會覆蓋minion端的所有同名值。比較拗口，總之記得，通過master下發的grains優先級是最高的可，/etc/salt/minion次之，/etc/salt/grains最低（core grains不大懂，就不討論了，這個比/etc/salt/grains還低）。

4、grains的下發

grains的下發大致可以分為兩個思路：

(1)自定義的（_grains）可以通過state.highstate、saltutil.sync_grains、saltutil.sync_all 等方法批量下發，切記所有在_grains目錄下的所有自定義grains值都會下發到minion，這是血的教訓。

(2)固定存放在minion端配置文件中，如grains、minion文件中，可以通過file manager的方法去批量下發/etc/salt/grains等配置文件實現grains的批量下發，當然了也通過別的方式把這個文件批量下發下去，都是ok的。

對比：

（1）通過state.highstate 下發的grains好處是無須重啟minion即可生效，但通過下發/etc/salt/grains文件下發的grains值則必須重啟minion端服務才可以生效。

（2）自定義的_grains每次在highstate調用的時候就會自動下發、刷新，而/etc/salt/grains文件的則不會。

Pillar

在大多數場景中，Pillar的表現行為和Grain一致，但有個很大的區別是：Pillar在Master上進行定義，存在于一個集中化的路徑。Pillar數據是與特定minion關聯的，也就是說每一個minion都只能看到自己的數據，所以Pillar可以用來傳遞敏感數據（在Salt的設計中，Pillar使用獨立的加密session，也是為了保證敏感數據的安全性）。

Pillar可以用在那些地方：

1、敏感數據

例如ssh key，加密證書等，由于Pillar使用獨立的加密session，可以確保這些敏感數據不被其他minion看到。

2、變量

可以在Pillar中處理平臺差異性，比如針對不同的操作系統設置軟件包的名字，然后在State中引用。

3、其他任何數據

可以在Pillar中添加任何需要用到的數據。比如定義用戶和UID的對應關系，mnion的角色等。

4、用在Targetting中

Pillar可以用來選擇minion，使用-I選項。

定義Pillar：

master配置文件中定義：

默認情況下，master配置文件中的所有數據都添加到Pillar中，且對所有minion可用。如果要禁用這一默認值，可以在master配置文件中添加如下數據，重啟服務后生效：

pillar_opts: False

使用SLS文件定義Pillar

Pillar使用與State相似的SLS文件。Pillar文件放在master配置文件中pillar_roots定義的目錄下。示例如下：

pillar_roots:

base:

- /srv/pillar

下面這段代碼定義了base環境下的Pillar文件保存在/srv/pillar/目錄下。與State相似，Pillar也有top file，也使用相同的匹配方式將數據應用到minion上。示例如下：

# cat /srv/pillar/top.sls:

base:

'*':

- packages

# cat /srv/pillar/packages.sls:

{% if grains['os'] == 'RedHat' %}

apache: httpd

git: git

{% elif grains['os'] == 'Debian' %}

apache: apache2

git: git-core

{% endif %}

base環境中所有的minion都具有packages中定義的數據。Pillar采用與file server相同的文件映射方式，在本例中，packages映射到文件/srv/pillar/packages.sls。注意key與value要用冒號加空格分隔，沒有空格的話將解析失敗。

如何知道minion擁有那些Pillar數據？

在Master上修改pillar文件后，需要用以下命令刷新minion上的數據：

使用Pillar獲取自定義數據：

State

簡述：SLS（代表SaLt State文件）是Salt State系統的核心。SLS描述了系統的目標狀態，由格式簡單的數據構成。這經常被稱作配置管理

top.sls是配置管理的入口文件，一切都是從這里開始，在master 主機上，默認存放在/srv/salt/目錄.

top.sls 默認從 base 標簽開始解析執行,下一級是操作的目標，可以通過正則，grain模塊,或分組名,來進行匹配,再下一級是要執行的state文件，不包換擴展名。

創建/srv/salt/top.sls

state實戰