You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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:
pvc-{{ .Release.Name }}-geonode
)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
The text was updated successfully, but these errors were encountered: