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

如何解决关于用户控制的 Docker 实例的架构问题

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

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

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

解决方法

以这种方式使用 Docker 存在严重的安全性和复杂性问题，我不建议这样做。

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

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

如果你这样做：

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