动态地将HTTP流量路由到特定于用户的Docker容器

Question

我正在尝试构建一个服务，它将在AWS (最有可能是ECS)的Docker容器中运行特定于用户的java进程。每个用户每个容器一个java进程。这种情况的唯一例外可能是当为一个行为不正常的容器旋转一个替换容器时。java过程是一个打包的软件，不能根据我的需要进行修改。本质上，我希望围绕这个特定的软件构建一个SaaS服务，并且我知道将有许可细节与软件的开发人员一起解决。

java进程有自己的web服务器，其中使用非标准端口(30000-30004)访问其WebUI。它可以根据配置支持HTTP或HTTPS。我计划在每个EC2实例中运行尽可能多的这些容器，以提高成本效益(这意味着在EC2实例上有不同的端口映射到容器的内部端口(30000-30004)。

我想用其他一些元素包装java进程的内置UI，以便控制java进程(停止、启动等)。并通过另一个web服务器或可能的API网关通过Lambda服务我的UI。这将允许用户在必要时启动或停止其实例，整个系统将使用这些请求启动或停止用户的特定Docker容器。

为了给出一个规模的概念，有可能有成千上万的并发用户。预计该项目的市场规模约为100 000名用户。可能的市场规模约为每月200万用户。实际上，用户总数可能约为10,000人，其中约7,500人在任何一个月内都在活动。它的潜在规模可能消除了为每个用户的容器实例使用带有单个目标和目标组设置的应用程序负载均衡器的选项，因为对ALB的限制只允许1000个目标，而只允许100个规则。

为了给出一个变化速度的概念，一个单独的容器可能需要运行几个小时，或者一天或更长的时间，而用户正在与它交互。但有时也可能只使用几分钟。单个用户的容器可能每周或两周只需要一次，或者每天使用一次。

现在，关于这个问题，有什么最好的解决方案来处理到码头集装箱的路由流量？我希望从我自己的域托管所有这些，并使用基于路径的路由将请求发送到适当的容器。

例如，

：

• container1是用于在端口30000-30004的主机ec2-app1上运行的user1。
• container2是用于在端口31000-31004的主机ec2-app1上运行的user2。
• container3用于运行在端口30000-30004的主机ec2-app2上的user3。
• 控件UI将使用iframe或类似于单个容器的以下内容从https://example.com中获得。
• 对https://example.com/user1的请求应该转到container1
• 对https://example.com/user2的请求应该转到container2
• 对https://example.com/user3的请求应该转到container3

除了为会话专门启动的容器外，用户不应该能够访问任何容器。在java进程中有一些内置的身份验证可以用来帮助实现这一点。

我实际上是从一个用户的软件中构建一个多租户服务，我知道我需要构建相当多的定制工具，我并不反对这样做。当需要自定义代码时，我更喜欢使用Python的解决方案，但如果有必要，欢迎使用其他语言。我怀疑我需要在容器或执行容器的EC2实例中包含某种代理或启动脚本，一旦容器启动，这些实例将向路由系统注册容器。然后，我需要查看一个用于删除容器注册的类似的关闭脚本，以及一个用于在容器或EC2实例在没有适当关闭的情况下失败时进行清理的常规系统。我已经研究过HAProxy和Nginx了，我愿意听听关于这些的想法，但是其他的选择也很受欢迎。

提前感谢您的建议！

Answer 1

您肯定是正确的，您将需要创建大量的定制工具来实现这一点，但我认为这是可以做到的。

我这样做的方法是使用应用程序负载均衡器(ALB)和目标组。ALB可以根据路径创建自定义路由，并向特定目标组(read: servers，或在您的情况下是Docker容器)发送通信量，但必须符合路径规则匹配，例如：

• 规则1:路径启动/user1，将流量发送到TG1
• 规则2:路径启动/user2，将流量发送到TG2
• 等等。
• 规则N:默认规则，TGN的所有其他流量(您的主站点、404处理程序等等)

您将需要创建工具；

• 提供为您的用户服务所需的容器(S)。Docker容器可以使用动态端口，相同的EC2/ECS实例可以驻留在不同端口上的多个TG中。一旦集装箱处于活动状态，就找出它正在监听的动态端口(S)。
• 提供一个TG来托管这些容器，并在适当的端口上注册适当的目标。
• 更新您的ALB，为您的路径添加一个新规则，路由到您刚刚创建的TG。
• 重定向用户

您可能可以在Lambda函数的范围内完成所有这些工作。我看不出为什么完成these..the的最长时间超过5分钟，最长的部分是等待容器激活，即使这样也不会太长。