Closed matteo-cristino closed 2 months ago
I have done a bit of research about this but have not found any good solution.
The only alternative that came to my mind is to use a custom request headers that have the full original uri of the request, for example orignal_uri
, and then if this header is present in the call to /docs
or /app
add the correct path to the relative urls. In my opinion, this complicate the life of a ncr
user since they should know something more about devops and know this particular header that is not present by default in caddy reverse_proxy for example.
If caddy is used to do this in the scenario explained above the Caddy file should be something like:
https://example.com {
handle_path /service1/* {
uri strip_prefix /service1
reverse_proxy :3000 {
header_up original_uri {http.request.orig_uri}
}
}
handle_path /service2/* {
uri strip_prefix /service2
reverse_proxy :3001 {
header_up original_uri {http.request.orig_uri}
}
}
}
So these are my two ideas ENV variable for PATH_PREFIX or the use of custom header to manage the path for internals calls (like oas.json and in the applets).
Suppose we have multiple services deployed with ncr that are behind the same url, e.g.
https://example.com
, and that we want to differentiate the servives based on the path in the url, for example* `https://example.com/service1` * `https://example.com/service2` * and so on...
being relative does mean that the additional services are under:
https://example.com/service1/app
https://example.com/service1/docs
https://example.com/service2/app
https://example.com/service2/docs
is this correct? Ideally I expect this as a user. So if the logic is only on HOSTNAME we can think of changing that to BASEPATH (or PATH_PREFIX) as you suggest.
I would make these options mutually exclusive, means that if BASEPATH
is passed, the hostname is derived.
Suppose we have multiple services deployed with ncr that are behind the same url, e.g.
https://example.com
, and that we want to differentiate the servives based on the path in the url, for examplehttps://example.com/service1
https://example.com/service2
In this moment this will require to reverse_proxy the call to the port where de service is running and removing the path prefix
service${n}
. This will result in an error if the swagger page or the appleats are visited since they use relative url that does not have the path prefix and thus can not be redirected.To solve this issue and simplify the deployment of future services in the case above (no more removing of prefix), we can add a new ENV variable called PATH_PREFIX that should be prefixed to all links and endpoints used and created in ncr.