如果我在Docker容器中运行Node.js，是否需要反向代理？
我已经阅读了一些推荐在Node.js应用程序之前使用反向代理（比如nginx ）的文章（就像那个： 在Node.JS之前的反向代理的优点 ）。 比起运行Node.js本身并暴露它更好（至less在安全性方面）。
但是，在Docker容器中运行Node.JS应用程序应该可以防止安全问题（因为应用程序在容器中运行，并与主机系统隔离）。
所以，我的问题是：在Docker容器中运行Node.js应用程序时使用反向代理是否有好处？ 如果是的话，它如何改善我的申请？
每一次我必须设置Nginx代理到Docker容器，不仅仅是安全方面，正如你所提到的，它是自包含在Docker容器中的，而且也是为了方便分布式系统的通信。
在标准体系结构中，您有一个API容器，一个IDP容器和一个前端容器（让我们假设这是一个web应用程序）。 一切都落后于Nginx。 IDP，API和前端暴露于外部stream量…但这里来了有趣的一部分。 假设您想要在不同的容器（地理位置服务，ETL或其他任何地方）上运行附加服务。 那个容器不需要暴露给公众。 只有内部的容器可以和它谈话。
在前面的场景中，请求会碰到前端，前端会将请求发送给API，API将使用IDP（内部调用）来validation令牌，如果没有授权，则将前端redirect到IDP（3脚authentication）或者只是返回403，并通过再次向API发送凭证来获得用户的真实性（2足够authentication）。 那么如果用户需要调用任何附加服务，所有的调用都会先通过API，或者直接映射到Nginx中，直接访问服务，只要确认用户已经被授权使用该服务即可。
我希望能够对Nginx的特定用法有所了解。 请记住，这只是“一个”用例，但是Nginx可以用于许多其他目的。