使用Docker构建Debian软件包

构建Debian软件包并不总是很有趣。 如果您曾经尝试将某些软件转换为.deb软件包，那么您可能会因大量可用的构建工具和文件格式不知所措，或者是为了满足软件包的所有依赖性而弄乱了系统。 有很多事情可能会而且最初会出错。

幸运的是，自动化和虚拟化的正确组合可以带来很大的不同。 在本文中，我将向您介绍我在Jimdo开发的Debian软件包构建系统背后的故事，该系统解决了我们多年来面临的许多难题 。

包装建造的黑暗时代

当我于2013年开始在Jimdo工作时，我们在构建Debian软件包时遇到了自己的问题。 从第一天开始，我们就依靠Debian操作系统为服务器供电。 Debian本身已经带有成千上万个可以安装的软件包。 但是，如果捆绑软件已过时，我们仍然需要自己重新编译较新的版本。 另外，我们也希望将自己的工具作为.deb文件分发。 因此，能够构建和维护Debian软件包对我们一直都很重要。

为了那时可以创建软件包，工程师必须登录一个专用的构建服务器，恰当地命名为buildhost02，然后以特殊的“ buildmaster”用户身份运行几个Shell命令。 这个过程有几个缺点：通常很难弄清楚是谁构建了特定的软件包，或者为什么要首先构建它。 最糟糕的是，有时我们不知道如何创建软件包。 除了松散的shell脚本集合外，没有统一的方法来创建软件包，更不用说它们来源的默认位置了。

问题列表清楚地表明，此构建系统不会永远持续下去。 我们的构建服务器buildhost02很难理解和修改，并且设置具有相同功能的另一台服务器非常麻烦（尽管其名称以“ 02”结尾，如果出现问题，则没有其他服务器）。 此外，由于构建通常涉及安装多个依赖项，因此随着时间的流逝，主机越来越受到污染。 综上所述，buildhost02是所谓的独特雪花 。

包装2.0

2014年5月，我有机会开始研究我们所谓的“包装2.0”里程碑。 里程碑的目标是根据我们过去的经验开发一个新的更好的构建系统。 后来，该项目被称为buildbox 。

使用buildbox时，软件包构建应该是：

• 自动化的。 工程师应该能够通过在本地计算机上运行单个命令来构建用于分发Y的软件包X。
• 记录下来。 很明显，如何以及为什么要构建软件包以及由谁来维护它。
• 可重复的。 应该有可能复制软件包的每个内部版本。
• 简单。 工程师，或者实际上是任何人，都应该能够建造。

为了完成这个里程碑，我们同意，我不仅必须使用buildbox重建所有100多个自定义Debian软件包（此过程需要大量的逆向工程）&#x