-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release GN v4.4.0 #107
Release GN v4.4.0 #107
Conversation
* Allow to set the application web context path using the new `WEBAPP_CONTEXT_PATH` (defaults to `/geonetwork`) * Move the exploded war to `/opt/geonetwork` * Add a new `GN_CONFIG_PROPERTIES` for passing addional configuration options to GN in the form of Java properties, for example `GN_CONFIG_PROPERTIES=-Dldap.base.provider.url=ldap://ldap:389` * `ES_HOST` is no longer mandatory and now defaults to `localhost`
This is a parameter to customize depending on size of metadata records (eg. many languages or many contacts)
Main idea was to more easily set up load balancing with sticky session. Co-authored-by: Joachim Nielandt <[email protected]>
Main idea is to avoid errors on some case (eg. OGC API records error starting on an empty database) and start services in order. Co-authored-by: Joachim Nielandt <[email protected]>
It should be noted that there is a sticky cookie here for forcing the user to use the same geonetwork across his visit: https://github.com/geonetwork/docker-geonetwork/pull/107/files#diff-bed7ab158ecf2f50be93c45dd9ae77da44d0689a155d95771d091515fb6d1ba7R59 If we have 2 geonetwork instances, the requests won't be evenly sent to all the geonetwork instances, in case we have 50% of users stuck to 1 geonetwork sending 80% of the overall requests, then one geonetwork will be overloaded while the other one will be underutilized. I guess it's inevitable because geonetwork is a stateful app, but that's something the users should be aware of it. |
Co-authored-by: Joachim Nielandt <[email protected]>
when starting multiple instances using the same data dir - XSD are copied to this folder on startup and copy may clash)
I have encountered a configuration issue that I can reproduce based on this 4.4.0 setup. The swagger docs for ogc-records-service are not accessible through Geonetwork:
I've tried configuring the context path for ogc-records-service such that it matches
However, in that case, the desired path results in a 404: http://localhost:8081/api/openapi/swagger-ui/. Probably not the way to go then. Could you advise on how to get the swaggerui accessible? |
@@ -195,7 +195,7 @@ To enable it use the `scaled` profile. In this mode: | |||
* any node can take a harvesting task manually triggered from the harvesting console | |||
* webserver is configured with sticky session (ie. a user stay on the same node) | |||
|
|||
To start new instances: | |||
First, start the main composition which will start all services (including the main node). Then start new instances with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need to start this up in multiple goes? I remember having all instances (regular + replicas) start up fine when triggering the command below.
Not sure @joachimnielandt . We have to fix it in OGC API Records side and it will not be fixed for 4.4.0. |
Checking a bit more, it looks like |
Co-authored-by: joachimnielandt <[email protected]>
Created docker-library/official-images#15618 in official images repo. |
Main changes
Run on Java 11
GeoNetwork 4.4.x use Java 11 (See geonetwork/core-geonetwork#7186)
Improved configuration
Documentation explains how to configure various aspects of the application (eg. root context, database, elasticsearch index, security, ...) using environment variables.
Changes and new options:
WEBAPP_CONTEXT_PATH
(defaults to/geonetwork
)/opt/geonetwork
GN_CONFIG_PROPERTIES
for passing addional configuration options to GN in the form of Java properties, for exampleGN_CONFIG_PROPERTIES=-Dldap.base.provider.url=ldap://ldap:389
ES_XYZ
variables are removed. Use JVM arguments instead.Move from Nginx to Traefik
Moving to traefik was mainly motivated for easier setup of the multiple instances configuration (see below).
Traefik dashboard is available on http://localhost:8000/
It defines a router to GeoNetwork with a redirect when requesting "/" on http://geonetwork.localhost/ and then load balance to the instances available.
Add health check
Add service health check and start services in order (eg. avoid to have error on OGC API Records when the database is empty).
Multiple instances configuration (experimental)
The composition allows to start multiple GeoNetwork nodes. eg. to start 2 more instances :
and traefik will register them as servers for the route
Related works