Infra

让机器取得明确的运行环境

Infra 面向受信、隔离的 IPv4 局域网与 x86-64 UEFI 机器。控制端提供网络引导、镜像发布和当前机器观察；Bootstrap 是机器先进入的小型引导系统，应用镜像则包含自己的入口与执行依赖。

操作者维护两项独立声明：启动网卡对应哪个静态业务地址，以及启动时选择哪个镜像名称。机器可以先通过自动分配地址的 DHCP 服务出现在租约中，再等待地址或镜像分配；尚无硬件报告，不妨碍发现它。

接入前，准备网络事实与完整应用

一次部署需要三类输入：可独占使用的启动网络配置、机器网卡与地址的对应关系，以及能够独立运行的应用镜像。网络配置应说明地址池、网关和路由；镜像应包含 /init 及其实际执行依赖，不能把引导系统中碰巧存在的文件当作应用依赖。

业务地址与启动内容分别维护。可以先声明机器应使用的镜像名称，再发布该名称的内容；在绑定或镜像尚未齐备时，机器等待，而不是改用另一份应用。维护 SSH 的权限另行配置，不能从镜像选择权推导出远程管理权。

1. 确认网络与机器

   从实际 DHCP 租约识别启动网卡，核对隔离网络、地址范围与已有占用。硬件报告用于补充判断，不是发现机器的前提。

2. 提交两项独立声明

   分别设置静态业务地址和镜像名称。若目标地址仍有冲突租约，先处理原租约的实际生命周期。

3. 发布应用并观察交接

   完整上传镜像后，观察实际地址、所选内容和应用自身输出。每项观察回答不同问题。

从当前声明走到完整镜像

静态地址声明提交后，客户端通过 DHCP 续租与重新发现取得实际地址。目标地址仍被另一台机器的有效租约占用时，变更会拒绝并保留原声明。设置成功表达的是地址策略已生效，实际取得地址仍需单独观察。

每个镜像名称对应一份完整的当前镜像，采用 EROFS 只读文件系统格式。上传核对字节长度与内容摘要，再原子替换名称对应的文件。正在读取的机器继续使用已打开的内容；等待下一次选择的机器读取当时的当前内容。

1. 发现

   从 DHCP 租约取得启动网卡与临时地址。

2. 声明

   指定业务地址，独立指定镜像名称。

3. 发布

   上传完整镜像，让等待中的机器具备可选内容。

4. 交接

   Bootstrap 核验与准备完成后，授予执行入口的权限。

一次启动中的执行权限

Bootstrap 将镜像挂载为只读根目录，为应用提供独立的进程与挂载视图，并准备设备、内核接口和可写运行目录。应用入口 /init 在自己的进程命名空间中作为首个进程（PID 1）启动，镜像需要携带完整的用户态执行依赖。

授予执行权限之前，传输或准备失败必须完成相关读写、挂载和子进程清理，才允许重新选择。权限一旦可能发出，本次启动就不再启动第二个应用。应用退出或没有报告就绪，都不会让 Bootstrap 重新授予权限。

把声明、观察和业务结果分开

硬件报告独立采集 CPU、可见内存、硬件网络接口和整块设备。每个来源可以单独不可用；成功取得的空集合与未能取得数据不同。控制端只在内存中保留最新样本，重启或淘汰后没有样本，不代表机器消失。

镜像上传完成仅说明内容完整且已发布。引导环境可用、维护 SSH 可连接、应用入口实际执行以及业务服务就绪，也各自需要对应观察。修改镜像名称或删除绑定，不会终止已交接的应用。

更换机器时，沿事实逐项核对

保留业务地址更换机器时，先确认旧地址的租约是否仍有效，再核对新机器的网卡声明和实际租约。删除配置不会收回已经发出的租约，也不会终止已经运行的应用；两台机器之间的业务排他性仍需由应用或运维条件建立。

若新机器停在等待阶段，检查当前绑定和完整镜像是否存在；若已经交接，则改看应用的启动身份、业务响应与已知持久数据。重新发布同名镜像可以改变后续选择，但不能作为修复当前应用的隐式重启操作。

• 可以确认：应用读回自己的已知数据

  这能支持该应用在当前环境中恢复了所观察的业务结果；需要同时保留机器、地址和数据的对应关系。

• 不能推断：维护 SSH 可达即服务已恢复

  SSH 证明的是维护路径。镜像已发布、地址已声明或引导环境可用，同样不足以证明应用已经完成任务。

• 继续核对：硬件样本暂时缺失

  先区分来源不可用、成功的空集合和控制端缓存已清空，再决定是否需要重新观察机器。

用应用自己的输出完成验证

设计中的验证链从未知网卡的 DHCP 发现开始，覆盖固件引导、实际启动网卡、运行镜像核验、原 DHCP 客户端续租和应用的独立输出。另一组场景在更换机器后核对相同业务地址和持久卷中的已知数据。

这些是验证要求，不能代替一次具体环境的执行记录。维护重启通过独立授权的 SSH 发出；连接断开只说明结果可能未知。要确认重启与服务恢复，需要另行观察新的启动身份和应用响应。