从ManagedVM中泄露多个端口 [英] Exposing multiple ports from within a ManagedVM
问题描述
我正在使用托管虚拟机功能来运行WebSocket服务器，我想通过以下网址在任何端口（最好是端口80）上暴露在Internet上：mvm.mydomain.com
I'm using the Managed VM functionality to run a WebSocket server that I'd like to expose to the Internet on any port (preferably port 80) through a URL like: mvm.mydomain.com
我没有太大的成功。
这是我用来完成这个的各种文件的相关部分：
I'm not having much success yet. Here are the relevant parts of various files I'm using to accomplish this:
Dockerfile：
Dockerfile:
EXPOSE 8080 8081
在Dockerfile的末尾，启动了一个Python应用程序：它响应端口8080上的运行状况检查（我可以验证此功能），并响应端口8081上的WebSocket请求。
At the end of the Dockerfile, a Python app is started: it responds to health checks on port 8080 (I can verify this works) and responds to WebSocket requests on port 8081.
app.yaml： / p>
app.yaml:
module: mvm
version: 1
runtime: custom
vm: true
api_version: 1
network:
forwarded_ports: ["8081"]
我将这个应用程序部署到云端：
I deploy this app to the cloud using:
$ gcloud preview app deploy .
在云端控制台中，确保TCP端口8080和8081被接收到入站流量。我也观察分配给GCE实例（mvm：1）的IP地址是：xyzz
In the cloud console, I make sure TCP ports 8080 and 8081 are accepted for incoming traffic. I also observe the IP address assigned to the GCE instance (mvm:1) is: x.y.z.z.
$ curl http://x.y.z.z:8080/_ah/health
$ curl http://mvm.my-app-id.appspot.com/_ah/health
再次使用 200 OK 。
使用一些连接WebSocket服务器JavaScript也是如此：
Connecting the WebSocket server using some JavaScript works as well:
new WebSocket('ws://x.y.z.z:8081');
到目前为止这么好。除非这不工作（超时）：
So far so good. Except this didn't work (timeout):
new WebSocket('ws://mvm.my-app-id.appspot.com:8081');
我想知道为什么上述WebSocket命令不起作用。
也许在GAE / GCE端口转发互动中我不明白什么？
I'd like to know why the above WebSocket command doesn't work. Perhaps something I don't understand in the GAE/GCE port forwarding interaction?
如果这样做可以以某种方式工作，我想像下面将会是最后一步完成它。
If this could be made to work somehow, I envision the following would be the last steps to finish it.
dispatch.yaml：
dispatch.yaml:
dispatch:
# Send all websocket traffic to the ManagedVM module.
- url: "mvm.mydomain.com/*"
module: mvm
我还在mvm.mydomain.com上设置GAE自定义域CNAME。
I also setup the GAE custom domain CNAME at mvm.mydomain.com.
使用JavaScript连接WebSocket服务器应该像：
Connecting the WebSocket server using JavaScript should then work like:
new WebSocket('ws://mvm.mydomain.com:8081');
推荐答案
可能是从<$考虑到在（相对较近）发布受管理的虚拟机之前，没有执行c $ c> appspot.com ，唯一的流量去了 appspot.com 在80或443端口。我建议使用您发现的IP-of-instance方法。
It may very well be that port forwarding from appspot.com isn't performed, given that prior to the (relatively recent) release of managed VMs, the only traffic that went to appspot.com was on port 80 or 443. I'd suggest using the IP-of-instance method you found to work.
如果没有找到满意的话，你应该去应用程序引擎的公开问题跟踪器，并发布功能请求以使 appspot.com 路由器检测请求是否正在标题对于与托管VM对应的模块，并尝试在这种情况下进行端口转发。
If you don't find that fully satisfying, you should go to the public issue tracker for app engine and post a feature request to have the appspot.com router detect whether a request is heading for a module that corresponds to a managed VM and attempt the port forwarding in that case.
事实是，将原始端口放在域名的末尾，这意味着您的浏览器将使用您指定为appspot.com的连接参数的端口，不是作为一个查询param，所以appspot.com将必须监听所有端口和重定向如果有效。这可能是不安全/低效的，所以也许端口号可能是查询参数或域字符串的一部分，类似于可以如何指定版本和模块...
The thing is, putting the raw port on the end of the domain like that means that your browser will use the port you specified as a connection parameter to appspot.com, not as a query param, so appspot.com will have to listen on all ports and redirect if valid. This could be insecure/inefficient, so maybe the port number could be a query param or part of the domain string, similar to how version and module can be specified...
无论如何，考虑到端口的工作方式，我非常怀疑，如果您的非常简单的示例导致失败，该应用引擎的 appspot.com 域甚至设置目前处理端口转发到托管的VM容器。
At any rate, given the way in which ports work, I would highly doubt, if your very simple example caused a fail, that app engine's appspot.com domain was even set up to handle port forwarding to managed VM containers at all at present.
这篇关于从ManagedVM中泄露多个端口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
