Open iszulcdeepsense opened 1 year ago
On the other hand, keep in mind that when deploying third-party apps, they usually don't serve /live
and /ready
endpoints, but Racetrack expects them to regularly check the condition of a Fatman by running liveness probes.
Either way, an additional "proxy" container would be still necessary in this case to fulfill the liveness probes, resulting in the "RUNNING" fatman's status. So this feature wouldn't help much.
It's interesting that RT currently requires /live
and /ready
, because it suggests that the current design assumes K8sish/dockerish infrastructure targets. If we implement a VMWare or even something like a fly.io or Heroku infrastructure plugin, such endpoints can of course be constructed but are not "native" there.
Some third-party applications like HUGO or Sphinx, running as a Fatman, expect requests to arrive at the root path (without any prefix). However, PUB component is serving requests at prefixed path (
/pub/fatman/{name}/{version}/{subpath}
) and passes them further, keeping the original path, which is unknown to the application. To make it work, Fatman usually is composed of 2 containers: proxy and an actual application. The "proxy" container is responsible for trimming down the URL path from/pub/fatman/{name}/{version}/{subpath}
to/{subpath}
.Here's an idea to move that responsibility to PUB and to instruct PUB whether the paths should be rewritten or not, before passing it further to a Fatman. A new field
rewrite_paths: bool
should be kept in a database next to a Fatman object to be fetched by PUB beforehand.