前言
sls文件作为saltstack中重要的一环,是必须掌握的
入门篇
放在入门篇的开始,带大家来了解一下sls的执行顺序
salt 'minion1' state.sls nginx.install
这是一个执行sls的命令,那么这个命令会读取那些文件呢?
- 遍历saltstack配置文件里边的file_roots
- 寻找file_roots 里边的nginx目录
- 访问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安装我们预期来执行呢?
- include引入的文件会被先执行
- 每个sls定义时可以定义order值,order值从小到大执行
- 按照依赖关系执行
下面看看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来读取机器的配置信息,从而动态生产配置文件,这样所有的服务器都可以共用一份配置文件.
