When deployed in a kubernetes environment, what’s the best way to add an additional host/domain name to a site? I want other apps within the same k8s cluster to be able to access the frappe API using the local cluster hostname (eg., http://some-host.some-namespace.svc.cluster.local:8080/api).
I see that the helm chart has an nginx.config option that will load a custom config via a configMap. It’s not clear to me how to override the necessary server{} section of the nginx conf to add the local hostname, though. Or, perhaps there’s a simpler way?
You can access the setup using service name and port as you mentioned. You need to override host header for request made to nginx service or x-frappe-site-name header for request made to gunicorn service and you’ll be able to access the api.
1 Like
Thanks! Do you use nginx.config in the helm chart to override the host header?
I was originally updating my cluster’s ingress with the annotation to override the host name but then I realized that that won’t have any impact. It’s not clear to me how to affect the built-in nginx instance. Other than using nginx.config, I don’t see a more direct way to accomplish this.
What do you wish to achieve?
If you have 1) internal service hostname and 2) actual site name (s), then your python (or any runtime) app can combine them in requests made by it.
If you need frontends to have site access with ui or just api then you’ll need to add annotations on ingress as you’re already doing.
nginx.config can be used for cases where you need to reverse proxy additional services, or do something drastically different. Also it’ll affect everything that the nginx service serves, which is part of the frappe-bench. You can’t lock it to one site unless you’re okay to add more services per sites. For service per site there’s nothing in helm chart, you’ve to create service resources separately.
What do you wish to achieve?
I probably should have started with that 
Ultimately, I want frappe to proxy auth requests for other apps within the cluster.
So, I want to add auth-url and auth-signin annotations to another application and force it to consult frappe to either shunt to the login screen or return the logged in user’s email in X-Remote-User.
The 3rd-party application is able to deal with header-based authorization and looks for its user id in X-Remote-User.
Having stepped back from my original approach, it’s probably fine to use the FQDN in the ingress’ annotations. This would negate the need to override any header values. I think what I need to do now is write a simple app that allows the nginx ingress to retrieve the email from frappe.session.user. This would be restricted to local cluster IPs.
I’m open to alternate ideas