标签: salt-stack

我正在使用SaltStack,并为那些与谷物匹配的小兵们提供支柱文件.

当我在minions CLI上运行mine.get命令时,它运行正常:

salt-call mine.get 'role:production-server' network.ip_addrs grain 返回主机及其IP的列表.

但是,在同一个minion上的jinja模板中使用相同的命令会导致错误:

{% for host, ip in salt['mine.get']('role:production-server', 'network.ip_addrs', expr_form='grain').items() %}

local:
Data failed to compile:
----------
Pillar failed to render with the following messages:
----------
Rendering SLS 'role_settings.staging-server' failed, render error:
Jinja error: 'master_uri'
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 265, in              render_jinja_tmpl
output = template.render(**unicode_context)
File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 894, in render
return self.environment.handle_exception(exc_info, True)
File "<template>", line 25, in top-level template code
File "/usr/lib/python2.7/dist-packages/salt/modules/mine.py", line 182, in get …

我们有以下盐状态,手表是否意味着要求？或者这条规则是最好的？

"celery-worker:":
  supervisord.running:
    - update: True
    - watch:
      - file: /etc/supervisor/conf.d/celery-worker.conf
      - pkg: ingestion
    - require:
      - file: /etc/supervisor/conf.d/celery-worker.conf
      - pkg: ingestion

在创建vm时,除非你处于详细模式,你的屏幕上有闪烁的音调,否则我不会完全得到盐的任何响应,它并不代表好的信息salt-call.

这是你得到的 vagrant up web

192:vagrant-starter holms$ vagrant up web
Bringing machine 'web' up with 'virtualbox' provider...
==> web: Importing base box 'debian80'...
==> web: Matching MAC address for NAT networking...
==> web: Setting the name of the VM: vagrant-starter_web_1410407135596_15907
==> web: Clearing any previously set forwarded ports...
==> web: Clearing any previously set network interfaces...
==> web: Preparing network interfaces based on configuration...
    web: Adapter 1: nat
==> web: Forwarding ports...
    web: 80 => 9999 (adapter 1) …

我在/ etc/salt/master中的环境结构如下所示

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

我的top.sls文件在/ srv/salt中

dev:
  'ip-10-1-1-28':
    - devtest

stg:
  'ip-10-1-1-252':
    - stgtest

prod:
  'ip-10-1-1-200':
    - prodtest

现在我想为特定环境运行state.highstate,比如'stg'.我在找这样的东西,

salt '*' state.highstate env=stg

我该如何实现这一目标？我的要求是每次运行命令时,我都不希望所有环境中的minions都运行SLS文件.有解决方案吗

运行初始安装大约需要20分钟,运行salt-call state.highstate大约需要6分钟.这不是不合理的,但我想加快速度,但我不确定如何找到最慢的状态.

除了用秒表观看我的屏幕6分钟之外,还有什么方法可以找到每个状态运行多长时间？

saltstack 是否有相当于 puppets versioncmp() 的函数？或者，是否有一种方法可以在 jinja+yaml 渲染的 sls 文件中获取 distutils.version 或 Packaging.version.parse 方法（如Compare version strings in Python 中提到的）？

我正在考虑转向salt(目前正在使用ansible)管理一组独立的物联网设备(实际上是Raspberry Pi).

这些设备将安装一个通用映像,我将在其上添加salt(客户端)安装以及指向的配置文件salt-master,该配置文件将提供由minions使用的状态文件.

状态文件包括名称的HTTP查询,然后将其应用于设备(​​作为其主机名).显而易见的问题是,在那个阶段,仆从已经使用salt-master之前的(通用)名称进行了注册.

如何处理这种情况？具体来说:如何将新主机名传播到salt-master？(只是更改主机名并重新启动没有帮助,我假设主机名是捆绑在服务器上的,具有minion的ID).

更一般的问题salt是,这种情况是否适合产品(设置小兵的状态改变其名称等)

我正在努力增强我的Python技能,我遇到了使用types.FunctionType的Saltstack的开源代码,我不明白发生了什么.

salt.cloud.clouds.cloudstack.py

函数create()有以下代码:

kwargs = {
    'name': vm_['name'],
    'image': get_image(conn, vm_),
    'size': get_size(conn, vm_),
    'location': get_location(conn, vm_),
}

函数get_image和get_size传递给函数'namespaced_function',如下所示:

get_size = namespaced_function(get_size, globals())
get_image = namespaced_function(get_image, globals())

salt.utils.functools.py

具有命名空间功能

def namespaced_function(function, global_dict, defaults=None, preserve_context=False):
    '''
    Redefine (clone) a function under a different globals() namespace scope
        preserve_context:
            Allow keeping the context taken from orignal namespace,
            and extend it with globals() taken from
            new targetted namespace.
    '''
    if defaults is None:
        defaults = function.__defaults__

    if preserve_context:
        _global_dict = …

我在 Kubernetes 上作为 pod 运行 Jenkins 版本 2.85（亲和力设置为一个工作节点）。我通过将 XML 传递给该模块来使用Salt Jenkins 模块创建作业。

我正在使用 Jenkins Global Library 来执行作业。

我的工作配置如下所示

我正在使用 repoURL、componet 等参数调用 GobalLibrary，

几周来一切都很顺利，现在我遇到了一个奇怪的情况，我的作业配置（config.xml）自动更新/恢复。

我的“使用参数构建”选项间歇性地消失，我只能在 Jenkins GUI 中看到“立即构建”。最初我以为有人在这样做，所以为了跟踪配置更改，我在 Jenkins 中安装了作业配置历史记录插件，但我发现很奇怪。用户名为“SYSTEM”的人正在进行/恢复更改。

这就是它的样子

我发现系统用户仅恢复作业配置更改，而不恢复管道。

我不确定幕后出了什么问题以及如何阻止或解决这个问题。这是我的生产实例，所以我更担心。

我可以在我的 Jenkins 中看到一个 SYSTEM 用户

但我无法删除该用户

我为此找到了一些相关问题，但没有答案

Jenkins 上的系统用户更新作业配置

Jenkins 系统用户删除自定义工作区配置

我不确定这个 Jenkins Bug 或某个插件是否在玩弄我的灵魂。

需要帮忙！:(

我正在使用 django 和 nginx 运行 Gunicorn 并使用 salt 进行部署。

我想更改gunicorn的过程名称，所以我用python制作了一个配置文件

gunicorn_config.py

bind = ...
workers = ...
proc_name = 'Name'
daemon = True
...

在盐状态文件中，

gunicorn_config_file:
  file.managed:
   - name: /etc/gunicorn_config.py
   - source: salt://.../files/gunicorn_config.py
   - template: jinja

并运行它

start_gunicorn:
  cmd.run:
    - name: '{{venv}}/gunicorn -c /etc/gunicorn_conig.py myProject.wsgi'
    - cwd: /path/to/django/project

minion返回全部成功，但gunicorn的进程名称仍然是 gunicorn: master并且gunicorn: worker

其他配置（例如工人）运行良好，但 proc_name 则不然。如何正确更改 proc_name？我setproctitle也在 venv 中用 pip 安装了。

谢谢。