关于用户控制的 Docker 实例的架构问题答案

【问题标题】：Architectural question about user-controlled Docker instances关于用户控制的 Docker 实例的架构问题
【发布时间】：2020-12-27 20:54:32
【问题描述】：

我在 Laravel 中有一个网站，您可以在其中单击一个按钮，该按钮将消息发送到在 Docker 中隔离的 Python 守护程序。这适用于简单的 MVP 来证明一个概念，但它在生产中不可行，因为用户很可能也希望暂停、恢复和停止该过程，因为该服务被设计为永不停止，否则考虑到它是一个循环的扫描仪.

我已经为此考虑了几个解决方案，例如在软件层中修复它，但这会增加程序的复杂性。我用谷歌搜索了 Docker，发现实际上可以通过命令 pause、unpause、run 和 kill 对 Docker 本身做我想做的事情。

如果我有一个服务可以按照上述标准与 Docker 实例交互并且能够从 HTTP 获取命令，那将是最佳选择。 Docker Swarm 是解决这个问题的正确方法还是有更简单的方法？

【问题讨论】：

您的问题不清楚。当您说“用户”时，您指的是什么用户？运行服务的操作人员？ HTML 前端的用户？如果您的意思是操作人员，那么您必须考虑服务中断（因为如果服务关闭，按钮将不起作用）。这包含在可用性概念 (itsm.tools/…) 中。一般来说，Swam 对任何事情都没有用——业界已经转向 Kubernetes 以实现高可用性 (HA)。暂停服务没有充分的理由。
对不起，我指的是网站上的普通用户，已经购买了账号。除了开始、暂停、恢复和停止扫描之外，用户应该没有任何特权（例如从仪表板启动网络爬虫）。我想通过简单地保存服务状态并使用停止和启动操作，暂停和恢复可能是多余的。是否需要进行大量设置才能使 Kubernetes 从 HTTP API 启动和停止 Docker 映像？
为了响应来自浏览器的任何请求，您的服务必须正在运行。因为很难预测用户可能使用您的应用程序的时间，所以该服务通常一直在运行。您没有每个用户的服务，您只有一个服务，它会响应所有用户。我很抱歉这么说，但是你需要大约 3 年的学习和研究才能理解和做到这一点——你应该忽略我以前的 cmets，因为 Kubernetes 对你来说太先进了。我教这些东西，最近的计算机科学硕士毕业生需要大约 6 个月的时间才能跟上进度。
我知道服务必须正在运行才能从消息代理接收消息，截至目前，我有一个始终在侦听消息的服务，但它只能按顺序处理消息。我考虑过拥有一个服务池并具有自动扩展功能，这将解决可扩展性问题。但我不确定如何停止来自网络用户的扫描。您将如何停止通过 Kubernetes 在服务中运行的用户发起的扫描？重新启动该服务？还是通过软件，例如通过发送消息或修改定期检查的 API？

标签： docker service docker-swarm

【解决方案1】：

以这种方式使用 Docker 存在重大的安全性和复杂性问题，我不推荐它。

Docker 安全的核心规则一直是，如果你可以运行任何docker 命令，那么你就可以轻松接管整个主机。（你不能阻止某人从docker run一个容器，作为容器根，绑定挂载主机文件系统的任何部分；所以他们可以将/etc/shadow文件中的主机根密码重置为他们知道的密码，允许远程根ssh 访问，并重新启动主机，例如。）我会非常小心地将此功能连接到我的网络层。将您的应用程序与 Docker 强耦合也会使其开发和测试更加困难。

与其为每个爬取作业启动一个进程，更好的方法可能是设置某种作业队列（可能是 RabbitMQ），并让一个多用户工作人员从队列中提取作业来完成工作。您可以为每个用户创建一个队列，以及一个接收停止/启动/取消消息的单独控制队列。

如果你这样做：

您可以在不需要 Docker 的情况下运行整个应用程序：您需要前端、消息队列系统和工作器，但这些都可以在您的本地开发系统上运行
如果您需要更多爬虫，可以启动更多工作器（适用于 Kubernetes 部署）
如果您生成的抓取请求过多，您可以启动更少的工作人员
如果工作人员意外死亡，您只需重新启动它，其作业仍将在队列中
无需跟踪哪个进程或容器属于特定最终用户

【讨论】：

我认为这听起来像是一个最佳解决方案，它消除了很多我试图尽我所能避免的复杂性。我有一个名为 ZeroMQ 的消息代理，它在将作业发送给工作人员时使用。 “多用户工作者”是什么意思？现在，通信是通过从队列中获取作业，然后通过 REST API 保存结果来进行的。根据我目前的理解，队列是在程序开始时定义的，用户队列将如何工作（例如对于新用户）？