前言

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来读取机器的配置信息,从而动态生产配置文件,这样所有的服务器都可以共用一份配置文件.

saltstack state编写

前言

入门篇

引入其他sls文件

执行顺序

进阶篇

jinja

引用外部变量

测试

配置文件管理

猜你喜欢