zoukankan      html  css  js  c++  java
  • 七天学会SALTSTACK自动化运维 (2)

    七天学会SALTSTACK自动化运维 (2)

    • 导读
    • Grains
    • Pillar
    • 总结
    • 参考链接

    导读
    上一篇主要介绍了安装和基本的使用方法,但是我认为如果理解了相关概念的话,使用会更加顺手,因为毕竟每一个组件都是有理由这么做的,并不是乱做的,所以一定要理解这些概念是什么意思,为什么要这样做,然后必要的时候再去debug代码。 这里主要介绍Grains和Pillar 这2个概念.


    接下来会分别介绍Saltstack中的核心概念,核心概念理解之后,应用起来才会得手,对于trouble shooting也是有很大的帮助.

    Grains

    Saltstack通过Grains来展示数据, Grans其实就是存储于minion上的一组静态数据,它在minion启动的时候就已经被读取并且存储了,不要被它的名字所误导,就是一组存储与minion上的数据而已,可以由SLS配置文件来配置来组织自己想要的数据,然后通过在master上通过简单的命令来获取,大部分时候可以用于minion的监控。grains的数据好比服务器的硬盘大小,cpu频率等各种参数.

    Grans 是大小写不敏感的, FOO, foo 会得到相同的返回结果.

    获取grains的值是非常简单的

    salt -G 'A:C' test.echo 'how are you'
    

    如上的命令会去匹配符合具有 'A:B' 的minion,然后在该服务器上执行 test.echo命令, 之前笔者都是使用pcre去匹配minion的id去选定主机的,现在可以使用grains去匹配了,而且grains的匹配也有多种方式,搭配灵活,又比方说如下的命令

    salt -G 'A:B:C' test.echo 'how are you again'
    

    这条命令就是用来匹配具有 grains A并且A下有一个字典,字典的内容是 B:C 的minion, 我的配置文件是这样写的

    grains:
          A:
            B: C
    

    Grains本身应用起来非常简单,如果想要获取全部的grains信息可以使用下面的命令

    salt -E mypc grains.ls
    salt -E mypc grains.items
    

    这2条命令会获取一个grains的字典,包含匹配minion的所有grains信息.

    Grains的配置

    Grains的配置途径有两种,可以配置在minion的配置文件中,也可以配置在minion服务器上的/etc/salt/grains中,配置方法大同小异,分别介绍之前,先要说明一件事,在官方的Grains指南当中,大部分的案例都是通过Grains去适配minion的,其实也就是起的一个选择器的作用,当然你也可以随意使用grains去做其他的功能,Grains通常用于minion适配非常方便,因为我总不能把mysql版本,apache版本,nginx版本,redis版本全都写进minion的id里去吧,这是笔者对grains的理解,当然你也应该有自己的理解,毕竟人各不同.

    #!/usr/bin/env python
    def my_grains():
    	grains = dict(user='younger')
    	return grains
    

    这样定义的脚本会被分发到minion,可以随意写入信息,脚本的位置应该是在一个叫做 _grains 的文件夹中,该文件夹位置与 master配置文件中的 file_roots 中所配置的路径相同, 脚本写好之后,经过

    sudo salt -E mypc state.highstate
    

    这条命令之后才可以通过 grains.get 获取, 按照文档中说法, 必须每次都执行在minion启动的时候都执行这条命令,文档中有一个补救方法,文中描述了一个先有鸡还是先有蛋的ISSUE(# TODO),有待深入研究,通过文中的reactor,便可以解决在启动minion的时候顺便同步grains的问题。

    最后关于grains还有一个优先级别的问题,由于有多种方式定义grains,而系统本身又带有自己的grains,所以就要小心在自定义grains的时候,覆盖系统自带的grain,除非你是故意这么做的。

    1 Core grains.
    2 Custom grain modules in _grains directory, synced to minions.
    3 Custom grains in /etc/salt/grains.
    4 Custom grains in /etc/salt/minion.
    

    上面的列表中,下面的条目会覆盖上面的条目,目录 _grains中的grains会覆盖系统自带的grians, /etc/salt/grains中的grain会覆盖前2个级别的grains,/etc/salt/minion 在有定义的情况下,会成为最终的grains,就是会覆盖其余的所有grains。 核心grains在这里.


    Pillar

    Pillar与Grains经常被混淆,这是官方Pillar文档里的说法,当然,就在昨天的之后我基本还不知道Pillar与Grains的区别,不过现在知道了,要分清楚2者是很简单的

    1 前者master定义传给minion,后者minion自己定义
    2 前者是存储在master上的,后者基本上全部存储于minion上
    3 前者可以动态定义,后者是静态常量
    

    从文档来看,Pillar基本上是作用于动态配置管理上的,基本的应用场景比如,a, b, 2台vps,一个是dev,是一个prod, 这2个服务器的grains中都有一个叫做ENV的值,值分别是 dev和prod, 在请求django的配置文件的时候,需要做highstate,这个时候把watch的config文件名写在pillar里, pillar里的逻辑是根据不同的grains值返回不同的结果,这里是文件名,这样不同的minion,在highstate的时候,就会获取不同的配置文件, 这个是很简单的场景, 当然你也可以直接在sls里配置。 更通用的情况是传输密码之类的敏感数据,这样不仅好管理,而且也更安全, 不用每次登陆ssh然后改完之后再改另一个,突触一个批量修改。具体请参见文档中的4个应用场景,不过一定要记住,pillar是动态的数据,可以写到变量里,然后根据不同的情况用不通的值,基本上就是这么个用法。

    现在来看一个简单的例子

    pillar的配置路径要在master的配置文件里设置, pillar_roots, 这里我使用默认的路径,也就是 /etc/pillar, 没有的话就直接建立相应文件,我的配置里一共有2个文件,分别如下

    top.sls
    
    base:
          '*':
            - config
    
    -------------------------------------------------------
    config.sls
    
    {% if grains['env'] == 'development'%}
    	config: dev
    {% else %}
    	config: prod
    {% endif %}	
    

    这个是一目了然的例子,模板是jinja2的,模板的使用可以参考这里.

    当我执行这条命令的时候

    sudo salt -E mypc pillar.get config
    返回
        mypc:
          prod
    这时候我的env是 development
    -------------------------------------
    返回
    mypc:
      dev
    这时候我的env配置是其他值
    

    这里只给出在我的理解之上最简单的用法,实际环境可以按需求慢慢扩展,慢慢学习。

    还有一个复杂一点的例子,这个例子用来配置不同apache配置文件,原理就是 读grains,然后pillar动态生成变量, /etc/salt/web.sls中使用jinja2渲染变量到模板,然后调用 sudo salt -E mypc state.highstate 命令同步文件,根据config grains来复制dev或者prod的配置文件.

        /etc/pillar/top.sls
    base:
                '*':
                        - config
    ------------------------
    /etc/pillar/config.sls
    {% if grains['env'] == 'development'%}
    	config: dev
    	{% else %}
    	config: prod
    	{% endif %}
    -------------------------
    /etc/salt/web.sls
    apache_config:
      file.managed:
    	    - name : /etc/{{ pillar.get('config', 'dev') }}.config
    	    - source: salt://{{ pillar.get('config', 'dev') }}.config
    
    gedit:
      pkg.installed:
    	    - watch:
      	    - file: apache_config
    
    /etc/salt/prod.config:
          password: 123
        /etc/salt/dev.config:
          password: 321
    

    比较简单的例子,功能比上一个复杂不少,具体的可以参见官方文档.


    总结

    笔者主要是在研究了好几篇文档之后才有的这篇心得,主要是理解概念上,理解之后就可以顺着软件的思路来写配置了,saltstack可以简单使用,也可以做非常复杂的分布式配置,单机可以配合花生壳使用,主要看应用场景是什么。


    参考链接

    http://docs.saltstack.com/en/latest/topics/tutorials/starting_states.html(pillar文档)
    http://docs.saltstack.com/en/latest/topics/targeting/grains.html (grains文档)
    http://docs.saltstack.com/en/latest/topics/reactor/index.html#minion-start-reactorss (鸡蛋问题)
    http://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html (jinaj2模板)

    http://www.shencan.net/index.php/2013/05/24/saltstack-二-grains和pillar/ (一个友人的grains和pillar教程)

  • 相关阅读:
    Cobbler自动装机试验
    内嵌元素、块元素、内联块的区分以及内嵌元素的问题
    内嵌元素、块元素、内联块的区分以及内嵌元素的问题
    MyEclipse构建WebService案例
    xgqfrms™, xgqfrms® : xgqfrms's offical website of GitHub!
    xgqfrms™, xgqfrms® : xgqfrms's offical website of GitHub!
    xgqfrms™, xgqfrms® : xgqfrms's offical website of GitHub!
    xgqfrms™, xgqfrms® : xgqfrms's offical website of GitHub!
    xgqfrms™, xgqfrms® : xgqfrms's offical website of GitHub!
    xgqfrms™, xgqfrms® : xgqfrms's offical website of GitHub!
  • 原文地址:https://www.cnblogs.com/youngershen/p/4316552.html
Copyright © 2011-2022 走看看