在当今互联的嵌入式设备市场中，在物联网 (IoT) 的驱动下，很大一部分正在开发的设备都基于某种形式的 Linux。 具有现成的 Linux 发行版的低成本主板的普及是其中的一个关键驱动因素。 获取硬件、构建您的自定义代码、将设备连接到其他硬件外围设备和互联网，以及使用商业云提供商进行设备管理从未如此简单。 开发人员或开发团队可以快速为新应用程序制作原型，并将设备交到潜在用户手中。 这是一件好事，并催生了许多有趣的新应用程序，以及许多有问题的应用程序。

当为原型设计阶段之后的系统设计进行规划时，事情会变得稍微复杂一些。 在这篇文章中，我们希望考虑开发和维护您的基本 操作系统 (OS) 镜像 的机制。 有许多工具可以帮助实现这一点，但我们不会讨论个别工具； 这里感兴趣的是维护和增强此镜像的底层模型，以及它将如何使您的生活变得更好或更糟。

生成这些镜像主要有两种模型

1. 集中式黄金镜像
2. 分布式构建系统

这些类别反映了 源代码管理 (SCM) 系统的驱动模型，并且在讨论操作系统镜像时，关于集中式与分布式的许多论点都适用。

集中式黄金镜像

业余爱好者和创客项目主要使用集中式黄金镜像方法来创建和维护应用程序镜像。 这一事实使该模型具有速度和熟悉度的优势，使开发人员能够快速建立这样一个系统并使其运行起来。 速度来自于许多设备制造商为其现成的硬件提供现成的镜像。 例如，来自 BeagleBone 和 Raspberry Pi 等系列的板卡提供即用型操作系统镜像和 刷写。 依赖这些镜像意味着只需点击几下鼠标即可启动并运行您的系统。 熟悉度是因为这些镜像通常基于许多设备开发人员已经使用过的桌面发行版，例如 Debian。 多年使用 Linux 的经验可以直接转移到嵌入式设计中，包括打包实用程序在很大程度上保持不变，并且设计人员可以轻松获得他们需要的额外软件包。

这种方法有一些缺点。 首先是 黄金镜像 通常是一个瓶颈，导致在原型设计阶段之后开发人员的生产力下降，因为每个人都必须等待轮到他们访问最新的镜像并进行更改。 在 SCM 领域，这种做法相当于具有单独 文件锁定 的集中式系统。 只有拥有锁的开发人员才能处理任何给定文件。

这种方法的第二个缺点是镜像的可再现性。 此问题通常通过手动登录目标系统、使用本机软件包管理器安装软件包、配置应用程序和点文件，然后就地修改系统配置文件来管理。 一旦此过程完成，磁盘将使用 dd 实用程序或等效实用程序进行镜像，然后分发。

同样，这种方法会产生许多潜在问题。 例如，基于网络的软件包源可能不再存在，并且供应商镜像提供的基本软件可能会更改。 脚本可以帮助缓解这些问题。 但是，当配置文件格式或供应商的基本软件包发生更改时，这些脚本往往很脆弱并且容易崩溃。

这种开发模型出现的最后一个问题是对第三方的依赖。 如果硬件供应商的镜像更改不适用于您的设计，您可能需要投入大量时间来适应。 更复杂的是，如前所述，硬件供应商通常将其镜像基于 Debian 或 Ubuntu 等上游项目。 这种情况引入了更多可能影响您设计的第三方。

分布式构建系统

这种为您的应用程序创建和维护镜像的方法依赖于生成与目标硬件分离的目标镜像。 此处的开发人员工作流程类似于使用 SCM 系统的标准软件开发； 镜像完全可以通过工具构建，并且每个开发人员都可以独立工作。 对系统的更改通过编辑元数据文件（脚本、配方、配置文件等）进行，然后重新运行工具以生成更新的镜像。 这些元数据文件随后使用 SCM 系统进行管理。 个别开发人员可以将最新的更改合并到他们的工作副本中以生成他们的开发镜像。 在这种情况下，不需要黄金镜像，开发人员可以避免相关的瓶颈。

然后，发布镜像由构建系统使用标准 SCM 技术从所有开发人员处提取更改来生成。

以这种方式工作允许您的开发团队规模扩大，而不会降低个别开发人员的生产力。 所有工程师都可以彼此独立地工作。 此外，这种构建设置确保您的构建可以重现。 使用标准 SCM 工作流程可以确保您可以在未来的任何时间重新生成特定的构建，从而实现长期维护，即使上游提供商不再可用也是如此。 然而，与使用分布式 SCM 工具类似，还需要制定额外的策略来启用可重现的候选发布镜像。 个别开发人员拥有他们自己的源代码副本，并且可以构建他们自己的测试镜像，但是为了进行适当的发布工程工作，开发团队将需要建立合并和分支标准，并确保所有针对发布的更改最终都合并到明确定义的分支中。 许多上游项目已经针对这种发布策略制定了完善的流程（例如，使用 *-stable 和 *-next 分支）。

这种方法的主要缺点是不熟悉。 例如，将软件包添加到镜像通常需要创建某种配方，然后更新定义，以便软件包二进制文件包含在镜像中。 这与登录到正在运行的系统时运行 apt 非常不同。 这些系统的学习曲线可能令人望而生畏，但结果更可预测和可扩展，并且在考虑大规模生产的产品的设计时，这可能是更好的选择。

专用构建系统（例如 OpenEmbedded 和 Buildroot）使用此模型，发行版打包工具（例如 debootstrap 和 multistrap）也是如此。 较新的工具（例如 Isar、debos 和 ELBE）也使用这种基本模型。 选择很多，并且值得投资学习这些软件包中的一个或多个用于您的设计。 这些系统的长期可维护性和可再现性将通过允许您生成可重现的构建、跟踪所有源代码并消除您对第三方提供商持续存在的依赖性来降低您设计中的风险。

结论

需要明确的是，分布式模型确实存在与黄金镜像模型提到的一些相同问题； 尤其是对第三方的依赖。 这是使用他人设计的系统的结果，除非您选择完全自行开发的方法，否则无法完全避免这种情况，但这会带来巨大的开发和维护成本。

对于原型设计和概念验证级别的设计，以及只有少数开发人员的团队，考虑到开发此阶段存在的时间和预算限制，黄金镜像模型很可能是正确的选择。 对于小批量、高接触的设计，这可能是生产用途的可接受的权衡。

对于一般生产用途，就团队规模可扩展性、镜像可再现性和开发人员生产力而言，其优势远远超过了实施分布式模型的系统的学习曲线和开销。 板卡和芯片供应商也广泛支持这些系统，从而降低了使用它们进行开发的前期成本。 对于您的下一个产品，我强烈建议在开始设计时认真考虑用于生成基本操作系统镜像的模型。 如果您选择使用黄金镜像模型进行原型设计，并打算迁移到分布式模型，请务必在您的计划中为这项工作留出足够的时间； 估计值将因您选择的特定工具以及需求的范围和您的代码所依赖的软件包的现成可用性而差异很大。