CF Dev does not fully expose TCP Routes / Non-standard Ports
teespoon opened this issue · comments
CF Dev should allow a TCP route / non-standard port to be fully exposed to the host. Three versions/setups were tested and failed:
- 0.0.11 (no iso)
- 0.0.10 (no iso)
- 0.0.9 + pcfdev-pas.v.2.0.20.0-build.0.82.0.iso
However, these VirtualBox-based local CF installations succeeded:
All were tested with an analogous setup. See "Repro Steps" below.
For Simplicity, use a Docker Image
We don't have to make our own CF app. Per the docs, we can use a Docker image that uses an EXPOSE directive with a non-standard port:
If you specify the EXPOSE directive, then the corresponding app pushed to Cloud Foundry listens on that exposed port.
Repro Steps
Note: Using Windows Powershell syntax. You may need to adjust slightly based on your OS.
1. Discover the default TCP router-group GUID and modify the port range to include the port we are interested in (in this case we are testing with the default Redis port, so 6379)
PS C:\path> cf curl /routing/v1/router_groups
PS C:\path> $json=@"
>> {\"reservable_ports\": \"1024-6399\"}
>> "@
PS C:\path> cf curl /routing/v1/router_groups/d6962e2e-7099-4f79-79d8-aef0612cde04 -X PUT -d $json
2. Create a TCP domain (IF your CF installation does not include one) using the TCP router-group exposed in Step (1).
PS C:\path> cf create-shared-domain tcp.MY-DOMAIN-NAME --router-group default-tcp
MY-DOMAIN-NAME might be dev.cfdev.sh or local.pcfdev.io or something else, depending on your install. @emalm in Issue 301 also suggested just using the IP address directly.
3. Push an app with a non-standard port and map a TCP route to it.
PS C:\path> cf push myredis -o redis --no-route
PS C:\path> cf map-route myredis tcp.MY-DOMAIN-NAME --port 6379
4. Test access to the port from the host.
PS C:\path> redis-cli -h tcp.MY-DOMAIN-NAME ping
PS C:\path> telnet tcp.MY-DOMAIN-NAME 6379
@teespoon Unfortunately cfdev has a different architecture than the previous virtualbox-based product pcfdev. Ports must explicilty fowarded inside of the VM before you see them. That includes the tcp ports. This product only has these ports routable for tcp routing 1024-1049, for the time being.
Our suggestion is to change your redis instance to listen within that port range instead, as this is the path of least resistance.
Thanks @aemengo for the info.
Would it be possible for CF Dev to publish an error if non-default ports outside of this range are pushed in a dockerfile EXPOSE and/or defined in a CF TCP Route since CF Dev (and thus, new versions of PCF Dev) will not support them?
I'm confused by this discussion. One benefit of the TCP router is to decouple the port that the service instance listens on from the port that external clients use to connect to it. In this example, the redis server in the container can continue to listen on port 6379 on the network interface specific to its container, and any external clients can connect to a port in the 1024-to-1049 range on the TCP router's IP address. The developer pushing redis as a CF app selects that external port when creating and mapping the TCP route, and then must communicate the entire socket address (IP and port) to its clients.
@teespoon Unfortunately our team is only tasked with packaging the product for the local use case. We'd love to publish an error as you've requested, but it would not only be beyond the scope of this project and its engineers but would be very non-trivial.
Moreover I think there was some confusion regarding the previous comment. CF Dev has a hard limit on the ports you can access from the outside of the VM, as is posted with in the README.md link that I've posted.
@teespoon would you mind sharing a bit about your use case? We are looking to better understand how people are using CF / PCF Dev, and what they are looking for. Your answers to this 4 question survey would be very helpful to us: https://goo.gl/forms/3OHzU2S5907hiu5r1