运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载Salt 的 Standalone Minion又称 masterless minion是一种不连接 Salt master、完全在本机执行配置管理的运行方式。本文基于仓库中 standalone_minion.rst 教程文档其重写记录见 changelog/57488.fixed.md完整讲解 Standalone Minion 的概念、适用场景、与主从模式的关键差异、两种操作模式并结合 salt/config/init.py、salt/cli/caller.py、salt/minion.py 源码剖析其底层实现原理。读完本文你将掌握如何用salt-call --local在无 master 环境下发配置、运行状态与外部 pillar并理解master_type: disable与file_client: local背后的机制。什么是 Standalone MinionStandalonemasterlessSalt minion 是指一台没有连接到 Salt master 的 minion 安装它在本机运行所有逻辑。与普通 minion 相比它执行的代码路径完全相同改变的只是配置、状态文件和 pillar 数据的来源——全部来自本地路径而不是 master 的文件服务器。也就是说Salt 的 state、pillar、module 体系依然完整可用只是数据从哪里来从master 下发变成了本地读取。何时应该使用 Standalone Minion根据教程文档Standalone minion 适合以下四类场景无网络路径连接 master 的主机如隔离网络air-gapped系统、构建代理build agents、自助终端kiosks、单服务器环境。这些主机无法与 master 通信但仍需要配置管理能力。入网前的本地引导bootstrap在系统加入 master 之前用本地 SLS 文件完成初始化配置也可以作为镜像构建流水线image build pipeline的一环。本地测试与开发对检出的 SLS 树state、pillar、formula 代码使用salt-call --local快速反馈无需启动整套 master/minion 基础设施。触发本地的 reactor 与 beacon 流程在不会向 master 发布事件的主机上运行仅依赖本地的 reactor 和 beacons。Standalone Minion 与主从 Minion 的差异教程文档明确列出了两者的核心区别下表为完整对照能力维度主从模式master-connectedStandalonemasterless目标选择targeting通过saltCLI 按目标下发到多台 minion隐式本地salt-call始终操作本机没有saltCLI因为没有 master文件与 pillar 根file_roots/pillar_roots在 master 端minion 通过网络拉取本地文件系统目录典型为/srv/salt与/srv/pillar不从网络获取 SLS外部 pillar由 master 配置并汇总依然可用只要 minion 能访问外部源如 gitfs、vault即可在 standalone minion 上配置mine可用依赖 master 汇总不可用mine 需要 master多 minion 目标可用不可用本地单机返回器returnersmaster 端返回器可用master 端 returners 不可用事件与 master 端 reactormaster 端 reactor 可用master 端不可用本地 reactor 与本地 engines 可用一句话概括所有依赖 master 的能力mine、多机目标、master 端 reactor、master 端 returners在 standalone 模式下均不可用而一切仅依赖本地的能力本地 reactor、本地 engines依然正常工作。两种运行模式教程文档指出操作 standalone minion 有两种实际可行的方法模式一不启动守护进程直接使用salt-call --local这是最简单的模式。完全不运行salt-minion服务按需调用salt-call --local function。适用于仅在供应阶段provisioning或按人工节奏执行配置的主机。模式二运行salt-minion守护进程但不连接 master当需要 beacon、engine、schedule 或本地 reactor持续运行但又没有 master 连接时将 minion 配置中的master_type设为disable守护进程就不会尝试连接 master。注意默认情况下salt-minion守护进程会尝试连接 master 并失败。salt-call命令是自足的不需要salt-minion守护进程。从版本 2016.11.0 起可以通过将master_type设为disable让 minion 守护进程在无 master 连接的情况下运行。该行为的源码实现在 salt/minion.py当opts[master_type] disable时minion 的连接逻辑直接提前返回并记录Master is set to disable, skipping connection警告将self.connected置为False从而跳过 master 发现与连接流程。Minion 配置file_client: local是关键教程文档强调本教程中的各项配置都写在 minion 配置文件中默认位置为/etc/salt/minion在 FreeBSD 系统上配置文件位于/usr/local/etc/salt/minion。salt-call用于在本机执行模块函数。正常情况下salt-call会向 master 报到check in以获取文件服务器与 pillar 数据在 standalone 模式下必须让salt-call不向 master 查询这些数据。实现方式就是设置file_client配置项file_client: local默认值为remoteminion 从 master 获取文件服务器与 pillar 数据。设置为local后salt-call不再查找 master并假定本机已具备全部文件与 pillar 资源。源码佐证salt/config/init.py 中minion 默认配置明确写有file_client: remote而file_roots、pillar_roots的默认base环境分别指向salt.syspaths.BASE_FILE_ROOTS_DIR即/srv/salt与salt.syspaths.BASE_PILLAR_ROOTS_DIR即/srv/pillar。有趣的是master 自身的默认配置反而是file_client: local见 salt/config/init.py——因为 master 本就是从本地根目录提供数据的。无 master 运行 StateMasterless StatesState 系统可以在没有 master 的情况下轻松运行所需文件全部位于 minion 本地。为此minion 配置文件需要像 master 一样配置file_roots。file_roots的base环境默认就是/srv/salt与 master 端一致file_roots: base: - /srv/salt然后按照 master 端的同等方式设置 Salt State Treetop.sls与各 SLS 模块。当file_client为local且存在可用的 state tree 时对 state 模块的调用将使用 minion 上的file_roots信息而不再向 master 报到。关键提示在 minion 上创建 state tree 无需任何语法或路径修改——为 master 编写的 SLS 模块无需任何改动即可在 minion 上工作。这让你可以在没有 master 的情况下用 Salt state 编写脚本式部署并随着部署规模增长轻松将这些 SLS 模块迁移到 Salt master 上。执行已声明的状态有两种等价方式# 方式一依赖配置文件中的 file_client: local salt-call state.apply# 方式二使用 --local 标志无需修改配置文件 salt-call state.apply --local源码视角--local与file_client是如何生效的在 salt/cli/caller.py 中salt-call判断本地模式的逻辑一目了然is_local ( self.opts[local] or self.opts.get(file_client, False) local or self.opts.get(master_type) disable )也就是说以下任一条件都会使salt-call进入本地模式不再向 master 回传数据使用了--local命令行标志对应opts[local]该标志定义于 salt/utils/parsers.py配置中file_client: local配置中master_type: disable。同一文件的后续逻辑if (not is_local) or returners:分支表明仅当非本地模式时才需要与 master 交互本地模式下salt-call完全自足。外部 Pillar 在 Masterless 模式下的支持教程文档明确指出外部 pillarexternal pillars在 masterless 模式下同样受支持。例如 gitfs 或 vault 这类外部 pillar只要 standalone minion 能够访问外部源就可以在 minion 上正常配置与使用。这与文件与 pillar 根在本地并不冲突——本地pillar_roots提供基础 pillar 数据外部 pillar 则作为补充来源二者可以共存。结语Standalone Minion 是 Salt 在无 master 环境下保持完整配置管理能力的核心机制。其设计要点可以归纳为三点数据本地化file_roots/pillar_roots指向本地目录、无需连接 masterfile_client: local或master_type: disable、按需或持续运行salt-call --local按需执行守护进程 master_type: disable持续运行 beacon/engine/本地 reactor。从源码看这一切都由 salt/cli/caller.py 的统一is_local判定与 salt/minion.py 的master_type: disable提前返回逻辑支撑简单而可靠。对于隔离网络主机、镜像构建、本地开发与快速原型验证等场景masterless 模式都是值得优先考虑的技术方案。赞分享运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载相关推荐Salt Minion 守护进程完全指南salt-minion 命令行参考与启动原理解析Salt Minion 守护进程完全指南 salt minion 命令行参考与启动原理解析 导读 salt minion 是 Salt 配置管理体系中运行在被运维配置管理后端Salt Minion 配置完全指南master 连接、认证安全、状态与 Pillar 全参数深度解析Salt Minion 配置完全指南master 连接、认证安全、状态与 Pillar 全参数深度解析 导读 本文基于 Salt 官方参考文档 doc/ref运维配置管理后端Salt 配置完全指南Master、Minion 与 Proxy Minion 的配置、密钥认证与运维实战Salt 配置完全指南Master、Minion 与 Proxy Minion 的配置、密钥认证与运维实战 SaltSaltStack是一个面向大规模基础运维配置管理后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考