像使用容器一样使用deb包来部署应用程序有什么缺点吗？

Question

我的团队目前正在考虑是否应该将Nodejs应用程序部署为一个deb包，而不是尝试在诸如Docker这样的容器中运行它。

我从阅读这个博客这里中获得了这个想法，它为以前存在的python应用程序使用deb包提供了一些很好的论据。这个博客吸引我们的重点是维护码头生态系统的问题(港口共享、权限、码头图片的托管等等)。

对于那些不关心端口冲突以及所有依赖项都在虚拟环境中维护的小型服务来说，“作为原始容器的dep包”似乎很有意义。

然而，我的直觉告诉我，如果deb软件包是一个很好的适合，它将更常见，码头将被宣传为一个更具体的语言解决方案。使用诸如deb包来部署我们的服务，而不是使用完整的系统(如docker )，有什么缺点吗？

Answer 1

首先，虽然Docker有时被看作是一个临时打包系统，但它实际上解决了一个完全不同的问题: Docker是关于运行程序的。码头系统允许描述服务，这些服务可以随意缩放，并可以控制成群的集装箱。Debian软件包用于安装程序，它们能够处理软件版本之间的依赖关系。Docker当然不符合下降打包系统的条件:每个“包”只能有一个依赖项，系统没有“递归构建”选项，并且不支持复杂的版本约束！

一个可能的答案是，如果您愿意为您的应用程序编写Debian包，您也可以使用Docker来部署应用程序。这可以通过配置脚本apt_setup.sh来实现，该脚本如下所示

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

和一个沿着……的Dockerfile

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(在您的特定情况下，apt_setup.sh会更复杂，添加nodesource存储库和一些助手包，比如。)

因此，确实有可能同时使用Debian包和Docker，但是…

我的直觉…告诉我，如果deb包是一个很好的适合，它将更常见。

这是一个正确的问题，这导致我们问自己，为什么码头工人被证明是流行的临时包装系统，而不是打算成为一个。(见上文)

来自给定发行版的“正式”打包系统只是许多其他人在某些计算环境中安装软件的可能性。还有许多其他可用的资源，如特定于社区的软件包管理器(如npm或opam )、端口树(如pkgsrc )和普通源代码分发。从这个角度来看，很容易理解“码头工人”作为一种临时包装系统的成功：

• Docker规范与shell脚本非常接近，不管它的来源是什么，我们都使用shell安装软件。
• 码头有一个“内置”(付费)服务，托管它生产的工艺品，码头枢纽。

作为一个包系统，Debian包在Docker映像上的优势是什么？在安装时对依赖项的严格控制。(升级和降级的可能性也存在，但如果我们正在实现不可变服务器模式，则没有实际意义。)这导致了

结论

如果您只在单个版本中部署了单个产品(这在SaaS中是典型的)，那么您的版本管理需求非常简单，使用Docker作为临时包管理器不应该有任何困难。一旦您使用单个产品或多个产品的多个版本，您需要解决的版本约束问题的复杂性就会增加，并且您需要一个适当的工具来解决这个问题，如果您是从不同的来源混合软件，则可能是Debian包或一些配置管理系统。

Answer 2

正确地安装应用程序的Debian (或RedHat)包是一个很好的实践。包用于部署很少更改的应用程序。Debian软件包涉及一些开销，如版本管理、依赖管理、安装前和安装脚本等.

在许多情况下，从旧版本升级到新版本需要仔细编写脚本，注意版本中的细节等，因为改变现有状态是很困难的。用一个新的状态来替换当前的状态要容易得多，而不会发生任何变化。

一旦您决定在每个部署上完全替换您的配置或依赖项或应用程序，因为这样做更容易，而且更容易出错。大多数组织(过去)都会切换到一个全新的VM或云实例。这意味着安装包将在“干净”服务器上完成，而在服务器上更改文件和配置不再是一个问题。

那些开发人员，谁创造了软件包，并没有理解的谬误和复杂的突变，因此遭受了相当多的困难。

当您只需要替换一个应用程序时，替换VM是次优的，这就是为什么引入轻量级容器作为解决方案的原因。使用Docker (或其他LWC)，您可以替换用户名，包括所有依赖项，而无需替换服务器本身。您还可以在同一台服务器上承载同一应用程序的多个版本，具有不同的依赖关系，并且只在升级时切换传入的网络通信量。以及在回滚(蓝绿色)上切换网络流量，这在通过包管理部署的情况下是非常困难的。

容器引入了一种将所有应用程序代码、依赖项和配置捆绑到映像中的方法。此映像具有多个属性，使其比传统的操作系统包要好得多。例如，它有启用版本控制的标记，但也有能够节省空间的层。它允许使用注册表将这些映像发送到服务器和开发环境。这些映像可以作为容器在任何环境和任何服务器上执行，几乎是相同的。这包括开发人员的笔记本电脑以及生产环境。同样，对于VM和/或基于包的软件版本来说，这要困难得多。在开发人员的笔记本上测试相同的映像，并且在生产中保持相同的位数和字节，可以消除许多“在我的机器上工作”的问题。

Answer 3

是的，有缺点。

使用.deb包，您将无法在同一主机上拥有同一应用程序的两个版本。如果您的应用程序依赖于nodejs，您将不得不依赖发行版可用的包，例如，要么您将使用发行版，要么您将不得不安装您自己的版本。

现在，当您想在同一台主机上托管倍数应用程序时，如果它们依赖于两个不同的版本(让我们将nodejs保存在这里)，您就会很快碰到一个墙。

docker的主要目标是将每个应用程序与宿主系统和同一主机上的其他应用程序隔离开来。实现这种隔离有两个原因: 1.为了避免应用程序能够接管主机或影响另一应用程序，2.给予应用程序确切的依赖关系，并防止它受到系统更新或另一应用程序依赖的影响。