机房二十台机器等着装系统U盘插拔到怀疑人生的时候谁都会想要一个能把系统一次性推到所有机器上的方案。iVentoy 干的就是这件事——它是 Ventoy 的网络版不需要量产 U盘不需要刻录光盘把 ISO 镜像放进共享目录客户端从网卡启动就能进入安装界面。配合 Docker 部署整个 PXE 网络装机平台从零到能用大约只需要十分钟。这篇文章我会把整套方案的选型思路、部署步骤、镜像管理和常见坑一次讲清楚不管你是机房运维、公司网管还是家里有台 NAS 想折腾的玩家按着做基本都能跑起来。1. 别急着装系统iVentoy 解决的是批量装机的头疼事1.1 传统网络装机的痛点在哪几年前我还在用最原始的方式维护测试机——做启动 U盘、量产、每台机器插拔一次、按 F12 选启动项、等安装进度条。机器少还好说超过十台就开始崩溃更别提有些机器前面板 USB 接口供电不稳U盘读到一半直接丢失然后又得从头再来。后来尝试过传统 PXE 方案纯手工配置一套环境非常痛苦DHCP 要配、TFTP 要配、NFS 或 HTTP 要搭、引导文件要自己找PXE 的 menu 文件写错了客户端启动直接黑屏排查半天也不知道是 TFTP 没起来还是路径不对。对偶尔批量装一次机的人来说维护这套环境的成本比装系统本身还高。iVentoy 的思路完全不一样。它把 PXE 的三个基础服务——地址分配、启动文件传输、镜像数据传输——全部打包成了开箱即用的服务。你不需要理解 tftp root 该怎么设不需要手写 pxelinux.cfg只要把 ISO 文件复制到镜像目录里客户端开机选择网络启动就能看到版本选择列表。第一次用的时候确实有点惊艳原来网络装机可以简单到这种程度。1.2 为什么选择用 Docker 部署部署市面上也有独立安装 iVentoy 的方式但我更推荐 Docker 部署原因很实在首先是依赖隔离。iVentoy 运行涉及 DHCP、TFTP、HTTP 多个服务直接装在物理机上容易和现有的 Nginx、Bind、路由器管理软件抢端口出了问题很难排查。用 Docker 容器隔离后服务本身是独立的不想要了就删掉容器不会留下任何垃圾依赖。其次是跨平台统一体验。它可以跑在普通 Linux 服务器上也可以跑在飞牛 NAS、PVE 虚拟机、云主机等任意能运行 Docker 的环境里。我自己的用法是在 PVE 里挂一台轻量虚拟机Docker 直接装在虚拟机上整个装机系统不占用任何物理机资源。以后迁移到别的机器把镜像目录和 compose 文件拷过去就能恢复。还有一条容易被忽略的优势镜像更新方便。iVentoy 出新的版本直接重新拉镜像、重建容器就行不像物理安装还要卸载旧版本、担心配置文件残留。1.3 这套方案适合谁来用一句话总结适合所有需要频繁重装操作系统、批量部署机器、或者想摆脱 U盘依赖的人。典型的使用者包括机房运维、学校机房管理员、企业 IT 支持以及喜欢折腾 NAS 和虚拟化的玩家。家里有超过两台电脑想快速试装各个 Linux 发行版也同样适用。与其说是“专业工具”不如说是一个让内网装机这件事变轻松的基建设施。2. Docker 部署前的准备工作硬件、网络和镜像资源2.1 硬件要求其实比想象中低跑 iVentoy 的机器不需要很强普通双核 CPU、2GB 内存就足够支撑几十台机器并发启动。真正的瓶颈在网络和存储镜像文件是几百 MB 到几 GB 的 ISO如果所有客户端同时启动百兆网口的带宽会很紧张建议至少千兆局域网有条件上万兆更好。存储方面尽量用 SSD 或高速 NAS 卷因为镜像读取速度直接决定安装程序加载的快慢。还有一点需要注意在 PVE 或虚拟机里跑 Docker 时建议给容器挂载一个独立的磁盘而不是用系统盘。原因很简单镜像目录会越来越大Windows 镜像加 Linux 镜像动辄几十 GB放在系统盘里容易把根分区写满系统出各种诡异问题。我一般会分一个新卷专门放 ISO挂载到容器里的镜像目录。2.2 网络环境的整体规划iVentoy 的 PXE 启动流程大致是这样客户端开机网卡向局域网发出 DHCP 请求iVentoy 响应请求、分配 IP同时告诉客户端“启动文件在 TFTP 服务器上去拿”客户端拿到引导文件后启动进入 iVentoy 的菜单界面用户选择要安装的 ISO客户端再从 HTTP 服务拉取完整镜像开始安装。这条链路决定了网络规划的核心前提客户端必须能访问到 iVentoy 的 IP并且没有被防火墙拦截 UDP 67、UDP 69、TCP 16000 等端口。如果 iVentoy 容器和客户端不在同一个网段跨网段 PXE 需要额外配置 DHCP Relay会比较麻烦所以最省心的做法是部署在客户端所在的二层局域网内。我自己就是这样在机房单独划了一个装机组机器全都接在同一台交换机下整个流程零额外配置。2.3 镜像资源的准备思路镜像建议直接去官方渠道下载原版 ISOWindows 用微软官方工具生成镜像Linux 发行版去官网或镜像站下载。这里有个小建议尽量下载包含 UEFI 启动支持的标准 ISO老一些的精简版 ISO 只支持 Legacy BIOS遇到新机器会非常尴尬。如果你是做无人值守批量安装还需要提前准备自动应答文件。Windows 对应 autounattend.xmlCentOS/RHEL 对应 kickstart 文件Ubuntu/Debian 对应 preseed 文件。这部分内容我会在第 4 章详细讲准备阶段你只需要知道这个文件将来会放在镜像目录里的特定位置或者作为变量传给 iVentoy。3. 核心章节Docker 部署 iVentoy 的完整步骤3.1 从 Docker Hub 拉取镜像先说明一点iVentoy 官方在 Docker Hub 上并没有唯一的“官方认证”仓库社区里存在多个维护者发布的镜像。我的做法是在 Docker Hub 搜索iventoy选择 star 数量较高、更新时间相对较新的镜像然后进详情页看一下文档确认镜像使用的数据目录、端口配置是否和维护者的说明一致。docker search iventoy --limit 10搜索结果出来之后关注 IMAGE NAME 列。注意看 tags 列表尽量选择 latest 或者带明确版本号的 tag避免选择长期不更新的镜像。第一次部署我建议用 latest 跑通环境之后再根据实际需求固定版本方便后续回滚。3.2 关键启动参数解析网络模式必须用 host这是整个部署过程中最容易踩坑的地方我单独拿出来讲。Docker 默认的 bridge 网络模式会给容器分配一个内部 IP外面访问不到更麻烦的是 DHCP 和 TFTP 服务依赖广播和固定端口bridge 模式下端口映射的处理会比较绕。最直接的解法是使用 host 网络模式。docker run -d --name iventoy \ --network host \ --restartalways \ -v /data/iventoy:/iventoy \ ghcr.io/iventoy/iventoy:latest使用--network host后容器直接共享宿主机的网络栈DHCP 监听 67 端口、TFTP 监听 69 端口、HTTP 服务监听 16000 系列端口这些都不需要额外做端口映射。这也就意味着宿主机的这些端口不能被其他程序占用部署前可以用ss -lunp | grep -E :(67|69)检查一下。如果你用的是飞牛 NAS 这类 Docker 管理面板面板上通常会提供“host 网络”选项直接在创建容器时选择即可不需要手动指定端口映射。如果面板强制要求端口映射说明它默认使用 bridge 模式这种情况下 PXE 功能大概率不正常需要去面板的网络/高级设置里切换网络模式。注意使用 host 网络模式后容器内的服务直接暴露在局域网中请确保你的局域网环境是可信的。不要在公网或不受信网络环境直接运行这套服务。3.3 目录挂载与权限处理数据目录挂载是整个部署中另一个关键点iVentoy 的 ISO 镜像目录、配置文件、日志都在这个目录里。上面的命令把宿主机的/data/iventoy挂载到容器的/iventoy实际路径可以根据你的存储规划调整比如在飞牛 NAS 上可以挂到/vol1/docker/iventoy。挂载后容易忽略的是目录权限。iVentoy 容器内进程通常以非 root 用户运行如果目录权限不对容器启动后无法写入日志和配置文件表现就是 Web 管理界面能打开但 ISO 列表始终为空或者在日志里报Permission denied。我的习惯是创建目录后直接设置宽松权限mkdir -p /data/iventoy/iso chmod -R 777 /data/iventoy这里用 777 纯粹是图省事生产环境更规范的做法是查出容器内用户 UID然后用chown -R UID:GID /data/iventoy精确授权。如果你用的是 PVE 的 LXC 容器跑 Docker还要确认容器和宿主机之间的映射关系不然权限问题会很折磨人。3.4 docker-compose 方式构建更清晰的配置管理命令行方式适合快速验证但真正长期使用我还是推荐 docker-compose。它把所有参数固化在配置文件里不会出现“当时启动命令写了什么来着”的尴尬也方便以后迁移。my-docker-compose.yml 至少需要包含以下几个配置version: 3 services: iventoy: image: ghcr.io/iventoy/iventoy:latest container_name: iventoy restart: always network_mode: host volumes: - /data/iventoy:/iventoy启动命令很简单docker compose up -d提示上面示例中镜像地址仅为示意。由于 Docker Hub 和 GHCR 上的仓库可能会有变动请以你在仓库搜索到的实际镜像名称为准避免因为镜像名不真实导致拉取失败。镜像拉取失败的情况我这里提一下如果你发现 docker pull 速度慢到没法用或者镜像仓库间歇性连接失败可以在 Docker daemon 配置文件里配置 registry mirror。这是常规的镜像源配置操作能有效改善拉取体验。配置完记得重启 Docker 服务再重新拉取。3.5 初始化验证确认服务真正起来了容器启动完成后不要急着拿客户机测试先做三个快速检查。第一看容器日志。docker logs iventoy正常启动会在日志里打印 iVentoy 的版本号、初始化 IP 地址、Web 管理界面的访问地址。这里有一个常见误会很多教程会告诉你“iVentoy 管理地址是 192.168.100.99”其实这个地址是 iVentoy 在没有现成 DHCP 时给自己分配的内置地址。如果你局域网里已经有路由器在分配 IPiVentoy 会自动获取网段 IP日志里打印的才是你真正要访问的地址。第二确认端口监听。ss -lunp | grep -E :(67|69)看到 UDP 67 和 69 处于 LISTEN 状态说明 DHCP 和 TFTP 服务已经起来了。HTTP 服务可以检查 16000 端口也可以用浏览器直接访问管理地址验证。第三打开 Web 管理界面。浏览器访问日志中打印的 IP 和端口正常会看到 iVentoy 的管理页面里面包括版本信息、客户端列表、镜像列表。到这个页面能够打开说明服务核心已经正常可以进行镜像上线了。4. 让 PXE 网络装机真正好用镜像管理与自动应答4.1 镜像管理目录的使用方法iVentoy 的镜像管理比想象中还要简单把下载好的 ISO 文件复制到挂载目录下的iso子目录回到 Web 管理界面刷新镜像就会出现在列表里。不需要重启容器不需要执行任何命令。目录结构可以参考这样/data/iventoy/ ├── iso/ │ ├── Windows_11_23H2.iso │ ├── Windows_Server_2022.iso │ ├── Ubuntu_22.04_Server.iso │ └── RockyLinux_9.iso ├── log/ └── config/这里有两个细节要提醒。一是不建议把 ISO 再放进 iso 目录的子文件夹里虽然 iVentoy 理论上支持递归扫描但实测下来子目录层级太深可能出现列表加载慢或者镜像漏扫的情况不如所有 ISO 平铺放在同一层用文件名区分版本最省心。二是镜像文件不要用中文名和空格PXE 启动链路里的引导程序对非 ASCII 字符支持并不好文件名里出现中文可能导致客户端加载镜像时路径解析失败。4.2 自动应答与变量功能无人值守的核心传统 PXE 装机即使网络引导成功了安装过程中依然要手动点“下一步”Windows 要输密钥、选分区Linux 要配时区、设密码批量装机的效率提升有限。iVentoy 提供了变量功能和自动应答文件机制可以跳过这些交互步骤。以 Windows 为例先准备一个autounattend.xml文件里面写好产品密钥、磁盘分区策略、管理员密码、计算机命名规则等参数。然后将这个文件放到镜像同级目录或者通过 iVentoy 的管理界面绑定到指定镜像。客户端选择该镜像启动后Windows 安装程序会自动读取应答文件整个安装过程无需人工干预。Linux 也是类似的思路Ubuntu 用 preseed 或 cloud-initCentOS/Rocky 用 kickstart。变量的具体引导参数在 iVentoy 文档中有清单你可以将安装器需要的参数传给内核。我的习惯是先手工安装一台机器把安装过程记录下来整理成对应的应答文件再使用变量功能对接——这样生成的自动应答不会漏掉关键选项。4.3 和现有 DHCP 的配合两种网络方案这是在真实网络里使用 iVentoy 时必须做出的选择。iVentoy 自带 DHCP 服务如果部署环境是一个完全隔离的网段直接用它的内置 DHCP 是最省事的客户端插上网线开机就能拿到 IP不需要任何手动设置。但如果你的局域网里已经有一台主路由器在分配 IP那么 iVentoy 的内置 DHCP 会和主路由器产生冲突严重的会导致整个网段内部分机器获取不到地址。解决办法有两个方案一是关闭 iVentoy 的内置 DHCP 功能在管理界面里找到相关开关或者在配置文件里设置然后让主路由器通过 DHCP option 66TFTP 服务器地址和 option 67引导文件名把客户端引导到 iVentoy。不同路由器设置路径不同但原理是一致的主路由依然负责分配 IP同时告诉客户端“去某个 IP 上找引导文件”。方案二是在现有网络中划出一个单独的 VLAN把需要装机的机器放到这个 VLANiVentoy 的 DHCP 只在这个 VLAN 内生效互不干扰。这个方案更干净但需要交换机支持 VLAN 配置普通家用场景不适用。我个人推荐方案一代价只是路由器上配置两个 DHCP option一次配完以后基本不用动。4.4 批量部署的实际操作从测试到铺开批量部署不能上来就直接对几十台机器操作我的流程是严格的“单台验证→小批量试错→全量铺开”三步。单台验证阶段找一台配置有代表性的机器关闭 Secure Boot设置网卡启动进入 iVentoy 菜单选择目标 ISO完整走一遍安装流程。这里重点确认三件事这个镜像能不能正常启动、安装过程中有没有报错、自动应答文件是否生效。如果这一台机器都没跑通先不要继续往下走。小批量试错阶段选三到五台不同品牌或不同配置的机器同时启动观察 iVentoy 管理界面的客户端列表是否全部出现以及安装过程中是否有机器掉线。机器的网卡固件版本千差万别这一步的目的是暴露各种隐藏的兼容性问题。全量铺开阶段把剩余机器全部开机挨个选择镜像开始安装。这时候管理界面上的客户端列表会显示所有正在拉取的机器你可以实时看到每台机器的 IP、MAC 和当前状态。实际测试中二十台机器同时启动在千兆交换机下Windows 镜像的加载速度基本能达到每秒 80MB 以上几分钟就能进入安装界面。真正的瓶颈不是网络而是目标机器的硬盘写入速度。5. 常见问题与排查技巧实录5.1 镜像目录是空的Web 界面看不到 ISO这个现象很常见但原因各不相同。先检查挂载是否成功在容器里执行ls /iventoy/iso看能不能看到你放在宿主机目录里的文件。如果容器里看不到说明挂载路径不对回到 compose 文件修正卷配置。如果容器里能看到文件但管理页面列表为空大概率是权限问题。容器内进程没有读取或遍历 ISO 文件的权限做法是回到宿主机重新设置目录权限然后重启容器。还有一个可能容易被忽略ISO 文件本身在复制过程中损坏或者没有完整落盘这种情况建议用ls -l检查文件大小是否和原始文件一致。5.2 客户端 PXE 启动卡在 DHCP 或 TFTP 阶段这是 PXE 装机里最常见的故障也是最有必要学会自己排查的问题。客户端开机网卡启动后一直停在DHCP......或者反复尝试获取 IP说明客户端根本没有收到 DHCP 应答或者收到了但没拿到正确的启动文件信息。第一步检查防火墙。很多 Linux 发行版默认开启防火墙会拦截 UDP 67 和 69 端口。这个很容易被忽略——容器已经在运行、管理页面也能打开但客户端就是连不上。临时关闭防火墙验证一下ufw status ufw allow 67/udp ufw allow 69/udp ufw allow 16000/tcp如果是 iptables 管理防火墙对应规则要放行 UDP 67、69 和 TCP 16000。第二步抓包确认。在 iVentoy 宿主机上抓 DHCP 报文看客户端请求是否到达、服务器是否回应tcpdump -i eth0 port 67 or port 69 -n如果看到客户端 DHCP Discover 包反复发出但服务器没有任何回应说明 DHCP 服务没有正常监听或配置有问题回到上一步检查端口和日志。如果 DHCP 分配正常但卡在 TFTP 加载引导文件重点检查引导文件路径。iVentoy 一般不需要你手动指定但如果你关闭内置 DHCP 改用主路由 option 67 引导option 67 里填写的文件名必须和 iVentoy 实际提供的引导文件名完全一致。5.3 UEFI 机器引导不了或者直接黑屏新一些的机器默认都是 UEFI 启动硬盘和网卡都走 UEFI 协议栈和传统 Legacy BIOS 的 PXE 流程不一样。黑屏的原因通常是两个一是镜像本身不支持 UEFI 启动二是机器开启了 Secure Boot阻止了未经签名的引导程序运行。排查时先进入主板固件设置确认网络启动的模式是 UEFI同时关闭 Secure Boot。注意有些主板把 Secure Boot 和 CSMCompatibility Support Module关联在一起如果开了 CSM反而会把网络启动强制切到 Legacy 模式所以建议完全是 UEFI 的机器将 CSM 关闭Security 菜单里把 Secure Boot 设为 Disabled。如果你有多种不同年代的机器混用可能需要在 BIOS/UEFI 两种模式之间切换测试iVentoy 两种协议都支持关键是镜像要匹配。5.4 客户端列表不显示但机器确实在安装出现这种情况先不要以为是故障。iVentoy 管理界面的客户端列表是客户端通过 HTTP 服务向 Web 后端上报信息后才会显示的。如果客户端已经成功下载完镜像、进入安装程序阶段它就不会再和 iVentoy 通信了列表里看不到很正常。所以正确判断“客户端是否在工作”主要看交换机端口流量和安装进程本身而不是盯着管理界面。5.5 常见问题速查表现象可能原因快速排查/解决办法容器起不来端口被占用宿主机已有 DNSMASQ 或别的 DHCP 服务停掉冲突服务或换台机器部署Web 界面打不开网络模式不是 host / 端口错误确认 host 网络按日志访问实际 IPISO 列表为空挂载路径或权限有问题容器内ls验证路径调整权限客户端卡 DHCP防火墙拦截 UDP 67 / DHCP 冲突放行端口检查是否有多个 DHCP 服务客户端卡 TFTPoption 67 文件名错误 / TFTP 端口被拦核对文件名放行 UDP 69UEFI 黑屏Secure Boot 开启 / 镜像不支持 UEFI关 Secure Boot换标准 UEFI 版镜像拉镜像很慢默认 registry 源连接不稳定配置 registry mirror 并重启 Docker6. 一些额外想说的话部署这套平台到现在我最深的体会是网络装机这件事工具选对了效率的提升是跨越式的。以前插 U盘装一台 Windows 大概要四十分钟期间人还得守在旁边现在二十台机器同时开始安装我只需要在管理界面确认所有客户端都进入安装流程然后安心等进度条。节省下来的时间精力远比折腾 iVentoy 本身多得多。另外有一个经验或许对你有用。第一次在真实生产环境批量部署时不要选在工作日的业务高峰期建议安排在非工作时间并且提前在交换机和 DHCP 服务层面做好隔离——装机的网段里尽量只有待装机的机器避免 DHCP 冲突和广播风暴影响到办公网络。自己在测试环境玩熟练之后再上手生产网心态会稳得多。还有一个小技巧是定期备份 iVentoy 的配置目录。它的数据其实就是镜像目录加配置文件把整个挂载目录定期同步到另一块磁盘即可。哪天容器出问题新起一个容器把目录挂回去所有配置和镜像原样恢复这种“无状态化”的运维方式能省掉大量灾难恢复的时间。如果你在部署中遇到了这篇文章没覆盖到的问题可以多看看官方文档和社区话题iVentoy 的迭代速度很快很多细节变化都以文档为准。祝装机顺利少踩坑一次成功。