Support context path for rendering static resources

[techgeek03]

Added simple support for rendering static content files such as the css and the image from a custom context path

[techgeek03]

@paulbouwer Any chance of approving this?

[paulbouwer]

@techgeek03 - thanks for submitting a PR.

Just want to dig into this a little bit further - what is the scenario you are looking to support with this update?

[techgeek03]

The reason for this change is the ability to sever the static files from any other context path then the root. If the ingress is configured on context path /api/v1/test the static assists are not loaded.

[paulbouwer]

Sounds like a great addition @techgeek03. Thank you again for submitting a PR.

So, the supported scenario is when you are using hello-kubernetes with an ingress and the inbound path requests will, in all likelihood, not match the current hardcoded static asset paths.

[jglick]

Whatever this does, it does not let the container respond to http://hello-kubernetes/the/supposed/context/path/. That is a 404. Maybe the idea is that this would used with a path-rewriting ingress? If so, docs should be clarified.

[paulbouwer]

@jglick - thank you for the feedback on needing clearer guidance around the purpose of the new CONTEXT_PATH parameter. It is indeed intended to be used in scenarios with an ingress.

Have a look at the upcoming release-1.10 branch. There are some changes in there that I hope provide others with better guidance and understanding.

[jglick]

intended to be used in scenarios with an ingress

I was using it in a scenario with an ingress, just with a plain ingress configuration that did not rewrite paths. In other words, the CONTEXT_PATH can only be used with custom annotations for a specific ingress controller supporting such a feature (such as ingress-nginx), or OCP Routes with haproxy.router.openshift.io/rewrite-target, since the official API does not support this. And the Helm chart docs

Indicate whether an ingress is being used.

should clarify that the chart does not itself deploy an Ingress, like most charts would when --set ingress.enabled=true; it just expects one to have been created by the user (with path rewriting that matches the value of ingress.pathPrefix).

If you want to test a plain path declaration in an Ingress, you would need to use some other tool that will actually respond to any URL path it is given. I Googled around and found a trick using busybox and nc -l -p 8080 or the like that worked well enough for my purposes.