很多第一次接触 PXE 网络装机的人都会被一堆名词劝退DHCP、TFTP、BOOTP、pxelinux.0、WIM 引导……听起来像要搭一整套 IDC 基础设施。实际上有了 iVentoy 之后这件事被简化成了“上传一个 ISO、客户端开机、选择镜像、回车”四步操作。如果再叠加上 Docker连 iVentoy 本体的安装和环境依赖都能省掉一台常年开机的 NAS 或者小主机就能变成全公司的装机服务器。这篇内容我会从 PXE 引导链路讲起把 iVentoy 的设计思路拆开然后给出完整的 Docker 部署方案、客户端装机的实际操作过程以及我在生产环境里踩过的一些坑。不论你是刚接触网络装机的小白还是想把手动 U 盘装机的重复劳动干掉的老手都可以照着操作。1. 项目概述与方案选型思路1.1 为什么批量化装机会用到 PXE如果你只需要装一台机器U 盘启动镜像当然是最简单的方式。但一旦机器数量变成五台、十台或者你需要频繁重装测试机、给新到的设备批量初始化系统“插 U 盘装一台、拔下来再插下一台”这种方式就会让人很崩溃。物理操作本身不复杂复杂的是重复劳动和时间成本。PXE 解决的核心问题是让机器在没有任何本地系统的情况下通过网络从服务器获取一个可引导的操作系统。整个流程中客户端机器只需要支持网卡启动基本上所有量产主板都支持服务器端提供一个能够响应网络引导请求的服务即可。传统的 PXE 方案需要配置的东西非常多要有一个 DHCP 服务器来分配 IP 并指定启动文件位置要有一个 TFTP 服务器来下发引导文件还要有一个 HTTP/NFS 服务来分发系统镜像配置文件还要按不同架构分别写好。这一套组合拳下来没有两三个小时很难跑通。1.2 为什么选择 iVentoy 而不是传统网刻工具用过传统网刻工具的人应该都有感觉界面老旧、依赖 Windows 环境、对 UEFI 支持不友好、驱动注入麻烦。iVentoy 把这些痛点基本全解决了。iVentoy 是一个跨平台的网络启动引导工具本质上它内置了 DHCP、TFTP、HTTP 服务并且把这些服务整合在一起通过一个 Web 管理界面就能控制。你不需要自己编辑pxelinux.cfg这类文本配置只需要把 ISO 镜像放进指定目录然后在网页上勾选允许哪个镜像启动客户端开机后就能在启动菜单里看到这个镜像。它对 Windows 和 Linux 的安装场景都有专门优化。比如 Windows 原版 ISO 在传统 PXE 环境下直接启动经常会卡在 WinPE 阶段iVentoy 会通过内置的驱动注入机制绕过这个问题Linux 发行版则基本可以像本地光盘启动一样直接进入安装界面。这一点比很多自家搭建的 PXE 方案要省心得多。1.3 为什么用 Docker 部署而不是原生安装iVentoy 官方提供 Linux 原生安装包直接解压运行iventoy.sh也能跑。但我在实际使用中更推荐 Docker 方式原因有三个。第一是环境隔离。iVentoy 依赖的库和系统版本如果和宿主机冲突排查起来相当麻烦。容器化之后所有依赖都被锁在镜像里只要 Docker 能跑iVentoy 就能跑。第二是迁移方便。原生安装之后如果你想换一台机器部署需要重新解压、停服务、拷贝数据目录。Docker 部署只需要把挂载的数据目录拷走到新机器上重新执行一条docker run命令配置和镜像全回来了。第三是习惯问题。现在很多人的 NAS、软路由、家用小主机都已经跑着 Docker与其再单独维护一个原生服务不如统一纳入容器管理。日志查看、开机自启、资源限制这些能力也都是现成的。2. 核心原理拆解一次 PXE 引导到底发生了什么2.1 PXE 的引导链路要理解 iVentoy 做了什么得先知道 PXE 引导的标准过程。这个过程可以粗略分成三个阶段。第一阶段是 DHCP 发现阶段。客户端开机后网卡固件会向网络发送一个广播请求询问“谁能给我一个 IP 地址并且告诉我启动文件在哪里”。这个请求的格式基于 DHCP 协议但里面包含了 PXE 特定的选项用来探测网络上是否有 PXE 服务可用。第二阶段是 TFTP 下载阶段。当 DHCP 服务器返回了 IP 地址、子网掩码、网关以及启动文件的路径之后客户端会通过 TFTP 协议去下载这个启动文件。传统方案里这个文件通常是pxelinux.0或者 EFI 引导程序grubx64.efi。启动文件本身非常小作用只是作为第一阶段引导把后续的配置文件和内核、initrd 下载到内存里。第三阶段是内核加载阶段。引导程序会读取配置文件再通过 TFTP 或 HTTP 下载真正的内核、initrd 以及根文件系统镜像加载到内存后把控制权交给操作系统。到了这一步PXE 的使命就完成了后面的安装过程就由加载起来的系统自己处理。2.2 iVentoy 在这条链路中扮演什么角色iVentoy 的精妙之处在于它把 PXE 链路中的三个关键服务全部集成到了一个进程里。它自带一个小型 DHCP 服务器能够为客户端分配 IP并告知启动文件位置自带 TFTP 服务用来下发第一阶段的引导程序还自带 HTTP 服务用来快速传输大型 ISO 镜像。相比原生 PXE 需要你自己组合 dnsmasq tftp-hpa nginx 再加一堆配置文件iVentoy 把这些服务的生命周期和数据流都管理好了。你只需要关心两件事镜像放在哪里以及允许哪台客户端启动。另外iVentoy 的引导菜单是动态生成的。传统 PXE 的引导菜单是静态文件新增一个系统镜像需要手动去改配置文件。而 iVentoy 会自动扫描镜像目录把可用的 ISO 列在 Web 界面上同时在客户端启动时通过程序动态生成菜单项。这就是它“开箱即用”的底层逻辑。2.3 传统 PXE 与 iVentoy 的差异对比我整理了一个对比表格方便你直观理解两者的差异。对比项传统 PXE 方案iVentoy服务组件DHCP、TFTP、HTTP 各自独立部署内置整合单进程提供全部服务镜像管理手动编辑引导配置指定路径放入目录Web 界面自动识别Windows 支持需要额外处理 WinPE 驱动和 WIM 加载逻辑内置优化直接选择 ISO 即可多架构支持需要分别配置 BIOS/UEFI 的启动文件自动识别引导模式动态下发对应文件菜单定制手动编辑 menu 文件Web 界面配置所见即所得部署复杂度高涉及多个服务调优低尤其配合 Docker 部署你可能会问iVentoy 是否完全替代传统方案我的看法是对于绝大多数批量装机、系统救援、临时跑 Live 系统的场景iVentoy 是更轻量的选择。只有当你需要高度定制 PXE 菜单、严格管控 DHCP 地址池、或者需要和其它网络服务深度整合时传统方案才更有优势。3. Docker 部署 iVentoy 完整实操3.1 环境准备与镜像选择部署前需要准备一台能跑 Docker 的 Linux 主机。这台主机的要求不高双核 CPU、2GB 内存、20GB 可用磁盘就够了因为真正吃资源的是镜像存储和网络传输。我在实验室用的是虚拟机跑的 Ubuntu Server生产环境里用的是一台群晖 NAS 的 Docker 套件两种方式没有本质区别。iVentoy 官方在 Docker Hub 上提供了镜像名称是iventoy/iventoy。需要注意一点Docker 镜像说起来是一个通用容器但因为 iVentoy 会直接操作网络接口、绑定特权端口容器的运行参数有一定讲究不能随便一条docker run -d就完事。如果你所在的网络拉取 Docker Hub 镜像比较慢建议先在 Docker 配置里加入加速地址或者在部署机上提前把镜像拉取好后续所有步骤都会顺畅很多。3.2 docker run 命令逐参数解析我推荐使用以下命令启动 iVentoy 容器docker run -d --name iventoy --net host --privileged \ -v /data/iventoy/iso:/iventoy/iso \ -v /data/iventoy/data:/iventoy/data \ -e IVENTOY_AUTO_INSTALL1 \ --restart unless-stopped \ iventoy/iventoy:latest每个参数解释一下。--net host是这里最关键的一个参数。iVentoy 需要监听多个端口包括 UDP 67DHCP、UDP 69TFTP、TCP 26000Web 管理端口等。如果使用 Docker 默认的 bridge 网络就需要手动映射一堆端口而且 DHCP 是广播协议在 bridge 网络下容易出现客户端收不到响应的情况。使用 host 网络让容器直接共享宿主机的网络栈最省心也最稳定。--privileged是因为 iVentoy 在运行过程中需要创建虚拟网卡接口用于内部网络通信。不加这个参数容器可能会在初始化时报错或者无法正常工作。-v /data/iventoy/iso:/iventoy/iso将宿主机的镜像目录挂载到容器内。所有 ISO 文件都放到这个目录iVentoy 会自动扫描识别。-v /data/iventoy/data:/iventoy/data用于持久化 iVentoy 的配置数据包括镜像索引、权限设置和日志。以后升级容器时只要这个目录还在配置就不会丢。-e IVENTOY_AUTO_INSTALL1是让容器启动后自动执行安装流程不需要手动进入容器执行脚本。--restart unless-stopped保证宿主机重启后容器自动启动。对于装机服务器来说这个选项很重要不然半夜机房断电重启之后所有客户端网卡启动都会失败人还得手动去拉起服务。启动之后用docker logs -f iventoy看一下输出。如果一切正常应该能看到类似“iVentoy is running, web interface: http://0.0.0.0:26000”的日志。3.3 上传 ISO 镜像与首次启动检查容器起来之后接下来就是把系统镜像放进挂载目录。我一般用scp或者rsync把 ISO 从本地传到服务器上rsync -avP ./Windows_11_23H2.iso rootserver-ip:/data/iventoy/iso/也可以直接在服务器上用wget从官方下载。放好之后不需要重启容器iVentoy 的文件监控功能会在十几秒内自动识别新镜像。打开浏览器访问http://服务器IP:26000进入 Web 管理界面。左侧是镜像列表刚放进来的 ISO 会出现在这里但默认是“禁用”状态。你需要点击镜像旁边的滑块把它启用客户端才能在启动菜单里看到这个镜像。如果镜像列表是空的先检查一下是不是目录挂载路径写错了。可以用docker exec iventoy ls /iventoy/iso看看容器内是否能看到文件。另外注意 iVentoy 只识别根目录下的 ISO 文件子目录里的镜像需要你手动配置扫描路径否则不会被自动发现。4. 快速上手用 iVentoy 给第一台机器装系统4.1 客户端启动前的准备服务器端配置好之后客户端机器的准备工作其实相当少。你只需要做两件事确保网线连接到了和服务器同一台交换机然后在 BIOS 里开启网络启动。不同主板的设置路径不同但关键词都是Network Boot、PXE Boot、UEFI: Built-in LAN之类的选项。新机器大概率默认支持老旧机型可能需要手动把 Network Boot 的优先级调到硬盘之前或者在开机时按 F12 呼出临时启动菜单选择网卡。这里要提醒一个容易踩的坑很多人在实验室里直接把 iVentoy 服务器和客户端都插在同一台家用路由器上结果客户端就是起不来。原因通常是家用路由器自带的 DHCP 服务抢先响应了客户端的请求iVentoy 的 DHCP 还没说话路由器已经把 IP 地址给了出去。这种场景下的解决方案我会在第五部分细说先记住核心原则PXE 网络里要么让 iVentoy 当唯一的 DHCP 服务器要么把 iVentoy 配置成不接管 DHCP 的 HTTP 模式。4.2 Web 界面选择镜像与并发安装当客户端通过网络启动后屏幕会进入 iVentoy 的引导菜单。如果你在 Web 界面上启用了多个镜像这里会列出来用方向键选择回车确认。我实际用的最多的是 Windows 镜像。选择 Windows ISO 后iVentoy 会进入 WinPE 环境并把 ISO 中的安装文件挂载为光驱。整个体验和本地插入光盘安装基本一致。你在 Web 界面上还能看到当前所有客户端的会话列表包括设备名、IP 地址、当前状态。多台机器同时安装时这个列表能帮你确认每台客户端走到哪一步了。有一点需要注意iVentoy 的 Web 界面虽然提供了“客户端限制”和“镜像隐藏”的功能但它并不做严格的权限认证。只要网络能到达这个管理端口任何人都能操作。所以在共用网络环境下建议通过防火墙把 26000 端口限制在受信任的管理网段内。4.3 安装 Windows 与 Linux 的差异Windows 镜像是 iVentoy 重点优化的场景。传统 PXE 启动 Windows 安装程序经常因为 WinPE 缺少网卡驱动或者磁盘控制器驱动而蓝屏。iVentoy 在引导 Windows 镜像时会自动注入一套通用的存储和网络驱动大大提高了成功率。Linux 镜像的处理则更直接。对于 Ubuntu、Debian、CentOS 这类主流发行版iVentoy 会启动到官方的安装器环境接下来就和本地光盘安装没有区别。个别精简版镜像或带特殊内核参数的发行版可能需要手动编辑启动参数但绝大多数情况下默认参数就够了。还有一个实际经验在安装 Linux 时如果客户端机器使用 UEFI 模式系统安装完成后要在安装器中确认引导程序写到哪块磁盘。多硬盘机器如果选错了引导盘重启后就会直接进不了系统。这个问题和 iVentoy 无关但在网络装机场景里被放大了因为通常你会同时给多台机器装系统比较容易看花眼。5. 进阶配置让 iVentoy 更贴合生产环境5.1 已有 DHCP 环境下使用“仅 HTTP 模式”刚才提到的家用路由器 DHCP 冲突问题在真实企业网络里同样存在。网络部门的大机房不可能为了你装个系统就去改 DHCP 全局配置更不可能把 iVentoy 当成唯一 DHCP 服务器。这个时候就要用 iVentoy 的“仅 HTTP 模式”。启用方式是在 Web 界面的选项设置里把 DHCP 模式改成“不接管 DHCPHTTP 模式”。这个模式下iVentoy 不再响应 UDP 67 端口的广播请求只保留 HTTP 服务来传输引导文件和 ISO。但客户端依然需要知道“该去哪里找引导文件”这个问题只能由已有的 DHCP 服务器来回答。标准做法是在 DHCP 服务器上配置两个 PXE 选项next-server指向 iVentoy 服务器 IP和boot-file指向 iVentoy 提供的引导文件路径。iVentoy 文档里会给出不同环境下应该填写的文件名通常在 Linux 环境下是pxelinux.0UEFI 环境下是EFI/BOOT/BOOTX64.EFI。这个方案我在公司网络里验证过。让网络管理员在 DHCP 作用域里加两个选项重启 DHCP 服务后客户端就能正常走到 iVentoy 的引导菜单同时网络里其它设备的 IP 分配完全不受影响。5.2 持久化配置与升级迁移容器化部署最大的好处就是升级和回滚非常干净。升级 iVentoy 时我一般这么做docker pull iventoy/iventoy:latest docker stop iventoy docker rm iventoy docker run -d --name iventoy --net host --privileged \ -v /data/iventoy/iso:/iventoy/iso \ -v /data/iventoy/data:/iventoy/data \ -e IVENTOY_AUTO_INSTALL1 \ --restart unless-stopped \ iventoy/iventoy:latest因为/data/iventoy/data里的配置和索引都保留着所以升级后镜像列表、权限设置这些都不需要重新配置。唯一需要留个心眼的是升级前最好看一眼 release notes有些大版本更新会改变数据目录结构万一不兼容旧容器已经删了你至少可以从备份里恢复数据目录。备份很简单把/data/iventoy整个目录打包即可。镜像文件比较大如果不方便全量备份至少把data目录备份好ISO 文件以后可以重新下载。5.3 多网段与交换机配置提醒如果你管理的网络不止一个 VLANPXE 跨网段引导需要额外处理。DHCP 广播不会穿过三层交换机所以每个需要提供 PXE 服务的网段要么单独跑一个 iVentoy 实例要么在汇聚交换机上配置ip helper-address指向 iVentoy 服务器。配置ip helper-address之后客户端的 DHCP 请求会以单播形式转发到服务器iVentoy 就能跨网段分配 IP 和下发引导信息。但要注意后续的 TFTP 和 HTTP 流量是客户端直接和服务器通信这就要求客户端的路由能到达 iVentoy 服务器同时交换机端口不能隔离这些流量。还有一个小细节部分交换机默认开启了 DHCP Snooping会拦截非信任端口上非法的 DHCP Offer。iVentoy 的 DHCP 响应如果被当作非法流量丢掉客户端永远拿不到 IP。遇到这种问题把 iVentoy 接入的端口设置为 DHCP Snooping 信任端口即可。6. 常见问题速查与避坑指南6.1 客户端无法获取 IP这是出现频率最高的问题。先看客户端在 PXE 启动阶段是卡在“DHCP”还是卡在“Downloading NBP”。卡在 DHCP 阶段说明没有任何 DHCP 服务器响应。用docker logs iventoy查看容器日志确认有没有收到 DHCP 请求。如果容器完全安静多半是网络问题客户端和服务器不在同一二层网络或者中间交换机有 DHCP Snooping。如果日志显示已经分配了 IP 但客户端拿不到则要看是不是有别的 DHCP 服务器抢先响应了。卡在“Downloading NBP”阶段说明 DHCP 已经成功但 TFTP 下载引导文件失败了。这时候检查防火墙是否放行了 UDP 69 端口以及 iVentoy 的引导文件是否和客户端的启动模式匹配。BIOS 启动Legacy和 UEFI 启动用的引导文件路径是不同的iVentoy 会自动判断但如果客户端固件比较老识别可能有偏差。6.2 Windows 安装时蓝屏或驱动报错Windows 原版镜像在 PXE 环境下最常见的错误就是蓝屏常见代码有0x7B存储控制器不可访问和0xC1网络控制器问题。iVentoy 的内置驱动注入机制能解决大多数这类问题但有两个前提一是你使用的是官方原版镜像修改过的精简镜像可能被 iVentoy 的驱动注入流程跳过二是 Windows 版本不能太旧Windows 7 时代的老镜像受支持程度远不如 Windows 10 和 11。如果依然蓝屏可以尝试在 iVentoy 的 Web 界面对该镜像开启“兼容模式”。这个模式会切换驱动注入策略用更保守的方式加载存储驱动容错率更高但启动速度会慢一些。6.3 ISO 镜像无法被识别放进镜像目录后Web 界面迟迟不出现该镜像。先确认文件扩展名是.isoiVentoy 对大小写不敏感但其它格式如.img、.wim默认不会被识别。另外一个隐蔽原因某些网盘下载工具会把 ISO 文件实际保存成二进制流文件只是显示名带着 .iso文件头根本不是光盘镜像。在 Linux 终端用file xxx.iso检查一下真实文件类型如果不是 “ISO 9660” 或 “DOS/MBR boot sector”重新下载或用压缩包解压出真正的镜像即可。6.4 表格式速查症状排查方向解决思路客户端卡在 DHCP网络隔离、DHCP Snooping、日志检查 VLAN 结构与防火墙规则引导文件下载失败TFTP 端口被拦、模式不匹配放行 UDP 69确认 BIOS/UEFI 选择Windows 蓝屏镜像非原版、驱动不兼容使用原版镜像开启兼容安装模式ISO 不显示文件类型异常、目录错误确认真实格式检查挂载路径Web 界面无法访问端口未放行放行 TCP 26000 管理端口7. 从实际使用中总结的几点习惯最后分享几个我在长期使用过程中沉淀下来的小习惯不是文档里会写的内容但确实能提高效率。我习惯把 iVentoy 服务器配一个静态 IP并且把 DHCP 地址池范围刻意避开服务器地址。原因很简单如果 iVentoy 自身是 DHCP 服务器它给自己分配 IP 的逻辑有时候会让你搞不清哪个地址是它的管理地址。手工指定静态 IPWeb 界面和客户端访问的地址永远不会变。镜像目录我会按日期和版本建子目录但 iVentoy 默认只扫描根目录。为了兼顾整理和自动识别我通常只把当前批次要用的 ISO 放到根目录旧的镜像归档到子目录里需要时候再复制回来。这样既不会污染引导菜单又不会被一堆旧版本镜像干扰判断。日志这事也得提一句。Docker 方式部署后容器日志默认会被 Docker 接管但长期运行后日志文件可能会膨胀。我在 Compose 文件里一般会给容器加上日志轮转配置logging: driver: json-file options: max-size: 10m max-file: 3这样即使 iVentoy 内部打印的调试信息频繁宿主机磁盘也不会被日志撑爆。还有关于安全的一个提醒。iVentoy 在公网环境或不受信任网络中使用时一定要限制网络访问范围。它本身不是一个高安全级别的应用没有复杂的认证体系端口一旦暴露别人不仅能看到你的镜像列表理论上还能操作引导配置。装系统工具而已别把它变成网络入口的漏洞。对我来说Docker 部署 iVentoy 最大的价值不在于省掉多少手工操作而在于它把“网络装机”这件原本基础设施味很重的事情变成了一个可以随取随用的服务。想用了一条命令拉起来不想用了容器一停宿主机干干净净。这种“用完即走、数据外置”的体验恰好是容器化最舒服的使用方式。如果你手头正好有一堆机器等着批量装系统这个方案值得一试。
