One-line use case: We want to use gameserver-ingress-controller's "path" mode without changing our game server code.
Use Case
We're interested in gameserver-ingress-controller because it offers a way to expose agones gameservers through a TLS-protected hostname (instead of http://NODE_IP:PORT).
gameserver-ingress-controller offer twos routing modes, "domain" and "path".
"domain" mode requires a wildcard subdomain ssl cert (or lots and lots of 1-subdomain certs), which we aren't able to create right now.
So we tried "path" mode, which routes requests to the right gameserver based on the first segment of the url path.
This solved our TLS issue but presented a new one: the relative path of every request to the server now started with a // segment.
We could update our server code to expose endpoints at paths like //healthz and just ignore the first segment, but this didn't seem like a good fix. In particular, if we were ever to deploy the same server code to a different environment that used the "domain" routing mode, we would have to change it back.
Our Approach
Our thought is to use url-rewriting at the ingress layer to strip the extra segment from the request, leaving the same relative paths that the server would see if it were in "domain" mode.
For example,
"domain" mode: gameserver-mc9cw-8p8wt.example.com/healthz -> /healthz
"path" mode: example.com/gameserver-mc9cw-8p8wt/healthz -> [url-rewrite] -> /healthz
ingress-nginx supports url rewriting using a combination of annotations and path, as shown in the docs here: https://kubernetes.github.io/ingress-nginx/examples/rewrite/#rewrite-target
It is already possible to set the necessary annotation in the gameserver or fleet yaml:
annotations: octops-nginx.ingress.kubernetes.io/rewrite-target: /$2
However, "path" mode currently sets the ingress path yaml to:
- path: /gameserver-name
For the url-rewrite to work, we would need to set the path yaml to:
- path: /gameserver-name(/|$)(.*)
To solve this for ourselves, we talked about deploying a modified version of this project, but...
Feature Request
If rewriting sounds like a good default behavior, "path" mode could include the capture group regex (/|$)(.*) in the path field of all generated Ingresses and add the rewrite-target nginx annotation automatically.
This way the request format in "path" mode will match the request format of "domain" mode (e.g. "/healthz")
I tested this out by hardcoding some values in Options.go and it worked.
Alternatively, the controller might provide a way to pass through custom path strings to the generated Ingress, the same way "octops-[custom-annotation]" passes an annotation through.
This would leave the default behavior of "path" mode as it currently is but enable users to achieve the url-rewriting described above.
This sounds like a bigger feature request, though.
*Our team actually resolved our blockers to getting a wildcard ssl cert, so we are now able to use "domain" mode. I wanted to post this anyway in case the issue is still relevant to anyone using "path" mode.
One-line use case: We want to use gameserver-ingress-controller's "path" mode without changing our game server code.
Use Case
We're interested in gameserver-ingress-controller because it offers a way to expose agones gameservers through a TLS-protected hostname (instead of http://NODE_IP:PORT). gameserver-ingress-controller offer twos routing modes, "domain" and "path". "domain" mode requires a wildcard subdomain ssl cert (or lots and lots of 1-subdomain certs), which we aren't able to create right now. So we tried "path" mode, which routes requests to the right gameserver based on the first segment of the url path. This solved our TLS issue but presented a new one: the relative path of every request to the server now started with a // segment.
We could update our server code to expose endpoints at paths like / /healthz and just ignore the first segment, but this didn't seem like a good fix. In particular, if we were ever to deploy the same server code to a different environment that used the "domain" routing mode, we would have to change it back.
Our Approach
Our thought is to use url-rewriting at the ingress layer to strip the extra segment from the request, leaving the same relative paths that the server would see if it were in "domain" mode. For example, "domain" mode: gameserver-mc9cw-8p8wt.example.com/healthz -> /healthz "path" mode: example.com/gameserver-mc9cw-8p8wt/healthz -> [url-rewrite] -> /healthz
ingress-nginx supports url rewriting using a combination of annotations and path, as shown in the docs here: https://kubernetes.github.io/ingress-nginx/examples/rewrite/#rewrite-target It is already possible to set the necessary annotation in the gameserver or fleet yaml:
annotations: octops-nginx.ingress.kubernetes.io/rewrite-target: /$2
However, "path" mode currently sets the ingress path yaml to:
- path: /gameserver-name
For the url-rewrite to work, we would need to set the path yaml to:- path: /gameserver-name(/|$)(.*)
To solve this for ourselves, we talked about deploying a modified version of this project, but...
Feature Request
If rewriting sounds like a good default behavior, "path" mode could include the capture group regex (/|$)(.*) in the path field of all generated Ingresses and add the rewrite-target nginx annotation automatically. This way the request format in "path" mode will match the request format of "domain" mode (e.g. "/healthz") I tested this out by hardcoding some values in Options.go and it worked.
Alternatively, the controller might provide a way to pass through custom path strings to the generated Ingress, the same way "octops-[custom-annotation]" passes an annotation through. This would leave the default behavior of "path" mode as it currently is but enable users to achieve the url-rewriting described above. This sounds like a bigger feature request, though.
*Our team actually resolved our blockers to getting a wildcard ssl cert, so we are now able to use "domain" mode. I wanted to post this anyway in case the issue is still relevant to anyone using "path" mode.