Multiple ports with public URL?

Resin.io exposes port 80 with a static public URL: https://docs.resin.io/management/devices/#enable-public-device-url

I have services which use multiple ports. For example, a simple static web app served on port 80 which communicates to an API over another port.

How can I accomplish this with Resin.io?

Hi, thatā€™s currently not possible though the Public URL to expose more than one ports.

In your particular case, Iā€™d probably assemble your app such, that both the web app and the API are on the same port, but the API is namespaced with e.g. an /api/ path. Many setups do this readily (e.g. Python/Flask apps that Iā€™ve used combined dynamic APIs and static web apps readily). This of course works easier if the whole app is the same framework. If not, then might need a server in front of the status app and the API to do the redirects (caddy or nginx, for example).

1 Like

Thank you for your prompt reply!

This is unfortunate. Using the same port with nginx routing requests to different namespaces (e.g. /api/ path) is a good idea. However, in some cases I do not have control over this. For example, the Deluge BitTorrent server uses a port for the web app, and separate ports for the APIs: https://github.com/Glavin001/resin-deluge I do not think I have control to configure the clients to send requests to :80/api/ and instead only can change the port number.

Is this a feature planned in the future, or something Resin.io does not expect to support?

As Iā€™ve quickly tried deluge-web, I think itā€™s connecting to the server through the localhost. So Iā€™m guessing in this particular case you donā€™t actually need to expose any other port, but move the default deluge-web port from 8112 to 80. Might be wrong about it, but the web interface didnā€™t seem to connect to any other port. Might worth a bit more checking out. :mag:

It is not currently planned, but will be discussing this possibility!

Yup, I have deluge-web port serving on 80. However, deluge itself uses other ports for connecting with the a ā€œthin clientā€ remotely, such as the ā€œdaemon_portā€: https://github.com/Glavin001/resin-deluge/blob/master/core.conf#L13

So far deluge-web has been great and works flawlessly ā€“ itā€™s API is over port 80 as well using an endpoint /json. The thin clients are the only feature I lack when I am away from home.

Thanks for looking into it! Hopefully something Resin.io team can consider :slight_smile:.

1 Like

Ah, so if I understand now, you are using both deluge-web and the thin clients, thatā€™s why you need two ports accessible? deluge-web uses that port too, but it can do it within the localhost, so wouldnā€™t need any extra ports.

Yeah, will keep you posted if thereā€™s any development regarding this feature.

Is this still actively being discussed? I could really use multiple ports exposed publicly as well.

1 Like

Hi @aafrey at the moment this is not actively discussed, but Iā€™ll add a +1 from you in our internal feature tracker for this item. Iā€™ll also link this thread with the feature, so once we implement this, we can notify you in this thread.

3 Likes

@afitzek appreciate the reply. i could also make due with more flexibility in URL structuring :slight_smile: been playing with a reverse proxy setup with multicontainer deployments, but using subdomains would provide more flexibility than just routing on paths. it looks like the device ID is used as an initial subdomain, but can it be broken down further i.e. foo.<device id>.balena-devices.com? i think having that would solve all my use cases.

@aafrey Cool, Iā€™ll add this suggestion to our feature tracke. Iā€™ll note it like this, start forwarding basically all subdomains to the devices. So *.<device id>.balena-devices.com would be forwarded to the device, in which case you can use a reverse proxy to route to all other containers and expose multiple services.

1 Like

:metal: appreciate it!

also have the same request:
im my case: Grafana on Port 3000, Node-Red on 1880, and a Webserver entry point on 80.

Hi @echteler, currently its not possible, but we are hoping to enable this kind of thing later this year. For now the way to do it would be to use something like HAproxy (as done in https://github.com/balena-io-projects/multicontainer-getting-started ) to route traffic to specific container ports via the public URL.

2 Likes

Thanks for the info. looking forward to the new feature :slight_smile:
i managed in the meantime to do it via nginx reverse proxy :slight_smile:

hi, is this feature available now, i.e. multiple ports? we have two express servers, each serving a different port. thanks!

1 Like

Looks like this is ā€œIn Progressā€ https://trello.com/b/9CSzdCXQ/balena-product-roadmap

Any status on multi-port support? The provided roadmap link is not showing anything related to multi port support

Hey, nothing to update here since using a reverse proxy would allow you to achieve this for most cases, but we are still keeping an eye on this and upvoting it internally as people ask for it.

I have a use case where a webpage and read only file listing is available on port 80 for the resin-vpn interface which is provided on the balena public url on 443/80.

I uses HSTS to ensure HTTPS connection on the balena url which has been advised for in Public url via http to ensure ā€˜secureā€™ connection eventhough RFC6797( https://www.rfc-editor.org/rfc/rfc6797.txt ) guides against HSTS in HTTP, see section 7.2.

The webpage and file listing is working as expected.

Additionally I try to provide WebDAV via the balena public url. I can use the unsecure port 80 for webdav access. If I try to connect to the Webdav on port 443, then the initial handshakes are performed on port 443 and then downgraded to port 80 for all remaining data transfers. This is no good.

In this case apache should redirect port 80 to port 443, but 443 is not accessible from the public url.

Hi there. Weā€™ve pinged the team behind the public URL feature to see if anything has progressed with this feature. One of them will post an update here when they can.

Cheers,
James.