企业官网建设流程全解析

机房二十台机器等着装系统，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 镜像资源的准备思路

镜像建议直接去官方渠道下载原版 ISO，Windows 用微软官方工具生成镜像，Linux 发行版去官网或镜像站下载。这里有个小建议：尽量下载包含 UEFI 启动支持的标准 ISO，老一些的精简版 ISO 只支持 Legacy BIOS，遇到新机器会非常尴尬。

如果你是做无人值守批量安装，还需要提前准备自动应答文件。Windows 对应 autounattend.xml，CentOS/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 \ --restart=always \ -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 时给自己分配的内置地址。如果你局域网里已经有路由器在分配 IP，iVentoy 会自动获取网段 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-init，CentOS/Rocky 用 kickstart。变量的具体引导参数在 iVentoy 文档中有清单，你可以将安装器需要的参数传给内核。我的习惯是先手工安装一台机器，把安装过程记录下来，整理成对应的应答文件，再使用变量功能对接——这样生成的自动应答不会漏掉关键选项。

4.3 和现有 DHCP 的配合：两种网络方案

这是在真实网络里使用 iVentoy 时必须做出的选择。iVentoy 自带 DHCP 服务，如果部署环境是一个完全隔离的网段，直接用它的内置 DHCP 是最省事的，客户端插上网线开机就能拿到 IP，不需要任何手动设置。

但如果你的局域网里已经有一台主路由器在分配 IP，那么 iVentoy 的内置 DHCP 会和主路由器产生冲突，严重的会导致整个网段内部分机器获取不到地址。解决办法有两个：

方案一是关闭 iVentoy 的内置 DHCP 功能，在管理界面里找到相关开关，或者在配置文件里设置，然后让主路由器通过 DHCP option 66（TFTP 服务器地址）和 option 67（引导文件名）把客户端引导到 iVentoy。不同路由器设置路径不同，但原理是一致的：主路由依然负责分配 IP，同时告诉客户端“去某个 IP 上找引导文件”。

方案二是在现有网络中划出一个单独的 VLAN，把需要装机的机器放到这个 VLAN，iVentoy 的 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 和 CSM（Compatibility Support Module）关联在一起，如果开了 CSM，反而会把网络启动强制切到 Legacy 模式，所以建议完全是 UEFI 的机器将 CSM 关闭，Security 菜单里把 Secure Boot 设为 Disabled。如果你有多种不同年代的机器混用，可能需要在 BIOS/UEFI 两种模式之间切换测试，iVentoy 两种协议都支持，关键是镜像要匹配。

5.4 客户端列表不显示，但机器确实在安装

出现这种情况，先不要以为是故障。iVentoy 管理界面的客户端列表，是客户端通过 HTTP 服务向 Web 后端上报信息后才会显示的。如果客户端已经成功下载完镜像、进入安装程序阶段，它就不会再和 iVentoy 通信了，列表里看不到很正常。所以正确判断“客户端是否在工作”，主要看交换机端口流量和安装进程本身，而不是盯着管理界面。

5.5 常见问题速查表

6. 一些额外想说的话

部署这套平台到现在，我最深的体会是：网络装机这件事，工具选对了，效率的提升是跨越式的。以前插 U盘装一台 Windows 大概要四十分钟，期间人还得守在旁边；现在二十台机器同时开始安装，我只需要在管理界面确认所有客户端都进入安装流程，然后安心等进度条。节省下来的时间精力，远比折腾 iVentoy 本身多得多。

另外有一个经验或许对你有用。第一次在真实生产环境批量部署时，不要选在工作日的业务高峰期，建议安排在非工作时间，并且提前在交换机和 DHCP 服务层面做好隔离——装机的网段里尽量只有待装机的机器，避免 DHCP 冲突和广播风暴影响到办公网络。自己在测试环境玩熟练之后，再上手生产网，心态会稳得多。

还有一个小技巧是定期备份 iVentoy 的配置目录。它的数据其实就是镜像目录加配置文件，把整个挂载目录定期同步到另一块磁盘即可。哪天容器出问题，新起一个容器把目录挂回去，所有配置和镜像原样恢复，这种“无状态化”的运维方式，能省掉大量灾难恢复的时间。如果你在部署中遇到了这篇文章没覆盖到的问题，可以多看看官方文档和社区话题，iVentoy 的迭代速度很快，很多细节变化都以文档为准。祝装机顺利，少踩坑，一次成功。