Saltstack的sls(7)

SLS(代表SaLt State文件)是Salt State系统的核心。SLS描述了系统的目标状态,由格式简单的数据构成。这经常被称作配置管理 首先,在master上面定义salt的主目录,默认是在/srv/salt/下面,vim /etc/salt/master:

file_roots:
   base:
     - /srv/salt
   dev:
    - /srv/salt-dev

然后,在/srv/salt下面创建top.sls文件(如果有的话,就不用创建了,直接编辑好了) vim top.sls

base:
  ‘*‘:

top.sls 默认从 base 标签开始解析执行,下一级是操作的目标,可以通过正则,grain模块,或分组名,来进行匹配,再下一级是要执行的state文件

base:
  ‘*‘:               #通过正则去匹配所有minion
    - nginx          #这里都是我自己写的state.sls模块名 这里可以无视 后面会提到

  my_app:             #通过分组名去进行匹配 必须要定义match:nodegroup
    - match: nodegroup
    - nginx

  ‘os:Redhat‘:        #通过grains模块去匹配,必须要定义match:grain
    - match: grain
    - nginx

整个top.sls大概的格式就是这个样子,编写完top.sls后,编写state.sls文件;

cd /srv/salt 
vim nginx.sls

nginx.sls内容:

nginx:
  pkg:               #定义使用(pkg state module)
    - installed      #安装nginx(yum安装)
  service.running:   #保持服务是启动状态
    - enable: True
    - reload: True
    - require:
      - file: /etc/init.d/nginx
    - watch:                 #检测下面两个配置文件,有变动,立马执行上述/etc/init.d/nginx 命令reload操作
      - file: /etc/nginx/nginx.conf
      - file: /etc/nginx/fastcgi.conf
      - pkg: nginx
/etc/nginx/nginx.conf:       #绝对路径
  file.managed:
    - source: salt://files/nginx/nginx.conf  #nginx.conf配置文件在salt上面的位置
    - user: root
    - mode: 644
    - template: jinja   #salt使用jinja模块
    - require:
      - pkg: nginx

/etc/nginx/fastcgi.conf:
  file.managed:
    - source: salt://files/nginx/fastcgi.conf 
    - user: root
    - mode: 644
    - require:
      - pkg: nginx

在当前目录下面(salt的主目录)创建files/nginx/nginx.conf、files/nginx/fastcgi.conf文件,里面肯定是你自己项配置的nginx配置文件的内容啦;使用salt做自动化,一般nginx都是挺熟悉的,这里不做详细解释了

测试安装:

[email protected] salt # salt ‘sa10-003‘ state.sls nginx test=True
··········这里省略输出信息
Summary
------------
Succeeded: 8
Failed:    0
------------
Total:     8

往minion上面进行推送的时候,一般salt ‘sa10-003‘ state.sls nginx 这种命令;当然,也可以执行 salt sa10-003 state.highstate 这种命令会默认匹配所有的state.sls模块。其中test=True 是指测试安装 ,也就是不进行实际操作,只是查看测试效果。



state的逻辑关系列表:

include: 包含某个文件 比如我新建的一个my_webserver.sls文件内,就可以继承nginx和php相关模块配置,而不必重新编写

[email protected] salt # cat my_webserver.sls 
include:
  - nginx
  - php

match: 配模某个模块,比如 之前定义top.sls时候的 match: grain match: nodegroup require: 依赖某个state,在运行此state前,先运行依赖的state,依赖可以有多个 比如文中的nginx模块内,相关的配置必须要先依赖nginx的安装

- require:
  - pkg: nginx

watch: 在某个state变化时运行此模块,文中的配置,相关文件变化后,立即执行相应操作

- watch:
  - file: /etc/nginx/nginx.conf
  - file: /etc/nginx/fastcgi.conf
  - pkg: nginx

order: 优先级比require和watch低,有order指定的state比没有order指定的优先级高,假如一个state模块内安装多个服务,或者其他依赖关系,可以使用

nginx:
  pkg.installed:
    - order:1

想让某个state最后一个运行,可以用last

时间: 2024-10-10 03:26:47

Saltstack的sls(7)的相关文章

关于saltstack下 sls文件编写的一点收获

初学saltstack,写sls文件,感觉YAML格式要求真是严格.仅以记录一下内容,作为分享.开源的知识就该告诉所有想知道的人. /opt/foo.conf:           #设定ID,只是一个标识而已 file.managed:          #使用的方法函数,file下面的managed(python格式) - name: /foo.conf    #设定文件的路径,这个路径是指master上的文件将被同步到minion的路径.若为设定name,将采用ID设定代替 - sourc

saltstack state.sls常用功能模板编写

saltstack常用功能模块编写 一.简介 Master - 控制中心,salt命令运行和资源状态管理端 Minions - 需要管理的客户端机器,会主动去连接Master端,并从Master端得到资源状态信息,同步资源管理信息 States - 配置管理的指令集 Modules- 包含命令行下运行的指令,和在配置文件里面使用的指令模块可以的函数可以在命令行下运行 Grains - minion端的变量,静态 pillar - minion端的变量,动态,可自定义 highstate - 给m

saltstack   state.sls 与 state.highstate

这里简单介绍一下state.sls 与 state.highstate 与区别,这也是自己在使用过程中的一点心得吧. 环境介绍:salt 2015.5.0 (Lithium) top.sls state.highstate 这个是全局的所有的环境的所有的状态生效: state.sls 用来指定特定sls进行处理. 当使用  salt '*' state.highstate 没有任何问题 可是当执行 salt '*' state.sls servers_packages 发现没法执行 翻看官方文档

SaltStack之sls文件

SLS(代表SaLt State文件)是Salt State系统的核心.SLS描述了系统的目标状态,由格式简单的数据构成.这经常被称作配置管理. SLS文件使用YAML语言编写,其规则主要有以下三方面: 缩进:每个缩进级别由两个空格组成,相同缩进表示相同的层级,严禁使用TAB键 冒号:冒号+空格 用来分隔键和值,key通常以冒号结尾,而且后面有一个空格 短横:短横+空格 表示列表项,多个项使用同样的缩进级别表示同一列表的一部分,列表可以表示一个key的值. 如: cd /srv/salt/bas

使用saltstack的sls功能

sls文件编写 [[email protected] ~]# vim /etc/salt/master #在master配置文件中添加以下内容 file_roots:   base:     - /srv/salt [[email protected] ~]# mkdir -p /srv/salt [[email protected] ~]# cd /srv/salt/ [[email protected] salt]# pwd /srv/salt  [[email protected] sal

saltstack知道这些就很好用了

[salt的目录结构] 环境是有默认的,不过可以更改配置/etc/salt/master文件中file_roots file_roots: base: - /data1/salt/base/ db: - /data1/salt/db/ dev: - /data1/salt/dev/ prod: - /data1/salt/prod/ [先掌握saltstack的SLS文件命名空间问题] 遵照以下规则: sls是扩展名 .sls是被省略的(如 zabbix.sls使用的时候 为 zabbix) 存

SaltStack配置管理之Gains与State测试

SaltStack的Grains主要是收集了minion的一些配置信息,如CPU.内存.硬盘.网络.操作系统等很少发生变化的静态数据,我们也可以在minion自定义Grains项和相应的值,Grains也可以用来匹配目标minion.SaltStack的state通过预先定制好的sls(salt state file)文件对被控制主机进行状态管理,支持包括程序包(pkg).文件(file).网络配置(network).系统服务(service).系统用户(user)等.通过sls文件定义好要达到

基于Saltstack、Artifactory打造传统模式下持续部署平台

一. 持续部署 1. 现状 由于没有建立标准的持续部署流程,导致了版本管理混乱,制品管理混乱,上线持续时间长,上线测试覆盖不全面,业务流量上升后故障较多,排查复杂.运维.测试.开发人员每次版本迭代的时候,都要可能需要经历一次通宵的历练,并且这种在上线的第二天依然会出现很多线上故障. 2. 痛点 ·自动化发布体系覆盖率低.·无标准化发布的流程.a) 只注重敏捷.忽视质量问题:b) 变更频繁导致故障率增加:c) 开发语言种类多,发布制品管理混乱,发布方式复杂:·安全问题容易被忽视. 二. 工具介绍

自动化运维浅谈

一.自动化监控 常见的有nagios和zabbix,外面已经用得很多了,网上文档也很多.这些软件,根据bash过滤业务日志监控某个指标很容易,但画出的监控图往往不太理想,很多时候,写技术分析报告需要参考过去一段时间的历史数据,有图是最好的了.公司如果有专门的运维开发人员,也可以用插件在java下自己开发出一些监控界面,如(同事wt开发): 另外,推荐百度的开源图表库ECharts(http://www.oschina.net/p/echarts?fromerr=GMUsF6Vg),利用这东西,应