amazon-web-services - 如何从前端容器访问Docker API容器？

Question

我是Docker的新手，并试图将我的头放在容器之间的网络周围。我正在运行两个容器，一个用于Node.js API服务器的容器，以及一个容纳前端React UI的容器。在本地运行它们时，一切正常。 API服务器公开端口3001，并且可以从我的React站点调用localhost:3001 / api。

鉴于容器的概念是可以在任何地方运行，那么当不在本地计算机上运行时，如何保证这两个容器服务可以连接？我知道可以在docker容器之间建立网络，但这似乎不适用于这种情况，因为react容器不是在发出请求，而是客户端正在访问react容器(因此localhost现在将引用其计算机而不是我的API容器)。

部署此类体系结构的最佳实践是什么？

需要什么样的设置来保证这些容器可以在云部署中进行对话，在该云部署中API主机可以在部署时动态生成？

如果相关，我正在寻找专门部署到AWS ECS的工具。

编辑:

package.json代理仅与开发相关，因为该代理在React应用的生产版本中不会生效。

Answer 1

据我了解，您想将由React前端和Node.js后端组成的经典两层应用程序部署到Amazon ECS(生产环境)。

我们前一段时间为我们的应用程序设置了此功能，我想概述解决方案。

部署此类体系结构的最佳实践是什么？

这是一个非常棘手的问题，因为它还取决于您的问题中未完全指定的两个层次的某些特征。

前端

我想到的第一个问题是，您是否真的需要从Docker容器运行React UI？它是动态内容吗？如果您的React应用程序是为生产而正确构建的(如[1]中所述)，则应为静态内容。静态内容的优点是可以轻松地缓存它，因此在生产中不需要从Docker容器提供内容。情况恰好相反:我认为在生产中从ECS容器中提供静态内容是一种不好的做法。相反，您应该做的是:

创建一个S3存储桶，并将您的静态 Assets 部署到该存储桶中。

(可选)，但强烈建议用于生产环境:使用某种形式的Content Delivery Network(CDN)，以便分发您的内容并将其有效地缓存在边缘。 AWS服务格局为此提供了CloudFront服务。使用CloudFront能否获得返回取决于您应用程序的流量模式。您可以直接从S3存储桶中提供静态 Assets ，这可能会导致更长的延迟，但可能更具成本效益。

总之，我建议您:如果您打算将一些严肃的应用程序投入生产，并且预期会收到大量流量和/或被设计为单页应用程序(SPA)，则 将您的静态 Assets 外包到S3中并提供服务他们通过CloudFront 。

后端

最佳实践很简单:创建应用程序负载平衡器(ALB)，目标组，然后将目标组指向ECS服务。 ECS为AWS Elastic Load Balancing提供了一个集成。在此处使用AWS ALB的优点是会自动为您创建DNS记录。 [3]

但是，如果我真的需要在ECS中使用两个容器怎么办？

如果您决定不外包静态 Assets 是因为您的React内容中包含动态部分，或者上述解决方案的定价不合适，那么让我回答您的第二个问题:

What kind of setup is needed to guarantee that these containers can talk in a cloud deployment where the API host may be dynamically generated at deployment?

在ECS中，有多种策略可以将事物连接在一起。我猜你的React容器不需要直接连接到Node.js容器，对吗？如果这个假设是错误的，请纠正我。对我来说，情况如下所示:

客户端-> Docker容器1“React”(加载例如index.html)

客户端(例如，从index.html内部使用Ajax)-> Docker容器2“Node.js”

如果这两层确实完全独立，则建议 创建两个单独的ECS服务-每个服务运行一个单独的ECS任务定义。其次，您创建一个应用程序负载平衡器，并在每个服务上激活负载平衡器集成。最后，您需要在负载均衡器上为每个服务创建一个单独的目标组，并在负载均衡器上分配一个单独的侦听器，以将流量重定向到相应的目标组。

例:

具有DNS名称的应用程序负载均衡器:my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com

带有React Frontend的

服务A

带有Node.js后端的

服务B

目标组A，它将流量重定向到服务A

将流量重定向到服务B的目标组B

ALB侦听器A，它将负载均衡器端口80上的流量重定向到目标组A

ALB侦听器B，它将负载均衡器的端口8080上的流量重定向到目标组B

(可选):您自己域的自定义DNS记录，该记录指向负载均衡器(通过别名记录)，以便在浏览器中提供更便于客户使用的名称，而不是在aws区域elb.amazonaws中自动创建的记录。 com。

现在可以在负载均衡器域的标准HTTP端口上访问前端，而可以在端口8080上访问后端。您可以轻松地在负载均衡器上激活SSL，而改用端口443。 [4]
这允许SSL在负载均衡器而不是docker容器上终止-一种称为SSL终止的功能[5]。

但是，如果这些容器必须彼此通信怎么办？

通过上面概述的方法，容器能够通过应用程序负载平衡器相互通信。但是，如果此通信本质上是内部的，则这不是理想的，因为它是通过公共(public)负载平衡器端点路由的。如果我们要确保 流量不会在容器之间离开专用网络，我们可以*将它们放在一起:

在ECS [6]中创建任务定义，并将两个容器都放入其中

为任务

指定 "NetworkMode": "bridge"

使用相应容器定义(任务定义内)的Links属性指定容器之间的链接

*再次有多种策略可以实现这一目标，我在这里概述了我所知道的最简单的策略(例如，也可以使用Service Discovery [7]或任务网络模式awsvpc将任务 secret 链接在一起)

我知道这是一个复杂且特别广泛的主题，因为有多种策略各有优缺点，但我希望能给您一些有用的参考。

参考文献

[1] https://create-react-app.dev/docs/production-build/
[2] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html
[3] https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html#resource-record-sets-elb-dns-name-procedure
[4] https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html
[5] https://infra.engineer/aws/36-aws-ssl-offloading-with-an-application-load-balancer
[6] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html
[7] https://stackoverflow.com/a/57540515/10473469