免费网站建设无广告,wordpress adminimize,在线产品设计,策划方案范文深入了解SLS的可以参考这篇博文#xff1a;http://www.ituring.com.cn/article/42238 个人觉得这篇文章翻译的不错#xff0c;所以转载过来。 Salt Sates 众多强大而有力的涉及都是建立在简单的原则之上。Salt SLS系统也是努力想K.I.S.S看齐。#xff08;Keep It Stupidly … 深入了解SLS的可以参考这篇博文http://www.ituring.com.cn/article/42238 个人觉得这篇文章翻译的不错所以转载过来。 Salt Sates 众多强大而有力的涉及都是建立在简单的原则之上。Salt SLS系统也是努力想K.I.S.S看齐。Keep It Stupidly Simple SLS代表Salt State文件是Salt Sate系统的核心SLS描述了系统的目标状态由格式简单的数据构成。这经常被称作配置管理。 只是数据而已 深入学习之前明白SLS文件只是结构化的数据而已是很有用的看懂和编写SLS文件不需要理解这一点但会让你体会到SLS系统的强大。 SLSL文件本质上只是一些dictionaries,lists,strings和numbers。这种设计让SLS文件非常灵活可以满足开发者的各种需求而且可读性很高写的越多就越清楚到底写的是什么。 默认的数据 -YAML Salt默认使用能战斗奥的最简单的序列化数据格式----- YAML来表达SLS数据。典型的SLS文件如下 1 2 3 4 5 6 7 apache: pkg: - installed service: - running - require: - pkg: apache 这些数据确保名为Apache的软件包处于已安装状态如果不是那么就安装Apache服务进程Apache处于运行状态。这些数据简洁易于理解。下面简单解释一下 第1行 是这段数据的ID被称作ID声明。这个ID是将要执行的这些命令的名字。 第2行和第4行表示State声明的开始使用了pkg和service这两个statespkg使用系统本地的软件管理器管理将要安装的软件service管理系统守护进程。 第3行和第5行是要执行的函数。这些函数定义了名字为ID的软件包和服务的目标状态。此例中软件包应当处于安装状态服务必须运行。 最后第6行是关键字require。这被称为必要语句Requisite,它确保了Apache服务只有在成功安装软件包后才会启动。 添加配置文件和用户 部署像Apache这样的web服务器时还需要添加其他的内容。需要管理Apache的配置文件需要添加运行Apache服务的用户和用户组 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 apache: pkg: - installed service: - running - watch: - pkg: apache - file: /etc/httpd/conf/httpd.conf - user: apache user.present: - uid: 87 - gid: 87 - home: /var/www/html - shell: /bin/nologin - require: - group: apache group.present: - gid: 87 - require: - pkg: apache /etc/httpd/conf/httpd.conf: file.managed: - source: salt://apache/httpd.conf - user: root - group: root - mode: 644 这个SLS大大扩展了上面的例子增加了配置、用户、组还有一个新的必要语句watch。 user和group这两个state添加在Apache的ID下所以增加的user和group名字都是Apache。require语句确保了只有在Apache这个group存在时才建立user只有在Apache这个package成功安装后才会建立group。 service中的require语句换成了watch从需要1个软件包改为监视3个state分别是pkg、file和user。watch语句和require很相似都能保证被监视或者需要的state在自己之前被执行但是watch还有其他作用。在被监视的state发生变化时定义watch语句的state会被执行自己的watcher函数。也就是说更新软件包修改配置文件修改Apache用户的uid都会触发service state的watcher函数。在这个例子中service state的watcher会重启Apache服务。 1 2 3 4 Note Salt的watcher概念非常有意思。Puppet中功能类似的是notify也可以触发服务重启。Salt的watcher 非常灵活watcher本质上是在state的代码中定义的名为mod_watch()的函数在这个函数中想做什么事 情完全就看你的需求了。我没有仔细看Puppet的notify如何实现不知道是否有这么灵活。 多个SLS文件 在更有扩展性的部署Salt State时需要用到不止一个SLS文件。上面的例子中只使用了1个SLS文件2个或者多个SLS文件可以结合形成State Tree。上面的例子还使用了一个奇怪的文件来源--salt://apache/httpd.conf这个文件究竟在什么位置呢 SLS文件一定是目录结构哦分布在master上SLS和要下发到minion上的文件都只是普通文件。 上面的例子中的文件再Salt的根目录见《SaltStack中的文件服务器》分布如下 apache/init.sls apache/httpd.conf httpd.conf只是Apache目录下的一个普通文件可以直接引用。使用多个SLS文件可以更加灵活方便以SSH为例 ssh/init.sls: 1 2 3 4 5 6 7 8 9 10 openssh-client: pkg.installed /etc/ssh/ssh_config: file.managed: - user: root - group: root - mode: 644 - source: salt://ssh/ssh_config - require: - pkg: openssh-client ssh/server.sls 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 include: - ssh openssh-server: pkg.installed sshd: service.running: - require: - pkg: openssh-client - pkg: openssh-server - file: /etc/ssh/banner - file: /etc/ssh/sshd_config /etc/ssh/sshd_config: file.managed: - user: root - group: root - mode: 644 - source: salt://ssh/sshd_config - require: - pkg: openssh-server /etc/ssh/banner: file: - managed - user: root - group: root - mode: 644 - source: salt://ssh/banner - require: - pkg: openssh-server 1 2 3 4 Note在ssh/server.sls中用了两种不同的方式来表示用Salt管理一个文件。在ID为 /etc/ssh/sshd_config段中直接使用file.managed作为state声明而在ID为/etc/ssh/banner段中 使用file作为state声明附加一个managed属性。两种表示方法的含义与结果完全一样只是写法不同。 现在State Tree如下有些被引用的文件没有给出内容不影响立即 1 2 3 4 5 6 7 apache/init.sls apache/httpd.conf ssh/init.sls ssh/server.sls ssh/banner ssh/ssh_config ssh/sshd_config ssh/server.sls中使用了include语句。include将别的SLS添加到当前文件中所以可以require或watch被引用的SLS中定义的内容还可以extend其内容马上讲到。include语句使得state可以跨文件引用。使用include相当于把被引用的内容文件添加到自身。 扩展被引用的SLS数据 Extend 扩展是什么意思呢比如在ssh/server.sls中定义了一个apache通用的服务器现在要增加一个带mod_python模块的apache不需要重头写新的SLS直接include原来的server.sls然后增加安装mode_python的state再在apache service的watch列表中增加mod_python即可。python/mod_python.sls内容如下 1 2 3 4 5 6 7 8 9 include: - apache extend: apache: service: - watch: - pkg: mod_python mod_python: pkg.installed 这个例子中先将apache目录下的init.sls文件包含进来在include一个目录时Salt会自动查找init.sls文件然后扩展了ID为apache下的service state中的watch列表。 也可以在Extending中修改文件的下载位置。ssh/custom-server.sls: 1 2 3 4 5 6 include: - ssh.server extend: /etc/ssh/banner: file: - source: salt://ssh/custom-banner Extend使得Salt的SLS更加灵活。为什么SLS能够做Extend呢文章一开始最强调了SLS中的文件仅仅是结构化的data而已在处理SLS时会将其中的内容解析成Python中的dict当然这个dict中会嵌套dict和list。修改apache watch的内容相当于往list里面添加一个元素修改banner文件的下载路径相当于修改dict中的某个key对应的值。在extending时会附加加require/watch的内容而不是覆盖。 理解渲染系统 Render System 因为SLS仅仅是data所以不是非得用YAML来表达。Salt默认使用YAML只是因为易学易用。只要有对应的rendererSLS文件可以用任何方式表达Salt关心的是最终解析出来的数据结构只要你的renderer能够按要求返回这个数据结构Salt干嘛关心你如何书写源文件呢。 Salt默认使用yaml_jinja渲染器。yaml_jinjia先用jinja2模板引擎处理SLS然后再调用YAML解析器。这种设计的好处是可以在SLS文件使用所有的编程结构jinja2能怎么用这里就能怎么用。条件循环Python代码什么都可以。 其他可用的渲染器还包括yaml_mako使用Mako模板引擎yaml_wempy使用Wempy模板引擎py直接使用Python写SLS文件pydsl建立在Python语法基础上的描述语言。 简单介绍默认的渲染器 —— yaml_jinja 关于jinja模板引擎的使用请参考其官方文档 在基于模板引擎的渲染器里可以从3个组件中获取需要的数据saltgrains和pilla。在模板文件中可以用salt对象执行任意的Salt function使用grains访问Grains数据。示例如下 apache/init.sls: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 apache: pkg.installed: {% if grains[os] RedHat%} - name: httpd {% endif %} service.running: {% if grains[os] RedHat%} - name: httpd {% endif %} - watch: - pkg: apache - file: /etc/httpd/conf/httpd.conf - user: apache user.present: - uid: 87 - gid: 87 - home: /var/www/html - shell: /bin/nologin - require: - group: apache group.present: - gid: 87 - require: - pkg: apache /etc/httpd/conf/httpd.conf: file.managed: - source: salt://apache/httpd.conf - user: root - group: root - mode: 644 这个例子很容易理解用到了jinja中的条件结构如果grains中的os表明minion的操作系统是Red Hat那么Apache的软件包名和服务名应当是httpd。 再来一个更NB的例子用到了jinja的循环结构在设置MooseFs分布式chunkserver的模块中 moosefs/chunk.sls: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 include: - moosefs {% for mnt in salt[cmd.run](ls /dev/data/moose*).split() %} /mnt/moose{{ mnt[-1] }}: mount.mounted: - device: {{ mnt }} - fstype: xfs - mkmnt: True file.directory: - user: mfs - group: mfs - require: - user: mfs - group: mfs {% endfor %} /etc/mfshdd.cfg: file.managed: - source: salt://moosefs/mfshdd.cfg - user: root - group: root - mode: 644 - template: jinja - require: - pkg: mfs-chunkserver /etc/mfschunkserver.cfg: file.managed: - source: salt://moosefs/mfschunkserver.cfg - user: root - group: root - mode: 644 - template: jinja - require: - pkg: mfs-chunkserver mfs-chunkserver: pkg: - installed mfschunkserver: service: - running - require: {% for mnt in salt[cmd.run](ls /dev/data/moose*) %} - mount: /mnt/moose{{ mnt[-1] }} - file: /mnt/moose{{ mnt[-1] }} {% endfor %} - file: /etc/mfschunkserver.cfg - file: /etc/mfshdd.cfg - file: /var/lib/mfs 这个例子展示了jinja的强大多个for循环用来动态地检测并挂载磁盘多次使用salt对象这里使用了cmd.run这个执行模块执行shell命令来收集数据。 简单介绍Python和PyDSL渲染器 在任务逻辑非常复杂时默认的yaml_jinja渲染器不一定满足要求这时可以使用Python渲染器。如何在State tree中添加使用py渲染器的SLS文件呢简单。 一个非常简单的基本Python SLS文件 python/django.sls: 1 2 3 4 5 6 7 #!py def run(): Install the django package return {include: [python], django: {pkg: [installed]}} 这个例子也很好理解第1行告诉Salt不使用默认的渲染器而是用py。接着定义了函数run这个函数的返回值必须符合Salt的要求即HighState数据结构我接下来就写关于HighState的文章现在不必关心其细节反正就是一个dictkey和value都有规定好的含义。 如果换用pydsl渲染器上面的例子会更简洁 python/django.sls: 1 2 3 #!pydsl include(python, delayedTrue) state(django).pkg.installed() 如果用YAML会是下面这个样子 1 2 3 4 include: - python django: pkg.installed 这也可以看出正常情况下使用YAML是非常合适的但如果有需要时使用纯粹的Python SLS可以非常NB。 运行和调试Salt States 写好的SLS如何才能应用到minion呢在SaltStack中远程执行是一切的基础。执行命令salt * state.highstate会让所有的minion到master上来取走自己的SLS定义然后在本地调用对应的state moduleuserpkgservice等来达到SLS描述的状态。如果这条命令只返回minion的主机名加一个:多半是哪一个SLS文件有错。如果minion是以服务进程启动执行命令salt-call state.highstate -l debug可以看到错误信息便于调试。minion还可以直接在前台以debug模式运行salt-minion -l debug。 本文转自027ryan 51CTO博客原文链接http://blog.51cto.com/ucode/1935058如需转载请自行联系原作者
