企业官网建设流程全解析

Salt Delta Proxy Minion 安装与配置实战指南：用单个 minion 管理海量网络设备

【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt

本指南是 Salt 项目官方文档（doc/ref/configuration/delta_proxy.rst）的深度实践版，面向系统与网络管理员，讲解自 Salt 3004 版本引入的 delta proxy minion 的完整安装、配置与验证流程。读完本文，你将理解 delta proxy minion 与标准 proxy minion 的架构差异，掌握在主控端通过 master 配置、pillar 文件与控制代理配置文件三步完成部署的实操方法，并能用test.version快速验证受管设备是否正常工作。

为什么需要 delta proxy minion

Salt 可以通过 proxy minion 管理那些无法运行标准 Salt minion 的网络设备，典型场景包括：

• 拥有 API 但运行专有操作系统的网络设备（交换机、路由器、防火墙等）；
• CPU 或内存受限的设备，无法承载完整的 minion 进程；
• 出于安全原因不允许安装 minion 的设备。

proxy minion 运行在 Salt master 上，作为 master 与被管设备之间的中间人：它接收来自 master 的命令，再按需翻译并下发到设备。由于采用按需连接的模型，proxy minion 一般只在真正需要下发命令时才建立到实际设备的连接，从而省去了 master 与每台设备之间常驻连接的开销，也让设备端只需在实际执行命令时才消耗 CPU 与内存。

从 proxy minion 到 delta proxy minion

标准模式下，每一台被管设备都需要一个独立的 proxy minion 实例。当设备规模达到数千台时，运行几千个 proxy minion 进程会占用大量内存与 CPU，扩展性成为瓶颈。

delta proxy minion 正是为解决这一瓶颈而设计：只需运行一个 minion，就能作为 master 与它所代表的众多网络设备之间的中间人。在这个架构中，一台运行在 master 上的 delta proxy minion（实际由"控制代理"承载）同时运行多个代理，大幅提升性能与整体可扩展性。

官方文档建议：如果尚未使用过标准 proxy minion，应先在环境中测试并部署标准 proxy minion，再考虑迁移到 delta proxy minion 环境。

核心术语速览

术语表中"managed device"的概念在源码中体现为：每个被管设备对应一个"sub-proxy"，在 salt/metaproxy/deltaproxy.py 中通过subproxy_post_master_init为每个 minion ID 初始化独立的ProxyMinion对象并保存在self.deltaproxy_objs字典中。

安装前置条件

开始安装前，请确认以下三点：

1. 你的网络设备及固件受支持；
2. 充当 control proxy 的 Salt master 对要管理的设备具有网络访问能力；
3. 已在你环境中安装、配置并测试过标准 Salt proxy minion，再引入 delta proxy minion。

同时，确保 Salt master 至少运行Salt 3004或更高版本（delta proxy minion 自 3004 版本起可用）。

安装流程总览

与 proxy minion 类似，delta proxy minion 的所有配置都集中在 Salt master 上完成，而非在被管 minion 上。整个安装过程分为四个阶段：

1. 配置 master 使用 delta proxy—— 在 master 上创建定义代理设置的配置文件；
2. 为每个受管设备创建 pillar 文件—— 为每台设备创建 pillar 文件，并在 top file 中引用；
3. 创建 control proxy 配置文件—— 创建列出其管理设备的 control proxy 文件，并在 top file 中引用；
4. 启动 delta proxy minion—— 启动 delta proxy-minion 服务并验证配置正确。

下面依次展开。

第一步：配置 master 使用 delta proxy

这一步骤创建的是一份通用配置文件，告诉 Salt master 如何处理所有 proxy minion。

1. 在 Salt master 上进入/etc/salt目录，若proxy文件不存在则创建它（在源码中，/etc/salt/proxy正是 proxy minion 默认的配置文件路径，见 salt/config/init.py 中DEFAULT_PROXY_MINION_OPTS的conf_file定义）；
2. 用编辑器打开该文件，写入如下配置：

# 使用 delta proxy metaproxy metaproxy: deltaproxy # 禁用 FQDNS grain enable_fqdns_grains: False # 启用多进程 multiprocessing: True

3. 保存文件。

此时 master 已配置为使用 delta proxy，接下来进入第二步。

delta proxy 配置选项详解

上述配置文件中的各选项说明如下：

从源码看，metaproxy选项的解析逻辑位于 salt/minion.py 的_metaproxy_call：它会通过salt.loader.metaproxy加载 metaproxy 模块，若opts中没有metaproxy键则默认使用标准proxy，然后根据opts["metaproxy"]的值分派到salt.metaproxy.proxy或salt.metaproxy.deltaproxy中的对应函数（post_master_init、tune_in、target_load、handle_payload等），从而决定整个 minion 采用哪种代理行为。

第二步：为每个受管设备创建 pillar 文件

每台需要由 delta proxy 管理的设备，都需在 master 上拥有独立的 pillar 文件：

1. 进入/srv/pillar目录；
2. 为某个 minion 创建新的 pillar 文件，例如my_managed_device_pillar_file_01.sls；
3. 打开该文件，写入该 minion 与环境所需的配置信息。以下是一个 Netmiko 设备的 pillar 示例：

proxy: proxytype: netmiko device_type: arista_eos host: 192.0.2.1 username: myusername password: mypassword always_alive: True

可用配置选项随 proxy 类型（即设备类型）不同而不同。要了解具体配置选项的详细说明，请查阅你所需管理设备类型的 proxy 模块文档（本地参考见 doc/ref/proxy/ 目录，Netmiko 对应实现见 salt/proxy/deltaproxy.py 同目录下的 proxy 模块族）。

4. 保存文件；
5. 用编辑器打开 top file：/srv/pillar/top.sls；
6. 在 top file 中增加一段，指明将被管理设备的 minion ID，并列出上一步创建的 pillar 文件名，例如：

my_managed_device_minion_ID: - my_managed_device_pillar_file_01

7. 对每个需要管理的 minion 重复上述步骤。

至此，你已为 delta proxy minion 管理的 minion 创建了 pillar 文件，并在 top file 中引用了它们。

在源码层面，每个受管子代理的 pillar 都会在subproxy_post_master_init中被单独编译：它基于对应 minion ID 调用salt.pillar.get_async_pillar(...).compile_pillar()，并将结果写入proxyopts["proxy"]，随后用它来初始化该设备的ProxyMinion（见 salt/metaproxy/deltaproxy.py）。

第三步：创建 control proxy 配置文件

每个 control proxy 都需要在 master 上创建或编辑对应的配置文件。control proxy 管理多台设备并向其代表的下发命令；master 至少需要一个 control proxy，也可以有多个 control proxy 各自管理不同的设备集合。

创建 control proxy 配置文件的步骤：

1. 在 master 上进入/srv/pillar目录，新建 proxy 配置文件，命名为描述性名称，如control_proxy_01_configuration.sls；
2. 打开文件，列出每台需管理设备的 minion ID，例如：

proxy: proxytype: deltaproxy ids: - my_managed_device_01 - my_managed_device_02 - my_managed_device_03

3. 保存文件；
4. 用编辑器打开 top file：/srv/pillar/top.sls；
5. 增加一段引用 delta proxy control proxy 的配置，例如：

base: my_managed_device_minion_01: - my_managed_device_pillar_file_01 my_managed_device_minion_02: - my_managed_device_pillar_file_02 my_managed_device_minion_03: - my_managed_device_pillar_file_03 delta_proxy_control: - control_proxy_01_configuration

6. 如有多个 control proxy，对每个 control proxy 重复上述步骤；
7. 打开 proxy 配置文件/etc/salt/proxy，添加 metaproxy 段落并将其值设为deltaproxy：

metaproxy: deltaproxy

注意：control proxy 通过proxytype: deltaproxy与ids列表将一组设备 minion ID 纳入管理。这与标准 proxy minion 每设备一实例的模式形成鲜明对比——ids列表正是 delta proxy 实现"一实例管多设备"的配置入口。

第四步：启动 delta proxy minion

配置完成后，需要为每个受管设备启动 proxy minion 服务并验证其工作正常。

说明：以下步骤演示如何启动单个 delta proxy minion 实例。由于逐台启动每个 minion 可能非常耗时，多数组织会编写脚本来批量启动 delta proxy minion（受管设备通常很多）。建议为你的环境实现类似脚本以节省部署时间。

启动单个 delta proxy minion 实例并测试配置是否正确：

1. 在 Salt master 终端中运行以下命令，将占位符替换为实际的 control proxy ID：

sudo salt-proxy --proxyid=<control_proxy_id>

2. 测试 delta proxy minion：在 master 上运行test.version命令并指定目标 minion，例如：

salt my_managed_device_minion_ID test.version

该命令返回类似下面的输出：

local: 3004

成功启动 delta proxy minion 并验证其工作正常后，这些 minion 的使用方式与标准 proxy minion 完全相同。

源码视角：delta proxy 的工作机制

为了让文章中的配置真正"知其所以然"，这里补充仓库源码中的关键实现证据：

• metaproxy 分派机制：delta proxy 本质上是 Salt 的 metaproxy 体系中的一个实现。salt/minion.py中的_metaproxy_call根据opts["metaproxy"]将post_master_init、tune_in、target_load、handle_payload、handle_decoded_payload、target、thread_return等生命周期函数分派到 salt/metaproxy/deltaproxy.py。默认值为proxy（标准代理），只有显式配置metaproxy: deltaproxy才会走 delta 分支。

• 控制代理与子代理的初始化：post_master_init完成主 minion（control proxy）的模块、pillar、grains 加载后，会遍历self.opts["proxy"].get("ids", [])为每个设备 ID 调用subproxy_post_master_init，为每台设备创建独立的ProxyMinion实例并存入deltaproxy_objs。若在 pillar 中设置parallel_startup: True，则通过asyncio.gather并行初始化这些子代理。

• 单连接接收、按目标转发：handle_payload首先处理发给 control proxy 自身的载荷，然后遍历self.opts["proxy"].get("ids", [self.opts["id"]])，将载荷交给对应deltaproxy_objs中每个子代理实例的_target_load/_handle_decoded_payload处理。也就是说，多个逻辑 minion 共享同一条到 master 的通道，载荷按目标 ID 被分发到各自的子代理对象。

• 多进程与线程模式：在handle_decoded_payload中，若opts.get("multiprocessing", True)为真则使用SignalHandlingProcess子进程执行任务；否则退化为threading.Thread线程模式。这正是文档中"delta proxy minion 可以在关闭多进程的情况下运行"这一选项的代码落点。

• 事件按 proxy_target 路由：salt/minion.py的handle_event中，若事件数据包含proxy_target且metaproxy == "deltaproxy"，会将事件路由到deltaproxy_objs[proxy_target]对应的子代理实例处理。

• control proxy 的 proxy 模块：salt/proxy/deltaproxy.py 是proxytype: deltaproxy对应的 proxy 模块实现，通过__proxyenabled__ = ["deltaproxy"]声明自身，提供init、initialized、grains、ping、shutdown等标准 proxy 模块接口，其中shutdown目前是空操作（源码注释提示未来可调用所有子代理的 shutdown）。

• 配置默认值：salt/config/init.py 的DEFAULT_PROXY_MINION_OPTS定义了proxy_merge_pillar_in_opts（默认False）、proxy_merge_pillar_in_opts_strategy（默认smart）、proxy_always_alive（默认True）、proxy_keep_alive（默认True）、proxy_keep_alive_interval（默认 1 分钟）等与设备连接生命周期相关的默认值，这些选项可与上述配置组合使用，精细控制与受管设备的连接行为。

验证与测试

仓库内置了针对 delta proxy 的完整测试覆盖，可作为部署后自检的参照：

• 单元测试 tests/pytests/unit/metaproxy/test_deltaproxy.py：验证post_master_init与subproxy_post_master_init的初始化流程，包括每个子代理按设备加载独立 grains 的打包逻辑；
• 集成测试 tests/pytests/integration/proxy/test_deltaproxy.py 与 tests/pytests/functional/metaproxy/test_deltaproxy.py：覆盖真实 master/minion 场景下的 delta proxy 行为；
• CLI 测试 tests/pytests/integration/cli/test_salt_deltaproxy.py：验证saltCLI 针对 delta proxy 受管 minion 的下发与返回链路。

部署完成后，除了文档中的salt <minion_id> test.version，你还可以结合salt <minion_id> test.ping与salt-run系列命令进一步验证设备连通性与执行链路。

延伸阅读

• Salt proxy minions 总体概念：本地文档 doc/topics/proxyminion/；
• proxy 模块参考：本地文档 doc/ref/proxy/；
• 标准 proxy 的 metaproxy 实现：salt/metaproxy/proxy.py；
• delta proxy 核心实现：salt/metaproxy/deltaproxy.py。

【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt