在生产中使用 ngrok：不再仅仅用于测试

在庞大的全球网络中提供数字服务的最大挑战是让这些服务能够安全地相互通信。保护端点通常并不像保护它们之间的路由那么困难。

如果您曾经使用 ngrok 生成临时安全隧道，以便服务和浏览器即使托管在 上也可以联系您的应用程序localhost，那么您可能已经问过自己是否有可能以同样无摩擦的方式交付生产应用程序和 API。

如果您在开发团队的网络甚至个人笔记本电脑上准备测试 API，ngrok 可让您在本地端口上打开 HTTPS 端点。您可以在笔记本电脑上启动应用程序，通过命令行调用 ngrok，现在另一个大陆的 beta 测试人员就可以进入了。

您附近的网络组件

当您在服务级别解决网络入侵问题时，一开始看起来并不那么容易。您很快就会意识到，微服务架构的消息传递协议使这一挑战增加了千倍。当从网络外部联系微服务时， API 网关会使用各种 Web 协议、内部协议以及 Kafka 使用的事件流协议来路由消息。理想情况下，良好的 API 网关可以足够高效地分配消息间流量，因此您不需要单独的负载均衡器。

在现代网络应用程序架构中，每个使服务能够从网络外部安全访问的重要功能（网络工程师称之为“南北流量”）都需要专用于该功能的网络组件。

因此，无论您是应用程序开发人员还是网络安全工程师，套用芝麻街鲍勃的话来说，这些就是您附近的单位：

• 网络地址转换 (NAT) 网关：将私有 IP 地址公开
• 安全网关 (SWG)：执行入站流量策略和限制
• API 网关：作为你的 API 与外界沟通的总机
• 负载均衡器：用于在请求服务的活动实例之间公平分配请求
• 入口控制器：为微服务提供反向代理和负载均衡器的功能
• 身份和访问管理器 (IAM)：验证服务并为它们之间的流量提供加密

每项功能一个组件的方法的问题在于，它会产生一定程度的架构复杂性，而这本身就构成了安全问题。此外，部署专门的代理来管理南北流量会增加 IT 的成本和工作量，因为必须部署、配置和维护每个代理，包括确保及时应用安全补丁。

“The Full Front Door”

部署如此多服务的替代方案是使用一个实用程序，将活动组件的数量减少到仅提供安全入口所需的组件。这就是 ngrok 重新进入画面的地方。

您可能从未想过 ngrok 实际上可以成为您的入口控制器。也就是说，您可以让 ngrok 组件成为应用程序或 API 中的全职操作员，管理对您的 API 的 HTTPS 调用，并在粒度级别有效地将任何经过身份验证的远程应用程序与您的本地微服务应用程序集成。

ngrok 的解决方案架构师Shub Argha表示：“[Ngrok] 移除了架构在生产中通常具有的移动部件。这些移动部件通常包括设置某种 Web 网关。”

Argha 表示，在传统的微服务应用中，服务被置于一个用于对用户进行身份验证的 Web 网关、一个用于分配流量的负载均衡器和一个用于将流量路由到最终目标地址的单独 NAT 网关（基本防火墙的主要组件）后面。这种网关通常允许通过私有子网访问资源，该子网连接了大量的内部 IP 地址。如何以及何时访问这些资源由防火墙管理的一组策略决定。传出的流量将在离开网络时通过相同的 NAT 网关进行路由。

“使用 ngrok，使用我们的入口控制器或 API 网关，它可以取代所有这些东西，”Argha 表示。“我们是‘全前门’。我们将提供负载平衡以及这两个网关，因此您不必设置它们。”

Argha 解释说，尽管 ngrok 确实提供了入口控制功能，但一旦将其集成到网络应用程序中，它还可以充当负载均衡器、Web 网关、NAT 网关和 API 网关的功能。这样一来，ngrok 还承担了安全工程师为这些组件分别制定的所有规则和策略的责任——Argha 指出，这些组件“将具有额外的安全规则，所有这些规则都必须由您构建并由安全团队管理。”

Ngrok 的身份验证功能和安全策略均由网络外部的托管服务 ngrok Edge 处理。“您只需设置我们的入口控制器，它就会与我们的托管服务建立出站连接，然后托管服务会自动为您提供该连接。”

使用从 ngrok Dashboard 服务获取的凭据，通过Helm Kubernetes 包管理器( helm install)安装 ngrok 作为入口控制器或“入口操作员” 。使用它，您可以创建一个命名空间，然后应用一个 YAML 文件，将该命名空间分配给指定的网络端口。

相比之下，Argha 表示，其他入口控制器（如HAProxy和NGINX）除了设置组件、建立防火墙规则和策略、设置负载均衡器和网关以及确保 DNS 服务指向正确的端点之外，还需要实施者。“在您的应用程序上线之前，您还需要采取更多额外步骤，”他补充道。“使用 ngrok，您就不需要了。”

90 度大转弯

Argha 表示，这种易于实现的特性使 ngrok 能够与服务网格进行协调。换句话说，运行在网络上的服务（该网络的可访问端点需要配置为使用 API 网关运行）可以通过 ngrok 自动设置的路由访问 ngrok API 网关。

Argha 绘制的模型表示客户端应用程序与使用 ngrok 代理构建的订阅音乐服务之间的网络交互。Ngrok 的 API 网关管理音乐服务的流量，代理将请求转发到应用程序内的各个服务。

该图中心的 ngrok Edge 平台是一项托管服务，负责右下角黄色框中列出的所有功能，包括身份验证和授权。后端应用程序不再负责这些功能，这意味着应用程序不再容易受到原本负责这些功能的组件的攻击。

同时，ngrok 代理能够将入站远程请求转发到各种服务。与现有的任何服务网格相结合，这使得远程客户端能够更直接地处理服务，就好像它们是独立的应用程序一样。对于音乐服务示例，这意味着在智能手机上运行的客户端应用程序可以向播放列表服务发出与播放列表相关的功能的请求。“搜索”pod 中的服务可以接受搜索请求，就好像它们是“搜索应用程序”一样。这改变了流量本身的性质，将Kubernetes pod 的角色提升为一等公民。

Argha 解释道：“Ngrok 可以让你进入不同 Pod 中所有这些不同的 Kubernetes 服务。”“Kubernetes 的优势在于，如果一个 Pod 突然死机，[Kubernetes] 可以自动将其启动。或者，如果一个 Pod 的流量很大，它可以开始创建更多 Pod。ngrok 真正擅长的是将流量路由到搜索（从图表中）或播放列表。”

由于 ngrok 本身并不是服务网格，因此它无法了解服务中 pod 的健康状况或数量，也无法了解 pod 之间的流量水平。您仍然需要一个服务网格。在最近由 ngrok 和 Buoyant 联合制作的YouTube 视频中，Argha 和他的 Buoyant 同事 Flynn 演示了如何将 ngrok 与Linkerd集成。在演示中，Flynn 首先花了几分钟在后端安装 ngrok，只是为了展示这个过程是多么简单和快速。

但 Linkerd 并不是 ngrok 集成的唯一服务网格。最近，Argha 尝试将 ngrok 与Red Hat管理的开源项目Skupper 配对，从技术上讲，Skupper 并不将自己标识为服务网格。相反，它是一个第 7 层网络服务互连平面项目。在这样的配对中，ngrok 管理南北路由，Skupper 处理东西路由。“这是 ngrok 的 90 度旋转，”Argha 评论道。然而，他补充道，“ngrok 可以与任何服务网格配对，并且工作方式相同。

“使用 ngrok，因为我们负责处理互联网层，”他继续说道，“使用我们的产品进行的其他所有操作都使您不必担心设置互联网层。这就是我们的优势所在，”Argha 说道。