尧图网站建设 
Nixpkgs 中用 Packer 构建跨平台镜像packer.withPlugins 与插件体系的完整解析【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs本文以 nixpkgs 官方手册中的 Packer 章节doc/packages/packer.section.md为核心结合仓库中 packer 包定义、withPlugins 实现 和 插件构建器 的源码系统讲解如何在 Nixpkgs 环境下免运行时下载地使用 Packer 插件读完你将掌握packer.withPlugins的用法与原理、如何枚举当前版本可用的全部插件、插件二进制命名与校验和机制以及如何用mkPackerPlugin自行打包一个新插件。1. Packer 与 nixpkgs 中的打包形态Packer 是一个从单一源配置为多个平台创建一致机器镜像的工具。在 nixpkgs 中它由 pkgs/by-name/pa/packer/package.nix 通过buildGoModule构建当前版本为1.15.4采用 BSL 1.1 许可见该文件meta.license lib.licenses.bsl11并在postInstall阶段安装 zsh 补全installShellCompletion --zsh contrib/zsh-completion/_packer。Packer 的核心功能通过插件扩展builder如 docker、qemu、provisioner如 shell、ansible、post-processor 等都独立发布为插件。Nixpkgs 的差异化之处在于不让 Packer 在运行时自行下载插件而是把所需插件一并静态打包进一个包装后的 Packer 可执行文件保证构建可复现、离线可用。这一能力的入口就是packer.withPlugins。2. 用 packer.withPlugins 组装“带插件的 Packer”packer.withPlugins接受一个函数它接收可用插件集作为参数返回要包含的插件列表packer.withPlugins (ps: [ ps.docker ])其产物是一个经过包装的packer可执行文件运行时自动带上PACKER_PLUGIN_PATH环境变量因此选中的插件无需再执行packer plugins install即可直接使用。官方手册给出的典型场景是搭建一个包含 Packer 与 Docker 插件的开发 shell{ pkgs ? import nixpkgs { }, }: pkgs.mkShell { packages [ (pkgs.packer.withPlugins (ps: [ ps.docker ])) ]; }也可以一次选择多个插件例如同时带上 Docker 与 QEMU 的 builderpacker.withPlugins (ps: [ ps.docker ps.qemu ])2.1 源码实现linkFarm 汇总插件 makeBinaryWrapper 注入环境变量上述行为在 pkgs/by-name/pa/packer/with-plugins.nix 中实现整份文件仅 54 行核心逻辑值得逐行看清插件选择L26plugins selector packerPlugins;—— 你在withPlugins (ps: ...)里写的函数就是对packerPlugins全部已打包插件的调用返回一个插件 derivation 列表。插件“农场”L27-L38用linkFarm packer-plugins为每个插件创建两组符号链接以插件的pluginPath为名链接${p}/bin/${p.meta.mainProgram}真正的插件二进制以${pluginPath}_SHA256SUM为名链接同名的校验和文件。 这正是 Packer 发现本地插件所需的目录形态二进制 配套 SHA256 校验文件。包装器L49-L52buildCommand中用makeWrapper把原生packer复制到$out/bin/packer并--set PACKER_PLUGIN_PATH ${pluginFarm}。至此运行这个包装版packer时Packer 就能在PACKER_PLUGIN_PATH下找到全部选定插件完全跳过运行时下载。withPlugins本身在 package.nix 的 passthru 中定义它先callPackage ./plugins.nix得到完整的插件作用域scope再把它连同packer finalAttrs.finalPackage一起传给with-plugins.nix最后以{ selector f; }注入你的选择函数——这就是为什么参数集ps只包含 nixpkgs 中“已打包”的插件。2.2 测试验证withPlugins 的端到端测试package.nix 的passthru.tests.withPlugins提供了权威验证路径它先用finalAttrs.passthru.withPlugins (ps: [ ps.docker ])构造出带 docker 插件的 Packer在runCommand中执行packer plugins installed再断言输出中包含 docker 插件的pluginPath若缺失则以非零状态退出。这印证了第 2.1 节的结论包装后的 Packer 确实能让packer plugins installed直接列出所选插件。3. 列出当前版本可用的全部插件npxkgs 手册给出的两条命令在此完整保留启用 flakes 与否各一条$ nix eval nixpkgs#packer.plugins --apply builtins.attrNames [ docker qemu ]不使用 flakes 时$ nix-env -f nixpkgs -qaP -A packer.plugins packer.plugins.docker packer-plugin-docker-1.1.2 packer.plugins.qemu packer-plugin-qemu-1.1.4两条命令的输出内容取决于你使用的 nixpkgs 版本——手册示例出自收录插件较少的早期版本在当前仓库中pkgs/by-name/pa/packer/plugins/ 目录下已收录 33 个插件涵盖主流云厂商与本地虚拟化方案类别插件示例属性名即插件目录去掉packer-plugin-前缀公有云amazon、azure、googlecompute、alicloud、jdcloud、tencentcloud、yandex、oracle、ncloud、oneandone、profitbricks、openstack、triton本地虚拟化qemu、docker、lxc、lxd、hyperv、virtualbox、vagrant、proxmox、kubevirt、cloudstack、hashicups测试用配置/合规工具ansible、chef、puppet、salt、converge、inspecSDK/脚手架sdk、scaffoldingnix-env -qaP输出的第二列同时给出了带版本的完整包名如packer-plugin-docker-1.1.3、packer-plugin-qemu-1.1.5可用于核对具体版本。3.1 属性名从哪里来插件作用域的构建pkgs/by-name/pa/packer/plugins.nix 解释了上述属性集的来源用lib.packagesFromDirectoryRecursive扫描./plugins/目录自动收集所有插件包用lib.mapAttrs将每个包名去掉packer-plugin-前缀后作为作用域属性名lib.removePrefix packer-plugin- name同时向作用域注入mkPackerPlugin供各插件包复用。而 package.nix 中plugins lib.filterAttrs (_: lib.isDerivation) pluginScope会过滤掉非 derivation 项如mkPackerPlugin函数本身因此packer.plugins里“看到的”全是可安装包。关键结论属性名如docker、qemu就是传给packer.withPlugins的键与手册 Notes 的说明一致。4. 插件是如何被构建的mkPackerPlugin 深入解析理解 pkgs/by-name/pa/packer/extra/mk-packer-plugin.nix99 行是理解整个插件体系的最佳入口它封装了 Packer 插件发布结构的硬性约定1Packer 对插件目录结构的期望。文件 L39-L49 的注释说明Packer 假设插件托管在 GitHub 上并遵循特定发布结构由此产生两条要求——二进制必须位于$PACKER_PLUGIN_PATH/github.com/$OWNER/$TYPE/其中$TYPE是仓库名去掉packer-plugin-前缀后的名字在 Packer 模板中声明插件时source属性必须写成同样的github.com/$OWNER/$TYPE形式。with-plugins.nix中 linkFarm 的命名name p.pluginPath正是为了满足第一条要求使离线插件与在线下载的插件在目录布局上完全等价。2二进制命名规则L53-L56suffix platformSuffix.${stdenv.hostPlatform.system} ...; binName ${finalAttrs.src.repo}_v${finalAttrs.version}_${apiVersion}_${suffix};例如 docker 插件在 x86_64-linux 上产出packer-plugin-docker_v1.1.3_x5.0_linux_amd64apiVersion默认x5.0。3校验和文件生成L86-L90postFixup阶段在二进制被 fixup 定型之后将$out/bin/${repo}重命名为带版本后缀的binName并计算sha256sum写入同名的_SHA256SUM文件。这就是 Packer 校验本地插件完整性所依赖的文件。4版本注入L68-L80通过ldflags的-X将${githubBase}/${owner}/${repo}/version包中的Version变量写入插件版本-X ...VersionPrerelease置空预发布标识保证packer plugins installed显示干净的版本号。5平台限制L1-L6, L53-L55platformSuffix只映射了三个系统Nix 系统Packer 发布后缀x86_64-linuxlinux_amd64aarch64-linuxlinux_arm64aarch64-darwindarwin_arm64在其他系统上调用会直接throw Unsupported system: ...。也就是说当前插件打包链路仅支持这三个系统这是使用该体系时必须知道的前提。6fetcher 限制L50-L52 用lib.assertMsg强制src必须携带repo、owner、githubBase字段——即目前只支持fetchFromGitHub。这与手册 Notes 一节“mkPackerPlugincurrently only supportsfetchFromGitHubas the fetcher”完全对应。若你的插件发布在 GitLab 或其他平台需要自行处理命名与校验和逻辑不能直接套用该构建器。4.1 一个具体插件包长什么样以 packer-plugin-docker 的 package.nix 为例一个插件定义非常短mkPackerPlugin提供pname、version、srcfetchFromGitHub拉取 hashicorp/packer-plugin-docker 的 tag 并附 SRI 哈希、vendorHashbuildGoModule的 vendor 依赖哈希和meta。packer-plugin-qemu 的 package.nix 结构相同仅版本与哈希不同当前仓库中 docker 1.1.3、qemu 1.1.5许可证均为 MPL-2.0。由此可以推断为 nixpkgs 新增一个插件本质上就是在plugins/下新建一个packer-plugin-name/package.nix、按上述模式填写fetchFromGitHub的owner/repo/tag/hash与vendorHashplugins.nix的packagesFromDirectoryRecursive会自动收录它无需改动任何注册表。5. 实战建议与已知限制小结结合文档与源码使用 nixpkgs 的 Packer 插件体系时注意以下几点优先使用包装器而非packer plugins install。withPlugins产物的插件路径在构建期即确定linkFarm 内容静态可复现这是 Nix 可复现性要求下的推荐做法packer plugins install会在运行时发起网络下载与这一原则相悖。插件名以作用域属性名为准。执行nix eval nixpkgs#packer.plugins --apply builtins.attrNames查询你手上 nixpkgs 版本实际可用的插件不要凭手册旧示例臆测。目标平台受支持。插件构建器目前仅覆盖x86_64-linux、aarch64-linux、aarch64-darwin见 mk-packer-plugin.nix 的 platformSuffix。fetcher 受限于 GitHub。所有已收录插件均通过fetchFromGitHub获取源码并用 Go 模块方式构建插件的source声明在 Packer 模板中需写成github.com/$OWNER/$TYPE形式。版本固定、可审计。每个插件都是独立 derivation版本与哈希固化在各自的 package.nix 中packer.plugins.docker与packer.withPlugins的端到端行为由 tests.withPlugins 守护。6. 延伸阅读手册原始章节doc/packages/packer.section.mdPacker 主包定义含 passthru 与测试pkgs/by-name/pa/packer/package.nixwithPlugins 包装实现pkgs/by-name/pa/packer/with-plugins.nix插件作用域与目录自动收录pkgs/by-name/pa/packer/plugins.nix插件构建器命名/校验和/平台规则pkgs/by-name/pa/packer/extra/mk-packer-plugin.nix已收录插件全集33 个pkgs/by-name/pa/packer/plugins/【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nixpkgs 中用 Packer 构建跨平台镜像：packer.withPlugins 与插件体系的完整解析
Nixpkgs 中用 Packer 构建跨平台镜像packer.withPlugins 与插件体系的完整解析【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs本文以 nixpkgs 官方手册中的 Packer 章节doc/packages/packer.section.md为核心结合仓库中 packer 包定义、withPlugins 实现 和 插件构建器 的源码系统讲解如何在 Nixpkgs 环境下免运行时下载地使用 Packer 插件读完你将掌握packer.withPlugins的用法与原理、如何枚举当前版本可用的全部插件、插件二进制命名与校验和机制以及如何用mkPackerPlugin自行打包一个新插件。1. Packer 与 nixpkgs 中的打包形态Packer 是一个从单一源配置为多个平台创建一致机器镜像的工具。在 nixpkgs 中它由 pkgs/by-name/pa/packer/package.nix 通过buildGoModule构建当前版本为1.15.4采用 BSL 1.1 许可见该文件meta.license lib.licenses.bsl11并在postInstall阶段安装 zsh 补全installShellCompletion --zsh contrib/zsh-completion/_packer。Packer 的核心功能通过插件扩展builder如 docker、qemu、provisioner如 shell、ansible、post-processor 等都独立发布为插件。Nixpkgs 的差异化之处在于不让 Packer 在运行时自行下载插件而是把所需插件一并静态打包进一个包装后的 Packer 可执行文件保证构建可复现、离线可用。这一能力的入口就是packer.withPlugins。2. 用 packer.withPlugins 组装“带插件的 Packer”packer.withPlugins接受一个函数它接收可用插件集作为参数返回要包含的插件列表packer.withPlugins (ps: [ ps.docker ])其产物是一个经过包装的packer可执行文件运行时自动带上PACKER_PLUGIN_PATH环境变量因此选中的插件无需再执行packer plugins install即可直接使用。官方手册给出的典型场景是搭建一个包含 Packer 与 Docker 插件的开发 shell{ pkgs ? import nixpkgs { }, }: pkgs.mkShell { packages [ (pkgs.packer.withPlugins (ps: [ ps.docker ])) ]; }也可以一次选择多个插件例如同时带上 Docker 与 QEMU 的 builderpacker.withPlugins (ps: [ ps.docker ps.qemu ])2.1 源码实现linkFarm 汇总插件 makeBinaryWrapper 注入环境变量上述行为在 pkgs/by-name/pa/packer/with-plugins.nix 中实现整份文件仅 54 行核心逻辑值得逐行看清插件选择L26plugins selector packerPlugins;—— 你在withPlugins (ps: ...)里写的函数就是对packerPlugins全部已打包插件的调用返回一个插件 derivation 列表。插件“农场”L27-L38用linkFarm packer-plugins为每个插件创建两组符号链接以插件的pluginPath为名链接${p}/bin/${p.meta.mainProgram}真正的插件二进制以${pluginPath}_SHA256SUM为名链接同名的校验和文件。 这正是 Packer 发现本地插件所需的目录形态二进制 配套 SHA256 校验文件。包装器L49-L52buildCommand中用makeWrapper把原生packer复制到$out/bin/packer并--set PACKER_PLUGIN_PATH ${pluginFarm}。至此运行这个包装版packer时Packer 就能在PACKER_PLUGIN_PATH下找到全部选定插件完全跳过运行时下载。withPlugins本身在 package.nix 的 passthru 中定义它先callPackage ./plugins.nix得到完整的插件作用域scope再把它连同packer finalAttrs.finalPackage一起传给with-plugins.nix最后以{ selector f; }注入你的选择函数——这就是为什么参数集ps只包含 nixpkgs 中“已打包”的插件。2.2 测试验证withPlugins 的端到端测试package.nix 的passthru.tests.withPlugins提供了权威验证路径它先用finalAttrs.passthru.withPlugins (ps: [ ps.docker ])构造出带 docker 插件的 Packer在runCommand中执行packer plugins installed再断言输出中包含 docker 插件的pluginPath若缺失则以非零状态退出。这印证了第 2.1 节的结论包装后的 Packer 确实能让packer plugins installed直接列出所选插件。3. 列出当前版本可用的全部插件npxkgs 手册给出的两条命令在此完整保留启用 flakes 与否各一条$ nix eval nixpkgs#packer.plugins --apply builtins.attrNames [ docker qemu ]不使用 flakes 时$ nix-env -f nixpkgs -qaP -A packer.plugins packer.plugins.docker packer-plugin-docker-1.1.2 packer.plugins.qemu packer-plugin-qemu-1.1.4两条命令的输出内容取决于你使用的 nixpkgs 版本——手册示例出自收录插件较少的早期版本在当前仓库中pkgs/by-name/pa/packer/plugins/ 目录下已收录 33 个插件涵盖主流云厂商与本地虚拟化方案类别插件示例属性名即插件目录去掉packer-plugin-前缀公有云amazon、azure、googlecompute、alicloud、jdcloud、tencentcloud、yandex、oracle、ncloud、oneandone、profitbricks、openstack、triton本地虚拟化qemu、docker、lxc、lxd、hyperv、virtualbox、vagrant、proxmox、kubevirt、cloudstack、hashicups测试用配置/合规工具ansible、chef、puppet、salt、converge、inspecSDK/脚手架sdk、scaffoldingnix-env -qaP输出的第二列同时给出了带版本的完整包名如packer-plugin-docker-1.1.3、packer-plugin-qemu-1.1.5可用于核对具体版本。3.1 属性名从哪里来插件作用域的构建pkgs/by-name/pa/packer/plugins.nix 解释了上述属性集的来源用lib.packagesFromDirectoryRecursive扫描./plugins/目录自动收集所有插件包用lib.mapAttrs将每个包名去掉packer-plugin-前缀后作为作用域属性名lib.removePrefix packer-plugin- name同时向作用域注入mkPackerPlugin供各插件包复用。而 package.nix 中plugins lib.filterAttrs (_: lib.isDerivation) pluginScope会过滤掉非 derivation 项如mkPackerPlugin函数本身因此packer.plugins里“看到的”全是可安装包。关键结论属性名如docker、qemu就是传给packer.withPlugins的键与手册 Notes 的说明一致。4. 插件是如何被构建的mkPackerPlugin 深入解析理解 pkgs/by-name/pa/packer/extra/mk-packer-plugin.nix99 行是理解整个插件体系的最佳入口它封装了 Packer 插件发布结构的硬性约定1Packer 对插件目录结构的期望。文件 L39-L49 的注释说明Packer 假设插件托管在 GitHub 上并遵循特定发布结构由此产生两条要求——二进制必须位于$PACKER_PLUGIN_PATH/github.com/$OWNER/$TYPE/其中$TYPE是仓库名去掉packer-plugin-前缀后的名字在 Packer 模板中声明插件时source属性必须写成同样的github.com/$OWNER/$TYPE形式。with-plugins.nix中 linkFarm 的命名name p.pluginPath正是为了满足第一条要求使离线插件与在线下载的插件在目录布局上完全等价。2二进制命名规则L53-L56suffix platformSuffix.${stdenv.hostPlatform.system} ...; binName ${finalAttrs.src.repo}_v${finalAttrs.version}_${apiVersion}_${suffix};例如 docker 插件在 x86_64-linux 上产出packer-plugin-docker_v1.1.3_x5.0_linux_amd64apiVersion默认x5.0。3校验和文件生成L86-L90postFixup阶段在二进制被 fixup 定型之后将$out/bin/${repo}重命名为带版本后缀的binName并计算sha256sum写入同名的_SHA256SUM文件。这就是 Packer 校验本地插件完整性所依赖的文件。4版本注入L68-L80通过ldflags的-X将${githubBase}/${owner}/${repo}/version包中的Version变量写入插件版本-X ...VersionPrerelease置空预发布标识保证packer plugins installed显示干净的版本号。5平台限制L1-L6, L53-L55platformSuffix只映射了三个系统Nix 系统Packer 发布后缀x86_64-linuxlinux_amd64aarch64-linuxlinux_arm64aarch64-darwindarwin_arm64在其他系统上调用会直接throw Unsupported system: ...。也就是说当前插件打包链路仅支持这三个系统这是使用该体系时必须知道的前提。6fetcher 限制L50-L52 用lib.assertMsg强制src必须携带repo、owner、githubBase字段——即目前只支持fetchFromGitHub。这与手册 Notes 一节“mkPackerPlugincurrently only supportsfetchFromGitHubas the fetcher”完全对应。若你的插件发布在 GitLab 或其他平台需要自行处理命名与校验和逻辑不能直接套用该构建器。4.1 一个具体插件包长什么样以 packer-plugin-docker 的 package.nix 为例一个插件定义非常短mkPackerPlugin提供pname、version、srcfetchFromGitHub拉取 hashicorp/packer-plugin-docker 的 tag 并附 SRI 哈希、vendorHashbuildGoModule的 vendor 依赖哈希和meta。packer-plugin-qemu 的 package.nix 结构相同仅版本与哈希不同当前仓库中 docker 1.1.3、qemu 1.1.5许可证均为 MPL-2.0。由此可以推断为 nixpkgs 新增一个插件本质上就是在plugins/下新建一个packer-plugin-name/package.nix、按上述模式填写fetchFromGitHub的owner/repo/tag/hash与vendorHashplugins.nix的packagesFromDirectoryRecursive会自动收录它无需改动任何注册表。5. 实战建议与已知限制小结结合文档与源码使用 nixpkgs 的 Packer 插件体系时注意以下几点优先使用包装器而非packer plugins install。withPlugins产物的插件路径在构建期即确定linkFarm 内容静态可复现这是 Nix 可复现性要求下的推荐做法packer plugins install会在运行时发起网络下载与这一原则相悖。插件名以作用域属性名为准。执行nix eval nixpkgs#packer.plugins --apply builtins.attrNames查询你手上 nixpkgs 版本实际可用的插件不要凭手册旧示例臆测。目标平台受支持。插件构建器目前仅覆盖x86_64-linux、aarch64-linux、aarch64-darwin见 mk-packer-plugin.nix 的 platformSuffix。fetcher 受限于 GitHub。所有已收录插件均通过fetchFromGitHub获取源码并用 Go 模块方式构建插件的source声明在 Packer 模板中需写成github.com/$OWNER/$TYPE形式。版本固定、可审计。每个插件都是独立 derivation版本与哈希固化在各自的 package.nix 中packer.plugins.docker与packer.withPlugins的端到端行为由 tests.withPlugins 守护。6. 延伸阅读手册原始章节doc/packages/packer.section.mdPacker 主包定义含 passthru 与测试pkgs/by-name/pa/packer/package.nixwithPlugins 包装实现pkgs/by-name/pa/packer/with-plugins.nix插件作用域与目录自动收录pkgs/by-name/pa/packer/plugins.nix插件构建器命名/校验和/平台规则pkgs/by-name/pa/packer/extra/mk-packer-plugin.nix已收录插件全集33 个pkgs/by-name/pa/packer/plugins/【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考