HOW DO I USE SALT STATES - 如何使用SaltStack States进行状态管理?

简单,简洁,简洁

许多最强大和最有用的工程解决方案都建立在简单的原则之上。 Salt State努力做到这一点:K.I.S.S (Keep It Stupidly Simple)。

Salt State系统的核心是SLS或SaLt State文件。 SLS表示系统应处于的状态,并设置为使用一种简单的格式包含此数据。 这通常称为配置管理。

注:这只是学习使用state状态的开始,请务必仔细阅读Pillar next

您也可以参考github上相同的一份技术资料:HOW DO I USE SALT STATES?

IT IS ALL JUST DATA

在深入研究细节之前,理解SLS文件只是一个数据结构会有帮助。 虽然理解SLS只是一种数据结构对于理解和利用Salt States并不重要,但它应该有助于增强对实际功能如何发挥作用的了解。

SLS文件实际上只是字典、列表、字符串和数字。 通过使用这种方法,Salt可以更加灵活。 当一个人写入更多的状态文件时,它就会更清楚地写出正在编写的内容。 结果会是一个易于理解的系统,但随着管理员或开发人员的需求而增长。

THE TOP FILE

可以使用名为top.sls的文件将以下部分中的示例SLS文件分配给主机。 需要深入了解此文件,可以参照这里

DEFAULT DATA - YAML

默认情况下,Salt代表SLS数据,它是最简单的可用序列化格式之一–YAML。

典型的SLS文件在YAML中通常如下所示:

注: 这些演示使用一些通用服务和包名称,不同的发行版通常对包和服务使用不同的名称。 例如,在Red Hat系统上应该用httpd替换apache。 Salt使用init脚本的名称、systemd名称、upstart名称等基于平台的底层服务管理。 要获取平台上可用服务名称的列表,请执行service.get_all salt函数。

有关如何使状态与多个发行版一起工作的信息将在本教程的后面部分中介绍。

apache:
  pkg.installed: []
  service.running:
    - require:
      - pkg: apache

此SLS数据将确保安装名为apache的程序包,并确保apache服务正在运行。 下面对各组件做简单的解释。

  • 第一行是一组数据的ID,称为ID声明。 此ID设置的是需要操作的事物的名称。
  • 第二行和第三行包含要运行的状态模块函数,格式为<state_module>.<function>pkg.installed状态模块功能可确保通过系统的本机程序包管理器安装软件包。 service.running状态模块函数确保给定的系统守护程序正在运行。
  • 最后,在第四行,是单词require。 这称为必需语句,它确保仅在成功安装apache包后才启动Apache服务。

ADDING CONFIGS AND USERS

在设置Apache Web服务器之类的服务时,可能需要添加更多组件。 比如很可能会管理Apache配置文件,并且可能需要设置用户和组。

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

添加更多状态很容易,因为新的用户和组状态在Apache ID下,用户和组将是Apache用户和组。 require语句将确保只在组之后创建用户,并且只有在安装Apache软件包之后才会创建该组。

接下来,服务中的require语句被更改为watch,现在正在观看3个状态而不是仅仅一个状态。 watch语句与require相同,确保在使用watch运行状态之前运行其他状态,但它会添加一个额外的组件。 watch语句将运行状态的观察器功能,以便观察对状态进行的任何更改。因此,如果更新了包、更改了配置文件或者修改了用户uid,那么将运行服务状态的观察程序。在这里服务状态的观察者只是重新启动服务,因此在这种情况下,配置文件的更改将触发相应服务的重新启动。

MOVING BEYOND A SINGLE SLS

以可扩展的方式设置Salt States时,需要使用多个SLS文件。 上面的示例位于单个SLS文件中,但可以组合两个或多个SLS文件来构建状态树。 上面的例子还引用了一个带有奇怪源文件路径的文件 - salt://apache/httpd.conf。 该文件也需要提供。

SLS文件布局在Salt master的目录结构中; SLS只是一个文件,要下载的文件也都只是文件。

Apache示例将在Salt文件服务器的根目录中像下面这样布局,如下所示:

apache/init.sls
apache/httpd.conf

所以httpd.conf只是apache目录中的一个直接引用的文件。

注意:不要在SLS文件名或其目录中使用.的字符。

top.sls和Include声明的初始实现遵循python导入模型,其中斜杠表示为句点。 这意味着无法在引用名称中使用带有句点的SLS文件(除了后缀句点)。 例如,webserver_1.0.sls不可引用,因为webserver_1.0将会去尝试引用配置目录/文件webserver_1/0.sls 。

这同样适用于任何子目录,这在创建git repos时特别“棘手”。 另一个通常无法正常呈现输出的命令是包含点的路径中文件的state.show_sls

但是,当使用多个单个SLS文件时,可以将更多组件添加到工具箱中。 看下这个SSH示例:

ssh/init.sls:

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:

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

请注意,我们使用了两种类似的方式表示文件由Salt管理。 在上面的/etc/ssh/sshd_config状态部分中,我们使用file.managed状态声明,而使用/etc/ssh/banner状态部分,我们使用文件状态声明并向该状态声明添加托管属性。 两种方式都产生相同的结果; 第一种方式使用file.managed会更加简洁一些。

现在我们的State Tree看起来像这样:

apache/init.sls
apache/httpd.conf
ssh/init.sls
ssh/server.sls
ssh/banner
ssh/ssh_config
ssh/sshd_config

此示例中引入了include语句。 include语句用于包含另一个SLS文件,在其中找到的组件同样可以被required、watched或者extended。

include语句允许状态跨链接引用。 当SLS具有include语句时,它实际上会被扩展为包括所包含的SLS文件的内容。

请注意,某些SLS文件称为init.sls,而其他文件则不称为init.sls。 有关这意味着什么的更多信息可以在States Tutorial中找到。

EXTENDING INCLUDED SLS DATA

有时需要扩展SLS数据。 也许apache服务需要观察额外的资源,或者在某些情况下需要放置不同的文件。

在这些示例中,第一个将向ssh添加自定义banner,第二个将向apache添加更多观察者以包含mod_python。
ssh/custom-server.sls:

include:
  - ssh.server

extend:
  /etc/ssh/banner:
    file:
      - source: salt://ssh/custom-banner

python/mod_python.sls:

include:
  - apache

extend:
  apache:
    service:
      - watch:
        - pkg: mod_python

mod_python:
  pkg.installed

custom-server.sls文件使用extend语句覆盖下载banner配置文件的位置,从而更改用于配置banner的文件。

在新的mod_python SLS中添加了mod_python包,但更重要的是扩展了apache服务以观察mod_python包。

Using extend with require or watch

extend语句中require或watch的工作方式不同。 它采取附加而不是替换必需的组件。

UNDERSTANDING THE RENDER SYSTEM

由于SLS数据只是数据,因此不需要用YAML表示。 Salt默认为YAML,因为它非常简单易学,易于使用。但是,只要提供了渲染器模块,就可以从几乎任何可以想象的介质渲染SLS文件。

默认渲染系统是jinja|yaml渲染器。 jinja|yaml渲染器将首先通过Jinja2模板系统传递模板,然后通过YAML解析器。这样做的好处是在创建SLS文件时可以使用完整的编程结构。

其他可用的渲染器是yaml_makoyaml_wempy,它们分别使用MakoWempy模板系统而不是jinja模板系统,更值得注意的是纯Python或pypydslpyobjects渲染器。 py渲染器允许用纯Python编写SLS文件,在准备SLS数据时允许最大程度的灵活性和功能;而pydsl渲染器提供了一种灵活的,特定于域的语言,用于在Python中创建SLS数据;pyobjects渲染器为你提供了一个建立状态数据的“Pythonic”界面。

注意:上述模板引擎不仅可用于SLS文件。它们还可以用于file.managed状态中,使文件管理更加动态和灵活。有关在托管文件中使用模板的一些示例,请参阅文件状态的文档以及下面的MooseFS示例。

GETTING TO KNOW THE DEFAULT - JINJA|YAML

默认渲染器 - jinja|yaml允许使用jinja模板系统。 可以在这里找到Jinja模板系统的指南:http://jinja.pocoo.org/docs

使用渲染器时,会传入一些非常有用的数据。对于基于模板引擎的渲染器,可以使用三个关键组件,salt, grains和pillar。 salt对象允许从模板中调用任何Salt函数,而grains允许从模板中访问Grains。 几个例子:

apache/init.sls:

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

这个例子很简单。 如果os grain声明的操作系统是Red Hat,那么Apache包和服务的名称需要是httpd。

下面是一个更积极的使用Jinja的方法,在一个模块中设置一个MooseFS分布式文件系统块服务器:

moosefs/chunk.sls:

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对象调用shell命令来收集数据。

INTRODUCING THE PYTHON, PYDSL, AND THE PYOBJECTS RENDERERS

有时,所选的默认渲染器可能没有足够的逻辑能力来完成所需的任务。 发生这种情况时,可以使用Python渲染器。 通常,YAML渲染器可以用于大多数SLS文件,但是设置为使用其他渲染器的SLS文件也可以轻松添加到树中。

下面是一个非常基本的Python SLS示例文件:

python/django.sls:

#!py

def run():
    '''
    Install the django package
    '''
    return {'include': ['python'],
            'django': {'pkg': ['installed']}}

这是一个非常简单的例子; 第一行有一个#!py,它告诉Salt不使用默认渲染器,而是使用py渲染器。 然后定义run函数,run函数的返回值必须是Salt友好的数据结构,或者更好地称为Salt HighState数据结构。

或者,使用pydsl渲染器,上面的示例可以更简洁地编写为:

#!pydsl
include('python', delayed=True)
state('django').pkg.installed()

pyobjects渲染器提供了一种基于“Pythonic”对象的方法来构建状态数据。 上面的例子可以写成:

#!pyobjects

include('python')
Pkg.installed("django")

如果它们是用YAML编写的,那么这些Python示例将如下所示:

include:
  - python

django:
  pkg.installed

这个例子清楚地说明了: 一、默认情况下使用YAML渲染器是一个明智的决定;二、可以通过使用纯Python SLS在需要的地方获得无限制的功能。

RUNNING AND DEBUGGING SALT STATES

一旦SLS中的规则准备就绪,就应对其进行测试以确保它们正常工作。 要调用这些规则,只需在命令行上执行salt '*' state.apply。 如果执行后只返回了主机名,但是没有返回数据,则可能是一个或多个sls文件出现问题。 在minion上,使用salt-call命令检查错误输出:

salt-call state.apply -l debug

这应该有助于解决问题。

通过运行salt-minion -l debug,也可以在调试模式下在前台启动minion,帮助调试问题。

NEXT READING

了解states状态后,下一个建议是熟悉Salt的pillar接口:

Pillar Walkthrough

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值