Fundamentally redesign stack network setup

[sm453]

The current design of a stack involves an nginx container routing all (http) requests to their relevant containers, mapping external URLs (with ports) to container-internal URLs (with potentially different ports).

This design is a show-stopper that prevents many off-the-shelf containers (e.g. from docker hub) from being usable within the stack. For example:

1. Some containers provide multiple endpoints on a single host URL at different ports. Even if one were able to map these to separate external URLs (which, I believe, isn't currently possible), this can break API libraries that are meant to be used with the container but were not designed for separate URLs.
2. Many containers provide front-ends that are not relocatable to different external URLs. They become unusable when hosted as part of a stack (on a custom external URL).

Do we need a fundamental re-think of our approach?

[gpeb2]

My first point is that this is only an issue with the web interfaces of these containers, the backends generally work fine.
This leads to the question of whether we intend users to access that web interface or whether it is more of a developer facing thing.
If it's the latter then I'd propose we make a clearer distinction between user-facing web interfaces and developer-facing ones. The former should be exposed via Nginx whilst the latter could be accessed more directly but in a way that is less public.

[sm453]

Example 1 illustrates how containers that just expose endpoints and no web-interface can break.

[gpeb2]

It's certainly possible to provide different routes for different ports. The only issue comes when a response contains a back reference as an absolute path. This is most often an issue with a web interface that has been optimised (i.e. nodejs) but I suppose might also be an issue with a Rest API that used absolute URLs.

One solution might be to expose more ports via Nginx (currently we just expose 80 and potentially 433, which are the defaults for http and https).

[sm453]

The issue is the following: A container may listen for requests on http://localhost:port1/ and http://localhost:port2/. Even if we map this to http://myhost:3838/endpoint1/ and http://myhost:3838/endpoint2/, this will not help us if the API library that one must use to talk to the container can only be configured to use addresses like http://host:port but not http://host:port/subpath/.

[gpeb2]

If we used ports we should be able to avoid the added subpaths.