About GeoNetwork in Kubernetes

[edevosc2c]

From #8021 (comment)

Actually, in geOrchestra, we have a hard time integrating geonetwork in this microservice architecture. It's not possible to have multiple instances of geonetwork for redundancy, and it's hard to move geonetwork around multiples servers in case one server fail.

Thanks for all feedback you provided. I'm curious what would be required from your perspective to make GeoNetwork easier to be deployed according to you? (I know this does not strictly relate to this topic)

Currently, GeoNetwork is mainly constraint with its datadir that is stored in the filesystem. If geonetwork were to only use a database as a store for all of its configuration files, moving geonetwork around servers would be an easy task because it wouldn't be constraint to a filesystem of a particular server. (NFS is an option for solving this issue, but it's more of a workaround than a real solution)

In the geoserver community, there is geoserver cloud which implemented this functionality, the datadir is stored in the database, and you can easily move geoserver around servers or even having multiple geoserver at the same time: https://geoserver.org/geoserver-cloud/

On top of this, in geOrchestra when we use Kubernetes, we can't launch multiple geonetwork in a "rolling deployment" type. Rolling deployment means that a new instance of the program will be brought up, the system will wait for it to be "healthy" (through checks) and when it is, the old instance of the program is shutdown and the HTTP traffic flows to the new instance. The benefit is no downtime for the user.

Currently, it is not possible to do that because it would create some conflicts in the datadir. I'm eager to discover ways to solve this issue because launching a new instance of geonetwork takes quite a lot of time, so when we do some re-deployment there is a downtime for our users.

[jahow]

This is relevant: #7337

The datadir in GeoNetwork might not be that much of an issue, at least by looking at the PR above. Most of the GN configuration is in the database (settings and UI settings) or in its web.xml and associated files. The comparison with GeoServer doesn't make that much sense since GS stores all its catalog (i.e. list of layers etc.) on the disk, whereas GN does not. Also, all GN instances can use the same ElasticSearch index, which can also be clustered independantly.

The limitations preventing clustering are there, but they might not be that hard to overcome 🙂

[edevosc2c]

There is still a plethora of local files that geonetwork relies on:

user:/mnt/geonetwork_datadir$ ls -alh *
-rw-r--r-- 1 jetty jetty  298 Mar 13 14:15 git.properties
-rw-r--r-- 1 jetty jetty  33M Jun  3 12:27 wro4j-cache.mv.db

config:
total 20K
drwxr-xr-x 3 jetty jetty 4.0K Mar 13 14:14 .
drwxr-xr-x 4 jetty jetty 4.0K May 30 12:25 ..
drwxr-xr-x 4 jetty jetty 4.0K Mar 13 14:14 codelist
-rw-r--r-- 1 jetty jetty  150 Mar 13 14:14 encryptor.properties
-rw-r--r-- 1 jetty jetty 1.4K May 30 12:25 schemaplugin-uri-catalog.xml

data:
total 36K
drwxr-xr-x  9 jetty jetty 4.0K Mar 13 14:14 .
drwxr-xr-x  4 jetty jetty 4.0K May 30 12:25 ..
drwxr-xr-x 15 jetty jetty 4.0K May 29 08:38 backup
drwxr-xr-x  7 jetty jetty 4.0K Mar 13 14:14 formatter
drwxr-xr-x  6 jetty jetty 4.0K May 27 19:17 metadata_data
drwxr-xr-x  2 jetty jetty 4.0K Mar 13 14:14 metadata_subversion
drwxr-xr-x  2 jetty jetty 4.0K Mar 13 14:14 node_less_files
drwxr-xr-x  7 jetty jetty 4.0K Mar 13 14:15 resources
drwxr-xr-x  2 jetty jetty 4.0K Mar 13 14:14 upload

All of these files have to exist locally, otherwise geonetwork doesn't work.

Thanks for the PR link.

[jahow]

Right, thanks for the list! a good part of them can be safely duplicated or do not need to be synchronized between instances (this is e.g. the case for the Wro4J cache which is generated on demand).

The biggest issue might be the metadata_data folder which is supposed to contain file attachments to metadata records, but I haven't seen mentions of it in the PR above. @fxprunayre was that intentionnally left aside?