google-chrome - Websocket 与多个 Chrome Docker 容器的通信

Question

我有一个 Chrome 容器(使用 this Dockerfile 部署)，它根据来自 App 容器的请求呈现页面。

基本流程是:

• 应用程序向 Chrome 发送一个 http 请求，并作为响应接收一个要使用的 websocket url(例如 ws://chrome.example.com:9222/devtools/browser/13400ef6-648b-4618-8e4c-b5c73db2a122)
• 然后应用程序使用该 websocket url 与 Chrome 进一步通信，并接收呈现的页面。我正在使用 puppeteer library使用 puppeteer.connect({ browserWSEndpoint: webSocketUrl });
连接到 Chrome 实例并与之通信

对于单个 Chrome 容器，这非常有效。

但我正在尝试扩大规模，以便在 Docker 群中拥有多个 Chrome 容器。

我认为，问题在于，App 接收的 websocket url 特定于在该特定 Chrome 容器中运行的实例，因此当 App 使用它时(并且现在有多个 Chrome 容器)，websocket 请求from App 不一定会路由到正确的 Chrome 容器。

处理这个问题的最佳方法是什么？

Answer 1

您的基本设计是正确的，但您遇到的问题是 session “粘性”。然而，与其尝试将后续请求重新路由回适当的机器，我们应该寻找一种方法来避免“预”请求。

最好的方法是让你的 Chrome docker 镜像在所有 http“升级”请求中居中。这个 http 操作是所有 WebSocket 连接在更改协议(protocol)之前发出的，包括 puppeteer 库(这只是一个 WebSocket 客户端)。这样做也将消除对预连接调用的需要，因为对 Chrome 的代理将在升级时发生，而不是公开一个 URL 供应用程序使用。这是使用 http-proxy 执行此操作的一个非常基本的示例。模块:

const http = require('http');
const httpProxy = require('http-proxy');

const proxy = new httpProxy.createProxyServer();

http
  .createServer()
  .on('upgrade', async(req, socket, head) => {
      const browser = await puppeteer.launch();
      const target = browser.wsEndpoint();

      proxy.ws(req, socket, head, { target })
  })
  .listen(3000);

这种方法还有其他好处:您可以限制并发等内容，甚至可以注入(inject)稍后运行的脚本。这些虽然需要更多的准备和准备，但总体思路保持不变。这也使负载平衡变得微不足道，因为不需要使路由变得粘滞。

如果您有兴趣在 browserless 中实现所有工作，大部分工作都会为您完成。 repo 。它甚至允许并发限制、 session 时间限制和 includes a feature-rich IDE 等。 .您可以找到更多docs on that project here .