Salt2019.2.0 Release Notes (Codename Fluorine) 新版本功能特性

SaltStack是基础设施管理的革命性方法,能够以速度取代复杂性。 SaltStack足够简单,可以在几分钟内运行,可扩展到足以管理数以万计的服务器,并且速度足以在几秒钟内与每个系统进行通信。从服务器、网络设备到一些行业领域的专有设备,从Linux、Unix、Windos到十几种主流的行业领域专有os类型,SaltStack有出色的兼容性,很多场景下可以允许你以相同方式的命令管理众多异构的设备设施。此外,SaltStack提供了足够完备的技术架构高可用解决方案,以确保你在管理超大规模设施时,不会受性能或可用性问题的干扰。

近日,SaltStack公司公布了2019年度的最新SaltStack发行版本——Salt2019.2.0 (代号:Fluorine )。本文介绍的是在该发行版本中的发布的软件功能新特性以及原有功能模块的相关变更。
在这里插入图片描述
SaltStack Github项目
SaltStack-Chinese-Manual 中文使用资料

以下即为:Salt2019.2.0 Release Notes Codename Fluorine - Salt2019.2.0 的新版本功能特性说明

官网原文参见:https://docs.saltstack.com/en/latest/topics/releases/2019.2.0.html

PYTHON 2.7 DEPRECATION

Python 2.7在2020年1月1日将达到其生命周期终止时间(EOL),SaltStack将在Sodium发行版本或之后的版本中弃用对Python 2的支持。该决定有待进一步的社区讨论确定。

Codename是SaltStack为了便于记忆和使用,而为Salt发行版本命名的一种代码名称。SaltStack采用了元素周期表中各元素的名称和顺序,每个元素均代指某一个的Salt发行版本,依次使用。

例如:

  • Salt 2016.10.0 —— Carbon(碳)
  • Salt 2017.7.0 —— Nitrogen(氮)
  • Salt 2018.3.0 —— Oxygen(氧)
  • Salt 2019.2.0 —— Fluorine(氟)
  • ? —— Neon(氖)
  • ? —— Sodium(钠)

YAML RENDERER的在非后向兼容方面的变化

在早期版本中,假设数据是包含unicode类型的键/值的列表或字典,这被认为是Python 2中的有效用法:

/etc/foo.conf:
  file.managed:
    - source: salt://foo.conf.jinja
    - template: jinja
    - context:
        data: {{ data }}

一个常见的用例是使用一个Salt的自定义Jinja过滤器返回列表或词典,例如ipv4过滤器

在Python 2中,Jinja将使用“u”前缀(例如{u’foo’:u’bar’})以在列表/字典中显示unicode字符串类型。 虽然属于无效的YAML,但早期版本会成功加载这些值。

截至本版本,上述SLS将会导致错误消息。 如果仍然需要允许将数据结构直接转储到SLS文件中,请使用tojson Jinja过滤器:

/etc/foo.conf:
  file.managed:
    - source: salt://foo.conf.jinja
    - template: jinja
    - context:
        data: {{ data|tojson }}

Note:
此过滤器是添加到了Jinja 2.9中。 但是,也不必担心! 在Salt 2018.3.3版本也添加了一个类似功能的tojson过滤器,如果此过滤器尚不存在,将使用该过滤器,以实现功能兼容,使其在RHEL 7和Ubuntu 14.04等平台上可用,这些平台上提供是旧版本的Jinja。

Important:
json_encode_dict和json_encode_list过滤器实际上并没有将结果转储到JSON。 而且由于tojson完成了那些过滤器的设计目的,它们现在已被弃用,并将在Neon版本中被移除。 在所有使用json_encode_dict和json_encode_list的场景下都应该替换为使用tojson过滤器。

ANSIBLE PLAYBOOK STATE AND EXECUTION MODULES

除了包含Oxygen版本中的ansible模块外,2019.2.0版本中还增加了运行playbooks的功能。 这包括一个ansible playbooks状态模块,它可以在目标主机上用来运行ansible playbooks,或者用在编排state runner中。

install nginx:
  ansible.playbooks:
    - name: install.yml
    - git_repo: git://github.com/gtmanfred/playbook.git
    - git_kwargs:
        rev: master

playbooks模块还支持指定一个git repo地址,用来获取部分运行所需的资源文件,或者在运行playbook时可以指定使用一个特定的目录。

NETWORK AUTOMATION - 网络自动化

从此版本开始,Salt为各种网络操作系统提供了更广泛的支持,以及配置变更或命令执行的功能。

NETBOX

在上一版本2018.3.0中新添加的netbox执行模块的功能,在该版本中扩展出了更多的可用功能列表:

  • netbox.create_circuit
  • netbox.create_circuit_provider
  • netbox.create_circuit_termination
  • netbox.create_circuit_type
  • netbox.create_device
  • netbox.create_device_role
  • netbox.create_device_type
  • netbox.create_interface
  • netbox.create_interface_connection
  • netbox.create_inventory_item
  • netbox.create_ipaddress
  • netbox.create_manufacturer
  • netbox.create_platform
  • netbox.create_site
  • netbox.delete_interface
  • netbox.delete_inventory_item
  • netbox.delete_ipaddress
  • netbox.get_circuit_provider
  • netbox.get_interfaces
  • netbox.get_ipaddresses
  • netbox.make_interface_child
  • netbox.make_interface_lag
  • netbox.openconfig_interfaces
  • netbox.openconfig_lacp
  • netbox.update_device
  • netbox.update_interface

除了这个执行模块,Salt用户还可以通过netbox External Pillar模块直接从NetBox将数据加载到设备Pillar中。

netbox是网络设施信息化与可视化管理项目,有兴趣的同学可以移动这里:https://github.com/digitalocean/netbox/tree/master

NETMIKO

NETMIKO=Network + Paramiko

Netmiko是一个简化Paramiko SSH与网络设备连接的多供应商库,现已正式集成到Salt中。 现在可以通过netmiko代理模块或直接从任何Salt Minions使用它,传递连接凭据 - 请参阅netmiko执行模块的文档。

ARISTA

Arista交换机现在可以在pyeapi代理模块下进行管理,并通过pyeapi执行模块执行RPC请求。

CISCO NEXUS

虽然在版本代号Carbon(2016.11)中已经添加了对基于SSH的操作的支持,但新的nxos_api代理模块和nxos_api允许通过NX-API管理Cisco Nexus交换机。

重要的是要注意这些模块没有第三方依赖,因此它们可以直接使用任何Salt Minion。 这也意味着用户可以直接在Nexus交换机上安装常规Salt Minion,并像常规服务器一样的管理这些网络设备。

GENERAL-PURPOSE MODULES

新的ciscoconfparse执行模块可用于具有Cisco IOS样式配置(一个空格缩进)的各种网络平台的基本配置解析、审计或验证,以及大括号分隔的配置样式。

iosconfig可用于Cisco IOS样式配置的各种配置操作,例如: configuration cleanup, tree representation of the config等。

NAPALM

COMMIT AT AND COMMIT CONFIRMED

从此版本开始,NAPALM用户可以执行计划提交(通常称为“commit at”)和“commit confirmed”(除非用户通过运行另一个命令确认,否则将恢复配置更改)。 这些功能可通过net.load_config和net.load_template执行函数或netconfig.managed的commit_in,commit_at,revert_in或revert_at参数获得。

对应的执行函数net.confirm_commit或net.cancel_commit,以及State函数netconfig.commit_cancelled或netconfig.commit_confirmed可用于确认或取消提交。

请注意,无论网络设备本机是否支持,任何平台都可以使用提交确认和提交已取消的功能。 但是,要小心谨慎,并确保在生产中使用它们之前阅读并理解警告。

NAPALM(具有多供应商支持的网络自动化和可编程性抽象层)是一个Python库,它实现了一组使用统一API与不同网络设备操作系统交互的功能。NAPALM支持多种方法来连接设备,操作配置或检索数据,对Cisco和Juniper等设备的支持较好。

MULTIPLE TEMPLATES RENDERED SIMULTANEOUSLY

net.load_template执行函数和netconfig.managed State函数的template_name参数现在支持使用模板列表了。 当一个非常大的Jinja模板被拆分成多个更小且更易于阅读的模板时,这一点尤其有用,这些模板最终可以在其他国家或地区得到重复使用。 例如,使用两个不同的模板并通过一次提交更改设备配置,以下语法不能同时管理NTP和BGP的配置:

manage_bgp_and_ntp:
  netconfig.managed:
    - template_name:
        - salt://templates/bgp.jinja
        - salt://templates/ntp.jinja
    - context:
        bpg: {{ pillar.bgp }}
        ntp: {{ pillar.ntp }}

CONNECTION RE-ESTABLISHMENT ON DEMAND

从此版本开始,在NAPALM Proxy Minion下运行时执行的任何NAPALM命令都支持force_reconnect魔术参数。

Proxy Minions通常在Minion启动时与远程网络设备建立连接,并且该连接将永久使用。

如果需要在设备上执行命令但是使用不同的参数进行连接(由于各种原因,例如,无法验证Pillar中指定的用户作为身份验证系统 - 比方说TACACS +不可用,或DNS解析器是目前已关闭并希望暂时使用IP地址等,这意味着需要更新Pillar数据并重新启动Proxy Minion进程重启。 在这种情况下,你可以传递force_reconnect = True关键字参数以及备用连接详细信息,以强制执行通过单独连接执行的命令。

例如,如果通常的命令是salt’*'net.arp,则可以使用以下内容来使用不同的用户名进行连接:

salt '*' net.arp username=my-alt-usr force_reconnect=True

与NAPALM连接所需的任何其他配置参数的使用方法类似 - 请参阅NAPALM代理文档

CONFIGURATION REPLACE FEATURES

要替换各种配置块,可以使用新的net.replace_pattern执行函数或netconfig.replace_pattern State函数。 例如,如果要更新配置并重命名在许多位置引用的BGP策略,可以通过运行以下命令来执行此操作:

salt '*' net.replae_pattern OLD-POLICY-CONFIG new-policy-config

同样地,你也可以使用net.blockreplace函数替换整个配置块。

CONFIGURATION SAVE FEATURES

net.save_config函数可用于将受管设备的配置保存到文件中。 对于State子系统,添加了netconfig.saved函数,该函数在管理可以保存网络设备配置的目标文件时提供完整的工具列表。

例如,在其自己的目录树下备份每个设备的运行配置:

/var/backups/{{ opts.id }}/running.cfg:
  netconfig.saved:
    - source: running
    - makedirs: true

上面提到的所有新的网络自动化模块都直接暴露给NAPALM用户,无需任何架构更改,在管理具体网络设备时只需最终按设备系统类型安装一些依赖包:

1. JUNOS

现有junos执行模块的功能可通过以下函数获得:

  • napalm.junos_cli: Execute a CLI command and return the output as text or Python dictionary.
  • napalm.junos_rpc: Execute an RPC request on the remote Junos device, and return the result as a Python dictionary, easy to digest and manipulate.
  • napalm.junos_install_os: Install the given image on the device.
  • napalm.junos_facts: The complete list of Junos facts collected by the junos-eznc underlying library.

能够使用这些功能,需要确保先满足junos模块的一些依赖性要求。 由于junos-eznc也是NAPALM的依赖项,所以只需要再安装一个jxmlease。详见junos模块说明。

使用样例:

salt '*' napalm.junos_cli 'show arp' format=xml
salt '*' napalm.junos_rpc get-interface-information

2. NETMIKO

新添加的netmiko执行模块的功能如下:

  • napalm.netmiko_commands: 通过Netmiko执行一个或多个要在远程设备上执行的命令,并将输出作为文本返回。
  • napalm.netmiko_config: 通过Netmiko在远程设备上加载一个配置命令的列表。 这些命令既可以从本地,也可以从远程路径加载,通过Salt的模板渲染pipeline传递(默认情况下使用Jinja作为模板渲染引擎)。

使用样例:

salt '*' napalm.netmiko_commands 'show version' 'show interfaces'
salt '*' napalm.netmiko_config config_file=https://bit.ly/2sgljCB

3. ARISTA PYEAPI

对于各种操作和各种扩展模块,pyeapi模块增加了以下功能:

  • napalm.pyeapi_run_commands: Execute a list of commands on the Arista switch, via the pyeapi library.
  • napalm.pyeapi_config: Configure the Arista switch with the specified commands, via the pyeapi Python library. Similarly to napalm.netmiko_config, you can use both local and remote files, with or without templating.

使用样例:

salt '*' napalm.pyeapi_run_commands 'show version' 'show interfaces'
salt '*' napalm.pyeapi_config config_file=salt://path/to/template.jinja

4. CISCO NX-API

以与上面完全相同的方式,用户可以通过使用以下配置原语通过NX-API管理Cisco Nexus交换机进行完全的控制:

  • napalm.nxos_api_show: Execute one or more show (non-configuration) commands, and return the output as plain text or Python dictionary.
  • napalm.nxos_api_rpc: Execute arbitrary RPC requests via the Nexus API.
  • napalm.nxos_api_config: 使用指定的命令通过NX-API配置Nexus交换机。 可以从命令行或本地或远程文件加载命令,最终使用所选的模板引擎(默认值:jinja)进行渲染。

使用样例:

salt '*' napalm.nxos_api_show 'show bgp sessions' 'show processes' raw_text=False

5. CISCOCONFPARSE

在操作Cisco IOS或Junos样式配置时,以下功能列表可能很方便:

  • napalm.config_filter_lines: 根据正则表达式匹配得到的其父级和子级节点关系,返回配置块的详细匹配列表。
  • napalm.config_find_lines: 返回与提供的正则表达式匹配的配置行。
  • napalm.config_lines_w_child: 返回与正则表达式匹配的配置行,且其子行与子正则表达式匹配。
  • napalm.config_lines_wo_child: 返回与正则表达式匹配的配置行,且这些配置行没有与子正则表达式匹配的子行。

这些函数需要安装ciscoconfparse Python库。

使用样例:

salt '*' napalm.config_lines_w_child 'interface' 'shutdown'

6. IOSCONFIG

对于Cisco IOS样式配置,在napalm执行模块中添加了以下功能:

  • napalm.config_tree: 获取并将Cisco IOS样式配置转换为结构化Python字典。
  • napalm.config_merge_tree: 获取受管理设备的配置树,并将其他配置内容合并配置树中(不实际加载设备上的任何更改)。
  • napalm.config_merge_text: 获取受管理设备的配置树,并将其他配置内容合并配置树中,将合并后的结果保存为一个文本文件。
  • napalm.config_merge_diff: 获取受管理设备的配置树,并将其他配置内容合并配置树中,返回那些有差别的合并内容(不实际加载设备上的任何更改)。

SCP

利NAPALM实现的连接与认证,现在还可以使用以下功能:

  • napalm.scp_put: 传输文件或文件夹到远程的网络设备上。
  • napalm.scp_get: 将文件和目录从远程网络设备传输到Minion的localhost。

PEERINGDB

peeringdb执行模块可用于收集有关可能与你的网络对等的其他网络的信息,并自动建立BGP会话,例如,仅需给定特定的AS号,其余数据(即IP地址,远程网络所在的位置) 从PeeringDB中检索可用的,并且会话配置是自动化的,只需要很少的维护(手动输入IP地址既繁琐又容易出错)。

NEW DOCKER PROXY MINION

现在可以使用新的docker proxy minion将Docker容器视为实际的minions,而无需在容器中安装salt。

此代理minion使用docker executor通过docker.call将命令传递到docker容器。 任何状态模块调用都通过docker模块的相应函数传递。

使用样例:

proxy:
  proxytype: docker
  name: keen_proskuriakova
salt myminion docker.call test.ping
salt myminion test.arg arg1 arg2 key1=val1
salt myminion dockerng.call compassionate_mirzakhani test.arg arg1 arg2 key1=val1

TERRAFORM SALT-SSH ROSTER

现在可以使用terraform-provider-salt定义的terraform资源动态生成Salt-SSH名册。

这允许结合使用terraform和Salt-SSH来监视和配置主机。 有关如何设置和使用的示例,请参阅terraform列表。

GRAINS DICTIONARY PASSED INTO CUSTOM GRAINS

从这个版本开始,如果在使用自定义grains函数时接受一个名为grains的变量,那么已经编译过的grains的Grains字典将被传入。由于grains在被渲染时的顺序是不确定的,唯一可以确定且可以被传入的是core.py grains,因为这些是首先编译的。

MORE PRECISE VIRTUAL GRAIN

在嵌套虚拟化环境(例如VM中的systemd-nspawn容器)中运行Salt并且安装了virt-what时,此版本提高了virtual grain的准确性。

到目前为止,virtual grain是通过匹配virt-what而不是单个项目的所有输出行来确定的,这可能导致不太精确的结果(例如,在基于Hyper-V的VM中运行的systemd-nspawn容器内报告HyperV)。

CONFIGURABLE MODULE ENVIRONMENT

Salt模块(状态,执行模块,returners等)现在可以在运行shell命令时应用自定义环境变量。 这可以通过在Grains或Pillar中设置系统环境键值对来配置。 语法如下:

system-environment:
  <type>
    <module>:
      # Namespace for all functions in the module
      _:
        <key>: <value>

      # Namespace only for particular function in the module
      <function>:
        <key>: <value>
  • <type>,是模块的类型(即states,modules等)
  • <module>,是模块名

模块名称可以是虚拟名称(例如pkg),也可以是物理名称(例如yumpkg)。

  • <function>,是该模块中的函数名称。 要将环境变量应用于给定模块中的所有函数,请使用下划线(即_)作为函数名称。 例如,要为所有包管理函数设置相同的环境变量,可以使用以下内容:
system-environment:
  modules:
    pkg:
      _:
        SOMETHING: for_all

为pkg.install函数设置专有的环境变量:

system-environment:
  modules:
    pkg:
      install:
        LC_ALL: en_GB.UTF-8

设置相同的变量但仅适用于SUSE minions(使用zypper进行包管理):

system-environment:
  modules:
    zypper:
      install:
        LC_ALL: en_GB.UTF-8

Salt目前还不不是全面的支持此功能; 模块必须要明确的支持此功能才可以(虽然这可能在将来发生变化)。 截至本版本,支持此功能的模块是以下几个pkg虚拟模块:

  • aptpkg
  • yumpkg
  • zypper

取消了对在APT中使用"VIRTUAL PACKAGE"的支持

在APT中,一些包具有它们提供的相关联的包列表。 这允许人们在真正的包名为foo1.0时运行apt-get install foo,也能安装上正确的包。

Salt传统上是设计为支持“virtual packages”,它们是由已安装的包提供的,但是没有安装该名称的真实包。 鉴于上面的示例,如果要为名为foo的包运行pkg.installed状态,那么pkg.list_pkgs将为包foo显示为1的包版本,表示它是virtual package。

然而,虽然这使得包管理的某些方面变得方便,但是这种方法的问题使得依赖于“virtual packages”成为问题。 例如,Ubuntu为nginx提供了四种不同的相互冲突的包:

  • nginx-core
  • nginx-full
  • nginx-light
  • nginx-extras

所有这四个都提供了nginx。 然而,还有一个名为nginx的包,它没有实际内容,只依赖于上述四个包中的任何一个。 如果在pkg.installed状态下使用了nginx,并且没有安装上述四个软件包,那么将安装nginx元数据包,这将引入nginx-core_。 稍后,如果在pkg.removed状态下使用nginx,则将删除nginx元数据包,并保留nginx-core。 结果是,由于nginx-core_提供了nginx_,Salt现在将nginx视为已安装的一个virtual package,pkg.removed state将会失败。 此外,实际上不会删除nginx,因为nginx-core将保持安装状态。

从此版本开始,Salt将不再支持在pkg状态中使用“virtual packages”名称,并且需要使用正确的包名指定包名称。 在给定包名(或glob)的情况下,pkg.list_repo_pkgs函数可用于在存储库中查找匹配的包名:

# salt myminion pkg.list_repo_pkgs 'nginx*'
myminion:
    ----------
    nginx:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-common:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-core:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-core-dbg:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-doc:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-extras:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-extras-dbg:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-full:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-full-dbg:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-light:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1
    nginx-light-dbg:
        - 1.10.3-0ubuntu0.16.04.2
        - 1.9.15-0ubuntu1

或者,新添加的pkg.show函数可用于获取有关给定包的更多详细信息,并帮助确定哪个包名称正确:

# salt myminion pkg.show 'nginx*' filter=description,provides
myminion:
    ----------
    nginx:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                small, powerful, scalable web/proxy server
        1.9.15-0ubuntu1:
            ----------
            Description:
                small, powerful, scalable web/proxy server
    nginx-common:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                small, powerful, scalable web/proxy server - common files
        1.9.15-0ubuntu1:
            ----------
            Description:
                small, powerful, scalable web/proxy server - common files
    nginx-core:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                nginx web/proxy server (core version)
            Provides:
                httpd, httpd-cgi, nginx
        1.9.15-0ubuntu1:
            ----------
            Description:
                nginx web/proxy server (core version)
            Provides:
                httpd, httpd-cgi, nginx
    nginx-core-dbg:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                nginx web/proxy server (core version) - debugging symbols
        1.9.15-0ubuntu1:
            ----------
            Description:
                nginx web/proxy server (core version) - debugging symbols
    nginx-doc:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                small, powerful, scalable web/proxy server - documentation
        1.9.15-0ubuntu1:
            ----------
            Description:
                small, powerful, scalable web/proxy server - documentation
    nginx-extras:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                nginx web/proxy server (extended version)
            Provides:
                httpd, httpd-cgi, nginx
        1.9.15-0ubuntu1:
            ----------
            Description:
                nginx web/proxy server (extended version)
            Provides:
                httpd, httpd-cgi, nginx
    nginx-extras-dbg:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                nginx web/proxy server (extended version) - debugging symbols
        1.9.15-0ubuntu1:
            ----------
            Description:
                nginx web/proxy server (extended version) - debugging symbols
    nginx-full:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                nginx web/proxy server (standard version)
            Provides:
                httpd, httpd-cgi, nginx
        1.9.15-0ubuntu1:
            ----------
            Description:
                nginx web/proxy server (standard version)
            Provides:
                httpd, httpd-cgi, nginx
    nginx-full-dbg:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                nginx web/proxy server (standard version) - debugging symbols
        1.9.15-0ubuntu1:
            ----------
            Description:
                nginx web/proxy server (standard version) - debugging symbols
    nginx-light:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                nginx web/proxy server (basic version)
            Provides:
                httpd, httpd-cgi, nginx
        1.9.15-0ubuntu1:
            ----------
            Description:
                nginx web/proxy server (basic version)
            Provides:
                httpd, httpd-cgi, nginx
    nginx-light-dbg:
        ----------
        1.10.3-0ubuntu0.16.04.2:
            ----------
            Description:
                nginx web/proxy server (basic version) - debugging symbols
        1.9.15-0ubuntu1:
            ----------
            Description:
                nginx web/proxy server (basic version) - debugging symbols

MINION STARTUP EVENTS

当一个minion启动时,它会在事件总线上发送一个通知,其标签如下所示:salt/minion/<minion_id>/start。 由于历史原因,minion还发送了一个类似的事件,其中包含如下事件标记:minion_start。 当有许多小兵时,这种重复可能会在事件总线上造成很多混乱。 在minion配置中设置enable_legacy_startup_events:False以确保仅发送salt/minion/<minion_id>/start事件。

新的enable_legacy_startup_events minion配置选项默认为True,但从Salt的Sodium版本开始将默认设置为False。

Salt Syndic目前也发送旧式的syndic_start事件。 syndic也支持enable_legacy_startup_events选项。

FAILHARD CHANGES

现在可以使用一个state-level failhard设置来覆盖全局的failhard设置。 这在全局failhard设置为True时,可以允许你通过将state级别failhard设置为False,而不会因为可能发生失败的特定state状态而影响到全局上的整体停止执行。 这也允许使用onfail*-requisites,这在以前全局failhard设置为True时会被忽略。 这会与以前的行为有所偏差,在以前全局failhard设置总是会在任何状态执行失败时立即停止下来(无论失败状态是否具有自己的失败设置,或者是否使用了任何onfail*-requisites)。

PASS THROUGH OPTIONS TO FILE.SERIALIZE STATE

这允许更精细地控制数据集序列化的方式。 有关详细信息,请参阅file.serialize状态中有关新serializer_opts和deserializer_opts选项的文档。

FILE.PATCH STATE REWRITTEN

file.patch状态已被重写并补充了几个新功能:

  • 补丁源现在可以是远程文件,而不仅仅是salt://URL
  • 现在支持多文件的修补程序
  • 补丁文件也可以支持模板化
    此外,不再需要指定patched file的哈希值。

NEW NO_PROXY MINION CONFIGURATION

支持使用no_proxy minion配置选项传递一个需要绕过HTTP代理的主机列表。

除非同时也配置了proxy_host,否则此配置选项不会执行任何操作。并且它不支持任何类型的通配符。

no_proxy: [ '127.0.0.1', 'foo.tld' ]

CHANGES TO SLACK ENGINE

使用Salt Slack引擎运行的功能函数,返回给Slack的输出现在可以使用该函数的正确输出器进行格式化。 早期的版本中会在YAML中为所有函数做统一的格式化输出,除了正在运行的状态。

ENHANCEMENTS TO WTMP BEACON

Linux系统中都会将系统用户登录、登出信息保存在/var/log/wtmp的一个文件中,在系统中一般可以使用last命令查看。

Salt WTMP Beacon功能正是提供了通过Salt侦听和管理目标主机系统用户登录行为的功能。

新版本中为此信标触发的事件中添加了一个新的键——action,它将包含字符串login或logout。 这将简化使用此信标数据的reactors,因为不再需要检查type键的整数值以了解事件是登录还是注销行为了。

此外,如果在你的平台中使用的是非标准的utmp.h,那么现在可以支持配置哪些类型编号表示登录和注销。

有关更多信息,请参阅wtmp beacon文档。

DEPRECATIONS - 不再支持的一些功能

API DEPRECATIONS

已删除对LocalClient的expr_form参数的支持。 请改用tgt_type。 此更改是由于社区成员报告说在使用中经常会发生混淆,而使用tgt_type定位目标主机发布到minions时,在作业缓存中也会显示为tgt_type,这样会更加清晰且一致。

那些使用LocalClient 旧参数(直接本地调用或通过netapi模块隐式调用)的人需要更新他们的代码以使用tgt_type。

>>> import salt.client
>>> local = salt.client.LocalClient()
>>> local.cmd('*', 'cmd.run', ['whoami'], tgt_type='glob')
{'jerry': 'root'}

MINION CONFIGURATION DEPRECATIONS - 弃用的一些minion配置选项

自2019.2.0发行版起,不推荐使用master_shuffle配置选项。 请改用random_master选项。

MODULE DEPRECATIONS - 弃用的一些Salt modules

  • napalm_network 模块有做以下的变更:
  • 已从net.load_template函数中移除了对template_path的支持。 这是因为已删除对NAPALM本机模板的支持。
  • pip模块有做以下的变更:
  • 已从pip.install函数中删除对no_chown选项的支持。
  • trafficserver模块有做以下的变更:
  • trafficserver.match_var函数已被删除。 请改用trafficserver.match_metric。
  • trafficserver.read_var函数已被删除。 请改用trafficserver.read_config。
  • trafficserver.set_var函数已被删除。 请改用trafficserver.set_config。
  • win_update模块已被删除。 它已被win_wua取代。
  • win_update模块有做以下的变更:
  • win_wua.download_update和win_wua.download_updates函数已被删除。 请改用win_wua.download。
  • win_wua.install_update和win_wua.install_updates函数已被删除。 请改用win_wua.install。
  • win_wua.list_update函数已被删除。 请改用win_wua.get。
  • win_wua.list_updates函数已被删除。 请改用win_wua.list。

PILLAR DEPRECATIONS

  • vault external pillar有做以下的变更:
  • 删除了对profile参数的支持。 在第一个"path=""之前和之后传递的任何选项都将被丢弃。

ROSTER DEPRECATIONS

  • cache roster模块有做以下的变更:
  • 已删除对roster_order作为列表或元组的支持。 截至2019.2.0版本,roster_order必须是字典。
  • roster_order选项现在除了IPv4之外还包括用于私有,公共,全局或本地设置的IPv6。 这些设置的语法分别更改为ipv4-或ipv6-

STATE DEPRECATIONS

  • docker state模块被移除了
  • 在2017.7.0中,该模块中的状态分为四个独立的state模块:
  • docker_container
  • docker_image
  • docker_volume
  • docker_network
  • 为了向后兼容性,docker模块仍保留,但现在已被删除。 请更新SLS文件以使用新的state名称:
    • docker.running => docker_container.running
    • docker.stopped => docker_container.stopped
    • docker.absent => docker_container.absent
    • docker.network_present => docker_network.present
    • docker.network_absent => docker_network.absent
    • docker.image_present => docker_image.present
    • docker.image_absent => docker_image.absent
    • docker.volume_present => docker_volume.present
    • docker.volume_absent => docker_volume.absent
  • docker_network模块有做以下的变更:
  • 已从docker_network.absent中删除了driver选项。 它没有任何功能,因为状态只是删除指定的网络名称(如果存在的话)。
  • 已弃用的ref选项已从git.detached状态中删除。 请改用rev。
  • 已删除k8s状态模块以支持更加通用的kubernetes状态模块。 请按如下方式更新SLS文件:
  • In place of k8s.label_present, use kubernetes.node_label_present
  • In place of k8s.label_absent, use kubernetes.node_label_absent
  • In place of k8s.label_folder_absent, use kubernetes.node_label_folder_absent
  • 已删除对netconfig.managed <salt.states.netconfig.managed()状态中的template_path选项的支持。 这是因为已删除对NAPALM本机模板的支持。
  • 已删除对pip.installed状态中no_chown选项的支持。
  • trafficserver.set_var状态已被删除。 请改用trafficserver.config。
  • 已删除对:py:funcvirtualenv.managed <salt.states.virtualenv.managed>函数中no_chown选项的支持。
  • 已删除win_update状态模块。 它已被win_wua取代。
  • 从py:mod:pkg state <salt.states.pkg>中移除了对virtual packages的支持。

UTILS DEPRECATIONS

  • cloud util模块有做以下的变更:
  • 已删除对salt utils模块中cache_nodes_ip函数的支持。 该功能不完整。
  • vault util模块有做以下的变更:
  • 已删除对在一个“profile”配置中指定Vault连接参数的支持。 有关新配置架构的详细信息,请参阅Vault execution module文档。

DEPENDENCY DEPRECATIONS

Salt-Cloud已更新为使用pypsexec Python库而不是winexe可执行文件。 winexe和pypsexec都针对Windows操作系统运行远程命令。 由于winexe并未针对每个系统进行打包,因此推荐使用pypsexec。

Salt-Cloud已经弃用了impacket,改为使用smbprotocol。 之所以进行此更改,是因为impacket与Python3不兼容。

SALTSSH MAJOR UPDATES

SaltSSH现在适用于多个主要的Python版本。 可以透明地支持Python 2.7~Python 3.x. 但是,这要求SaltMaster应该安装Salt包括Python2和Python3的所有相关依赖项。所有内容都需要从相应的Python环境中导入。

SaltSSH可以捆绑到任意版本的Salt。 例如,如果有一个旧设备,在运行过时且不受支持的Python 2.6,仍然可以从使用Python 3.5或更高版本的SaltMaster访问它。 此功能需要在/etc/salt/master中进行其他配置,如下所示:

ssh_ext_alternatives:
    2016.3:                     # Namespace, can be actually anything.
        py-version: [2, 6]      # Constraint to specific interpreter version
        path: /opt/2016.3/salt  # Main Salt installation
        dependencies:           # List of dependencies and their installation paths
          jinja2: /opt/jinja2
          yaml: /opt/yaml
          tornado: /opt/tornado
          msgpack: /opt/msgpack
          certifi: /opt/certifi
          singledispatch: /opt/singledispatch.py
          singledispatch_helpers: /opt/singledispatch_helpers.py
          markupsafe: /opt/markupsafe
          backports_abc: /opt/backports_abc.py

也可以使用几种替代版本的Salt。 例如,您可以使用runners生成最小的tarball并包含它。 但这是唯一可能的,仅当Master主机上也有这种特定的Salt版本时,虽然不需要与旧的Python解释器一起直接安装。

SaltSSH现在支持私钥密码。 您可以通过以下方式对其进

  • –priv-passwd for salt-ssh cli
  • salt_priv_passwd for salt master configure file
  • priv_passwd for salt roster file

STATE MODULE CHANGES

salt STATE MODULE (USED IN ORCHESTRATION)

现在,test选项默认为None。 此处设置的True或False值将传递给正在运行的状态,并可用于覆盖在minion的配置文件中设置的test:True选项。 在以前的版本中,minion的配置选项优先,在配置文件中已经将测试模式设置为True的minion上运行编排是不可能的。

如果minion在配置文件未设置为处于永久测试模式,并且此处的’test’参数保留为None,那么在命令行上使用的test=True值将正确传递给minion以在测试模式下运行编排。 目前,无法在命令行上传递test=False,对已经设置为永久测试模式下的minion进行变更,因此仍必须在编排文件中设置test:False选项。

EVENT.SEND STATE

event.send状态不知道发送事件的结果,因此每次运行状态都会返回更改。 现在可以设置为返回已更改或未更改。

INFLUXDB_USER.PRESENT INFLUXDB USER MODULE STATE

password参数已更改为passwd以消除与Influxdb客户端配置(client_kwargs)的名称混淆,这用于允许在Influxdb实例上启用身份验证时管理用户。

Old behavior:

influxdb_user.present:
  - name: exampleuser
  - password: exampleuserpassword
  - user: admin
  - password: adminpassword

New behavior:

influxdb_user.present:
  - name: exampleuser
  - passwd: exampleuserpassword
  - user: admin
  - password: adminpassword

WINREPO_CACHE_EXPIRE_MIN WINDOWS PACKAGE DEFINITIONS CACHING

winrepo_cache_expire_min已从0更改为1800(30分钟)例如,如果运行highstate,则包定义通常会更新,但是现在如果包定义比winrepo_cache_expire_min(30分钟)更年轻,则package definitions将不会刷新,从而减少了运行第二次highstate所需的时间。 要继续使用旧功能,请在minion配置文件中将值更改回0。 这也会影响默认刷新的其他函数的行为。 pkg.refresh_db将始终刷新包定义。

LDAP EXTERNAL AUTHENTICATION

FREEIPA GROUPATTRIBUTE SUPPORT

以前,如果Salt对freeipa LDAP系统使用外部身份验证,则只能通过accountattributename字段搜索用户。 此版本还使用groupattribute字段添加其他搜索支持。 原始accountattributename搜索首先完成,然后是groupattribute,允许向后兼容以前的Salt版本。

JINJA INCLUDE RELATIVE PATHS

当jinja包含模板名称以./或…/开头时,将使用相对路径寻找并导入文件。

先前的实践中是按下面的样子定义的:

{% from tpldir ~ '/foo' import bar %}

现在可以使用一个更自然的方式:

{% from './foo' import bar %}

从父目录导入时 - 先前的做法是:

{% from tpldir ~ '/../foo' import bar %}

使用新的样式来导入父目录中的文件:

{% from '../foo' import bar %}

SALT-API

SALT-API WINDOWS SUPPORT

以前,Microsoft Windows平台不支持salt-api。 现在它支持了! salt-api为正在运行的Salt系统提供RESTful接口。 它允许通过REST API访问minions、runners和jobs以及通过正在运行的Salt系统的执行execution modules 和 runners,返回JSON格式的输出结果。 请参阅Salt-API文档。 … _Salt-API:https://docs.saltstack.com/en/latest/topics/netapi/index.html

LOGGING CHANGES

INCLUDE JOB ID (JID) IN MINION AND MASTER LOGS

通过在log_fmt_console或log_fmt_logfile配置选项中包含jid,现在可以选择将作业ID(JID)包含在minion和master日志中:

log_fmt_console: "[%(levelname)-8s] %(jid)s %(message)s"

这将导致JID被包含在与特定Salt作业相关的任何日志条目中。 JID信息将使用默认格式[JID:%(jid)s],但也可以使用log_fmt_jid配置项自定义:

log_fmt_jid: "[JID: %(jid)s]"

SECURITY

WINDOWS RUNAS CHANGES

在正常情况下,runas不再需要密码。 只有当minion进程在受限(非管理员)帐户下运行时,才需要使用密码选项。 在上述情况下,只有在使用runas参数以不同用户身份运行命令时才需要密码。

NEW MODULES

EXECUTION MODULES

PILLAR MODULES

PROXY MODULES


Finished

猜你喜欢

转载自blog.csdn.net/watermelonbig/article/details/88555701