运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载导读pkg是 Salt 中最常用的执行模块家族之一pkg.installed、pkg.removed等状态模块均调用它完成包管理。在 Salt 的 Resources 框架中ssh资源类型通过 salt/resources/ssh/modules/pkg.py 提供了一套针对 SSH 远程主机的pkg.*执行模块覆盖当作业被分派到ssh资源即通过 SSH 可达的远程 Linux/Unix 主机时pkg.install、pkg.remove、pkg.version、pkg.list_pkgs会经由 SSH Shell 传输通道在远端执行对应包管理器命令而不再作用于本地管理 minion文件系统。读完本文你将掌握这套覆盖模块的加载机制、按os_family粒度的包管理器自动分派逻辑、每个函数的参数与返回结构以及如何配置 Pillar 主机清单并与其他ssh资源覆盖模块cmd、test、state配合使用。一、定位pkg.py 在 Resources 框架中的角色1.1 什么是执行模块覆盖Salt Resources 框架允许为每种资源类型在salt/resources/rtype/modules/目录下放置执行模块覆盖execution module overrides。规则非常简单文件名去掉.py即成为覆盖的槽位slot例如 modules/cmd.py 覆盖cmd槽位、modules/pkg.py覆盖pkg槽位。参见 doc/topics/resources/authoring/execution_modules.rst。当一次发布publish被分派到某资源类型时__salt__首先在rtype/modules/中查找未覆盖的函数才回退到标准salt/modules/。这正是框架的核心设计意图你可以为ssh资源类型提供自己的pkg.install、cmd.run而不必 fork 标准模块、也不必触碰__virtual__。pkg.py的模块头注释明确说明了这一职责salt/resources/ssh/modules/pkg.pyExecution module override for thesshresource type —pkg.*surface. Implements package management against SSH resources by running the appropriate package-manager commands on the remote host via the SSH Shell transport. Mirrors the interface ofsalt.modules.aptpkg/salt.modules.yumpkgfor the functions most commonly called by state modules (pkg.installed,pkg.removed, etc.).也就是说这个文件刻意镜像了aptpkg/yumpkg中状态模块最常调用的那部分接口保证标准状态模块如pkg.installed可以不加修改地在 SSH 资源上运行。1.2 加载约定文件名即槽位无需__virtual__pkg.py不需要__virtualname__或__virtual__门控——其加载资格完全由目录位置决定经由salt.loader._module_dirs中 per-type 的 prepend 机制只被 ssh 资源加载器发现。这一点在该文件与 salt/resources/ssh/modules/cmd.py、salt/resources/ssh/modules/test.py 的注释中都有说明管理 minion 自身的作业继续使用标准执行模块常规self.functions加载器只有资源作业才走这套覆盖。因此在覆盖模块内部不需要 proxy 风格的is_proxy()运行时守卫。1.3 关键 dunder__resource_funcs__与__grains__覆盖模块内部可用的 dunder 由 per-type 加载器注入doc/topics/resources/authoring/execution_modules.rst__resource_funcs__连接模块connection module的命名空间按rtype.fname索引。pkg.py正是通过__resource_funcs__[ssh.cmd_run]调用连接模块的远程执行原语——这是覆盖模块触达连接模块的标准方式__grains__资源自身的 grain 字典即grains()为该资源返回的结果而非管理 minion 的 grains。pkg.py用它判断远端os_family来选择包管理器__resource__{type: ..., id: ...}标识当前被操作的资源__salt__合并后的 per-resource 加载器覆盖槽位 标准模块回退。二、核心机制按 os_family 分派的远程包管理2.1 远程执行原语_runpkg.py的全部功能都建立在连接模块 salt/resources/ssh/init.py 的cmd_run之上pkg.py 内部辅助函数def _run(cmd, timeoutNone): Run a shell command on the remote resource, return (stdout, retcode). result __resource_funcs__ssh.cmd_run return result.get(stdout, ), result.get(retcode, 1)它把每条包管理命令委托给连接模块的cmd_run(cmd, timeoutNone)。cmd_run的实现在 salt/resources/ssh/init.py通过_make_shell()构造salt.client.ssh.shell.Shell实例并执行shell.exec_cmd(cmd)返回包含stdout、stderr、retcode的字典。也就是说包管理命令直接以 shell 形式在远端执行不需要部署任何 Salt 组件到远程主机。可选的timeout参数只覆盖本次调用不会改动 Pillar 中持久化的连接配置。2.2 包管理器自动选择_pkg_manager_pkg_manager()pkg.py L39-L55读取资源 grains 中的os_family按以下规则分派os_family取值使用命令debian、ubuntuapt-getredhat、centos、fedora、suseyum其他 / 未识别apt-get回退注意 grain 值会被.lower()归一化后再比较大小写不敏感。因此同一套pkg.*覆盖代码即可管理 Debian/Ubuntu 系与 RedHat/CentOS 系目标。值得一提的是os_family来自 ssh 资源连接模块的grains()该方法通过 salt-thin bundle 在远端运行grains.items与salt-ssh完全相同的机制保证获得完整、准确的 grain 集合而不是手工拼凑的子集。这也直接支撑了pkg.py对os_family判断的可靠性。2.3 grains 缓存与刷新连接模块会将每次收集的 grains 按资源 ID 缓存在__context__[ssh_resource][grains]中调用grains_refresh()可强制重新采集salt/resources/ssh/init.py。这意味着pkg.*分派所依赖的os_family在一次作业周期内保持一致如果远端系统从 Debian 换成 RPM 系极端情况刷新 grains 后才会采用新分派。三、pkg.* 函数面逐个拆解3.1install(nameNone, pkgsNone, sourcesNone, **kwargs)安装一个或多个包pkg.py L63-L89def install(nameNone, pkgsNone, sourcesNone, **kwargs): pkg_mgr _pkg_manager() if pkgs: names .join(pkgs if isinstance(pkgs, list) else [pkgs]) elif name: names name else: return {} env DEBIAN_FRONTENDnoninteractive if apt in pkg_mgr else cmd f{env}{pkg_mgr} install -y {names} stdout, retcode _run(cmd, timeoutkwargs.get(timeout)) if retcode ! 0: log.warning(pkg.install failed for %s: %s, names, stdout) return {result: False, comment: stdout} return {result: True, comment: stdout}要点参数形态pkgs优先于namepkgs可以是列表元素以空格连接成命令行或单值。sources参数仅作接口兼容保留当前实现未使用。非交互安装当包管理器为apt-get时自动加DEBIAN_FRONTENDnoninteractive前缀避免 apt 在安装过程中弹出交互式对话框导致挂起。返回结构{result: bool, comment: str}——comment承载远端命令的完整 stdout便于状态模块直接展示失败原因。失败时还会通过log.warning记录。CLI 示例来自模块 docstringsalt -C Tssh:node1 pkg.install curl salt -C Tssh:node1 pkg.install pkgs[curl, git]目标选择表达式Tssh:node1表示以资源类型ID 定位 SSH 资源与 doc/topics/resources/targeting.rst 中描述的资源寻址语法一致。3.2remove(nameNone, pkgsNone, **kwargs)卸载一个或多个包pkg.py L92-L116。实现与install对称同样先归一化pkgs/name执行pkg_mgr remove -y names返回{result: ..., comment: stdout}非零退出码记 warning。注意卸载不会自动带上-y之外的其他标志apt-get remove与yum remove的命令语义一致均为移除已安装包、保留配置文件。CLI 示例salt -C Tssh:node1 pkg.remove curl3.3version(*names, **kwargs)返回指定包的已安装版本pkg.py L119-L150。按os_family分派查询命令Debian/Ubuntudpkg-query -W -f${Version} name 2/dev/null其余RPM 系rpm -q --queryformat %{VERSION} name 2/dev/null返回语义单包名返回版本字符串多包名返回{包名: 版本}字典查询失败retcode ! 0时对应条目为。这一返回值形状与标准pkg.version一致保证了pkg.latest等上层模块的兼容性。CLI 示例salt -C Tssh:node1 pkg.version curl3.4list_pkgs(**kwargs)列出远端全部已安装包pkg.py L153-L180Debian/Ubuntudpkg-query -W -f${Package} ${Version}\n其余rpm -qa --queryformat %{NAME} %{VERSION}-%{RELEASE}\n输出按行解析为{包名: 版本}字典每行以首个空白分割为 name/version。RPM 系的版本串包含VERSION-RELEASE与rpm -qa的展示习惯一致。该函数是pkg.installed状态模块进行已安装状态比对的基础数据来源。CLI 示例salt -C Tssh:node1 pkg.list_pkgs四、配置Pillar 中的 ssh 资源清单pkg.*覆盖的执行依赖连接模块从 Pillar 读取每个 ssh 资源的主机连接配置。顶层 Pillar key 默认为resources可通过 minion 选项resource_pillar_key覆盖doc/topics/resources/configuration.rst。连接模块的完整配置示例见 salt/resources/ssh/init.pyresources: ssh: hosts: web-01: host: 192.168.1.10 user: root priv: /etc/salt/ssh_keys/web-01 web-02: host: 192.168.1.11 user: admin passwd: secretpassword no_host_keys: true每个主机的连接参数摘自连接模块 docstring均为仓库内已确认的字段参数说明默认值host远端主机名或 IP必填—userSSH 登录用户rootportSSH 端口22priv私钥文件路径与passwd可同时给出但priv优先—passwdSSH 密码生产环境建议优先使用密钥认证—priv_passwd保护私钥的 passphrase—sudo通过 sudo 以 root 执行命令FalsetimeoutSSH 连接超时秒30identities_only传递-o IdentitiesOnlyyes防止 SSH agent 提供无关密钥Falseno_host_keys完全禁用主机密钥校验同时设置StrictHostKeyCheckingno与UserKnownHostsFile/dev/nullFalseignore_host_keys仅传-o StrictHostKeyCheckingno保留 known-hosts 数据库Falseknown_hosts_file该主机使用的自定义 known_hosts 文件—ssh_options额外-o KeyValue选项列表原样传给 ssh 二进制—keepalive启用 TCP keepaliveTruekeepalive_intervalServerAliveInterval秒取 Salt opts 或60keepalive_count_maxServerAliveCountMax取 Salt opts 或3需要特别强调的是pkg.py的分派正确性依赖两点远端os_familygrain 的准确性由 salt-thin 的grains.items保证与Pillar 中主机配置的完备性host缺失时_make_shell/_make_single会直接 KeyError。修改 Pillar 后可通过salt-call saltutil.refresh_pillar或salt-run resource.refresh minionminion-id强制重新注册。五、与同目录其他覆盖模块的协同pkg.py不是孤立的它所在的salt/resources/ssh/modules/目录构成 ssh 资源类型的一套完整覆盖面cmd.py覆盖cmd.*槽位提供cmd.run返回 stdout 字符串、cmd.run_all返回{stdout, stderr, retcode}字典、cmd.retcode只返回退出码。pkg.py通过ssh.cmd_run委托远程执行而cmd.py则是用户在 CLI 上直接调用cmd.run的入口两者共享同一条 SSH Shell 通道test.py覆盖test.*提供test.ping——委托连接模块的ping()远端执行echo ping并校验输出反映真实的 SSH 连通性而非管理 minion 的存活状态state.py覆盖state.*在管理 minion 进程内复刻 salt-ssh 的 state 执行管线编译 →prep_trans_tar打包 → SCP 到远端thin_dir→ thin bundle 调用state.pkg。它是pkg.installed、pkg.removed等状态模块能够在 SSH 资源上完整跑通的关键一环。从 doc/topics/resources/authoring/execution_modules.rst 可以看到框架还提供namespaced_function重新导出模式将标准模块函数复制进覆盖模块 globals使 dunder 在调用时解析到 per-resource 加载器上下文state.py即是仓库内随附的典型范例。六、测试与验证仓库为 ssh 资源类型提供了单元测试 tests/pytests/unit/resources/test_ssh_resource.py。虽然该测试主要聚焦连接模块的_make_single()验证fsclient被正确传入salt.client.ssh.Single以避免Single.cmd_block()内部mod_data(fsclient)在fsclient为None时抛AttributeError但它确认了 ssh 资源代码在管理 minion 作业线程内构造 salt-ssh 组件这一独特路径——这正是pkg.*覆盖在执行时所依赖的运行时环境。与之相关的还有 tests/pytests/unit/modules/test_sshresource_state.py 与 tests/pytests/integration/resources/ 下的一组资源子系统集成测试。日常验证建议# 1. 先确认资源可达性与 grains 采集正常 salt -C Tssh:web-01 test.ping salt -C Tssh:web-01 grains.item os_family # 2. 再执行包管理操作 salt -C Tssh:web-01 pkg.install curl salt -C Tssh:web-01 pkg.version curl salt -C Tssh:web-01 pkg.list_pkgs若pkg.install返回result: False其comment中即为远端命令的完整 stdout可作为首要排查线索同时可检查管理 minion 日志中的pkg.install failed for ...warning 记录。七、局限与注意事项命令面刻意最小化pkg.py只实现了状态模块最常调用的四个函数install/remove/version/list_pkgs。pkg.installed状态模块所需的其他内部函数如upgrade、hold、repo操作等未覆盖时会回退到标准salt.modules执行——这可能在对 SSH 资源执行时语义不符因此对 ssh 资源请以这四个函数为界规划用法sources与pkgs的富参数被简化install接受sources参数但未使用pkgs仅支持简单列表/单值拼接不支持标准 aptpkg/yumpkg 中{name: ..., version: ...}之类的结构化 spec需要精确版本控制时需自行在name中体现如curl7.0由底层包管理器解析分派仅基于os_family白名单_pkg_manager对未识别家族回退到apt-get误判时安装命令会在错误包管理器下失败远端系统若为 Arch、Alpineapk等需自行扩展该函数每次调用都走实时 SSH 往返_pkg_manager()读取的 grains 来自缓存但命令执行本身无状态多次调用会重复建立 SSH 会话连接连接层 keepalive 参数可缓解开销无幂等性逻辑与标准模块不同这些函数不包含已安装则跳过的幂等判断幂等语义由上层pkg.installed状态模块通过list_pkgs/version比对来保证。结语salt/resources/ssh/modules/pkg.py是 Resources 框架执行模块覆盖设计在 SSH 场景下的典型落地通过文件名约定占据pkg槽位、通过__resource_funcs__[ssh.cmd_run]委托连接模块、通过资源自身的os_familygrains 实现 apt/yum 自动分派最终让pkg.installed、pkg.removed等标准状态模块原封不动地在远程 SSH 主机上工作。理解这个文件也就理解了如何在自有资源类型中编写正确的执行模块覆盖连接逻辑收敛在连接模块覆盖文件只做槽位绑定与语义适配。赞分享运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载相关推荐Salt ssh_pkg 执行模块深度解析基于 SSH Proxy Minion 的包管理实现Salt ssh_pkg 执行模块深度解析基于 SSH Proxy Minion 的包管理实现 导读 ssh_pkg 是 Salt 项目中专门服务于 SSH运维配置管理后端Salt SSH 资源执行模块 cmd无代理远程命令执行的源码级解析Salt SSH 资源执行模块 cmd无代理远程命令执行的源码级解析 导读 本文聚焦 salt.resources.ssh.modules.cmd 执行模块运维配置管理后端Salt 的 macOS Homebrew 软件包管理模块pkg 执行模块mac_brew_pkg完整指南Salt 的 macOS Homebrew 软件包管理模块pkg 执行模块mac_brew_pkg完整指南 导读 salt.modules.mac_bre运维配置管理后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考