运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载SaltSaltStack通过top.sls顶层文件将网络中的一组组机器minion与要施加到它们身上的配置角色state建立映射关系。本文以 Salt 官方参考文档 doc/ref/states/top.rst 为主体骨架结合本仓库的 salt/state.py、salt/modules/state.py、conf/master 等源码与配置系统讲解 top file 的三大组成、单/多环境 file_roots 配置、九种以上匹配类型、saltenv选择机制以及 top 文件编译时的四种合并策略帮助读者从能写 top.sls进阶到能解释 top.sls 为什么这样被编译执行。什么是 Top File绝大多数基础设施都由多组机器构成组内的每台机器承担相似的角色各组机器协同工作形成一套应用栈。要高效管理这些机器组管理员需要为它们定义角色例如一组承担前端 Web 流量的机器其角色可能要求全部安装 Apache Web 服务器软件包并保证 Apache 服务始终运行。在 Salt 中负责机器组与配置角色映射关系的文件就叫top file。top file 默认命名为top.sls之所以叫top是因为它总是位于一个包含状态文件state files的目录层级即state tree的顶部。top file 由三个组件构成组件含义Environment环境一个 state tree 目录包含一组用于配置系统的状态文件Target目标一组将要被施加状态集合的机器State files状态文件要应用到目标上的状态文件列表每个状态文件描述一个或多个需要在目标机器上配置并强制执行的状态三者的嵌套关系是环境包含目标目标包含状态。将概念落到实例上——所有以web开头的 minion ID 都应用apache状态base: # 从 base 环境的目录根应用 SLS 文件 web*: # 所有 minion_id 以 web 开头的 minion - apache # 应用名为 apache.sls 的状态文件环境Environments与 file_roots环境是包含一个 top file 和一组状态文件的目录层级。Salt 并不强制要求使用多个环境——事实上最常见的部署方式是只使用一个名为base的环境。官方文档建议只有确实需要管理多套状态树版本时才创建多个环境。每个环境在 Salt Master 配置中由file_roots定义。最常见单环境配置如下# /etc/salt/master file_roots: base: - /srv/salt此时 top file 只能从一个环境拉取内容。对应的单环境 top file 放在/srv/salt/top.slsbase: *: - core - edit意思是对于base环境所有 minion*匹配都会应用core.sls与edit.sls两个状态文件。Salt 会到/srv/salt目录下查找这两个文件。在 conf/master 中file_roots的默认配置为#file_roots: # base: # - /srv/salt注释中还给出一个关键约束每个环境可以配置多个根目录但多个根目录下的子目录不能重名否则无法保证文件下载的可靠性同时必须存在一个base环境来承载 top file。配置默认值同样体现在源码 salt/config/init.py 的DEFAULT_MASTER_OPTS中state_top: top.sls表明默认 top 文件名就是top.sls。多环境配置dev / qa / prod当团队需要在隔离的机器集合如 staging 环境中先行测试 Salt 配置验证通过后再发布到生产环境时可以扩展file_roots创建多个环境file_roots: dev: - /srv/salt/dev qa: - /srv/salt/qa prod: - /srv/salt/prod对应的 top file 同时引用三个环境dev: webserver*: - webserver db*: - db qa: webserver*: - webserver db*: - db prod: webserver*: - webserver db*: - db这样所有 ID 以webserver开头的 minion 都会从指定环境获得webserver状态。迭代流程是先在/srv/salt/dev中修改状态文件并应用到开发用 Web 服务器上验证通过后再将文件复制到/srv/salt/qa进入 QA 验证。选择要使用的环境saltenvtop file 用于为 minion 分配环境除非通过下述方式显式覆盖。top file 中出现的环境必须是一个合法的 fileserver 环境即 saltenv否则该环境下的状态无法被应用到 minion。使用默认 fileserver 后端roots时环境由file_roots定义。查看某个环境下 minion 将被应用哪些状态可以使用state.show_top函数salt * state.show_top其实现位于 salt/modules/state.py它构建salt.state.HighState实例调用st_.get_top()获取 top 数据、st_.verify_tops(top_)校验结构比如要求 top 数据必须是 dict最终由st_.top_matches(top_)根据 minion 自身信息ID、grains、pillar 等算出匹配到的状态列表并返回。选定环境有三种方式minion 配置固定绑定在 minion 配置文件中设置environment值minion 将只从该环境请求文件。命令行动态指定在salt、salt-call、salt-ssh执行时通过saltenv参数动态选择。最常见于state模块相关函数。例如只使用prod环境中的 top file 与 SLS 文件对全部 minion 执行 highstatesalt * state.highstate saltenvprod注意并非所有函数都接受saltenv参数使用前需查阅单个函数的文档确认。在 salt/modules/state.py 中可以看到highstate、show_top、sls、show_sls、show_low_sls、graph等函数均支持saltenv参数且若未显式传入会回退到 minion 配置中的saltenv参数最后再回退到默认的base环境见源码中if opts[saltenv] is None: opts[saltenv] base的逻辑。简写语法如果只给某个目标分配一个 SLS可以使用简写——直接用字符串代替列表base: *: global dev: webserver*: webserver db*: db qa: webserver*: webserver db*: db prod: webserver*: webserver db*: db高级目标匹配Targeting上面所有例子使用的目标表达式都是 glob。实际上自 2014.7.0 起 top file 中的默认匹配类型是复合匹配器compound matcher而非 CLI 中的 glob 匹配器。单个 glob 表达式经过复合匹配器处理后与 glob 匹配效果相同多数情况下二者无法区分。但存在一个边界情况minion ID 中包含空白字符。虽然不推荐在 minion ID 中使用空格但 Salt 并不会阻止这么做由于复合表达式按词解析含空格的 minion ID 会匹配失败。此时必须显式指定glob匹配器base: minion 1: - match: glob - foo可用的匹配类型top file 中可为目标表达式设置的匹配类型如下表完整来源见 doc/ref/states/top.rst详细语法见 doc/ref/targeting/index.rst 下的相关章节匹配类型描述glob完整 minion ID 或用于匹配多个 minion 的 glob 表达式如minion123或minion*pcre用 Perl 兼容正则PCRE匹配 minion ID如web[0-3].domain.comgrain匹配一个 grain可选地使用 glob如kernel:Linux或kernel:*BSDgrain_pcre用 PCRE 匹配 grain如kernel:(Free|Open)BSDlist逗号分隔的 minion 列表如minion1,minion2,minion3pillarPillar 匹配可选地使用 glob如role:webserver或role:web*pillar_pcre用 PCRE 匹配 pillar如role:web(server|proxy)pillar_exact不使用 glob 或 PCRE 的精确 pillar 匹配如role:webserveripcidr子网或 IP 地址如172.17.0.0/16或10.2.9.80data匹配 minion 数据仓库由data执行模块创建中保存的值rangeRange 集群compound组合多种匹配类型的复合表达式见 compound 章节nodegroupmaster 配置文件中预定义的复合表达式见 nodegroups 章节综合示例下面是一个较复杂、覆盖多种匹配类型的 top file 示例源自原文档注释为原文语义的中文整理# 所有文件取自 base 环境在 file_roots 配置中指定的路径 base: # 以 nag1 开头的所有 minion或任何 grain role 值为 monitoring 的 # minion将应用 nagios/ 目录下的 server.sls nag1* or Grole:monitoring: - nagios.server # 所有 minion 应用以下三个状态文件 *: - ldap-client - networking - salt.minion # 所有 ID 以 salt-master 开头的 minion 应用 salt 目录下的 # master.sls目录相对于 file_roots 中 base 环境指定的根 salt-master*: - salt.master # ID 匹配该正则的 minion 应用 nagios/mon 目录下的 web.sls # 同时还会应用 apache/ 目录下的 server.sls # # 注意这里的 match 指令它告诉 Salt 将目标字符串当作正则处理 ^(memcache|web).(qa|prod).loc$: - match: pcre - nagios.mon.web - apache.server # grain 表明运行 Ubuntu 操作系统的 minion 应用 repos 目录下的 # ubuntu.sls。同样注意 match 指令——这里匹配的是 grain 而非 minion ID os:Ubuntu: - match: grain - repos.ubuntu # RedHat 或 CentOS 的 minion 应用 repos/ 目录下的 epel.sls os:(RedHat|CentOS): - match: grain_pcre - repos.epel # ID 为 foo、bar、baz 的这三个 minion 应用 database.sls foo,bar,baz: - match: list - database # 任何 pillar 键 somekey 存在且值为 abc 的 minion 应用 xyz.sls somekey:abc: - match: pillar - xyz注意nag1* or Grole:monitoring这条没有显式match指令的表达式它走的正是默认的复合compound匹配器——这是 top file 与 CLI 的一个关键差异点。匹配器实现与更多语法请参见 doc/ref/targeting/compound.rst 与 doc/ref/targeting/nodegroups.rst。Top File 如何被编译指定环境时的行为执行 highstate 并显式指定了环境通过 minion 配置的environment选项或执行 highstate 时传入saltenv时只会使用该环境的 top file 为 minion 分配状态且只运行指定环境中的状态。从源码 salt/state.py 的get_tops()可以看到当self.opts[saltenv]非空时只会调用self.client.cache_file(self.opts[state_top], self.opts[saltenv])缓存并编译单个saltenv 的 top 文件。未指定环境时的行为未指定环境时minion 会在每个环境中查找 top file并逐个处理以确定要运行哪些 SLS。默认情况下各环境的 top 文件会被合并merge。在环境较多的配置中例如 GitFS 把每个分支和 tag 都当作独立环境这种合并可能产生意外结果——旧 tag 中的 SLS 会让已经废弃的 SLS 混入 highstate。合并策略top_file_merging_strategymerge默认将各环境 top 文件合并合并顺序不确定多环境 未设置env_order时源码会打印警告日志见get_tops中found 1 and merging_strategy merge的判断分支。same强制每个环境只使用自己的 top 文件# minion 配置 top_file_merging_strategy: samemerge_all自 2016.11.0 引入合并所有 top 文件中的全部配置。源码 salt/state.py 中合并函数按策略名动态查找merge_attr f_merge_tops_{merging_strategy}即_merge_tops_merge、_merge_tops_same、_merge_tops_merge_all若传入非法策略名则记录警告并回退到merge。same策略下若未设置default_top会直接抛出SaltRenderError。三个合并函数的行为可归纳为_merge_tops_mergebase 环境具有权威性最先被检查非 base 环境的 top 文件中只有与自己同名的 section 才被考虑且如果该 saltenv 已在 base 的 top 文件中定义过则忽略非 base 文件的对应 sectionsalt/state.py。_merge_tops_same对每个 saltenv只考虑来自该 saltenv 自己的 top 文件出现在别的环境 top 文件里的 section 一律忽略若某环境没有 top 文件则回退使用default_top指定环境 top 文件中与该环境同名的 sectionsalt/state.py。_merge_tops_merge_all把各环境 top 文件合并进单个字典同一目标若在多个 top 文件中重复出现则状态列表会去重合并salt/state.py。这些行为都有对应的单元测试覆盖例如 tests/pytests/unit/modules/state/test_top_file_merge.py 中的test_merge_strategy_mergeBase overrides everything断言merge策略下 base 环境覆盖其他环境test_merge_strategy_merge_limited_base验证 base top 文件只含basesection 时、其他环境若没有自己的 top 文件则不会出现在结果中以及state_top_saltenvbase时只从 base 拉取状态的测试。只使用指定环境的 topstate_top_saltenv另一个方案是设置state_top_saltenv为特定环境确保其他环境的 top 文件被忽略# minion 配置 state_top_saltenv: base从 salt/state.py 可见state_top_saltenv被设置后get_tops()只会遍历[state_top_saltenv]这一个环境。GitFS 场景的附加手段使用 GitFS 时也可以直接分开管理每个环境的 top 文件、或在执行 highstate 时手动指定环境避免复杂的合并。master 端的gitfs_saltenv_whitelist与gitfs_saltenv_blacklist见 doc/ref/configuration/master.rst可用来隐藏 GitFS 中不需要的分支与 tag从而减少参与合并的 top 文件数量。多环境下的维护建议使用多个环境时不必为每个环境都创建 top 文件。最容易维护的做法是在base环境中放一个单一 top 文件。这在 GitFS 下往往不可行分支/tag 容易产生多余的 top 文件但仅使用默认 roots fileserver 后端时在base环境放单个 top 文件是最常见的 highstate 配置方式。影响编译的四个 minion 配置项未指定环境时以下四个 minion 配置项决定 top 文件如何编译建议逐一查阅对应文档章节深入理解state_top_saltenv只从指定环境读取 top 文件top_file_merging_strategymerge/same/merge_allenv_order控制多环境合并时的顺序冲突时靠后的值胜出default_topsame策略下某环境没有 top 文件时回退使用的环境默认base。这些配置在 conf/master 的注释中有明确说明# When using multiple environments, each with their own top file, the # default behaviour is an unordered merge. To prevent top files from # being merged together and instead to only use the top file from the # requested environment, set this value to same. #top_file_merging_strategy: merge # To specify the order in which environments are merged, set the ordering # in the env_order option. Given a conflict, the last matching value will # win. #env_order: [base, dev, prod] # If top_file_merging_strategy is set to same and an environment does not # contain a top file, the top file in the environment specified by default_top # will be used instead. #default_top: base对应的默认值同样定义在 salt/config/init.pytop_file_merging_strategy默认merge、env_order默认[]、default_top默认base、state_top_saltenv默认None、state_top默认top.sls。Top File 编译示例四种场景假设存在以下配置/etc/salt/masterfile_roots: base: - /srv/salt/base dev: - /srv/salt/dev qa: - /srv/salt/qa/srv/salt/base/top.slsbase: *: - base1 dev: *: - dev1 qa: *: - qa1/srv/salt/dev/top.slsbase: minion1: - base2 dev: minion2: - dev2 qa: *: - qa1 - qa2说明本示例中qa环境没有 top 文件。场景 1指定dev环境highstate 以saltenvdev调用或 minion 配置中设置了environment: dev。结果只有dev环境中的dev2会进入 highstate且只应用于 minion2minion1 不会应用任何状态。若指定base环境只有base环境中的base1会进入 highstate应用于所有 minion若指定qa环境由于qa环境没有 top 文件highstate 会以错误退出。场景 2未指定环境top_file_merging_strategy 为 merge假设base环境的 top 文件被最先求值那么base1、dev1、qa1会被应用到所有 minion。如果/srv/salt/base/top.sls中没有定义qa这个 section那么由于qa环境没有自己的 top 文件qa环境中将没有状态被应用。场景 3未指定环境top_file_merging_strategy 为 same版本说明2016.11.0 起 same 的行为已修正此前版本行为有偏差官方选择在特性版本而非点版本中修正此行为以避免意外影响用户已有的 top 文件。结果base环境中的base1应用到所有 miniondev环境中的dev2应用到 minion2。若default_top未设置或设置为默认的baseqa环境将回退使用base的 top 文件其中qasection 下的qa1应用到所有 minion。若default_top设置为dev则回退使用dev的 top 文件其中qasection 下的qa1与qa2都会应用到所有 minion。场景 4未指定环境top_file_merging_strategy 为 merge_all自 2016.11.0 引入。所有 top 文件中的所有配置都会被应用base环境base1应用到所有 minionbase2仅应用到 minion1dev环境dev1应用到所有 miniondev2仅应用到 minion2qa环境qa1与qa2都应用到所有 minion。注意qa1虽然出现了两次base 与 dev 的 top 文件里都有但不会被执行两次——_merge_tops_merge_all在合并同一目标的状态列表时会去重salt/state.py。实践要点与排查建议命名与位置top 文件默认名为top.sls且base环境必须存在并承载 top 文件state_top配置可自定义 top 文件名。默认匹配是 compound从 2014.7.0 起 top file 默认使用复合匹配器与 CLI 的默认 glob 不同含空格的 minion ID 必须显式写- match: glob。用state.show_top验证执行salt * state.show_top可查看 minion 在当前配置下实际会拿到的状态是排障 top 文件映射的首选工具。合并策略的选择单一base环境 单一 top 文件最易维护多环境场景下若要避免 top 文件互相合并产生幽灵状态可设置top_file_merging_strategy: same配合default_top或设置state_top_saltenv锁定单一环境GitFS 场景可用gitfs_saltenv_whitelist/gitfs_saltenv_blacklist减少 top 文件数量。不要依赖 merge 的无序合并默认merge策略在多环境时的合并顺序不确定源码会打印警告如有依赖合并顺序的需求务必设置env_order。验证编译行为本仓库的 tests/pytests/unit/modules/state/test_top_file_merge.py 覆盖了merge、same、merge_all以及state_top_saltenv的多种组合场景可作为理解编译行为的可执行文档。延伸阅读匹配器与目标表达式详解doc/ref/targeting/index.rst、doc/ref/targeting/compound.rst、doc/ref/targeting/nodegroups.rsthighstate 运行机制doc/ref/states/highstate.rstmaster 配置选项全集doc/ref/configuration/master.rstminion 配置选项全集doc/ref/configuration/minion.rst顶层编译与合并的源码实现salt/state.pyget_tops与三个_merge_tops_*方法state.show_top模块salt/modules/state.py示例配置conf/master赞分享运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载相关推荐Salt State 状态系统全解析SLS 文件、Top File 与模块热加载机制Salt State 状态系统全解析SLS 文件、Top File 与模块热加载机制 SaltSaltStack提供了一套完整的状态系统接口用于从中心管运维配置管理后端Salt 文件服务器Salt File Server完全指南架构、环境、配置与 cp 模块实战Salt 文件服务器Salt File Server完全指南架构、环境、配置与 cp 模块实战 导读 Salt 文件服务器Salt File Serve运维配置管理后端Salt SSH 目标选择机制详解基于 minion ID 的 glob 与 PCRE 正则匹配Salt SSH 目标选择机制详解基于 minion ID 的 glob 与 PCRE 正则匹配 导读 在使用 salt ssh 对一批主机执行命令或下发状态运维配置管理后端上一篇Cataclysm-DDA 的 Mind Over Matter 异能模组完全指南力量体系、Nether 协调与觉醒机制解析下一篇Kue 与无服务器架构集成AWS Lambda 任务执行创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
