一、管理物件

saltstack系統中管理物件叫做Target，在master上可以採用不同的Tatget去管理不同的minion。這些Target都是通過去管理和匹配Minion的ID來做一些集合。

1.1   -E, --pcre ： 正則匹配

# salt -E '[a-z].*' test.ping  #直接就是匹配字母開頭的minion

# salt -E 'a.*' test.ping    #匹配a開頭的minion

# salt -E '(a|z).*' test.ping   #匹配a或者z開頭的minion，切記是開頭而不是包含。

1.2  -L ： 列表匹配

# salt -L agent1.salt,zwidc_kvm_192.168.1.104 test.ping   #同時讓兩個minion去執行，多minion之間用逗號隔開。

1.3  -G ： grains匹配

minions的Grains資訊時在Minions服務啟動的時候彙總給Master的，Grains是saltstack組建中非常重要的，因為在配置部署的過程中會經常使用它，Grains是saltstack記錄minion的一些靜態資訊的元件，grains裡面記錄著每臺minion的一些常用屬性如CPU、記憶體等，可以通過grains.item檢視某臺minion的所有grains資訊。

# salt -G 'os:CentOS' test.ping  #讓minion端作業系統是CentOS去執行，當然也支援正則表示式的方式

# salt -G 'os:C*' test.ping   #如匹配作業系統是C開頭的

# salt -G 'osmajorrelease:[1-9]' test.ping   #匹配系統版本是數字的。

1.4  -N ： 組匹配

# cat /etc/salt/master |grep groups  #如我們定義了一個centosgroups組

nodegroups:
   centosgroups: '[email protected]

:CentOS'

# salt -N centosgroups test.ping #就可以指定讓某個組的minion去執行。

1.5  -C ： 複合匹配

# salt -C '[email protected]:CentOS and [email protected]:6.4' test.ping  #讓os是CentOS並且系統版本是6.4的去執行

# salt -C '[email protected]:CentOS or [email protected]:6.5' test.ping   #讓os是CentOS或者系統版本是6.5的去執行

# salt -C '[email protected]:CentOS and [email protected]:6.4 and [email protected]*' test.ping #讓zwidc的minion並且作業系統是CentOs6.4的去執行

1.6  -S ： CIDR網段匹配

# salt -S '192.168.1.0/24' test.ping  #192.168.1.0/24是一個指定的CIDR網段，這裡CIDR匹配的IP地址是minion連線master4505埠的來源地址。

博文來自：www.51niux.com

二、Grains介紹

Grains上面已經介紹過了，類似於facter。簡單的說就是把minion端在啟動的時候把自身的的各種屬性資訊採集彙報給master端。

2.1 grains模組的一些命令列的使用方法：

# salt '*' grains.ls  #可以檢視有哪些屬性可以檢視，顯示的是屬性的名字，類似於os之類的。

# salt '*' grains.item os osrelease oscodename  #知道了屬性的名稱，我們就可以檢視屬性的值，這裡就是檢視os,osrelease，oscodename這三個屬性的值，多屬性用空格隔開。

# salt '*' grains.items  #這種就是將minion端屬性以及屬性的值全打印出來。

2.2 通過minion端配置檔案定義grains：

minion端的操作：

# cat /etc/salt/minion.d/position.conf   #在預設的/etc/salt/minion.d目錄下面建立一個position.conf，這個檔案的目的是來自定義伺服器所在的位置的屬性資訊。下面就是標準格式。
grains:   #以grains開頭
  roles:    #設定一個屬性叫roles，下面如果多條就像下面一樣- value值，這裡的意思是標註伺服器屬於什麼業務
    - webserver
    - memcache
  deployment: bj-zw-datacenter    #這裡是標註所在機房的位置
  cabinet: B13              #標註所在機櫃的位置
  cab_u: 14-15              #標註所在機櫃的U位

# service salt-minion restart  #上面已經說了，grains資訊是在minion端啟動的時候才會傳送，所以要重啟minion端。

master端的檢視：

# salt 'agent1.salt' grains.ls #用這個檢視會發現我們自定義的哪幾個grains的屬性已經出現了。

# salt 'agent1.salt' grains.item roles deployment cabinet cab_u  #檢視一下對應的值

2.3 命令自定義grains

# salt 'agent1.salt' grains.append the_person 'chaishao'  #通過grains.append方法為agent1.salt機器添加了一個屬性，the_person使用人，後面跟的值是chaishao。

還可以使用其他的方法，如grains.setvals來定義多個屬性，或者還可以刪除自定義的grains。這都是立馬生效並永久生效的。因為它修改的是minion端的/etc/salt/grains 檔案。

三、Pillar介紹

Pillar是saltstack元件中非常重要的一個，是資料管理中心，經常配合states在大規模的配置管理工作中使用它，它的主要作用是儲存和定義配置管理中需要的一些資料。它的定義儲存格式跟grains類似，都是YAML格式。

下面的操作都是在master端的操作：

# mkdir /srv/pillar #這是master配置檔案裡面#pillar_roots:預設指定的路徑。預設不存在需要手工建立。

# cat /srv/pillar/top.sls  #top.sls是配置管理的入口檔案，一切都是從這裡開始，這裡是預設位置
base:  #top.sls 預設從 base 標籤開始解析執行,下一級是操作的目標，可以通過正則，grain模組,或分組名,來進行匹配,再下一級是要執行的state檔案，不包換副檔名。

  '*':
    - pkgs
# cat /srv/pillar/pkgs.sls  #一個簡單的根據minion端的grains資訊，動態的設定apache軟體包對應的name名稱。
pkgs:

  {% if grains['os_family'] == 'RedHat' %}  
  apache: httpd  
  {% elif grains['os_family'] == 'Debian' %}  
  apache: apache2  
  {% elif grains['os'] == 'Arch' %}  
  apache: apache  
  {% endif %}

#  salt '*' pillar.item pkgs

有結果來看，pillar資料是在Salt master上生成的並被安全地分佈到minions上。Salt當定義pillar的時候，不必限制在sls檔案，也可以從外部資源獲得資料，我們可以把Pillar資料。pillar中最強大的抽象之一就是將states引數化的能力。

四、States介紹

States是SaltStack中的配置語言，在日常進行配置管理時需要編寫大量的States檔案。如安裝軟體啊，更改配置啊等，就需要編寫states sls檔案（描述狀態配置的檔案）去描述和實現這些功能。編寫states sls檔案一般是是YAML語法格式，也支援使用Python語言來編寫。

4.1 檢視相關的states內容

# salt 'agent1.salt' sys.list_state_modules  #檢視minion支援的所有states列表。

# salt 'agent1.salt' sys.list_state_functions file host  #檢視file和host的所有function，多模組用空格隔開

# salt 'agent1.salt' sys.state_doc file #檢視指定模組的function的用法與例子，日常編寫states按照例子編寫便可。

# salt 'agent1.salt' sys.state_doc file.managed #檢視file.managed的詳細用法與例子，這也是我們經常用到的function。

4.2 編寫一個簡單的sls檔案並執行

# cat /srv/salt/test1.sls  #編寫了一個簡單的file.managed的sls檔案
 /tmp/test1.conf:   #state ID，全檔案唯一，標籤定義，如果模組沒有跟-name,預設用的ID作為-name
    file.managed:     #file state的manage function，狀態定義，指定引用哪個模組的方法函式。
         - source: salt://files/test1.conf   #檔案來源（salt://預設代表了根目錄也就是states的工作目錄也就是/srv/salt。）
         - user: root  #檔案的屬主，剩下的這些都是file.managed裡面的引數。

         - group: root  #檔案的屬組
         - mode: 0644  #檔案的mode

# mkdir /srv/salt/files/  #因為我們的source指定的是salt://files/，所以源目錄的絕對路徑應該是/srv/salt/files/下面的。

# touch /srv/salt/files/test1.conf  #建立我們要傳送的檔案，你也可以寫點內容。

# salt '*' state.sls test1  #top.sls這個入口檔案不是必須存在的，但是生產是肯定要存在的，只是我們這裡測試top.sls可以暫時不存在。用state.sls來進行測試，state.sls預設的執行環境是base,state.sls並不讀取top.sls，所以state.sls需要單獨執行哪些sls的話，需要自定義。這裡我們讓其執行test1.sls這個檔案。

下面是測試截圖（下面是測試結果正確的截圖）：

#如果你原始檔沒有發生改變，再次執行的話，Comment會提示你這個檔案是正確的。Changes:下面沒內容。Succeeded: 1，這就是區別，也就是不更新

五、SLS檔案介紹

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

5.1 YAML編寫技巧

因為我們用YAML格式來編寫sls檔案，所以掌握編寫技巧利於後面少出錯。

5.1.1 什麼是YAML？

YAML 語言（發音 /ˈjæməl/ ）的設計目標，就是方便人類讀寫。它實質上是一種通用的資料序列化格式。語法很簡單，結構通過空格來展示，專案使用“-”來代表，鍵值對使用“：”分隔。
它的基本語法規則如下：
大小寫敏感，以“：”來分隔key和value。物件：鍵值對的集合，又稱為對映（mapping）/ 雜湊（hashes） / 字典（dictionary）。

使用固定的縮排風格表示層級關係。縮排時不允許使用Tab鍵，只允許使用空格，一般每個縮排級別由兩個空格組成。
# 表示註釋，從這個字元一直到行尾，都會被解析器忽略。

想要表示列表項，使用一個短橫槓加一個空格。多個專案使用同樣的縮排級別作為同一列表的一部分。列表可以作為一個鍵值對的value。

5.2 top.sls

top.sls是配置管理的入口檔案，這個很重要在生產中很重要，預設存放在/srv/salt/目錄。預設從base標籤開始解析執行，下一級是操作的目標也就是要對哪些主機進行操作，可以通過正則、grain模組或分組名等來進行匹配，然後再下一級是要執行的state檔案（不包含.sls副檔名）。

5.2.1 正則匹配示例：

# cat /srv/salt/top.sls  #執行的test1還是我們上面編寫的那個簡單的test1.sls
base:
   'agent*':   #這裡定義了只有是註冊的時候是agent開頭的minion端的客戶端才能去執行test1裡面的配置管理
   - test1  #這裡指的是同目錄下的一個test1.sls。只有這裡top.sls制定了，我們在master執行：# salt '*' state.highstate test=True的時候才會被引用到。

# cat /srv/salt/top.sls   #如果你不是指定*所有來執行test1，只是想讓多個匹配規則去執行test1的話，可以像我下面這樣寫。
base:
   'agent*':
     - test1
   'zwidc*':  
     - test1

# cat /srv/salt/top.sls  #但是上面那種寫法顯然要low一點，可以- match: pcre，匹配正則表示式的方式來匹配對應的主機。     
base:
   ‘(agent|zwidc)*’:
     - match: pcre
     - test1

5.2.2 通過分組名進行匹配示例：

# cat /srv/salt/top.sls
base:
   centosgroups:  #這裡就是我們上面在master配置檔案裡面定義的那個組名
   - match: nodegroup  #這句話是必須要有的，指定以組匹配
   - test1

5.2.3 通過grain模組匹配的示例：

# cat /srv/salt/top.sls   #同上-match: grain也是必須要帶的，指定讓其按照grain進行匹配，指定讓os是Centos的作業系統來執行。   
base:
    'os:CentOS':
      - match: grain
      - test1

5.2.4 通過複合匹配的示例：

# cat /srv/salt/top.sls #上面的grain模組匹配可能滿足不了我們的匹配條件，我想要更加精確的讓所有Centos6.4的作業系統去執行，就是我下面的設定。
base:
    '[email protected]:CentOS and [email protected]:6.4':
        - match: compound
        - test1

5.2.5 某一個網段匹配示例：

# cat /srv/salt/top.sls
base:
    '192.168.1.0/24':
        - match: ipcidr
        - test1

5.3 state.highstate

# salt '*' state.highstate  #master將會指導所有的目標minions執行 state.highstate。當minion執行highstate，它將會下載top檔案中匹配的內容，minion將表示式中匹配的內容下載、編譯、執行。一旦完成，minion將返回所有的動作執行結果和所有更改

# salt '*' state.highstate test=True  #只是測試執行，類似於模擬，不會在minion真正執行，便於我們編寫測試時使用。

5.4 SLS檔案名稱空間

1. SLS檔案的副檔名.sls在state檔案裡面將被省略，上面已經展示到了，如test1.sls在檔案裡面就變為了test1.

2. 子目錄可以更好的進行組織架構，每個子目錄都由一個點來表示，如/srv/salt/init/dns.sls在呼叫時就可以寫為init.dns。

3. 如果子目錄建立一個init.sls的檔案，引用的時候僅指定該目錄即可，（例如test1/init.sls可以簡稱為test1）

4. 如果一個目錄下同時存在test1sls和test1/init.sls，那麼test1/init.sls將被忽略，sls檔案引用的test1將只引用test1.sls。

5.5 state的層級關係

include：將別的SLS新增到當前檔案中，所以可以require或watch被引用的SLS中定義的內容，還可以extend覆蓋其內容。include語句使得state可以跨檔案引用。使用include相當於把被引用的內容檔案新增到自身。

extend:擴充套件被引用的SLS資料。不需要重頭寫新的SLS，可以先直接include sls檔案，然後在其基礎上增加或者覆蓋內容。

include示例：

# cat /srv/salt/top.sls  #我們只引用了一個test1.sls檔案

base:
    '192.168.1.0/24':
        - match: ipcidr
        - test1

# cat /srv/salt/test1/init.sls

include:   #格式就是include: 下面用- 空格 後面要載入的sls檔案
 - test1.test2   #這裡我們雖然跟init.sls檔案在同一個目錄下面，但是根目錄是/srv/salt，所以這裡要用test1.test2來表示test1目錄下面的test2.sls檔案
/tmp/test1.conf:  #剩下的就是test1的內容了。
    file.managed:
         - source: salt://files/test1.conf
         - user: root
         - group: root
         - mode: 0644
         - backup: minion

# cat /srv/salt/test1/test2.sls  #寫了一個很簡單的傳送檔案的例子，用test2.conf和test1.conf區別開

/tmp/test2.conf:
    file.managed:
         - source: salt://files/test2.conf
         - user: root
         - group: root
         - mode: 0644
         - backup: minion

# salt '*' state.highstate test=True  #master端執行測試檢視效果，從結果檢視test2.sls確實被載入了：

extend示例：

覆蓋值的示例：

# cat /srv/salt/test1/init.sls

include:
 - test1.test2 
/tmp/test1.conf:
    file.managed:
         - source: salt://files/test1.conf
         - user: root
         - group: root
         - mode: 0644
         - backup: minion
extend:   #extend: 下一行是test1.test2的ID號，所以/tmp/test2.conf這個檔案是不能變的，這就是這個ID號是不能變的不然就找不到要去修改的標識了。
  /tmp/test2.conf:   #這個ID號是不能變的，是為了告訴extend去修改哪個ID下面的內容。
    file.managed:   #因為我們配置的比較簡單，就file.managed這一個模組函式，這裡就是指定要對哪個模組函式進行修改。
         - source: salt://files/test3.conf #也就是file.managed下面的一些引數對應的值，這裡我們將source從要下載test2.conf改為了下載test3.conf

# salt '*' state.highstate  #master端執行讓minion去執行同步管理任務。從下方的可以看出，客戶端/tmp/test2的檔案內容發生了變化。

新增引數的示例：

# cat /srv/salt/test1/init.sls  #其實就是test2.sls裡面沒有定義- watch，所以這裡就相當於是添加了。

include:
 - test1.test2 
extend:
  /tmp/test2.conf:
    file.managed:
      - watch:  
        - file: /tmp/test1.conf 
/tmp/test1.conf:
    file.managed:
         - source: salt://files/test1.conf
         - user: root
         - group: root
         - mode: 0644
         - backup: minion

#Extend使得Salt的SLS更加靈活。為什麼SLS能夠做Extend呢？SLS中的檔案僅僅是結構化的data而已，在處理SLS時，會將其中的內容解析成Python中的dict（當然這個dict中會巢狀dict和list）。修改test2 watch的內容，相當於往list裡面新增一個元素；修改test2.conf檔案的下載路徑相當於修改dict中的某個key對應的值。在extending時，會附加加require/watch的內容，而不是覆蓋。

5.6 state的邏輯關係

match   : 配模某個模組，比如 match: grain match: nodegroup
require： 依賴某個state，在執行此state前，先執行依賴的state，依賴可以有多個
watch  ： 在某個state變化時執行此模組,watch除具備require功能外，還增了關注狀態的功能。

order   ： 優先順序比require和watch低，有order指定的state比沒有order指定的優先順序高,假如一個state模組內安裝多個服務，或者其他依賴關係，可以使用

5.7 state的邏輯關係示例

require和require_in簡單示例：

# cat /srv/salt/test1/init.sls   #這是require的示例，就是表示自己依賴於誰。

vim:   #定義了第一個ID為vim
  pkg:  #然後引用的是pkg模組
    - installed  #引用的是installed函式
    - name: vim-enhanced  #因為vim的軟體包名稱並非vim，所以這裡要加上vim包組的名稱
/tmp/vimrc:
  file.managed:
    - source: salt://files/vimrc
    - require:   #- require： 依賴於下面的ID操作，如果下面的ID操作了或者說要操作的內容已經存在了，本ID也就是/tmp/vimrc才會去執行
      - pkg: vim  #依賴於id為vim的pkg狀態，多依賴的話，下面照著這個來多行就可以了。

#成功的測試就不截圖了，下面我估計講minion端的DNS解析關閉掉，然後執行檢視一下錯誤截圖：

# cat /srv/salt/test1/init.sls  #這是require_in的示例，表示誰依賴於我

vim:
  pkg:
    - installed
    - name: vim-enhanced
    - require_in:  #表示下面的id代表的操作依賴於我是否能執行成功，在這裡就是表示我本次是否要安裝成功或者要安裝的軟體包組是否存在。
      - file: /tmp/vimrc  
/tmp/vimrc:
  file.managed:
    - source: salt://files/vimrc

watch和watch_in的示例：

# cat /srv/salt/test1/init.sls  #這是watch的示例，表示我檢測誰的變化，如果它變化執行了我就跟著執行，它要不執行我也不執行。

ntpd:  #定義了一個ID是ntpd的配置規則
  service.running:  #這裡引用了service.running函式- enable: True預設就是這個，這裡就不加了。
    - watch:  #這裡它是監聽ID為file: /etc/ntp.conf，如果下方的狀態沒有發生改變，那麼我這個重啟規則就不會執行，那麼就不會執行服務重啟操作。
      - file: /etc/ntp.conf  #也就相當於如果minion端的ntp.conf或者master端的salt://files/ntp.conf的檔案沒有發生改變，也就不會發生檔案下發操作，也就可以理解為如果沒有發生檔案更改。

/etc/ntp.conf:
  file.managed:
    - source: salt://files/ntp.conf

下面是檔案狀態沒有發生改變的截圖（一切相安無事）：

下面是我更改了下master段的原始檔，也就是ntp.conf，在其上面加了一行註釋，再次檢視，ntpd服務重啟了：

# cat /srv/salt/test1/init.sls  #這是watch_in的示例，表示我改變了執行了我就通知依賴於我變化的狀態規則讓他們也去執行。

ntpd:
  service.running  #主要是這裡要注意，上面的例子有冒號而這裡沒有，這是因為當不將任何引數傳遞給狀態時，冒號必須被省略。

/etc/ntp.conf:
  file.managed:
    - source: salt://files/ntp.conf
    - watch_in: #這就是如果執行了下發了ntp.conf操作，我就通知ID是ntpd的server狀態，讓其執行重啟服務操作。
      - service: ntpd

5.8 state的執行順序

state的執行是無序，那個無序是指執行我們寫的那個sls是無序的，一般執行的時候會根據sls檔案裡面狀態ID:寫的順序從上到下執行，正是因為那個無序，salt保證每次執行的順序是一樣的，就加入了state order。

# salt 'agent1.salt'  state.show_highstate #就是檢視狀態的執行順序從高到底排序結果

# salt 'agent1.salt'  state.show_lowstate #檢視狀態的執行順序從低到高排序結果

通過觀察會發現一個欄位order,是order決定了狀態之間的先後執行順序，因為salt預設會自動設定order，從10000開始。可以通過設定master配置檔案引數新增一行：state_auto_order: False來關閉master的自動設定order。

Order的設定：

1. include 被include的檔案Order靠前，先執行。

2. 手動定義order欄位，order的數字越小越先執行從1開始，-1是最後執行。

下面是order手工設定的一個小例子：

# cat /srv/salt/test1/init.sls  #為了演示效果，我打亂了狀態ID：在sls中的上下順序：

ntpd:
  service.running:
    - enable: True
    - order: 3
ntp:
  pkg.installed:
   - name: ntpdate
   - order: 1 
  
/etc/ntp.conf:
  file.managed:
    - source: salt://files/ntp.conf
    - order: 2

# salt 'agent1.salt'  state.highstate #執行一下檢視一下效果（測試的時候可以把order那一行註釋掉再次測試檢視一下效果就很有對比性。也可以# salt 'agent1.salt'  state.show_highstate直接檢視）：

 

六、Jinja使用介紹

6.1 Jinja介紹

Jinja是基於Python的模板引擎，功能比較類似於PHP的Smarty。Salt預設使用yaml_jinja渲染器。yaml_jinja的流程是選用jinja2模板引擎處理SLS，然後再呼叫YAML直譯器。我們需要了解一點Jinja語法知識，因為在配置管理中經常會用到，這也是salt能真正實現高度自動化配置的一個重要技能。

Jinja的使用分為三個步驟：

1. File狀態使用template引數 - template: jinja。

2. 模板檔案裡面變數使用{{名稱}}，比如{{PORT}}.

3. File狀態模組裡面指定變數列表。

6.2 Jinja使用示例：

# cat /srv/salt/jinja1/init.sls  #引用jinja靈活配置的小例子。

{% set iplist = grains['ipv4'] %}  #首先{% set 變數名 = 給變數賦值 %}，這種格式可以設定一個格式。這裡我們引用了grains獲取minion端的ipv4值的方式，得出來一般是一個列表也就是一個數組，127.0.0.1在第一位。
/tmp/minion.conf:
  file.managed:
    - source: salt://files/minion.conf.jinja  #這裡如果你是要使用到jinja模式，檔案裡面有好多變數的話，最好有個字尾，比較容易區分。
    - template: jinja   #這就是介紹裡面說的第一步，使用這個引數，說明自己使用的是jinja模板。
    - defaults:   #預設將值傳遞給模板
      IP_ADDR: {{iplist[1]}}  #IP_ADDR是minion.conf.jinja裡面定義的一個變數，後面的賦值用{{}}包起來，去iplist這個列表的第二個值。這個根據自己情況再進行修改，我這就是為了演示簡單寫了下。

# cat /srv/salt/files/minion.conf.jinja  #這是模板檔案，就寫了很短的一行，為了掩飾效果。
ipaddr:{{IP_ADDR}}
# salt 'agent1.salt'  state.highstate  #master端執行一下，成功了，就不接圖了。下面我們檢視一下客戶端的配置檔案裡面的IP是不是跟本機是一致的。

6.3 Jinja變數的使用

Jiaja變數使用很靈活的，下面大概總結一下：

變數使用單純的變數賦值（上面的例子也簡單的用了下）（除了模板引用以外sls檔案也可以直接引用，下面就是非模板的變數引用）：

{% set keepalived_tar = 'keeplived-1.2.17.tar.gz' %}  #用{%...%}符號定義變數
{% set keepalived_source = 'salt://modules/keepalived/files/keepalived-1.2.17.tar.gz' %}
keepalived-install:
  file.managed:
    - name: /usr/local/src/{{ keepalived_tar }} #這裡用{{...}}引用變數賦值
    - source: {{ keepalived_source }}

變數使用Grains（上面的例子也有列出）：

IP_ADDR: {{grains['ipv4'][1]}}  #上面的變數引用，可以直接這樣寫的，更簡潔一點。

變數使用執行模板，也就是使用salt命令返回的值（因為grain只有再minion重啟的時候才會將資訊上交一份，要是在重啟之前有些配置發生了更改，難免匹配不準）：

# cat /srv/salt/jinja1/init.sls

/tmp/minion.conf:
  file.managed:
    - source: salt://files/minion.conf.jinja
    - template: jinja
    - defaults:
      IP_ADDR: {{salt['network.ip_addrs']}}   #一個是獲取IP地址，salt代表是使用salt命令['要使用的funtion方法']
      MAC: {{ salt['network.hw_addr']('eth0') }}  #一個是獲取MAC地址，後面('eth0')是因為有的方法後面好跟引數，如network.hw_addr後面就需要跟介面名稱

# cat /srv/salt/files/minion.conf.jinja  #注意模板這裡寫了幾個變數，sls檔案裡面就要寫結果變數應該對映的值，不然會報錯說Jinja某個變數未定義

ipaddr:{{IP_ADDR}}
mac:{{MAC}}

變數使用Pillar來定義變數的值（這個就是首先定義好了pillar，這裡來直接引用下就可以了）：

{{ pillar['apache']['PORT'] }}

6.4 Jinja邏輯關係

Jinja還主要用來給狀態增加邏輯關係，如for迴圈，或者if判斷，也是經常使用到的。

salt,grains,pillar是salt中jinja裡面的三個特殊字典，salt是包含所有salt函式物件的字典，grains是包含minion上grains的字典，pillar是包含minion上pillar的字典。上面已經介紹瞭如何使用了。

if...elif...endif的示例：

# cat /srv/pillar/pkgs.sls

apache:
  pkg.installed: #這是根據系統的不同，判斷安裝的軟體名稱。如果有變數就放到{{}}中
  {% if grains['os_family'] == 'RedHat' %}  #jinja中判斷，迴圈等標籤是放在{% %}中
    - name: httpd  
  {% elif grains['os_family'] == 'Debian' %}  
    - name: apache2  
  {% elif grains['os'] == 'Arch' %}  
    - name: apache  
  {% endif %}   #也會有結束標籤{% end** %}

#當然還支援：{% if %}...{% elif %}...{% else %}...{% endif %}之類的寫法。

for迴圈的示例：

{% set userlist = ['yunwei','cacti','www'] %}
{% for user in userlist %}
{{ user }}:
 user.present:
   - shell: /bin/bash
   - home: /home/{{ user }}
{% endfor %}