【2】Saltstack handbook：Grains and Pillar

 

 

寫在前面的話

 

上一節談及了 Saltstack 的安裝和初始化配置，本節將談談 Saltstack 中兩個重要的東西，Grains 和 Pillar。

 

 

數據系統 Grains 入門

 

Grains 是靜態數據，其數據來源於 Minion 啓動的時候收集的有關客戶端本地的相關信息。

包括操做系統，內核，CPU，內存，硬盤，設備型號等等。這就意味着咱們可使用 Saltstack 作資產管理。

這些靜態數據除非是  Minion 重啓或者 Master 端主動同步更新，不然不會改變。

1. 查看 grains 默認支持的 Key：

salt 'saltstack-node-01' grains.ls

結果以下：

咱們能夠看到超級多的 Key。我這裏只截圖了一小部分。grains.ls 這其實就是 python 裏面引用 grains 模塊中的 ls 方法。

 

2. 查看全部 Key 的值：

salt 'saltstack-node-01' grains.items

結果如圖：

返回的結果其實就是 YAML 格式，後面會單獨的提到 YAML 語法特色。這裏咱們只須要知道其實就是 K/V 結構就行。

 

3. 查看單獨某個 Key 的值：

salt 'saltstack-node-01' grains.item os

結果如圖： 

這裏區別查看全部，item 採用單數的形式，若是該 Key 不存在或者沒值，那麼就不會有下面綠色部分的顯示。

 

4. 咱們就能夠根據這裏的 KV 來就行選擇特定的機器，相似 K8S 中的標籤選擇器（Label Selector）：

salt -G 'os:CentOS' cmd.run 'uptime'

結果如圖：

注意，若是咱們用 KV 選擇須要使用 -G 參數。且這裏的冒號後面沒空格。

 

5. 固然，默認的 grains 可能沒法知足咱們的需求，咱們能夠自定義，一共有兩種方法：

方法 1：在 /etc/salt/minion 配置文件的 129 行 有關於 grains 的配置（不一樣版本可能不同）

能夠添加一下配置進行測試：

grains:
  roles: app-server

注意 roles 前面空格 2 個，roles 後面 : 後面空格 1 個，這是 YAML 語法要求。 

而後咱們重啓 minion 測試一下：

systemctl restart salt-minion

在 Master 查看：

salt '*' grains.item roles

結果如圖：

能夠發現剛剛添加的 node3 節點已經可以看到咱們新添加的 KV 配置了。

 

方法 2：經過方法 1 咱們發現，若是都寫到 minion 配置文件，不便於咱們管理，全部咱們能夠抽離出來：

咱們能夠新建 /etc/salt/grains 文件，該文件可以自動被 salt 識別，直接在內部寫 KV：

server_env: product
server_name: mall-server

注意冒號後面有個空格。咱們也能夠不重啓 minion，直接在 Master 端同步，而後再度查看：

# 不重啓直接同步
salt '*' saltutil.sync_grains

# 查看多個
salt '*' grains.item server_env server_name 

結果以下：

 

6. 或者某個 Key 的值咱們還可使用以下方法：

salt '*' grains.get os

對比 grains.item 查看結果：

咱們發現使用 item 相對於使用 get 多顯示了 Key。

 

7. 本身用 Python 開發一個 grains： 方法就是寫個腳本，返回一個字典便可。

首先咱們須要修改 master 的配置文件：/etc/salt/master 在當前版本的 658 行有關於 file_roots 的配置，咱們把配置放開。

file_roots:
  base:
    - /srv/salt

該目錄同時也用於咱們以後寫 YAML 文件使用。固然這個目錄不存在，還須要咱們在 Master 節點手動創建。

# 重啓 Master
systemctl restart salt-master

# 建立目錄
mkdir /srv/salt

咱們存放 Python 腳本的目錄爲：_grains

cd /srv/salt/ && mkdir _grains

咱們在下面新建一個獲取時間的 Python 腳本：get_time.py

#!/usr/bin/env python
#-*- coding:utf-8 -*-

import time

def get_time():
    grains = {}
    grains['year'] = time.localtime().tm_year
    grains['month'] = time.localtime().tm_mon
    grains['day'] = time.localtime().tm_mday
    return grains

而後同步到全部 Minion 節點：

salt '*' saltutil.sync_grains

結果如圖：

咱們能夠查看同步以後的腳本在 Minion 節點放到了什麼位置：

tree /var/cache/salt/

結果如圖：

咱們須要知道的是 /var/cache/salt 目錄至關重要，從 Master 端同步的都會放到該目錄下，其中紅色部分就是可以執行的代碼。

能夠直接查看剛剛咱們定義的那些 Key：

salt '*' grains.item year

結果如圖：

若是這過程當中出現問題，咱們均可以查看日誌：/var/log/salt/minion

固然，在咱們定義 grains 的時候，可能會和系統的名稱出現同樣的狀況，這就牽扯到一個優先級：

系統自帶 > grains 文件中 > minion 中寫的 > 本身寫的

 

 

數據系統 Pillar 入門

 

Pillar 相比於 Grains，首先 Pillar 是動態的數據。其次 Pillar 定義在 Master 上面，只有特定的節點能看到，因此安全。

咱們能夠查看當前系統中的 Pillar 數據：

salt '*' pillar.items

能夠看到目前是沒數據的，可是其實系統是有一部分數據的，只是被隱藏了而已，若是你確實想看，能夠經過修改 Master 配置實現查看，配置在 /etc/salt/master 的 878 行（我當前的版本），修改配置爲以下配置，再度重啓 Master 便可：

pillar_opts: True

其最終查看的結果其實際是一個叫作 master 的字典，可是並不推薦開啓，由於不便於管理 pillar 配置。

 

咱們從前面知道了 Grains 是能夠直接在 minion 配置文件中定義的，那麼 Pillar 須要這麼定義呢？此時就能夠看出 Grains 和 Pillar 的明顯不一樣，Grains 配置在 Minion 端，Pillar 配置在 Master 端，且 Pillar 使用咱們後面會常常用到的 sls 文件進行管理。至於 sls 的具體使用方法，後面會單獨詳講。

1. 咱們須要經過修改 master 配置文件，放開 Pillar 配置，在 /etc/salt/master 我當前版本的 828 行：

pillar_roots:
  base:
    - /srv/pillar

重啓 Master 新建目錄：

# 重啓
systemctl restart salt-master

# 新建目錄
/srv/pillar

# 查看目錄結構
tree /srv/

結果如圖：

 

2. 爲了更好的進行管理，能夠對 sls 文件進行歸類，咱們這裏在 pillar 下面新建一個 test 目錄，用於存放測試 sls 文件：

cd /srv/pillar/ && mkdir test

# 建立配置
vim server_role.sls

內容以下：

{% if grains['fqdn'] == 'demo-node1' %}
salt_role: master
{% else %}
salt_role: minion
{% endif %}

在該配置中咱們加入了 Grains 判斷。至於這個文件的語法，若是你學過 Python 而且使用過 Django 你就會發現特別熟悉，沒錯，Jinja2 語法。後面也會詳講，這裏先簡單應用。該配置大體意思就是根據主機名給不一樣的 Minion 設置不一樣的角色屬性。

 

3. 新建 top.sls，在 Saltstack 中 sls 配置有一個統一的入口，那就是 top.sls 文件，咱們這裏也是簡單的應用，後面講到配置的時候單獨詳講，先有這麼個概念和印象就行。

vim top.sls

內容以下：

base:
  '*':
    - test.server_role

簡單作個說明：* 指代全部主機，你也能夠寫特定的主機或者通配符，由於咱們新建了 test 目錄，全部咱們得像 Python 調用模塊同樣，使用 test.server_role 來調用配置文件。此時能夠查看下目錄結構：

 

4. 同步配置，能夠像 grains 同樣不用重啓直接同步：

salt '*' saltutil.refresh_pillar

結果以下： 

再度查看：

salt '*' pillar.item salt_role

結構如圖： 

 

5. 使用選擇器執行想要的：

salt -I 'salt_role:master' cmd.run 'w'

查看結果：

注意：這裏 Pillar 的規則須要使用 -I （大寫 i）參數，就行 Grains 須要使用 -G 參數同樣。同時可能會遇到這樣的狀況，以下：

對於 Minion did not return. [No response] 這種問題，通常重啓 minion 端就能解決。

 

 

小結

 

經過對比 Grains 和 Pillar，咱們會發現其最大的特色有如下幾個：

1. Grains 主要配置在 Monion，而 Pillar 主要配置在 Master。

2. Grains 能夠本身用 Python 寫方法，返回一個字典就行。Pillar 則是用 Salt 最爲主要的 sls 配置。

3. Grains 通常是靜態數據，雖然自定義的可使用方法動態獲取，而 Pillar 則是能夠利用 Jinja2 模板進行邏輯判斷。

4. Grains 和 Pillar 都能很好的支持數據查詢，配置管理，Pillar 還可以進行敏感數據管理。

5. 二者都能很好的協助咱們經過相似標籤選擇器（Label Selector）的方式對服務器進行批量選擇。

注意：這裏所說的所謂保護敏感數據實際上是由於咱們在 Master 端作的定義，這樣即便黑客攻陷了某臺 Minion 他也沒法拿到敏感數據而已。