七天學會SALTSTACK自動化運維 (3)
- 導讀
- SLS
- TOP.SLS
- MINION選擇器
- SLS文件的編譯
- 總結
- 參考鏈接
導讀
SLS
SLS (aka SaLt State file) 是 salkstack 中非常基礎和重要的一種配置文件. 重要程度僅次於minion和 master 的主配置文件(或者說是一種數據結構，使用yaml編寫), 因為 SLS 配置文件決定了我們所定義的命令的執行路徑，比如 target到的很多minion, target完成之后就要開始執行命令了，或是真的執行一組命令，或是同步一堆配置文件，都是要確定哪個target ,執行哪個命令或者操作的，尋找對應的環境是sls文件的功能之一，也是第一步要學會的關於SLS的知識，關於環境配置,大多數都寫在 top.sls 中, 每個環境都有自己的top.sls，方便多環境配置，其他的sls多用於控制配置文件同步或者執行命令之類的工作。
TOP.SLS
我的 file_roots
/etc/master
file_roots:
base:
- /srv/salt/base
dev:
- /srv/salt/dev
test:
- /srv/salt/test
我的 top.sl
/srv/salt/base/top.sls
base:
'*':
- salt.minion
- base
/srv/salt/dev/top.sls
dev:
'dev*':
- development_config
- dev_db
/srv/salt/test/top/sls
test:
'env:test':
- match: grain
- test_config
- test_db
我的配置文件中有３個環境，不同的環境對應不同的環境配置目錄，目錄在 master 的file_roots中配置，意思就是說，每個minion可以讀取base的配置文件， dev的可以讀取dev的環境， test的可以讀取test的環境，這樣就可以避免把 settings.py, nginx.conf, my.cnf等等都放到同一個目錄中.
現在我的/srv/salt/base/中只放一些通用配置，當執行state.highstate的時候就會執行base.sls中的所有操作到我的minion上，下面參見我的base.sls.
minion_config:
file.managed:
- name: /etc/base/minion.config
- source: salt://minion.config
apache:
pkg.installed:
- watch:
- file: minion_config
非常簡單，且saltstack自動處理的非常好，只需要告訴minion應該保存文件的位置就可以，source則完全不用配置，因為salt自己知道當前minion對應的哪個環境目錄，自動去尋找minion.config文件並且同步到自己的/etc/base/minion.config下，這樣就實現了不同環境的分離，不過有一個地方需要注意的是，如果/etc/base目錄不存在會同步失敗，所以要事先確定目錄是否存在。
MINION選擇器
官方文檔中的關於top.sls的一節有完整的使用方法，不過既然要寫自己的理解，就一定寫最簡單最常用的.
其實就把這個東西當做是jquery的選擇器來使用就好了，jquery的選擇器的出現是因為dom節點非常多，需要通過一中好用的手段去選取自己要控制的節點，而saltstack的選擇器也是出於同樣的理由而被設計出來，那就是不同minion節點的選擇，因為你可能要管理夢幻西游的服務器，夢幻西游的服務器少說也有好幾千台吧，有了saltstack選擇起來很容易了.
Saltstack的選擇器根據文檔來看大致分為２種，一中是基於 Compound Matcher，另一種是基於 Node groups的, 其實按筆者的角度來看，其實只有一種，那就是前者，后者只不過是按照前者提供的方法，分了一下組而已，把不同功能的minion分到不同的組，這樣就不用每次用很長的正則去匹配 id或者grains了.
compound:
Letter Match Type Example
G Grains glob G@os:Ubuntu
E PCRE Minion ID E@web\d+\.(dev|qa|prod)\.loc
P Grains PCRE P@os:(RedHat|Fedora|CentOS)
L List of minions L@minion1.example.com,minion3.domain.com or bl*.domain.com
I Pillar glob I@pdata:foobar
S Subnet/IP address S@192.168.1.0/24 or S@192.168.1.100
R Range cluster R@%foo.bar
上方的表格出自官方文檔，有了第一次的使用經驗( sudo salt -G 'env:test' test.ping) 理解起來就很容易了，而且這么多匹配方式還支持混用，也支持 and not or 之類的邏輯運算，就像nginx的配置文件一樣靈活。
sudo salt -C 'G@env:dev and G@cpu_nums:8 and E@tokyo* and P@os:(CentOS)'
上面的復雜表達式雖然很長，但是一眼就可以看懂，無需多說，只是對於正則的使用是一個難關.
Node groups:
這個分組配置在 master 的配置文件里，具體的寫法可以參考 這里, 簡單配置之后就可以使用，沒有太多需要注意的地方.
SLS文件的編譯
這個結果也是讀官方文檔之后得出的,而且有一個ISSUE,這里並不解釋如何使用jinja2模板引擎來編譯sls文件，而是要說明sls文件的定義順序對環境變量的影響,在前面的配置中已經看到了，在每個環境的目錄下都可以配置top.sls文件來定義自己的配置，而且每個環境的top.sls只定義了自己的配置，也就是說base/top.sls只配置了base,沒有配置其他的，而當base目錄下沒有top.sls的時候(或者是沒有base的section)，那么就按照字母表的順序去查找其他的其中含有base section的top.sls, 這是一種容錯策略，也是加強配置靈活性的方法，這個例子可以見文檔，筆者這里只說自己的理解，盡量避免復制代碼.
base/top.sls文件比較特殊(其實並不特殊)，因為一般情況下base的目標是所有的minion,而且在base/top.sls中也是可以配置其他環境的section的，這里有一點就是說，當在base/top.sls 發現dev的section之后，那么這個環境就會使用base/top.sls中的dev的配置，而不管dev/top.sls中是否有自己的配置，換一種方法說就是base.sls是在第一時間被解析編譯的，可以通過讀代碼去驗證，不過這是學會使用之后的事情了.(其實在ISSUE存在的情況下，上面的一段話是錯誤的，具體可以hack代碼)
對於除base/top.sls之外的其他環境的top.sls, 也遵循與base/top.sls相同的策略，自己的top.sls不存在自己section的，按照字母表順序去查找其他包含自己section的top.sls，找到之后就使用這個section作為自己的環境.
最后關於ISSUE，該ISSUE目前還沒有關閉，表明該bug目前仍然存在，不過這里會說一個安全方法，不過安全方法也是有安全前提的，因為安全方法不一定符合你的使用需求.
作者的意思是，他的 base , qa ,dev, master 環境，每一個環境都有自己的一個top.sls,而且這個top.sls是同一個文件，但是這個top.sls的內容不是相同的，為什么呢？因為top.sls是在git中的不同版本，所以是同一個文件，但是內容不同，由於含有重復的配置，所以最后一個配置，覆蓋了前面所有的配置，最后一個就是qa, 其實作者還有幾句含糊的話讓我看不明白，不過大致就是這樣，避免的方法就是按照我說的，每個top.sls只做自己分內的事情，不要包含其他的section.
如果誰知道作者為什么使用不同版本的top.sls放在不同的目錄中，請聯系我
總結
完全基於自己的理解，基本上對SLS說明的比較清楚了，下一步可能會去debug該軟件，或者按照實踐去研究，不過我認為別人不一定能完全懂得我的意思，痛點幾乎都找到了，下面就是看實踐了，可能會開發一套基於saltstack的運維組件，畢竟是提供了api的.
參考鏈接
http://salt.readthedocs.org/en/latest/topics/tutorials/starting_states.html
http://salt.readthedocs.org/en/latest/ref/states/top.html#other-ways-of-targeting-minions
https://github.com/saltstack/salt/issues/12483#issuecomment-64181598