用Docker部署iVentoy实现PXE网络批量装机实战-平芜编程栈

装系统的活儿，干过的人都懂：单台电脑用 U 盘慢慢磨没问题，可一旦面对几十台甚至上百台机器，逐个插 U 盘、按 F12、选启动项、再等镜像拷贝，心态很容易崩。我第一次被逼着搞 PXE 网络装机，是因为新办公室一下子到了四十多台整机，第二天就要统一交付 Windows 和 Ubuntu 双系统环境。手头 U 盘不是容量不够就是引导坏了，后来一跺脚，直接上 PXE。传统 PXE 方案配置链路长，DHCP、TFTP、HTTP、引导菜单一个个搭，光是排错就花了一个下午。直到我遇到 iVentoy，配合 Docker 部署，不到十分钟就把一个完整的 PXE 网络装机平台拉起来了。这篇文章就是一次完整的实战记录，从原理、部署、配置到踩坑排查，一次性讲清楚，给正准备搞批量装机的运维同学一个可以直接抄作业的参考。

1. iVentoy 是什么？先把它和 Ventoy、传统 PXE 的关系捋清楚

1.1 从 Ventoy 到 iVentoy：一个本地 U 盘工具的网络化进化

Ventoy 在系统维护圈子里的知名度相当高，很多人兜里都揣着一个装好 Ventoy 的 U 盘，日常装系统、进 PE 都靠它。Ventoy 的思路很巧妙：把 U 盘格式化成专用格式后，你只要把 ISO 镜像文件直接复制进去，开机就会自动弹出一个引导菜单，选哪个镜像就启动哪个，完全不用反复烧录。

iVentoy 就是 Ventoy 团队在同一个思路上做的网络版。核心逻辑没变：镜像文件直接存放在服务器目录里，但把“U 盘”换成了“局域网”，把“本机引导”换成了“PXE 网络引导”。客户端电脑开机后从网卡启动，通过网络获取引导菜单，选定要安装的 ISO，再由服务器通过 HTTP 协议把镜像内容传送过去完成启动和安装。

这个设计最讨喜的地方在于：它没有试图做一个“全功能集成安装系统”，而是老老实实把“镜像存放”和“网络引导”这两件事做好。你不需要关心 PXE 协议栈怎么实现，不需要手动生成引导配置文件，只要把 ISO 往目录里一放，剩下的事情交给 iVentoy 去处理。无论是 Windows、Ubuntu、Debian、Rocky Linux，还是各种 PE 维护盘、LiveCD，只要能通过 ISO 启动，就能通过它网络引导。

1.2 PXE 网络装机的基本链路：为什么传统方案又臭又长

要说清楚 iVentoy 的价值，得先搞清楚传统 PXE 引导到底做了哪些事。PXE 是 Intel 定义的网络启动协议，整个流程可以拆成四步：

第一步，客户端开机，网卡在局域网内发一个 DHCP 广播，申请 IP 地址。普通家用路由器只会返回 IP、网关和 DNS，但 PXE 场景下，DHCP 服务器还必须额外返回两个关键信息：下一跳服务器地址（也就是 next-server，通常是 TFTP 服务器）和需要下载的引导文件名。

第二步，客户端拿到这些信息后，通过 TFTP 协议去下载引导文件。TFTP 是一个非常古老且简单的协议，没有认证、速度也慢，但优点是可靠，这个阶段传输的文件通常只有几百 KB，慢一点也感觉不出来。

第三步，引导文件被加载后，会继续通过网络读取一个菜单配置文件，把可引导的镜像列表展示出来。用户选择某个镜像后，引导程序把内核和 initrd 加载进内存。

第四步，内核起来后，安装程序需要继续从服务器读取 ISO 内容，这里通常用到 HTTP、NFS 或 iSCSI 协议。

传统环境下搭这么一套，意味着你要同时维护 DHCP 服务、TFTP 服务、HTTP 服务，还要处理不同的引导文件格式、UEFI 和 Legacy 的差异、菜单语法规则。任何一个环节配错，客户端启动就会像断了线的风筝，什么提示都不给。iVentoy 做的事情就是把这四步全部接管：内置 DHCP 分配功能，内置 TFTP 服务，内置 HTTP 数据服务，引导菜单直接生成，你只需要在网页上勾选哪个镜像可用。

1.3 iVentoy 的适用场景与边界

根据我自己的使用体感，下面这几类场景特别适合 iVentoy。

第一类是新电脑批量初始化。公司进了一批机器要统一装系统，用 PXE 并发安装比一个 U 盘轮转快太多了，安装速度主要受限于网络和磁盘，人工干预基本为零。第二类是机房和实验室的日常重装。学生上课折腾坏了系统，管理员随时重装，一台机器从开机到进入系统安装界面约十几分钟，人还不累。第三类是测试环境快速交付。需要临时验证某个 Linux 发行版、启动一个 WinPE，把 ISO 丢进数据目录，即时可用。

边界也很清晰。iVentoy 是局域网工具，跨 VLAN 使用需要配置 DHCP Relay，普通交换机做不到开箱即用。它只负责把 ISO 引导起来，不负责驱动注入、自动应答、软件分发这些装完系统之后的事情。另外，如果局域网里已有严格的 DHCP 服务，直接启动它的内置 DHCP 会引发冲突，这个我在后面专门讲。

2. 为什么用 Docker 来跑 iVentoy，而不直接跑二进制

2.1 一条命令拉起服务，升级和迁移都省心

iVentoy 官方其实提供了 Linux 二进制包，解压后修改配置就能直接运行。但我还是推荐用 Docker，理由很实际。

一是依赖环境干净。iVentoy 虽然不依赖太多系统库，但你保不齐要把它跑在 Ubuntu、CentOS、Debian 或者是 NAS 的容器环境里，系统版本一换，兼容性问题就可能冒出来。Docker 镜像把运行环境固化住了，同一份镜像在任何能跑 Docker 的机器上行为一致。

二是升级和回滚方便。裸装方式升级 iVentoy，需要先停止服务、备份数据、替换二进制、再启动，操作繁琐且容易出错。用 Docker 升级就是改一下镜像 tag，或者直接复用原来的端口和数据目录，启动一个新容器，几分钟搞定。万一新版本有坑，还能迅速换回旧镜像。

三是资源控制和日志聚合。Docker 自带docker logs命令，看实时日志很顺手。还可以通过--memory、--cpus限制容器资源，防止在 NAS 那种小设备上把 CPU 吃满。对于追求省心的运维选手，这些都是实打实的加分项。

2.2 host 网络模式是 PXE 能工作的核心前提

这里必须重点强调网络模式。我第一次部署时想当然写了标准的-p 26000:26000 -p 69:69/udp -p 67:67/udp端口映射，Web 管理页面确实能打开，但客户端从网卡引导时始终卡在 DHCP 阶段，日志里连一条请求都看不到。排查了很久才发现，问题出在 Docker 默认的 bridge 网络模式上。

PXE 的早期阶段依赖广播消息，客户端发送的 DHCP 请求是发到整个网段的。在 bridge 网络模式下，容器处于一个隔离的 NAT 子网里，广播包不会原样转发到物理局域网，单纯映射 UDP 端口也无法满足 DHCP 协议的行为要求。iVentoy 必须直接监听宿主机物理网卡，才能收到客户端的广播、正确回应 DHCP Offer。

所以部署 iVentoy 时，容器网络模式建议直接使用host。host 模式下容器和宿主机共享网络栈，没有端口映射的问题，DHCP、TFTP、HTTP 全都走物理网卡，行为和裸装程序完全一致。这个教训是我整个部署过程中踩过最大的坑，写出来就是希望大家别再走一遍。

2.3 数据目录规划：镜像、配置、日志要分清楚

Docker 部署有状态服务，数据卷规划一定要提前想明白。iVentoy 容器内有一个/data目录，里面存放镜像、配置和日志。我的做法是在宿主机建目录/opt/iventoy/data，然后用-v挂载进去，让所有数据落在宿主机上。

挂载时有个性能细节需要注意：iVentoy 的 Web 界面同步镜像、多个客户端并发读取 ISO，IO 压力都在这个数据目录上。如果条件允许，尽量放在 SSD 上。我最早把 ISO 放在机械硬盘上，同时让 10 台机器拉同一个 Windows 镜像，机械硬盘随机读取能力直接顶不住，每台机器的下载速度都掉到 20MB/s 左右。换成 SSD 之后，同时 20 台机器并发，千兆网卡下每台基本都能稳定跑到 80MB/s 以上。

目录结构上，我不建议在数据目录里嵌套太深的层级。iVentoy 会递归扫描镜像目录，但层级太深在 Web 界面里显示路径太长，找起来费力。我的习惯是按系统类型分一层子目录，比如Windows/、Linux/、PE/，每个子目录里直接放对应 ISO 文件，简洁明了。

3. 手把手部署 iVentoy：从拉取镜像到第一台机器被网络引导

3.1 部署前要确认的环境条件

开始操作之前，先确认三件事。

一是 Docker 服务正常。执行docker version分别查看客户端和服务器版本，确认 Docker daemon 已经启动。如果之前安装过旧版 Docker，建议提前升级，新的镜像层特性对老版本兼容性不太好。

二是给宿主机规划一个固定 IP。iVentoy 服务器必须有一个稳定的局域网地址，最好在路由器或 DHCP 服务器里做静态绑定。我这里用192.168.50.100作为示例，实际部署时换成你自己环境里的地址。

三是创建数据目录。执行mkdir -p /opt/iventoy/data，这个目录后面会挂载进容器。如果你有一块独立数据盘，也建议挂载到这个路径，保证 ISO 读取和系统盘 IO 互不干扰。

3.2 docker run 命令逐项拆解

环境准备妥当后，我直接运行下面的命令启动容器：

docker run -d \ --name iventoy \ --restart unless-stopped \ --net host \ -v /opt/iventoy/data:/data \ ventoy/iventoy:latest

逐项解释一下：

-d：后台运行，日志交给 Docker 管理。
--name iventoy：给容器起名，后续docker logs iventoy、docker restart iventoy都靠这个名字。
--restart unless-stopped：容器异常退出或宿主机重启后自动拉起，适合做长期服务。
--net host：host 网络模式，PXE 广播和 DHCP 正常工作的前提，原因前面说过。
-v /opt/iventoy/data:/data：数据卷挂载，镜像和配置持久化到宿主机。
ventoy/iventoy:latest：官方镜像。这里有个细节，镜像名和版本 tag 要以你拉取时的 Docker Hub 页面说明为准，不同时期官方可能调整仓库地址，生产环境建议指定明确版本号，不要长期追 latest。

启动后执行docker ps，看到容器状态是 Up 就说明服务起来了。然后在浏览器打开http://192.168.50.100:26000，看到 iVentoy 的 Web 管理界面即部署成功。

如果你习惯用 Docker Compose 管理服务，也可以写一份docker-compose.yml：

services: iventoy: image: ventoy/iventoy:latest container_name: iventoy restart: unless-stopped network_mode: host volumes: - /opt/iventoy/data:/data

在该文件所在目录执行docker compose up -d，效果和上面的docker run完全一致。Compose 的好处是配置沉淀成文件，换服务器时直接备份这个 YAML 和数据目录，就能完整复现整套环境。

3.3 添加 ISO 镜像并完成首次 PXE 启动

服务跑起来之后，第一件事就是把 ISO 镜像放进去。两种方式任选：一是直接把 ISO 文件复制到/opt/iventoy/data/iso目录，二是登录 Web 界面，在镜像管理页上传。大文件我更喜欢用 scp 或 sftp 直接拷入目录，上传过程更稳定，不会因为浏览器页面超时导致传输中断。

放置完成后，回到 Web 界面点击“同步”，iVentoy 会扫描 iso 目录，识别出新出现的镜像。同步完成后，镜像列表里就能看到刚才放入的 ISO，默认是启用状态。

接下来做一次完整的 PXE 启动测试。我找了一台测试电脑，开机按快捷键进启动菜单，选择从网卡启动（通常显示为 PXE 或 IPv4 Network Boot 字样）。客户端随即发送 DHCP 广播，iVentoy 响应分配一个 IP 地址，然后自动加载引导文件。此时屏幕上会出现 iVentoy 的引导菜单，列出所有可用的 ISO 镜像。我用方向键选中一个 Ubuntu 的 Live ISO，回车，大约两分钟后看到 Ubuntu 桌面加载出来，首次网络引导成功。

从拆开新机器包装到进入安装界面，全程没有插过 U 盘，也没有在每台电脑前蹲守，这种感觉确实不一样。

4. 界面、配置与日常运营细节

4.1 Web 管理界面：镜像、客户机、日志三大块怎么用

iVentoy 的 Web 管理界面做得简洁，并没有塞满花哨功能，核心就三块。

镜像管理区用来维护可用的 ISO 列表，可以对每个镜像做启用、停用、备注、排序操作。批量装机的场景里，我经常把不常用的 PE、LiveCD 临时停用，避免安装人员误选。

客户机管理区是最有存在感的一块。这里能看到当前所有由 iVentoy 引导的客户端，包括它们的 IP、MAC 地址、当前引导状态和实时传输速度。批量装机时，我会在这里盯一会儿，确认每台机器都进入了安装阶段而不是卡在引导环节。如果某台机器传输速度为 0 且持续很久，就要考虑是网线问题还是镜像问题。

日志区记录每一次引导请求的详细过程，包含时间戳、客户端 MAC、请求的镜像、错误码等信息。这是排查问题的一手线索，后面讲问题处理时还会提到。需要注意的是，容器默认时区可能是 UTC，日志时间比北京时间慢 8 小时，建议启动容器时加上-e TZ=Asia/Shanghai环境变量校准时间。

4.2 配置文件 config.json 里的关键项

iVentoy 的配置信息以 JSON 格式存放在数据目录下，容器启动时读取。我的使用习惯是，能通过界面改的设置不在配置文件里动，只有需要批量修改或者做脚本化部署时，才会直接编辑配置文件。

几个关键配置项，按我的理解说一下作用。

DHCP 相关的配置项决定内置 DHCP 服务的行为，包括是否启用、分配的地址池范围、子网掩码、默认网关等。如果 iVentoy 跑在一个独立网段，默认配置基本够用。如果跑在已有 DHCP 的办公网，需要关闭内置 DHCP 或者使用共存方案，后面详细说。

Web 访问验证相关的配置项，可以给管理界面添加账号密码保护。在人员比较杂的环境里强烈建议开启，避免有人恶作剧把可用镜像全部停用，影响正常装机任务。

日志级别相关的配置项，可以切换日志的详细程度。排错时调到最详细，日常建议保持默认，避免日志文件增长太快。

编辑配置文件前先备份一份，改完后重启容器，因为服务运行中可能会把内存里的配置覆盖回去。我习惯用docker cp先把容器内的配置文件复制出来备份一份，改坏了随时恢复。

4.3 和现有 DHCP 共存：一个必须提前想清楚的架构决策

这是整个部署中最容易引发生产事故的点，单独拿出来说。

iVentoy 默认启用内置 DHCP 服务，如果你把它部署在一个已有 DHCP 服务器的局域网里，会出现两台 DHCP 服务抢应答的情况。客户端可能先收到路由器发的响应，也可能先收到 iVentoy 发的响应，IP 分配混乱，甚至会波及整个网络里的正常设备。我亲自踩过一次：在办公网里测试 iVentoy，忘记关闭内置 DHCP，结果整个楼层的设备都收到了 iVentoy 发来的 DHCP Offer，网关信息还是我随手填的，差点把办公网 IP 地址池搞乱。

两种解决方案比较靠谱。

第一种是使用独立网段。iVentoy 所在的交换机只连接需要 PXE 装机的客户端，与办公网物理隔离，这样内置 DHCP 就不会影响到其他设备。这是我的首选方案，尤其是在长期使用的机房环境里，一次规划好，后面省心。

第二种是关闭内置 DHCP，借助 DHCP Relay 转发 PXE 请求。现有 DHCP 服务器负责分配 IP，同时配置 next-server 参数指向 iVentoy 服务器地址，以及 boot-file 参数指向引导文件名。iVentoy 只负责提供引导文件和数据传输服务。这个方案需要交换机支持 DHCP Relay 配置，对网络管理员有一定要求，小团队不一定能搞定。

4.4 性能与存储：多客户端并发时如何不拖后腿

并发安装时，瓶颈大多数时候在磁盘 IO，而不是网络带宽。ISO 文件本身是大文件顺序读取，如果同时有十几台机器读取同一个镜像，磁盘就要同时响应多个读取请求，机械硬盘在这种随机并发场景下表现很差。这也是我前面反复强调数据目录放到 SSD 的原因。

网络方面，千兆交换机同时引导二十台机器，每台机器分到的带宽仍然够用，系统安装的主要时间消耗在写盘阶段，下载速度再快也弥补不了机械硬盘的写入时间。如果机器数量特别多，可以用万兆交换机，或者把镜像拆分到多个数据目录、起多个 iVentoy 实例分散压力。不过对绝大多数场景来说，一个实例加 SSD 镜像存储已经完全够用。

还有一个小细节：镜像在数据目录里不要直接放在根目录与配置文件混在一起，我习惯建一个专门的iso子目录，这样在备份数据目录时也很清楚哪些是需要保留的镜像文件。

5. 常见问题排查与实用避坑清单

5.1 客户端拿不到 IP，或者一直卡在 DHCP

最典型的故障现象是客户端开机后停在 DHCP 阶段，屏幕显示 “No boot filename received” 或者干脆没有反应。我的排查流程是固定的。

先确认容器状态，执行docker ps，看 iVentoy 是否在运行。再看 Web 界面日志里有没有出现客户端的请求记录。如果日志里完全空白，说明客户端的 DHCP 请求没有到达 iVentoy 容器，重点检查两件事：容器网络模式是不是 host，以及宿主机防火墙有没有放行 UDP 67 和 UDP 69 端口。

我在 CentOS 上遇到过一次，防火墙默认放行了 TCP 流量，但 UDP 67、69 没有放行，客户端一直卡在 DHCP。用firewall-cmd --add-service=dhcp --add-service=tftp按服务方式加放行规则，问题立刻解决。另外，宿主机如果有多个网卡，还要留意 iVentoy 是否绑定了客户端所在的物理网卡，虚拟网卡上的广播包通常不会转发到物理局域网。

5.2 镜像能引导，但进入安装界面报错或退出

有些 ISO 能正常出现 iVentoy 菜单，但选择后进入安装程序就报错。这种情况大多不是 iVentoy 的问题，而是镜像本身对网络引导方式的兼容性差异。

Windows 系统强烈建议用官方原版镜像，网上各种精简优化的第三方镜像在 PXE 环境下的出错概率明显更高。Linux 发行版里，Ubuntu、Debian 官方镜像兼容性最好，CentOS Stream、Rocky Linux 也基本没有坑，但某些基于 Ubuntu 二次封装的发行版，改了内核参数或者裁剪了驱动，可能在挂载 HTTP 安装介质时失败。排查时先用一个纯净的官方镜像测试，基本能确认是不是镜像自身的兼容性问题。

另一点和 iVentoy 无关，但实际装机流程里非常影响体验：品牌机和某些工作站默认把硬盘模式设置成 RAID，Windows 安装时会提示“找不到硬盘”。需要在 BIOS 里把硬盘模式改成 AHCI，或者提前在 Windows 安装镜像里注入对应 RAID 驱动。

5.3 UEFI 与 Secure Boot 的兼容处理

现在的机器基本都是 UEFI 引导，默认还开着 Secure Boot。iVentoy 对 UEFI 引导有适配，但个别主板的安全策略比较严格，可能会在加载引导文件时被拦截，提示安全策略校验失败。

最直接的解决办法是进 BIOS 关闭 Secure Boot。对于批量装机环境来说，关闭 Secure Boot 并不影响系统安装，反而能减少大量兼容性问题。如果项目有合规要求必须保留 Secure Boot，可以参考 iVentoy 官方文档里关于证书信任的说明，把引导文件加入主板信任列表，但这个操作在批量部署时效率太低，如果不是硬性要求，不推荐优先考虑。

还需要注意 UEFI 和 Legacy 引导模式切换的问题。一台机器如果之前用 Legacy 模式装过 Windows，后来改成 UEFI 模式通过网络引导装新系统，很可能因为磁盘分区表格式不匹配导致安装失败。建议在交付方案里统一规划引导模式，新机器全部 UEFI，老机器保持 Legacy，不要在同一个机房混着改。

5.4 容器日志与数据卷权限的几个坑

排查 iVentoy 问题，第一步永远是docker logs iventoy。常见做法是先用docker logs --tail 200 iventoy看最后 200 行日志，如果没有线索，再开一个终端执行docker logs -f iventoy实时观察，同时让一台测试客户端发起引导，看日志里有没有新的连接记录。

容器层面还常遇到数据卷权限问题。把数据目录挂载进容器后，如果 iVentoy 无法创建日志文件或者同步镜像列表时报 Permission denied，容器可能反复重启。这种问题通常是宿主目录的属主和容器内运行用户的 UID 不匹配导致的。解决办法是查看容器文档里指定的用户 UID，用chown调整宿主目录属主，不要偷懒直接 chmod 777，否则后续目录里文件越来越多，权限问题会越来越难收拾。

还有一个经常被忽略的坑：iVentoy 容器默认时区是 UTC，日志和 Web 界面显示的时间比北京时间慢 8 小时，排查问题时时间对不上很别扭。启动容器时加上-e TZ=Asia/Shanghai，把时区校准到本地时间。

5.5 用得最多的排查命令速查表

我把实际运维中反复使用的查验命令整理成一张表，方便直接对照。

命令	用途
`docker ps`	确认容器状态是否正常
`docker logs -f iventoy`	实时查看 iVentoy 运行日志
`docker restart iventoy`	修改配置后重启容器
`docker exec -it iventoy ls /data/iso`	进入容器查看镜像目录
`firewall-cmd --list-all`	确认宿主机防火墙放行情况
`ss -ulpn	grep 67`
`ss -tlpn	grep 26000`