运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载Saltify 是 Salt Cloud 中一个非常特殊的驱动它不调用任何云厂商 API、不创建任何实例而是通过 SSH 把 Salt 安装到已经存在的机器物理机或虚拟机上并把这些机器纳入 Salt 集群统一管理。本文以 doc/ref/clouds/all/index.rst 所列的salt.cloud.clouds.saltify模块为主体结合其官方使用指南 doc/topics/cloud/saltify.rst、示例配置conf/cloud.providers.d/saltify.conf、conf/cloud.profiles.d/saltify.conf、conf/cloud.maps.d/saltify.map以及单元测试 tests/pytests/unit/cloud/clouds/test_saltify.py完整讲解 Saltify 的配置、部署、验证、WoL 远程唤醒、销毁与批量部署并深入到模块源码 salt/cloud/clouds/saltify.py 揭示其底层实现原理。Saltify 是什么无需云厂商的“安装盐”驱动Salt Cloud 的大多数驱动如 EC2、OpenStack、DigitalOcean 等负责“从零创建虚拟机”因此需要云厂商的 API 凭据。而 Saltify 模块的文档说明非常直接“The Saltify module is designed to install Salt on a remote machine, virtual or bare metal, using SSH. This module is useful for provisioning machines which are already installed, but not Salted.”也就是说Saltify 面向的场景是机器物理服务器或虚拟机已经装好操作系统、处于可 SSH 登录状态但还没有安装 Salt Minion希望通过统一的salt-cloud工作流自动完成 SSH 连接、安装 Salt、注册 Minion、自动签收密钥等全套流程希望这些机器随后能像云主机一样被salt-cloud查询、重启、销毁。从源码结构看salt/cloud/clouds/saltify.py模块的__virtual__()直接返回True即不需要任何特殊的外部依赖或云配置即可加载——这是它和所有“真云”驱动最大的区别。官方文档也明确Saltify 驱动没有任何外部依赖The Saltify driver has no external dependencies.。另外需要注意版本演进wake_on_lan远程唤醒、destroy销毁、reboot重启与query查询能力是在2018.3.0版本加入的见 salt/cloud/clouds/saltify.py这也是saltify真正具备“类云主机管理”能力的分水岭。Provider 配置极简只需声明驱动名由于 Saltify 不依赖任何真实云厂商其 Provider 配置是所有 cloud 驱动中最简单的。官方文档 doc/topics/cloud/saltify.rst 指出唯一必须设置的项就是驱动名driver: saltify其余信息按需补充比如 salt-master 的地址。配置可以写在/etc/salt/cloud.providers文件或/etc/salt/cloud.providers.d/目录下的任意文件中# 示例/etc/salt/cloud.providers.d/saltify.conf my-saltify-config: minion: master: 111.222.333.444 driver: saltify仓库自带的示例配置 conf/cloud.providers.d/saltify.conf 与之呼应全部注释掉仅作模板#my-saltify-config: # driver: saltify关于“master 必须在本机”这一条官方文档强调如果要使用 salt-cloud 的高级能力重启、列出、断开机器等salt-master 必须扮演通常由云厂商管理系统承担的角色——即 master 必须运行在运行salt-cloud的这台机器上且新部署的节点必须连接到该 master。这一点从源码也能印证list_nodes、destroy、reboot、show_instance等操作全部通过salt.client.LocalClient()在本地 master 上执行命令详见下文“管理操作”小节。Profile 配置每台机器一个 profile或借助 map 文件Saltify 的 Profile 配置与云厂商驱动有本质区别官方文档明确要求“Saltify requires a separate profile to be configured for each machine that needs Salt installed”即每台待安装机器都需要一个独立 profile除非你使用 map 文件来提供各机器的独有参数。每个 Profile 必需的参数是ssh_host目标机器的 IP 地址或 DNS 主机名ssh_username登录用户名key_filename与password二者至少提供其一SSH 私钥或密码。官方 profile 示例/etc/salt/cloud.profiles.d/saltify.confsalt-this-machine: ssh_host: 12.34.56.78 ssh_username: root key_filename: /etc/salt/mysshkey.pem provider: my-saltify-config仓库自带的模板 conf/cloud.profiles.d/saltify.conf 即为同一模式的极简形态#make_salty: # provider: my-saltify-config部署单台机器salt-cloud -p salt-this-machine my-machine该命令会按 profilesalt-this-machine指定的 SSH 参数连接目标机器 → 在其上安装 Salt → 赋予 minion idmy-machine。官方文档特别说明如果命令是在 salt-master 上执行的master 会自动接受该机器的 Salt key。随后可用以下命令验证连通性salt my-machine test.version理解 create()deploy 与 SSH 参数解析单机部署的入口是模块的create(vm_)函数salt/cloud/clouds/saltify.py。其核心逻辑为读取deploy配置默认值为False通过config.get_cloud_config_value(deploy, vm_, __opts__, defaultFalse)若未显式配置ssh_host则默认取 minion 的 name 作为 ssh_host源码中vm_[ssh_host] vm_[name]这对 DNS 解析正常的环境非常友好若deployTrue执行正式部署走__utils__cloud.bootstrap即 Salt Cloud 统一的安装引导流程在此之前若配置了 WoL 参数会先执行远程唤醒若deployFalse调用_verify(vm_)只做凭据/连通性验证不实际安装。create()的 docstring 完整列出了该驱动的核心配置参数salt/cloud/clouds/saltify.py参数默认值作用deployFalse为True时正式安装 Salt 并把 key 注册到 master为False时仅测试 SSH 连接provider—salt/cloud.providers.d/中的 provider 条目名ssh_hostminion 名目标机器的 IP 或 DNS 名ssh_usernameroot登录用户名ssh_password—登录密码除非使用 key_filenamekey_filename—可选免密登录的 SSH 私钥路径ssh_port22SSH 连接端口wake_on_lan_mac—可选目标机器网卡 MAC 地址用于 WoL 唤醒wol_sender_node—可选发送 WoL 魔术包的 Salt minionwol_boot_wait30发送 WoL 后等待目标机器启动的秒数force_minion_config—可选替换目标机器上的 minion 配置文件值得注意的实现细节是ssh_username的默认值在_verify()中为root源码 salt/cloud/clouds/saltify.py而key_filename兼容了ssh_keyfile这一别名key_filename未配置时回退读取ssh_keyfile见 salt/cloud/clouds/saltify.py。另外_verify()会读取gateway参数支持跳板机并以maxtries: 1控制探测次数最终通过__utils__[cloud.wait_for_passwd]验证 SSH 凭据salt/cloud/clouds/saltify.py。deploy: False 的妙用部署前凭据验证因为 Saltify 并不真正创建 VM所以当deploy设为False时它的行为与其它驱动完全不同。官方文档 doc/topics/cloud/saltify.rst 的 Credential Verification 一节对此有专门说明此时 Saltify 会尝试向目标节点认证并对每个认证成功的节点返回True。这非常适合在正式上线前先验证端口、协议、服务与凭据是否正确配置。官方给出的返回值约定为True凭据验证成功False凭据验证失败None未进行凭据验证。从源码看_verify()salt/cloud/clouds/saltify.py实际支持两种认证路径SSH 路径未配置win_installer时按上述参数构造连接信息调用cloud.wait_for_passwd探测Windows 路径配置了win_installer时先通过smbprotocol的smb.get_conn测试 SMB 连接若设置use_winrm: True则再通过cloud.wait_for_winrm测试 WinRM默认端口5986超时 10 秒。其中win_username默认Administrator。注意Windows 路径依赖smbprotocol与winrm库——模块在导入时用HAS_SMB/HAS_WINRM标记其可用性salt/cloud/clouds/saltify.py缺失时验证直接返回False并记录错误日志。单元测试test_create_no_deploytests/pytests/unit/cloud/clouds/test_saltify.py验证了deploy: False时create()走_verify分支的行为test_create_and_deploy同文件 L58-L74则验证deploy: True时仅调用一次cloud.bootstrap。另外官方文档还特别提示ssh_host对 Windows 主机同样适用——Windows 通常不跑 SSH 服务但该字段仍用于指示目标系统的 IP 或主机名。用 Map 文件做批量部署对多台机器推荐把共性与个性参数分层组织。仓库自带的 conf/cloud.maps.d/saltify.map 即给出了最基础的 map 形态#make_salty: # - myinstance: # ssh_host: 54.262.11.38 # ssh_username: ubuntu # ssh_keyfile: /etc/salt/mysshkey.pem # sudo: True官方文档的完整示例/etc/salt/saltify-mapmake_salty: - my-instance-0: ssh_host: 12.34.56.78 ssh_username: root password: very-bad-password - my-instance-1: ssh_host: 44.33.22.11 ssh_username: root password: another-bad-pass此时my-instance-0与my-instance-1将分别成为部署后 minion 的 id。执行salt-cloud -m /etc/salt/saltify-map验证salt my-instance-* test.version有两个官方文档强调的关键点使用 map 时profile 名上例中的make_salty仍必须在 profile 配置中定义哪怕它本身不含任何 SSH 参数# /etc/salt/cloud.profiles.d/saltify.conf make_salty: provider: my-saltify-configssh_host缺省时取 minion id。官方文档明确如果ssh_host未提供其默认值就是 Minion 标识符。因此对于 DNS 解析正常的环境map 可以精简为只列机器名# /etc/salt/saltify-map make_salty: - my-instance-0 - my-instance-1这一行为与源码完全一致create()中if not config.get_cloud_config_value(ssh_host, vm_, __opts__, default): vm_[ssh_host] vm_[name]。单元测试test_create_no_ssh_hosttests/pytests/unit/cloud/clouds/test_saltify.py专门验证了未配置ssh_host时其值会被设置为 minion 名。批量部署的推荐组织方式官方文档 Bulk Deployments 一节给出最佳实践当大量目标系统共享同一组凭据时把相同参数放进 profilemap 里只保留各机器的差异项# /etc/salt/cloud.profiles.d/saltify.conf make_salty: provider: my-saltify-config ssh_username: root password: very-bad-password# /etc/salt/saltify-map make_salty: - my-instance-0: ssh_host: 12.34.56.78 - my-instance-1: ssh_host: 44.33.22.11这样既避免了在 map 中重复大量相同数据又保留了每台机器的独立 IP。Wake On LAN远程唤醒后自动部署从 2018.3.0 版本起Saltify 支持通过 WoL 魔术包magic packet远程启动一台已关机/待机状态的硬件机器然后继续部署流程。官方文档对适用条件的说明很关键魔术包必须由与目标机器位于同一网段的既有 Salt minion发送或路由器已专门配置为转发 WoL 包目标机器的 BIOS/网卡必须已配置为监听 WoL 并响应。需要配置三个参数wol_sender_node负责发送 WoL 包的 Salt 节点 idwake_on_lan_mac目标机器网卡的 MAC 地址可用ifconfig查到wol_boot_wait发送 WoL 后等待启动的秒数默认 30 秒。完整 profile 示例/etc/salt/cloud.profiles.d/saltify.confsalt-this-machine: ssh_host: 12.34.56.78 ssh_username: root key_filename: /etc/salt/mysshkey.pem provider: my-saltify-config wake_on_lan_mac: 00:e0:4c:70:2a:b2 # 用 ifconfig 查询 wol_sender_node: bevymaster # 与目标机同网段的节点 wol_boot_wait: 45 # 睡眠等待秒数从源码salt/cloud/clouds/saltify.py看 WoL 的完整执行流程create()读取wake_on_lan_mac与wol_sender_node仅当两者都有值时才触发唤醒逻辑若已配置ssh_host先在发送节点上执行ping -c 1 ssh_hostWindows 平台用ping -n 1通过cmd.retcode判断返回码探测目标是否在线若 ping 不通则调用发送节点的network.wol执行模块发送魔术包MAC 是字符串时会被包装成单元素列表便于一次传入多个地址若发送成功按wol_boot_wait秒数time.sleep等待目标启动随后才进入cloud.bootstrap部署阶段。单元测试test_create_wake_on_lantests/pytests/unit/cloud/clouds/test_saltify.py验证了这条链路它会断言network.wol以[aa-bb-cc-dd-ee-ff]的形式被调用并检查time.sleep收到预期的等待时长。管理操作查询、重启与销毁Saltify 与“真云”驱动不同它没有云厂商 API 可查因此所有管理操作都通过本地 salt-master 对已托管 minion 执行命令来实现。从源码看这些操作统一使用salt.client.LocalClient()salt/cloud/clouds/saltify.py。查询依赖 salt-cloud grainssalt-cloud -Qlist_nodes只返回标准字段id、image、private_ips、public_ips、size、statesalt-cloud -Flist_nodes_full返回增强后的完整信息。两者的数据来源都是_list_nodes_full()——它向所有带salt-cloud:driver:saltifygrain 的 minion 执行grains.itemsgrain 匹配tgt_typegrain再按 IP 地址做公私网分类_build_required_items()使用ipaddress模块判断剔除回环地址127.0.0.1、::1私网地址进private_ips、公网地址进public_ipssalt/cloud/clouds/saltify.py。list_nodes_full还会删除cpu_flags、disks、pythonpath、dns、gpus等过于冗长的 grains 以精简输出salt/cloud/clouds/saltify.py。show_instance(name)则对单个 minion 执行grains.items。单元测试test_list_nodestests/pytests/unit/cloud/clouds/test_saltify.py构造了一个含回环/私网/公网混合 IP 的 grains 样例验证了公私网 IP 的正确归类。另外两个查询函数是固定行为avail_locations()永远返回空字典{}Saltify 没有“可用区域”概念对应salt-cloud --list-locationsavail_sizes()永远返回空字典{}没有“实例规格”概念对应salt-cloud --list-sizesavail_images()返回当前配置的所有 profile 列表对应salt-cloud --list-images saltify返回结构为{Profiles: [...]}。这些行为都被单元测试test_avail_locations/test_avail_sizes/test_avail_imagestests/pytests/unit/cloud/clouds/test_saltify.py固定了下来。重启salt-cloud -a reboot vm_namereboot()salt/cloud/clouds/saltify.py要求必须以 action 方式调用call action否则抛出SaltCloudException随后对目标 minion 执行system.reboot。测试test_saltify_reboot验证了system.reboot被正确调用。销毁断开并清理salt-cloud --destroy mymachinedestroy()salt/cloud/clouds/saltify.py的作用是断开 minion 与 master 的连接并移除其 key物理机当然不会被“销毁”因此官方文档称之为 tear down 而非 vaporize。执行过程中会先发salt/cloud/name/destroying事件再通过grains.get salt-cloud反查该 minion 使用的 profile 以读取销毁选项。destroy支持两个可配置项官方文档 doc/topics/cloud/saltify.rst 的 Destroy Options 一节remove_config_on_destroy: true # 默认: true # 禁用 salt-minion 开机自启并删除其 /etc/salt 下的 minion 配置与 key 文件。 # 注意若禁用自启失败如较老的 Ubuntu 机器salt-minion 重启时会 # 自动生成一套新的、多余的 key 文件此时可用 force_minion_config 选项覆盖。 shutdown_on_destroy: false # 默认: false # 最后向客户端发送 shutdown 关机命令。从源码看当remove_config_on_destroy: True默认时销毁流程依次执行service.disable salt-minion防止重启后重新生成 key→ 读取conf_file并file.remove删除配置 → 读取pki_dir并file.remove删除 key 目录当shutdown_on_destroy: True时最后执行system.shutdown。整个过程中每次命令执行都会核对返回结果再继续。完成后发送salt/cloud/name/destroyed事件并返回{Destroyed: name was destroyed.}。单元测试test_saltify_destroytests/pytests/unit/cloud/clouds/test_saltify.py用一个关闭了remove_config_on_destroy、开启了shutdown_on_destroy的测试 profile验证了销毁链路最终会调用system.shutdown。从测试看驱动的契约行为汇总 tests/pytests/unit/cloud/clouds/test_saltify.py 的用例可以提炼出 Saltify 驱动对外承诺的行为契约这些也是排查问题时的判断基准deploy: False时create()走凭据验证分支test_create_no_deploydeploy: True时create()恰好调用一次cloud.bootstraptest_create_and_deploy未配置ssh_host时自动取 minion 名test_create_no_ssh_hostWoL 场景下network.wol以 MAC 列表形式调用并按wol_boot_wait睡眠test_create_wake_on_lanavail_locations/avail_sizes恒为空字典、avail_images返回 profilestest_avail_*list_nodes只输出标准字段且公私网 IP 正确归类test_list_nodesreboot调用system.reboottest_saltify_rebootdestroy按 profile 选项执行清理与关机test_saltify_destroy。配置速查与常见问题把官方文档 doc/topics/cloud/saltify.rst 与源码参数合并得到一份可直接参考的速查表配置项默认值说明driver—Provider 中必填值为saltifyssh_hostminion 名目标 IP/DNSWindows 主机同样使用该字段ssh_usernamerootSSH/AdministratorWindows登录用户password/ssh_password—密码认证与 key 认证二选一key_filename别名ssh_keyfile—私钥免密认证ssh_port22SSH 端口deployFalseTrue正式部署False仅验证凭据wake_on_lan_mac—WoL 目标 MACwol_sender_node—发送 WoL 的节点wol_boot_wait30WoL 后等待秒数force_minion_config—覆盖目标机 minion 配置remove_config_on_destroyTrue销毁时禁用自启并删除配置/keyshutdown_on_destroyFalse销毁时关机win_installer/win_username/win_password/use_winrm/winrm_port—Windows 部署与验证依赖 smbprotocol/winrm常见问题排查要点--list-locations/--list-sizes输出为空是正常现象Saltify 没有区域与规格概念源码与测试都固定了空字典行为deploy: False时返回False表示凭据验证失败先检查 SSH 端口、用户名/密码/私钥、gateway跳板配置WoL 不生效确认wol_sender_node与目标机同网段且目标机已开启 WoL 监听销毁后 minion 重新生成 key这是remove_config_on_destroy执行时service.disable失败的典型症状较老系统官方建议配合force_minion_config覆盖配置。小结Saltify 填补了 Salt Cloud 生态中“已有机器纳管”的空白以极简的 provider 配置仅driver: saltify加每台机器的 SSH 参数就能让salt-cloud统一完成安装 Salt、自动签收 key、查询、重启、WoL 唤醒与销毁清理。它与其它驱动的本质区别在于——没有云厂商 API 可依赖一切管理操作都经由本地 salt-master 对已托管 minion 执行。理解这一点就能在使用list_nodes、destroy、reboot等高级功能时明确前置条件master 必须与salt-cloud同机且目标机器必须已连接到该 master。如需进一步深入可继续阅读模块全量文档 doc/ref/clouds/all/salt.cloud.clouds.saltify.rst、官方入门指南 doc/topics/cloud/saltify.rst、源码实现 salt/cloud/clouds/saltify.py 与单元测试 tests/pytests/unit/cloud/clouds/test_saltify.py。赞分享运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载相关推荐用 Saltify 驱动为存量机器安装 Saltsalt-cloud 无云厂商接入全指南用 Saltify 驱动为存量机器安装 Saltsalt cloud 无云厂商接入全指南 本指南围绕 Salt Cloud 的 Saltify 驱动 展开它运维配置管理后端如何快速制作标准证件照HivisionIDPhotos AI离线证件照工具完整使用指南如何快速制作标准证件照HivisionIDPhotos AI离线证件照工具完整使用指南 HivisionIDPhotos 是一款轻量级 AI 证件照制作工具运维配置管理后端Salt 深入salt-ssh roster 按主机启用 relenvSaltPython 捆绑部署的精确控制Salt 深入salt ssh roster 按主机启用 relenvSaltPython 捆绑部署的精确控制 导读 本篇文章围绕 Salt 变更 ch运维配置管理后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考