搭建一个通过容器分发应用的可复用系统可能很复杂，但这儿有个好方法。

一个用于将源代码转换成可运行的应用的构建系统是由工具和流程共同组成。在转换过程中还涉及到代码的受众从软件开发者转变为最终用户，无论最终用户是运维的同事还是部署的同事。

在使用容器搭建了一些构建系统后，我觉得有一个不错的可复用的方法值得分享。虽然这些构建系统被用于编译机器学习算法和为嵌入式硬件生成可加载的软件镜像，但这个方法足够抽象，可用于任何基于容器的构建系统。

这个方法是以一种易于使用和维护的方式搭建或组织构建系统，但并不涉及处理特定编译器或工具容器化的技巧。它适用于软件开发人员构建软件，并将可维护镜像交给其他技术人员（无论是系统管理员、运维工程师或者其他一些头衔）的常见情况。该构建系统被从终端用户中抽象出来，这样他们就可以专注于软件。

为什么要容器化构建系统？

搭建基于容器的可复用构建系统可以为软件团队带来诸多好处：

• 专注：我希望专注于应用的开发。当我调用一个工具进行“构建”时，我希望这个工具集能生成一个随时可用的二进制文件。我不想浪费时间在构建系统的查错上。实际上，我宁愿不了解，或者说不关心构建系统。
• 一致的构建行为：无论在哪种使用情况下，我都想确保整个团队使用相同版本的工具集并在构建时得到相同的结果。否则，我就得不断地处理“我这咋就是好的”的麻烦。在团队项目中，使用相同版本的工具集并对给定的输入源文件集产生一致的输出是非常重要。
• 易于部署和升级：即使向每个人都提供一套详细说明来安装一个项目的工具集，也可能会有人翻车。问题也可能是由于每个人对自己的 Linux 环境的个性化修改导致的。在团队中使用不同的 Linux 发行版（或者其他操作系统），情况可能还会变得更复杂。当需要将工具集升级到下一版本时，问题很快就会变得更糟糕。使用容器和本指南将使得新版本升级非常简单。

对我在项目中使用的构建系统进行容器化的这些经验显然很有价值，因为它可以缓解上述问题。我倾向于使用 Docker 作为容器工具，虽然在相对特殊的环境中安装和网络配置仍可能出现问题，尤其是当你在一个使用复杂代理的企业环境中工作时。但至少现在我需要解决的构建系统问题已经很少了。