我们有一个严重依赖 websockets 的应用程序。由于我们的应用程序是软件即服务,因此我们的客户可以使用他们自己的域(并通过 CNAME 将其转发到我们的服务器)。目前,我们使用反向代理来平衡多个固定 IP 后端服务器之间的传入流量。
我们现在想将我们的架构迁移到docker,支持动态升级和降级,所以我们当前的反向代理不再可用,它无法自动在我们的AWS ECS Docker集群中找到后端服务。
预期的基础设施看起来像这样:
+-> Docker Container 1
Clients --> Load Balancer --+-> ...
+-> Docker Container n
然而,我们有多重限制:
- 我们需要支持 ACME 协议才能获取 Let's Encrypt 或 AWS ACM SSL 证书
- 我们需要为 websocket 建立粘性连接(直到一个节点发生故障)
- 负载均衡器和后端服务器之间的连接需要加密
- 我们的每个客户都有自己的域名,因此我们需要支持数百个不同域名的传入 HTTPS 连接。
- 多个不同的域名不得共享一个 SSL 证书,以防止查找我们的客户群
- 负载均衡器需要找到来自同一服务的新容器
有什么建议适合我们使用的负载均衡器吗?
编辑:应用程序负载均衡器不适用于我们的使用,因为目前它们的证书数量限制为 25 个
答案1
好像应用程序负载均衡器是您最好的选择。
我们需要支持 ACME 协议才能获取 Let's Encrypt 或 AWS ACM SSL 证书
AWS ACM 无疑是 ELB/ALB 的一个更简单的选择。
我们需要为 websocket 建立粘性连接(直到一个节点发生故障)
打钩。
负载均衡器和后端服务器之间的连接需要加密
勾选。您可以在容器上拥有自签名证书,ALB 会对此感到满意。
我们的每个客户都有自己的域名,因此我们需要支持数百个不同域名的传入 HTTPS 连接。
打钩。
多个不同的域名不得共享一个 SSL 证书,以防止查找我们的客户群
每个 ALB 的证书数量限制为 25 个 - 我猜可以通过支持单增加。即使没有,您也可以设置多个 ALB,也许可以在不同的地区为不同的客户子集设置。
负载均衡器需要从同一服务中找到新的容器。
这将成为您的容器部署的一部分。
看着AWS ECS (弹性容器服务),AWS Fargate(无服务器容器平台)和AWS EKS (弹性 Kubernetes 服务)这些都是不同的跑步方式Docker 容器在 AWS 上,每种方式都有其优点、缺点和不同的定价。它们都可以无缝地与应用程序负载均衡器。
或者看看网络负载均衡器但是您必须处理容器中的 SSL 终止,包括 SSL 证书的分发和轮换(可以通过 S3 或 EFS 等共享存储完成)。
希望有帮助:)