saltstack之state編寫指南

前言

sls文件作為saltstack中重要的一環,是必須掌握的

入門篇

放在入門篇的開始,帶大家來了解一下sls的執行順序

salt 'minion1' state.sls nginx.install

這是一個執行sls的命令,那么這個命令會讀取那些文件呢?

1. 遍歷saltstack配置文件里邊的file_roots
2. 尋找file_roots 里邊的nginx目錄
3. 訪問java目錄下的nginx.sls

上面命令執行時,指定了Java目錄下的nginx.sls文件,而實際上有時候是可以不指定的,如:

salt 'minion1' state.sls java

這時候saltstack就會訪問到java目錄下的init.sls

---

簡單的sls編寫:

nginx_install:   # sls_id 不可重復
  pkg.installed: # 模塊方法
    - pkgs:      # 參數
      - nginx

nginx_conf:
  file.managed:
    - name: /etc/nginx/nginx.conf
    - source: salt://nginx.conf
    - require:
      - pkg: nginx_install

• :與- 后需要空格
• salt:// 想當於master的file_roots目錄
• 多個 - 表示列表
• 每一級縮進由2個空格組成,不能用Tab

就這一個簡單的sls就可以安裝nginx,並把nginx.conf替換成預先寫好的配置文件

而再看一下這個:

nginx:
  pkg.installed:

/etc/nginx/nginx.conf:
  file.managed:
    - source: salt://nginx.conf
    - require:
      - pkg: nginx_install

這次的代碼對比上面, - pkgs 和 - names 的內容不見了,相反把sls_id 的名字分別改成了nginx
和/etc/nginx/nginx.conf

這樣寫和上面的效果是一樣的,當sls執行需要指定名字是,如果sls里邊沒有定義,那么默認會用sls_id的值

至於更多的模塊方法可以到官網去找到saltstack官網

引入其他sls文件

include 就像nginx一樣,include表示包含某個文件

include:
  - nginx.install
  - nginx.config

這樣我們就在文件中引入了nginx目錄下的install.sls(sls忽略不寫了)和nginx.config.sls文件了

執行順序

經常會聽到別人說sls執行時是無序的,那么我們怎么做才能使得sls安裝我們預期來執行呢?

1. include引入的文件會被先執行
2. 每個sls定義時可以定義order值,order值從小到大執行
3. 按照依賴關系執行

下面看看order的用法,至於依賴關系,可以看回文章開始時的使用,分辨出require與require_in的作用

nginx:
  pkg:
  - installed
  - order: 1

/etc/nginx/nginx.conf:
  file.managed:
    - source: salt://nginx.conf
    - require:
      - pkg: nginx_install
    - order: 2

進階篇

在知道了更多的模塊方法后,我們基本可以用sls來完成大部分事情,但這還不能滿足我們,下面再來看看一些關於sls的小技巧

jinja

在sls的文件中,我們還可以使用用jinja語法來控制sls執行,或者配置文件等

{% if grins[os] == 'Centos' %}

nginx:
  pkg.installed:

/etc/nginx/nginx.conf:
  file.managed:
    - source: salt://nginx.conf
    - require:
      - pkg: nginx_install
{% endif %}

一個十分簡單的例子,但這並不能說明jinja的強大,除了if還有set,for,marco等等,jinja的強大之處還需要大家獨自去領悟

引用外部變量

知道了jinja控制和引用變量之后也都不能滿足與所有需求,有時候我們需要在執行時來定義變量

salt 'minion1' state.sls nginx.install pillar='{"version":"1.13.4"}'

nginx:
  pkg.installed:
{% if pillar["version"] %}
  - version: {{ pillar["version"] }}
{% endif %}

當然我們並不會每次都在執行命令時附帶參數,我們可以把pillar,grains的數據預先設定好.下面來看看如何引入其他變量

{% set files = salt['cmd.run']("ls /data","default") %}

echo_files_name:
  cmd.run:
    - names:
{% for file in files %}
      - echo {{ file }}
{% endfor %}

• salt 固定寫法
• ['cmd.run'] 表示執行cmd.run方法
• ls /data 表示執行命令
• "default" 最后的空字符代表默認值

這種方法可以執行大部分salt命令來獲取返回值,然后傳入到sls文件中執行

測試

有時候由於編寫的sls文件太大,想測試一下剛添加進去的功能需要執行很久.

其實可以通過sls_id方法來執行sls文件內的某個方法

salt 'minion1' state.sls_id nginx_install nginx.install

這時候saltstack只會執行nginx.install.sls里邊的nginx_install,而不會執行其他,但是我們要注意它的依賴關系

配置文件管理

在很多時候,我們需要統一管理配置文件,但是每台機器的配置信息又不一樣,我們想根據每一台機的具體配置來定義應用的配置文件

通過saltstack file模塊管理的文件,其實也可以使用jinja來獲取,定義變量的

下面來看一份postgres配置,由於配置過長,刪減了部分

listen_addresses = '*'
max_connections = {{ conn }}
{% if ((grains.mem_total|int) / 4)|round|int <= 8096 -%}
shared_buffers = {{ ((grains.mem_total|int) / 4)|round|int }}MB
{% else -%}
shared_buffers = 4GB
{% endif -%}
work_mem = {{ ((grains.mem_total|int) / conn * 2) |round|int }}MB
{% if ((grains.mem_total|int) / 16)|round|int <= 2048 -%}
maintenance_work_mem = {{ ((grains.mem_total|int) / 16)|round|int }}MB
{% else -%}
maintenance_work_mem = 2GB
{% endif -%}
temp_buffers = {{ ((grains.mem_total|int) / conn) |round|int }}MB
checkpoint_completion_target = 0.9
effective_cache_size = {{ (((grains.mem_total|int) * 3) / 4)|round|int }}MB

可以看到,配置文件內大量使用了granis來讀取機器的配置信息,從而動態生產配置文件,這樣所有的服務器都可以共用一份配置文件.