saltstack

自動化工具比較

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、Pyjinjia二、python-msgpack 和 PyYAML 等）構建。

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

SaltStack 具備如下特性：

一、部署簡單、方便；

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

三、主從集中化管理；

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

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

六、支持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安裝

Salt須要epel源支持，全部安裝前須要先安裝epel源包。

[root@Poppy ~]# yum install epel-release -y  不管master minion都須要安裝這個epel源支持

1.  master端安裝

[root@joker ~]# yum install salt-master -y
[root@joker ~]# systemctl start salt-master

2. 奴才端安裝

[root@Poppy ~]# yum install salt-minion -y 

奴才配置文件修改，告知master

16行指向master，78行默認是fqdn完整主機名

[root@Poppy ~]# cat /etc/salt/minion |grep -v "#"
master: master_ip 域名也是能夠的
[root@Poppy ~]# systemctl start salt-minion

3. master進行奴才端的受權認證

1）master

[root@joker master]# tree /etc/salt/pki/
/etc/salt/pki/
└── master
    ├── master.pem   私鑰
    ├── master.pub   公鑰
    ├── minions
    ├── minions_autosign
    ├── minions_denied   無權限的主機
    ├── minions_pre      待確認的主機
    └── minions_rejected 拒絕的主機

2）minion