geonetwork: fix Elasticsearch version for 4.4 images#2674
Draft
juanluisrp wants to merge 5 commits into
Draft
Conversation
The geonetwork:4.4 tag now resolves to 4.4.10, which requires Elasticsearch 8.x. The compose.yaml and quick-start examples still referenced elasticsearch:7.17.15, causing 400 errors due to ES 8 treating text-field aggregations differently. Changes: - compose.yaml: upgrade elasticsearch and kibana to 8.14.3, add xpack.security.enabled=false (required for local ES 8 without TLS), remove Jetty-specific JVM flags, update DB type to postgres, upgrade PostgreSQL to 17-3.5, simplify postgres service (no debug logging) - content.md: update quick-start docker run to ES 8.14.3, add Elasticsearch/GeoNetwork version compatibility table, correct Tomcat/Jetty history note and H2 database path description Fixes: geonetwork/docker-geonetwork#144
- Use postgres:17 instead of postgis/postgis (multi-arch, no PostGIS needed with GEONETWORK_DB_TYPE=postgres) - Database healthcheck: verify geonetwork db/user exist via psql instead of pg_isready (avoids race with PostgreSQL init restart) - GeoNetwork healthcheck: check actual app endpoint, add start_period - Remove pglog volume (no longer needed)
Align the Elasticsearch/GeoNetwork version compatibility table in content.md and fix YAML quoting style issues in compose.yaml to satisfy the CI format checks.
- Bump Elasticsearch and Kibana versions to 8.19.13 in compose.yaml and the quick-start example in content.md - Add REMOTE_IP_INTERNAL_PROXIES env var (new in both 4.4.10 and 4.2.15 with the Jetty-to-Tomcat migration) - Add WEBAPP_CONTEXT_PATH env var for 4.4.x images - Fix ES_INDEX_RECORDS / es.index.records default value: gn-records (hyphen), not gn_records (underscore)
Tomcat-based images (GN 3, 4.2.15+, 4.4.10+) run as root, while the previous Jetty-based images ran as the jetty user. Add a file permissions section warning users upgrading from Jetty-based images that they may need to update ownership of existing mounted volumes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Updates the GeoNetwork Docker Hub documentation to fix an incompatibility between the compose example and the current
geonetwork:4.4image.Why
The
compose.yamland quick-start examples specifiedelasticsearch:7.17.15, butgeonetwork:4.4now resolves to 4.4.9+ which requires Elasticsearch 8.x. Starting from GeoNetwork 4.4.3, the required ES version moved to 8.x. ES 8 changed how text-field aggregations work, causing 400 errors on the Map and Search pages.Reported in: geonetwork/docker-geonetwork#144
Changes
compose.yamlelasticsearchandkibanafrom7.17.15to8.14.3xpack.security.enabled: "false"andxpack.security.enrollment.enabled: "false"(ES 8 enables auth by default; required for a local demo setup)GEONETWORK_DB_TYPEfrompostgres-postgistopostgrespostgis/postgis:17-3.5withpostgres:17(multi-arch; PostGIS not required withGEONETWORK_DB_TYPE=postgres)psqlto verify the geonetwork database and user exist before starting GeoNetwork, instead ofpg_isready -U postgreswhich passes too early during the PostgreSQL init cyclestart_period: 60spglogvolume (was only used by the now-removed verbose postgres logging command)content.mddocker runexample for GN 4.4 to useelasticsearch:8.14.3withxpack.security.enabled=falseTesting
Brought up the updated stack locally, loaded templates and samples, and confirmed no "Query returned an error" errors on the Map and Search pages. All
_searchrequests return 200 with correct aggregation results.