Feature: refector nginx deployment

[mwallschlaeger]

current nginx deployed by this helm chart includes several tasks, which can also be implemented using the kubernetes build in ingress functionallity. These are artifacts comming from the migration process from the original docker-compose.yaml file in geonode/geonode repository towards geonode-k8s. The current tasks of the nginx deployment include:

• proxy for geoserver
• (optional) proxy for pycsw
• proxy to the celery monitor
• proxy to django application
• provide access to the /uploaded folder in the RWX volume (geonode-pvc.yaml: pvc-{{ .Release.Name }}-geonode)
• deliver static geonode content

I suggest to implement proxies to geoserver and pycsw using the ingress functionality of kubernetes. further it reduces complexity of the nginx configuration file and gives more flexibility for the different endpoints within the installation. Anyway i would keep the default as it is.

Further the nginx deployment could get independent from the geonode initialization process by having a exclusiv volume for the static content. This the can be build by a init container in the nginx deployment only running manage.py makestatics. This change would be the first step away from the single RWX volume towards multiple RWO volumes.

I think this could be implemented without having breaking changes with current installations

[mwallschlaeger]

i will postpone this issue to later release

[mwallschlaeger]

I'm about open an PR on optionally, based on ingress enabled or disabled, excluding pycsw and geoserver locations from the nginx.conf loaded as configmap via nginx-conf.yaml. This would come with performance improvements for both services as the traffic to this services is not traversed through two nginx proxies anymore.

What keeps me from always enabling geoserver and pycsw via kubernetes.ingress are the requirements of always having an ssl certificate in place, so that django application can reach pycsw and geoserver under trusted certificates, which are not always available in every minor setup). Further configuring django to use external pycsw service using: CATALOGUE_URL could be done via kubernetes.services names. But then links generated to metadata between django and pycsw are not working properly as the generated links will contain kubernetes.service names and not the external domain name.