Docker适合我的用例吗？

#1 楼

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

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

#2 楼

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

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

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

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

主要缺点是您需要主机OS和某种编排。有很多选择，但是不要低估评估一个，放置它并进行维护所需的工作量。

#3 楼

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

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

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

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

#4 楼

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


Debian打包系统旨在在主机上安装软件并尽可能轻松地对其进行升级。可能。它能够处理软件组件之间的复杂依赖性和约束模式，例如“软件X版本A要求软件Y安装了版本B或更高版本”或“软件X绝不应该安装软件Z版本C”。
Docker系统被认为可以轻松地描述和部署服务，尤其是微服务，可能在多个主机上-例如

这两个问题本质上是正交的，这意味着如果要解决部署问题，则可以使用其中一个，或者两者都使用，甚至可能都不使用，作为解决方案的一部分。当同时使用它们时，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软件包。

#5 楼

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

您可以提供一个URL，其中包含您所创建容器的所有标签/版本，客户端将读取该URL以查看是否存在容器的新版本。

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

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

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

#6 楼

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

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