多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

基于iVentoy和Docker打造简易PXE网络装机平台

基于iVentoy和Docker打造简易PXE网络装机平台 一直觉得 PXE 网络装机是个有两副面孔的东西懂配置的人用它批量部署机房很爽不懂的人光是搭环境就被劝退。传统一套 dnsmasq 做 DHCP Proxy、tftpd 托启动文件、再挂 HTTP/NFS 供镜像的做法对一台临时组建的装机服务来说维护成本实在太高换个镜像还要一层层改配置。后来我把 iVentoy 塞进 Docker整个 PXE 网络装机平台的搭建速度被压缩到了几分钟——把 ISO 丢进目录客户端开机网启屏幕上直接出现图形化选单选中镜像就开始装系统。这篇文章我把自己实际跑通的部署流程、网络规划思路和踩过的坑完整捋一遍给要批量装机、维护实验室或者机房的朋友做个参考。1. 为什么我会选择 Docker 来部署 iVentoy1.1 传统 PXE 方案的痛点先说说没有 iVentoy 之前我是怎么被传统 PXE 折腾的。标准流程大概是dnsmasq 负责 DHCP 和 DHCP Proxy要在配置里指定 option 66tftp 服务器地址和 option 67启动文件名tftpd-hpa 负责提供 bootloader 文件比如 pxelinux.0、grubx64.efi 这些真正安装系统的时候还要把 ISO 解压再用 NFS 或者 HTTP 方式挂载让安装器能读到 install 源。听起来不复杂但你只要换一个镜像、换一种架构就得重新检查 boot 文件路径、修改 DHCP 配置、确认 NFS 挂载参数。最要命的是多台机器同时安装时任何一个环节出问题当场就要抓包排查。这类问题单看可能不难但组合起来维护成本真的很高。1.2 iVentoy 让网启体验发生了哪些变化iVentoy 做的事情本质上是把“PXE 服务端”和“引导菜单”这两个东西整合成了一体。它内部集成了 DHCP 服务、TFTP 服务和 HTTP 镜像服务你不需要手动配置 option 66、67也不需要准备 pxelinux.0 这些引导文件。最省事的是ISO 原文件直接丢进去就能用不用解压、不用挂载。客户端通过网络启动后会看到一个类似 Ventoy 的图形化菜单列出服务器上存放的全部 ISO你选一个就进入了对应系统的安装流程。这种体验几乎把传统 PXE 最劝退的那一层全抹掉了。1.3 Docker 部署的三个直接好处iVentoy 本身就提供 Linux 下的可执行压缩包直接解压也能跑。那我为什么还要坚持用 Docker 跑三个原因环境隔离iVentoy 要监听 67、69 这样的特权端口还会自带 DHCP 服务如果宿主机上恰好还有别的网络服务直接解压运行容易互相干扰。用 Docker 跑容器独立出问题直接删掉重建。升级回滚方便iVentoy 更新比较频繁解压二进制升级需要手动备份配置和数据目录而 Docker 只要改一下镜像标签重新起一个容器旧容器还留着随时能回滚。迁移成本低只要挂载目录结构和网络环境保持一致这个容器迁移到另一台宿主机就是一条 docker run 命令的事适合临时搭一个装机服务用。基于这些原因我最终的方案就是在 Linux 宿主机上安装 Docker用官方镜像启动 iVentoy 容器然后把整个使用流程沉淀成了一篇可以直接照抄的笔记。2. 部署前必须想清楚的网络规划很多人上来就 docker run结果客户端一开机网启就卡住然后跑来问我怎么排查。我看了半天发现问题往往不在容器本身而是网络规划一开始就没想清楚。所以这部分必须先讲。2.1 先搞懂 iVentoy 的 DHCP 工作模式iVentoy 的 DHCP 相关功能有两种使用姿势一种是它自己充当完整的 DHCP 服务器直接从 67 端口广播响应接管客户端 IP 分配另一种是 DHCP 代理模式也就是你现有的路由器或局域网 DHCP 服务器继续负责分配 IPiVentoy 只去响应 PXE 相关的请求告诉客户端“引导服务在我这里”。这个区别特别重要。如果局域网里已经有一个很稳的 DHCP 服务器你非要把 iVentoy 的独立 DHCP 模式打开很可能出现两台设备抢着分配 IP 的情况轻则客户端拿不到地址重则整个局域网一时半会都上不了网。我实际部署时如果客户端数量不多且主路由可控会更倾向于让主路由继续做 DHCP然后把 iVentoy 放在旁路的 Docker 容器里做引导服务。但也要注意部分路由器/交换机环境下DHCP 代理方式可能被网络里的安全策略拦截那就只能选择一个相对清爽的网段直接用 iVentoy 当 DHCP 服务器。简单判断标准如果你只是搭一个临时装机网络客户端和宿主机都在一个傻瓜交换机下面直接用 iVentoy 独立 DHCP 没问题如果你要把这个服务长期插在公司办公网里务必先问清楚网管有没有 DHCP Snooping 之类的策略不然可能直接被断电。2.2 端口清单与映射注意点iVentoy 在 Docker 里需要暴露的端口大致有三组端口协议用途26000TCPWeb 管理控制台26001TCPiVentoy 服务辅助通信67UDPDHCP / PXE 发现响应69UDPTFTP 启动文件传输提示具体端口号以你拉取的 iVentoy 镜像对应版本文档为准部署前先去官方页面确认一遍不同版本可能会调整端口设计。用 Docker bridge 网络模式时这些端口都要手动映射。其中 67 和 69 是 UDP 端口特别是 69TFTP 的传输模式比较特殊后面我会专门讲为什么 69 端口在 bridge 模式下容易出问题。简单结论是在 Linux 宿主机上我强烈建议直接使用--network host网络模式让 iVentoy 在宿主机网络栈里原生监听这些端口少一层 Docker 的 NAT 和代理转发PXE 稳定性会高很多。2.3 一条请求链路的全流程理解部署前最好在脑子里过一遍客户端从开机到进入安装界面的完整链路后面排查问题会快很多客户端网卡 PXE ROM 开机 - 通过 67/68 端口广播 DHCP 请求 - iVentoy 响应并附带引导服务器地址和启动文件名 - 客户端到 TFTP 69 端口拉取网络引导程序 - 引导程序运行后通过 HTTP 从 iVentoy 加载镜像索引和 ISO 文件 - 显示图形化选单 - 用户选择 ISO 后进入系统安装器。理解了这条链路你就会发现每次排查网启问题本质上就是在问请求走到了哪一步哪一步被卡住了。是 DHCP 没响应还是 TFTP 拿不到文件还是 HTTP 加载不出菜单不要再盲目重启容器和客户端了。3. Docker 部署 iVentoy 实操步骤3.1 宿主机准备与 Docker 环境检查部署 iVentoy 的宿主机最好是 Linux发行版不限。如果你手里只有 Windows 或 macOS硬要用 Docker Desktop 跑也不是不行但对于 67/69 这类 UDP 广播敏感场景Docker Desktop 的网络层跨了虚拟机和宿主转发稳定性不如甚至可以说远不如 Linux 原生 Docker。装机这事本身讲究省心别给自己添堵。Docker 环境如果还没有安装大部分发行版一条命令就能装好curl -fsSL https://get.docker.com | sh systemctl enable --now docker装完先确认 Docker 守护进程正常运行sudo docker version sudo docker ps如果拉取镜像比较慢可以先配置 registry mirror镜像加速地址不同环境差异较大建议自行检索当前可用的公共镜像加速配置。这一步不是必须的但直接影响后续体验。3.2 使用 docker run 启动我实际在 Linux 宿主机上最常用的是 host 网络模式命令很简短sudo docker run -d \ --name iventoy \ --restartalways \ --network host \ -v /opt/iventoy/data:/data \ ventoy/iventoy命令里的几个参数解释下--network host让容器直接使用宿主机网络不需要映射端口DHCP/TFTP 的行为最接近原生运行。-v /opt/iventoy/data:/data把宿主机目录挂载进容器的数据目录也就是将来放 ISO 和配置的地方。--restartalways宿主机重启后容器自动拉起适合把装机服务长期跑着。如果你因为某些原因只能用 bridge 网络模式例如 Docker 版本或宿主机网络限制不支持 host 模式那需要显式映射端口sudo docker run -d \ --name iventoy \ --restartalways \ -p 26000:26000 \ -p 26001:26001 \ -p 67:67/udp \ -p 69:69/udp \ -v /opt/iventoy/data:/data \ ventoy/iventoy注意宿主机的防火墙。很多发行版默认开了 firewalld 或 ufw67/69/26000 这几个端口如果不放行容器内部服务启动得再好外部请求也进不来。可以临时用sudo firewall-cmd --add-port67/udp --permanent这类命令放通具体看你用的防火墙管理工具。3.3 使用 Docker Compose 固化配置如果你的宿主机上管理了多个 Docker 容器用 Docker Compose 会更清晰。我在专门放装机服务的机器上就写了这样一份docker-compose.ymlservices: iventoy: image: ventoy/iventoy container_name: iventoy restart: always network_mode: host volumes: - /opt/iventoy/data:/data然后一条sudo docker compose up -d就能拉起。这里还是要强调network_mode: host只在 Linux 宿主机上行为符合预期Windows/macOS 的 Docker Desktop 对 host 网络模式的支持非常有限这也是我反复建议用 Linux 的原因。3.4 部署后的三连检查容器启动完不要急着开机网启先做三件事# 1. 确认容器处于 running 状态 sudo docker ps | grep iventoy # 2. 确认 Web 控制台能打开 curl -I http://127.0.0.1:26000/ # 3. 确认关键端口在监听 sudo netstat -lnp | grep -E :(67|69|26000)如果 curl 返回了 HTTP 200说明管理服务正常。如果 netstat 里 67/69 监听异常去翻容器日志sudo docker logs iventoy日志里通常能直接看到 DHCP、TFTP、HTTP 服务各自的启动状态哪个起不来问题基本就锁定在端口占用和网络模式上了。4. 第一次网络装机从控制台到客户端全流程4.1 Web 控制台和 ISO 管理部署就绪后浏览器打开http://宿主机IP:26000进入 iVentoy 的 Web 控制台。第一次进控制台界面很简洁左侧是镜像列表右侧是客户端装机状态之类的内容。需要确认宿主机上挂载的/opt/iventoy/data目录里能放 ISO。你把Win10_22H2.iso或者ubuntu-22.04.3-desktop-amd64.iso这类原版镜像直接拷贝进去回到 Web 控制台一般刷新一下就能看到它们出现在列表里。iVentoy 不需要你解压或转换镜像它会自动解析 ISO 里的启动配置。这点对习惯 Windows 原版镜像和 Linux 发行版镜像混用的场景特别友好我经常一次性扔十几个镜像进去。不过有一点要提醒控制台默认可能没有设置访问认证在很多办公网络环境下这就等于把装机服务裸奔在局域网里。如果当前网络环境不是你独占的临时网线建议先确认 iVentoy 当前版本是否支持独立的访问密码控制或者干脆放在一个隔离的 VLAN 里使用避免被无关人员通过 Web 控制台乱改配置。4.2 客户端网络启动设置与引导菜单客户端需要进入 BIOS/UEFI 设置界面打开网络启动选项不同品牌主板的快捷键不一样多数是开机狂按 F12、F8 或 F11 弹出启动菜单然后选择类似 PXE Network Boot UEFI: Realtek/Intel PXE 这样的选项。如果 BIOS 里把网络栈完全关闭了首先要在芯片组/集成外设设置里打开 Network Stack 之类的开关否则网卡根本不会发起 PXE 请求。客户端发起网启后正常情况下会先经历 DHCP 获取地址接着屏幕出现 iVentoy 的引导选单。选单里能看到服务器上所有 ISO 镜像选中目标镜像回车就开始加载安装器了。这里有个很实用的观察点如果客户端能进入选单说明 DHCP、TFTP 和 HTTP 这条链路已经通了后面装系统阶段出错基本都属于镜像本身或驱动问题。4.3 Windows 与 Linux 镜像安装的差异处理Windows 镜像的网启安装流程比较接近日常用 U 盘装系统会先加载 Windows PE然后进入安装界面。我常用的原版 Windows ISO 基本都能正常工作但某些精简版、定制版 ISO 可能由于启动配置不标准在 iVentoy 选单下没法进入安装器。遇到这种情况第一选择永远是对调回官方原版镜像没必要在精简版上耗时间。Linux 镜像的话多数主流发行版对网络启动支持很好。需要注意启动方式对架构的影响BIOS 启动和 UEFI 启动对同一张 ISO 的引导路径可能不同。你在选单里可能会看到同一镜像对应多个启动项比如 UEFI 模式、Legacy 模式根据客户端固件类型选对应项。如果客户端是纯 UEFI 且开了 Secure Boot某些镜像可能需要关闭 Secure Boot 才能正常引导这个在网启阶段尤其明显。5. 实际使用中容易踩的五个坑5.1 客户端拿不到 IPDHCP 排查链路这是最容易遇到的坑现象是客户端开机网启后一直卡在 Acquiring IP address... 或者反复尝试 DHCP、最后超时进入本地系统启动。按我经验最常见的三个原因网络不通客户端和宿主机看似在一个交换机上实际上被二层隔离了。先看客户端能不能 ping 通宿主机或者宿主机抓包看有没有 DHCP Discover 广播进来。DHCP 模式冲突主路由 DHCP 和 iVentoy 同时响应导致客户端无所适从。可以把 iVentoy 切换到代理模式或者更直接一点搭一个独立的小网络只让 iVentoy 分配地址。防火墙拦截了 67/68 端口很多发行版默认防火墙规则只管常规端口UDP 67/68 被拦得很不起眼。用tcpdump -n -i 网卡名 udp port 67 or port 68在宿主机上抓包如果一直只能看到 Discover 而没有 Offer 出去基本就是防火墙或 iVentoy 服务状态问题。5.2 UEFI 网启报错NBP 或 HTTP Boot 问题客户端在 UEFI 模式下发起网络启动有时会出现类似 NBP file not found 或者直接卡在 HTTP Boot Failed 的提示。NBP 全称 Network Boot Program也就是从 TFTP 服务器下载的引导文件这个文件找不到通常不是 iVentoy 的问题而是 UEFI 固件需要手动指定引导文件路径的场景。少部分主板固件对于厂商远程启动文件名的处理非常死板需要你在 BIOS 网络启动设置里手动填写 iPXE 或 bootx64.efi 这类文件名。不同 iVentoy 版本的默认文件名可能不一样你可以去 iVentoy 官方 FAQ 或本地日志里查实际文件名然后填进主板设置里。如果报的是 HTTP Boot 失败先确认这个主板是否支持 UEFI HTTP Boot。很多“网络启动”功能标称支持 UEFI但实际走的还是 TFTP 拉 NBP 的老路子HTTP Boot 只是附加项。5.3 Windows 安装找不到磁盘VMD/RST 驱动这个坑我用 iVentoy 装新机器时踩过一次。现象是 Windows 安装器能正常启动但选磁盘时看不到 NVMe 固态硬盘设备列表里只有 U 盘或没有磁盘。原因大多是 Intel VMDVolume Management Device或 RST 驱动的缺失这在新款笔记本和部分台式机上尤其常见它们的磁盘默认挂在 VMD 控制器下Windows 安装器没有自带对应驱动。解决办法有两条路一是进 BIOS 把 VMD 模式改成 AHCI 模式重新引导后磁盘就能看到但这会改变硬盘控制器的固件设置不是所有商务机器都允许二是把磁盘驱动放进 iVentoy 的插件机制里让它注入到引导时使用的 PE 环境。具体插件目录结构建议直接参考 iVentoy 官方文档不同版本差异不小。5.4 Docker bridge 模式下 TFTP 不稳定端口映射的坑如果你用了 bridge 模式而不是 host 模式网启过程中可能出现一种很诡异的状况控制台能打开DHCP 也能响应但客户端引导文件传输总是到一半就超时或者时好时坏。问题基本锁定在 Docker 对 69 端口的 UDP 转发机制上。TFTP 的传输模式和其他常见 UDP 服务不太一样客户端首先连服务器的 69 端口拿文件但后续数据包会从服务端一个高位随机端口发回给客户端。Docker bridge 网络的端口映射对这种方式的支持有限特别是 Docker 的 userland-proxy 机制介入时TFTP 很容易出现数据包回传丢失表现就是文件传输卡住。这也是我坚持推荐 host 网络模式的真正原因少了这一层 NAT 和 proxy 的干扰TFTP 就不再是玄学问题。如果你受环境限制只能用 bridge那至少要把 Docker 的 userland-proxy 参数行为了解清楚并在容器日志里观察 TFTP 请求是否频繁超时。5.5 并发批量装机时的带宽与镜像加载注意点批量装机场景对带宽敏感。之前我一次给二十多台机器同时装系统iVentoy 本身没掉链子但网络先扛不住了——百兆交换机下多台机器同时从 HTTP 拉取 ISO 镜像带宽被瞬间占满每台机器的安装时间都被拉得很长其中几台还因为下载过慢导致安装器报错。后来换到千兆交换机同时装机数量控制在几台到十几台之间情况就好了很多。另一个经验是如果镜像源文件比较大、客户端数量又特别多尽量把 iVentoy 部署在万兆网口或至少千兆网卡的宿主机上同时确认网卡驱动和 MTU 设置正常。还有一个特别容易被忽略的细节批量装完机器后客户端 BIOS 里的网启优先级往往还排在硬盘之前。等这批机器重新上生产环境时只要开机偶尔碰一下网络就可能意外进入 iVentoy 选单反而把启动流程卡住。装完一批机器后记得把客户端的启动顺序改回硬盘优先或者直接把 iVentoy 容器停掉避免后续误网启。最后聊聊实际部署中的一点体会折腾了这么多轮网络装机之后我的体会是iVentoy 确实把 PXE 的门槛拉到了很低但它毕竟还是一个依赖网络基础设施的工具。真正消耗时间的地方不是“把容器跑起来”而是网络规划、端口放行、固件设置和驱动兼容这些看起来不起眼的环境因素。个人经验是把网络模式和端口这几件事在部署前想清楚后面能省一大半排查的力气。另外一个小技巧给镜像文件命名时把系统版本、架构和用途都标清楚比如Win11-x64-Designer.iso这种多人协作装机时控制台选单里的可读性会好很多。网启装机这件事工具选对了剩下就是按流程办事希望这篇文章能帮你少走几步弯路。
返回列表