Docker适合我的用例吗？

我公司有一个销售的系统，该系统基本上由运行Ubuntu 12.04的微型计算机“ Smartbox”组成。此框运行Django应用程序以及与此相关的许多不同的新贵进程。没什么。我们在现场有成千上万个这样的盒子。我们通过deb软件包管理软件包的依赖关系，过程注册等，并获得不同程度的成功。

我们需要一种有效，强大地将更新发布给我们的用户的方法。我们还需要一些东西，当我们升级操作系统时（如您所知，我们已经过时了进行Ubuntu升级），我们可以对我们的软件包“可以正常使用”感到相对安全。

我对Docker知之甚少，但是当我第一次听说我们的问题（我是新员工）时，Docker是我的第一个想法。但是我想得更多，我觉得可能不是，因为这些盒子是我们的，我们控制着它的操作系统，这是Docker价值主张的重要组成部分，或者据我所知。因此，如果我们知道我们的机器始终是Ubuntu，那么我们基本上只有Django应用程序和一些要运行的进程，那么Doc​​ker是否比deb包更好？

TL; DR：适用于始终运行Ubuntu的分布式设备的Docker vs deb软件包，因此平台独立性并不那么重要。

我不是100％确信我从这个问题中明白了，但听起来Docker解决方案将是从拥有（物理？）设备并装有OS和您的应用程序，到拥有OS和在其上运行Docker的单个容器中。但这并不能消除在主机中更新操作系统的需要，它增加了一层复杂性（还有许多更新需要应对，因为您现在必须对Docker 和 OS进行修补）而没有明显的好处。就问题中提到的具体领域而言。

但是，如果您要谈论的是从虚拟设备转移到Docker容器，则可能会为您带来麻烦，但同时也会将Docker添加为产品的依赖项。您将不使用Docker且不想将其添加到其堆栈中以使用您的产品的任何人拒之门外。您可以通过像以前一样继续交付（现在为“旧版”）虚拟设备来继续支持那些不使用/不使用Docker的设备，但是现在您的工作量增加了一倍，因为您需要支持两个发行版而不是一。

我在Docker工作了很长时间。平台独立性很好，但是对于我来说，这并不是最有用的。

首先，您将获得可重复性。您可以创建一个Dockerfile，在开发人员机器上的容器中调试，在连续集成服务器上运行测试，然后在最终产品中运行，并且您知道它在所有这些环境中的行为都相同。不要忘记开发人员已经在其计算机上安装了依赖项。另外，您的开发人员不必在办公桌前使用Ubuntu。重要的是要使我们的Arch Linux用户满意:-)

其次，对于您的升级方案，您可以一次将多个版本拉到计算机上。如果您正在运行一段docker pull myapp:2.0时间，1.0则可以2.0非常快速地切换到。比完成完整的操作系统升级要快得多。如果您将协调器与多个微服务实例一起使用，则甚至可以进行滚动升级，而根本不会中断服务。

如果您使用微服务模型，则Docker还提供了沙箱，这些沙箱可以限制攻击者在受到攻击时可以造成的损害。他们只获得一个容器的控制权，而不是获得整个机器的控制权。

主要缺点是您需要主机操作系统和某种编排。有很多选择，但是不要低估评估，放置和维护它所需的工作量。

总的来说，泊坞窗为开发人员和操作人员提供了许多优势。我将docker用于我的某些应用程序，并发现它是一种非常可靠且强大的方法。

我采用docker的问题是，我听不到您提出正确的问题，如果不解决最重要的要求，您的生活可能会变得更加复杂。

您应该问的第一个问题（您说自己是新手）是如何处理OS和应用程序的更新？当前的方法学对您（您的公司）有效吗？哪个运作良好？有什么可以改进的？您可以在目标计算机上进行物理配置审核吗，以验证它们是否具有正确的OS补丁，应用程序以及是否存在未经授权的更改。

我喜欢docker，但在不首先评估您现在所处的位置（包括哪些方法行得通和需要改进的地方）之前，我不会跳槽docker潮流。

尽管存在一些微小的重叠区域，但Docker和Debian打包系统本质上解决了两个非常不同的问题：

• Debian打包系统旨在在主机上安装软件并尽可能轻松地对其进行升级。它能够处理软件组件之间的复杂依赖性和约束模式，例如“软件X版本A要求软件Y安装了版本B或更高版本”或“软件X绝不应该安装软件Z版本C”。

• Docker系统旨在轻松地描述和部署服务，尤其是微服务，并可能在多个主机上进行部署，例如Docker群或Kubernetes集群。

这两个问题本质上是正交的，这意味着在解决要解决的部署问题的情况下，可以将其中一个（或者两个都使用，甚至可能都不使用）作为解决方案的一部分。当同时使用它们时，Debian软件包将用于生成Docker映像，并且您的Dockerfile（用于准备Docker映像的配方描述了在容器中运行的“虚拟化系统”）将在实质上将您的Debian存储库注册到Debian打包系统的源文件并安装您的软件包。

考虑到这一点，在我看来，您真正想要的是实现不可变服务器模式。云技术的最新发展使升级软件成为可能，而不是通过使用软件包系统（例如Debian打包系统）中的经典软件升级系统，而是通过一次更换整个服务器来进行。（在开发此产品之前，有人通过在服务器上安装三个OS，两个用于交替运行该设备的OS和一个专用于执行设备更换的微型OS来进行此操作。虽然并不太复杂，但这似乎始终是这种技术可能对您很感兴趣，因为如果您习惯使用软件包管理器来升级服务器上的软件，则服务器的最终状态取决于服务器的“升级历史记录”，尤其是如果升级过程。这种异质性不好

我们在现场有成千上万个这样的盒子。我们通过deb软件包管理软件包的依赖关系，过程注册等，并获得不同程度的成功。

可能与此有关。不变的服务器模式通过从问题中破坏“升级历史记录”的概念来消除这种错误源。

现在，有很多选项可以实现不变的服务器模式，两个流行的选择是使用Docker映像，映像或使用云提供商的“主实例映像”（AWS中的AMI，在Google Compute Engine中只是自定义映像） 。您的用例禁止使用基于云的技术，因此，我将Docker映像视为唯一合格的选择。（为了完整起见，当然可以使用其他方法来替代Docker，例如使用Virtual Box或类似的虚拟化解决方案。）

使用不可变服务器模式技术时，您将引入一个代表服务器的新工件（Docker映像），并且也可以对该工件进行测试，并且很容易获得可以真实复制您的生产设置的设置（除了服务负载）。

现在考虑您描述的具体问题，让我们假设实际上需要使用Docker实现不可变服务器模式。由于Docker系统和Debian打包系统是互补的，而不是相互排斥的（请参阅介绍），所以我们仍然必须解决是否应该为软件准备Debian软件包的问题。

使用Debian软件包（在Docker映像中或在主机上）安装软件的相关性在于必须解决的版本控制问题的复杂性。如果您同时运行多个软件版本，则有时需要降级，并且需要仔细记录复杂的版本要求，因此必须拥有Debian软件包。否则，可以跳过此步骤–但由于您已经在努力生产和部署这些软件包，因此放弃工作没有真正的价值。因此，我建议继续生产您的Debian软件包。

我认为这可能是个不错的选择（需要进一步测试）

您可以提供包含所制作容器的所有标签/版本的URL，客户端将读取该URL以查看容器是否有新版本。

您可以将个人文件/设置存储在本地，并且在升级过程中不会丢失任何信息，并且可以确保所做和测试的内容以相同的方式适用于所有人。

甚至您也可以给用户提供从他们想使用的版本中选择哪个版本的可能性（如果您愿意的话）。

就像“仅升级一个软件包”，谈论只检索容器的新版本，这比处理debian软件包要好得多；）

Docker对我来说听起来很合理，因为您可以在内部对容器进行更改和测试，然后根据您的发布过程，始终使用：latest或类似的方式重启容器，以提供经过测试的升级。

您需要处理的注意事项包括数据存储，因为容器在重新启动时不会保留更改，因此您需要一个数据量。一旦深入研究，您可能还会有更多注意事项。我目前正在使用的系统（所有基于docker的系统）已经开发了一年多，我们仍在寻找需要更改容器，配置等的区域。