openSUSE:ALP/Workgroups/Installation/Iguana

ALP 安装工作组希望尝试一种新的安装概念。Iguana 是实现该概念的原型代号。

简而言之

安装程序将构建一个完全定制的 ALP 镜像，以匹配系统，然后部署该镜像。

Iguana 的基础是一个小的 initrd，可以执行容器。然后，安装程序本身由几个组件组成，所有组件都作为容器运行。其中一些组件将负责使用与生成“规范”ALP 镜像相同的工具来生成镜像。

主要高级步骤

• 分析系统并读取用户设置
• 基于上一步生成清单
• 使用该清单生成完全定制的镜像
• 部署镜像

仓库

https://github.com/aaannz/dracut-iguana

愿景

鉴于我们希望涵盖的范围之广，以及我们在工作组讨论和会议中谈论的内容，我们都同意安装程序本身将继续是其中之一，并且必须继续是 ALP 生态系统提供的许多不同类型的 initrd/引导镜像之一。我们不试图成为每个 ALP 镜像的一部分。

我们将“安装程序引导镜像”定位为能够处理软件包和镜像的镜像。需要软件包是因为第三方软件的需求。需要镜像是因为我假设 ALP 将其部分内容作为完整的 OCI 镜像分发，甚至可能还有其他不同类型的镜像（例如，flatpak、sys-ext systemd 镜像）。

安装程序引导镜像能够执行

• 本地和远程安装（适用于具有“正常”HW、没有 ipmi 等且没有额外的安装服务器，即“如果我在家里如何安装？”的用户）
• 基于某种清单的无人值守安装

安装程序应该能够开箱即用地支持一些合理的硬件。对于一些特殊的 HW 配置，需要有一种机制来附加驱动程序和/或元数据（例如，自定义强制分区）到安装程序。我认为该机制不应该触及安装程序引导镜像本身，而是对其的扩展，例如使用 overlayfs 加载。另一个悬而未决的问题是如何验证此扩展，如果我们允许用户构建自己的扩展。

安装应该使用与构建 ALP 镜像相同的工具完成，唯一的区别是它不是构建到某个输出文件，而是直接构建到存储介质上。使用这些工具，安装程序将支持我们构建镜像时支持的一切（例如，配置服务、用户等）。这也有望提供一些调试帮助，因为有了用户的安装清单，我们应该能够构建相同的镜像并对其进行处理。

因此，安装程序的工作是收集来自 HW、用户（在有人值守安装的情况下）以及如果提供某种清单的数据，并从这些数据创建“安装清单”，然后使用已知的工具构建/安装机器。

该安装清单应该可用于调试目的，并且应该与用于构建其他官方 ALP 镜像的清单相同。

我们收集的用户数据的范围取决于构建系统可以配置多少（当然还有 UX 设计）。

动态内容如 [此处] 所述将与用户使用 ALP 工具构建自己的镜像时使用的内容相同。

这种方法的一个重要优势是将始终相同的微型 initrd 与一组容器结合起来，就是 initrd 和容器都可以签名，从而确保整个组件集的完整性。

这种方法尚未解决的问题

• 我们目前不知道镜像构建工具会是什么样子。
• 我们不知道由该工具生成的镜像会是什么样子，但我倾向于认为它们最多是文件系统镜像，例如一个分区，因为这项工作的目的是使 ALP 更具容器友好性。我不认为它们会是我们当前所知的 OEM 镜像或整个磁盘镜像。
• 由于我们不知道该工具，我们不知道修改它以构建到真实存储而不是某个文件需要多少精力。

关于与 SUMA (SUSE Manager) 的互操作性的说明

目前，在 SLE15 世界中，SUMA 使用 autoyast 或 saltboot 来安装/部署系统。如前所述，安装程序将只是可用的引导镜像之一。对于 SUMA saltboot，我们将拥有一个单独的引导镜像，其中包含 salt，它将负责遵守 APL 标准，并且根本不使用安装程序。

对于基于清单的安装，我们尚不清楚它会是什么样子，但回顾 SLE15 世界，我们添加了 autoyast 安装后脚本，这些脚本正确配置了预安装的 salt-minion。最终目标是机器启动到系统后，它将自动在 SUMA 上显示。如果安装程序具有一些引导镜像扩展，我们很可能拥有一些 SUMA 特定的引导镜像扩展，提供所有必要的配置。