运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载导读本文围绕 Salt 状态系统State System中的virtualenv.managed状态展开讲解如何在 SaltStack 中以声明式 SLS 配置创建 Python 虚拟环境、安装 pip 依赖并做幂等变更管理。通过阅读本文你将掌握virtualenv状态的虚拟名加载机制、managed状态的全部参数语义、底层virtualenv.create执行模块的命令拼装原理以及如何利用salt://requirements 文件、clear重建、env_vars编译变量等实战技巧。文档实体为 salt.states.virtualenv 参考页其技术内容完全由 状态模块源码 的 docstring 与实现承载本文结合 执行模块源码 与 单元测试、功能测试 进行深度佐证。模块概览状态如何挂载到virtualenv虚拟名virtualenv状态从 Salt0.17.0版本开始引入用于创建 Python 虚拟环境virtualenv sandbox并在创建的同时通过 pip 安装依赖包。其状态模块文件名为salt/states/virtualenv_mod.py但通过__virtualname__ virtualenv与__virtual__()函数注册为虚拟名__virtualname__ virtualenv def __virtual__(): if virtualenv.create in __salt__: return __virtualname__ return (False, virtualenv module could not be loaded)这意味着在 SLS 文件中你必须使用virtualenv.managed而非virtualenv_mod.managed同时状态的可用性取决于 minion 上是否加载了virtualenv.create执行函数由salt/modules/virtualenv_mod.py提供。若加载失败状态直接返回result: False与提示信息 Virtualenv was not detected on this system状态源码。版本说明从源码的versionchanged标注可以看到当前仓库代码已演进到支持把 Python 解释器直接作为venv_bin传入3006.28变更并允许在venv_bin: venv场景下用python参数指定解释器版本这些细节会在下文逐一展开。快速上手一个最小可运行的 SLS 示例virtualenv.managed状态的核心用法是给定虚拟环境的目标路径name确保该环境存在并可选地通过 pip 安装依赖。状态模块 docstring 中的标准示例为/var/www/myvirtualenv.com: virtualenv.managed: - system_site_packages: False - requirements: salt://REQUIREMENTS.txt - env_vars: PATH_VAR: /usr/local/bin/该示例同时展示了三个高频选项system_site_packages: False环境默认不继承系统全局 site-packagesrequirements: salt://REQUIREMENTS.txt从 Salt master 的文件服务器拉取 requirements 文件env_vars为 pip 安装过程注入编译期环境变量例如某个 Python C 扩展的 Makefile 需要INCLUDE_PATH指向头文件目录。apply 该状态后Salt 会在目标路径创建虚拟环境并执行pip install -r REQUIREMENTS.txt。状态返回的changes中会记录新建/清除环境的 Python 版本以及本次安装的包列表便于审计。参数总览与完整语义managed的签名与 docstring 位于 salt/states/virtualenv_mod.py#L34-L167。除name外所有参数均有默认值绝大多数为None或False即不传即为默认行为。下面分三组整理。第一组环境创建参数透传给virtualenv.create参数默认值说明venv_binNone见下文解析创建环境的命令名/路径。取值有三类virtualenv二进制名、特殊值venv选用 Python 标准库venv模块、或一个 Python 解释器路径如/usr/bin/python3.11此时以interpreter -m venv建环境。也可在 minion 配置中全局设置virtualenv.venv_binpythonNone用于构建环境的 Python 可执行文件。当 Salt 以 onedir 包安装时默认使用 onedir 自带解释器因此通常应显式指定目标解释器system_site_packagesFalse是否允许环境访问系统 site-packages透传给 virtualenv/venv 的--system-site-packagesdistributeFalse透传给 virtualenv 的--distribute。注意 virtualenv ≥ 1.10 已废弃该选项见下文版本相关参数处理clearFalse若环境已存在则先清空再重建透传--clearextra_search_dirNone额外的搜索目录可传逗号分隔字符串或列表逐个转为--extra-search-dirnever_downloadNone透传--never-download仅 virtualenv 二进制路径支持promptNone环境的 shell 提示符前缀透传--promptuserNone以指定用户身份运行 virtualenv 与 pip即设置环境属主第二组pip 安装参数参数默认值说明requirementsNonepip requirements 文件路径以salt://开头时先从 master 文件服务器缓存到 minionpip_pkgsNone替代requirements的包列表直接传给pip.install的pkgsindex_urlNone基础包索引 URL透传--index-urlextra_index_urlNone额外包索引 URL透传--extra-index-urlpre_releasesFalse是否允许安装预发布版本no_depsFalse透传--no-deps给 pip installpip_exists_actionNone路径已存在时 pip 的默认动作(s)witch / (i)gnore / (w)ipe / (b)ackuppip_ignore_installedFalse透传--ignore-installedpip_upgradeFalse透传--upgradeproxyNone代理地址透传给 pip installpip_download/pip_download_cacheNone下载目录 / 下载缓存目录pip_no_cache_dirFalse透传--no-cache-dirpip_cache_dirNone自定义 pip 缓存目录env_varsNone为某些构建注入的环境变量字典cwdNonepip install执行时的工作目录use_vtFalse使用 VT 终端模拟可实时看到安装输出第三组wheel / binary 相关与兜底参数参数默认值说明use_wheelFalse优先使用 wheel 归档需 pip ≥ 1.4no_use_wheelFalse强制不使用 wheel需 pip ≥ 1.4no_binaryNone强制不使用二进制包需 pip ≥ 7.0.0可传:all:、:none:或包名列表process_dependency_linksFalse透传--process-dependency-links2017.7.0新增除上述命名参数外managed还接受virtualenv.create支持的任何其他关键字参数含use_vt、saltenv等。docstring 特别提醒部分 kwargs如pip选项要求搭配distribute: True才生效状态源码。从salt://拉取 requirements 文件状态层的缓存流程当requirements以salt://开头时状态会在创建环境之前先完成文件落地这是状态模块中一个值得注意的细节salt/states/virtualenv_mod.py#L182-L203调用__salt__cp.is_cached检查是否已在本地缓存未缓存则调用cp.cache_file从 master 下载用cp.hash_file对比 master 端与本地缓存文件的哈希若 master 端文件已变更则重新缓存确保总是使用最新版本若最终缓存失败状态返回result: False并提示pip requirements file path not found。该设计保证salt://requirements 文件的变更能被状态感知而不是永远命中旧缓存。底层执行virtualenv.create如何拼装命令状态层的环境创建最终委托给 salt/modules/virtualenv_mod.py 的create()函数签名见 create() 定义。该函数对venv_bin的值做了三路分支命令构建逻辑if venv_bin venv: # sys.executable 或 python 参数指定的解释器 -m venv elif _is_python_binary(venv_bin): # 解释器 -m venvpython 参数若同时给出会报Ambiguous冲突 else: # 直接运行 virtualenv 二进制其中_is_python_binary用正则(python|pypy)[0-9.]*(\.exe)?识别python3、/usr/bin/python3.11、pypy3、python.exe等形态源码识别为解释器的输入一律走interpreter -m venv路径。virtualenv 二进制路径下的参数处理当使用 virtualenv 二进制时create()会做如下处理distribute解析 virtualenv 版本号若版本 ≥(1, 10)则只打日志提示该选项已废弃、不再追加--distribute否则追加源码。单元测试 test_issue_6029_deprecated_distribute 精确验证了 virtualenv 1.9.1 追加--distribute、1.10 之后不再追加的行为python校验解释器存在于 PATH 后追加--pythonpathtest_python_argumentextra_search_dir字符串按逗号拆分后逐个追加--extra-search-dir列表则直接遍历test_issue_6031_multiple_extra_search_dirsnever_downloadvirtualenv 1.10~14.0 之间该选项被废弃代码仅记日志never_downloadTrue且版本 1.10 或 ≥ 14.0 时追加--never-downloadnever_downloadFalse且版本 ≥ 20 时反而追加--download源码prompt以--promptvalue形式追加test_prompt_argument。venv 模块路径下的参数处理当venv_bin为venv或解释器路径时走 Python 标准库venv模块分支upgrade、symlinks分别追加--upgrade、--symlinkstest_venv_module_option_ordering 验证了选项的稳定追加顺序prompt以--prompt value形式追加venv 模块自 Python 3.6 起支持extra_search_dir、never_download在 venv 路径下明确拒绝直接抛CommandExecutionError避免把 virtualenv 专属参数误传给-m venv源码。两条路径共用的公共选项无论哪条路径clear: True追加--clear、system_site_packages: True追加--system-site-packages最后拼接目标路径源码。创建命令通过__salt__cmd.run_all执行。失败清理与 pip/setuptools 引导create()有一个重要的健壮性设计若创建命令返回非零退出码且目标路径在命令执行前并不存在则用shutil.rmtree删除这个半成品目录防止后续的virtualenv.managed其存在性判断以bin/python是否在为准把残缺环境误判为可用源码。test_venv_failure_removes_partial_env 与 test_venv_failure_keeps_preexisting_path 分别覆盖了删除半成品与不删除预先存在的路径两种情形。创建成功后若传了pip或distribute且不是 venv 模块环境还会通过_install_script依次引导ez_setup.py与get-pip.pybootstrap 脚本经cp.cache_file缓存后执行venv 模块环境则由ensurepip自带 pip跳过此步骤源码相关断言见 test_venv_skips_setuptools_bootstrap。幂等性、test 模式与changes报告virtualenv.managed是一个幂等状态其执行逻辑在 salt/states/virtualenv_mod.py#L176-L378存在性判断Windows 上以Scripts/python.exe、其他平台以bin/python是否存在作为环境是否已创建的判据源码test 模式testTrue环境不存在则返回result: None、comment: Virtualenv name is set to be created已存在但clear: True则返回Virtualenv name is set to be cleared已存在且不清理则直接返回Virtualenv name is already created源码创建/清理仅当环境不存在、或存在且clear时调用virtualenv.create返回码非 0 时状态失败并把 stdout/stderr 拼入 comment。创建成功后记录changes[new] python -V 输出clear模式下还会在创建前记录changes[cleared_packages] pip.freeze 结果与changes[old] 旧 Python 版本源码依赖变更检测安装依赖前用pip.freeze(bin_envname)快照现有包集合安装后再次pip.freeze做差集将新增/移除的包写入changes[packages][new/old]源码。这样每次 apply 后都能清楚看到环境里发生了什么变化。pip 版本门槛use_wheel/no_use_wheel/no_binary状态层对 wheel 相关参数做了显式版本校验而不是盲目透传salt/states/virtualenv_mod.py#L260-L314use_wheel与no_use_wheel仅支持 pip1.4 ~ 9.0.3区间超出则状态失败并提示检测到的 pip 版本no_binary要求 pip ≥7.0.0否则状态失败。版本通过__salt__pip.version获取即环境内 pip 的版本并使用salt.utils.versions.compare比较。这意味着如果你在较新 pip9.0.3环境下仍开启use_wheel状态会明确报错而非静默失效。实战组合示例示例一指定解释器 编译期环境变量 私有索引针对 onedir 安装的 Salt miniondocstring 特别强调默认会使用 onedir 自带解释器建环境因此通常应显式提供目标解释器/srv/venvs/app: virtualenv.managed: - python: /usr/bin/python3.11 - venv_bin: venv - system_site_packages: False - pip_pkgs: - requests - pyyaml - index_url: https://pypi.example.com/simple - env_vars: INCLUDE_PATH: /usr/local/include/ LD_LIBRARY_PATH: /usr/local/lib/ - user: appuser其中python与venv_bin: venv的组合3006.28起支持让create()以python -m venv建环境适用于 virtualenv 二进制过旧的发行版如 EL8为任意已装解释器建环境create() docstring。对应的功能测试 test_create_venv_module_with_python 与 test_create_venv_interpreter_as_venv_bin 验证了这两种写法的产物与pyvenv.cfg。示例二requirements 文件 重建场景/var/www/myvirtualenv.com: virtualenv.managed: - requirements: salt://REQUIREMENTS.txt - clear: True # 环境已存在时先清空再重建 - use_vt: True # 实时观察 pip 输出 - pip_upgrade: True # 每次 install 都 --upgrade功能测试 test_clear 展示了clearTrue的真实语义先在环境内安装pep8再以clearTrue重建后pip.list中已不再包含该包证明环境被整体清空重建。示例三仅创建环境、不装依赖managed不需要任何依赖参数——只给name即可确保环境存在/srv/venvs/tooling: virtualenv.managed: - venv_bin: /usr/bin/python3.11此时若环境已存在状态返回成功且comment为virtualenv exists不做任何多余操作完美契合幂等目标。配套能力与延伸阅读底层 CLI执行模块同样可直接在命令行使用如salt * virtualenv.create /path/to/new/virtualenv、salt * virtualenv.get_site_packages /path/to/my/venv、salt * virtualenv.get_distribution_path venv dist后者自2016.3.0提供返回某发行版在环境内的安装路径。全局默认值venv_bin未显式给出时的解析顺序为Pillarvenv_bin→ minion 配置virtualenv.venv_bin→ PATH 中第一个 virtualenv 二进制 → 回退venvcreate() 解析对应单测 test_default_resolution_pillar_overrides_opts。与 pip 模块的衔接managed的 pip 相关参数最终汇入 salt/modules/pip.py 的install()签名见 install() 定义其中index_url/extra_index_url会先经salt.utils.url.validate校验协议合法性再拼入--index-url/--extra-index-urlno_deps、pre_releases等同样有对应命令行参数映射。相关状态若你只需要确保某 Python 包被安装/移除而无需管理整个虚拟环境可参考pip_statesalt/states/pip_state.py虚拟环境的系统级解释器选择则与 grains 中的 Python 信息联动。小结virtualenv.managed是 Salt 中管理 Python 环境的一体化状态它把创建虚拟环境与安装 pip 依赖两个动作收敛为一条幂等声明并通过changes输出、test 模式、salt:// 文件缓存与 pip 版本门槛等机制保证了可预测、可审计、可回放。理解其背后virtualenv.create对 virtualenv 二进制与标准库venv模块的差异化命令拼装能帮助你在混合解释器版本、onedir 安装、老旧发行版等真实环境中准确配置参数避免环境建好了但解释器不对或pip 选项静默失效这类隐蔽问题。赞分享运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载相关推荐Python venv 虚拟环境与 pip 包管理完全指南创建、激活与依赖隔离Python venv 虚拟环境与 pip 包管理完全指南创建、激活与依赖隔离 导读 venv 是 Python 标准库中用于创建虚拟环境virtual编程语言语言运行时解释器标准库NoteDiscovery核心功能详解如何高效组织和管理你的笔记与文档NoteDiscovery核心功能详解如何高效组织和管理你的笔记与文档 NoteDiscovery是一款功能强大的自托管知识管理工具专为需要完全掌控自己数据后端前端知识管理MCP 服务如何快速掌握Python虚拟环境venv与依赖管理完整指南如何快速掌握Python虚拟环境venv与依赖管理完整指南 学习Python编程时虚拟环境管理是每个开发者必须掌握的核心技能。本文将为您提供Python虚拟示例工程教程上一篇解锁视频时间压缩掌握HTML5播放速度控制的专业方案下一篇Flink CDC Paimon Pipeline Connector 实战指南MySQL 实时入湖 Paimon 的流水线配置、原理与类型映射创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考