Align to GeoNode master (4.2.0) and improve/fix docker initialization

[afabiani]

This PR introduces improvements and fixes to docker-compose and initialization scripts in general:

• Removing some unused variables.
• Removing some unused and obsolete containers, such as Jenkins.
• Removing the incorrectly written and non-functioning part for setting the password of GeoServer.
• Inverting the startup dependency from GeoServer -> Django to Django -> GeoServer.
• Ensuring that OAUTH2 is properly initialized on restart in all its parts.
• Enhancing NGINX to make sure that GeoServer functions well behind any proxy, including HTTPS.

Some implementation details:

1. Environment file

DOCKERHOST and DOCKER_HOST_IP variables removed as useless and misleading. Instead, it exposed NGINX_BASE_URL which was calculated automatically and badly.

The variables

GEONODE_LB_HOST_IP=django
GEONODE_LB_PORT=8000
GEOSERVER_LB_HOST_IP=geoserver
GEOSERVER_LB_PORT=8080

are important, they are used by NGINX to create the upstream proxyPass and by GeoServer to create the internal OAuth2 endpoints. They represent the name and port of the GeoNode and GeoServer containers. In general it is not necessary to change them, but in an environment like Microsoft Azure these must be set to the address of the subnet as the names are not internally resolved.

Increased MAX_DOCUMENT_SIZE=200 because the previous default of 2Mb did not allow rendering even one document.

Updated create-envfile.py to also enable staging mode to test HTTPS on localhost, which was previously totally ignored.

2. Dockerfiles

Removed useless stuff and started it from geonode/geonode-base:latest-ubuntu-22.10

3. Readme

Added a Quick Start section with docker

4. Docker Compose

Fixed healthchecks which are now faster and more efficient and switched Django -> GeoServer startup dependency, because it's the Django entrypoint that sets OAutg2 parameters in the GEOSERVER_DATA_DIR before it starts.

Updated to POSTgresql 15

5. UWSGI + NGINX

Enabled proxyPass instead of uwsgiPass because we set headers correctly in geonode.conf only with proxyPass

6. GeoServer docker entry points

Fixed the .sh to set OAuth2 which previously worked badly and only partially checking when there was the localhost value. Now they update everything and always.

7. nginx/geonode.conf.envsubst

Made proxy passes dynamic

set $upstream $GEOSERVER_LB_HOST_IP:$GEOSERVER_LB_PORT;

set $upstream $GEONODE_LB_HOST_IP:$GEONODE_LB_PORT;

Updated the GeoServer conf so that the GUI works fine behind any proxy.

8. A general reformat to the black code

9. Version bump

from 4.0.0.final to 4.2.0.dev

[ridoo]

@afabiani these are quite good changes! However, the PR raises a maintenance question:

What do you actually recommend when users have to decide between a GeoNode Fork or the creation of a separate Geonode project via geonode-project template?

The main problem I see is to keep track of all the changes you make on this repository (e.g. those within this PR). Once a project has been created, it gets detached from version control. If a user decides to upgrade their GeoNode project, they would have to follow the commit history and apply all changes manually, right? Wouldn't it be better to just use a GeoNode fork so the changes become visible once you do a merge/pull?

Is there is a discussion (issue/documentation) about Forking vs. GeoNode-Project somewhere? Some good practice guidance would be helpful too.

I'd be happy for any pointer :-)

[afabiani]

Those changes won't ba backported. Those will be eventually part of the 4.2.0 train, currently under development.

[ridoo]

Ok .. but what about mainaining a project which got generated from the geonode-project repository? When upgrading to 4.2.0 .. I would have to go through the commit history and apply the changes manually on that project. Or do I miss something?

[afabiani]

The idea would be to update the documentation of the 4.2.0 release with a specific section for this topic. However we can open a discussion on the mailing list to further investigate the problem and hear from the community if there are some suitable proposals/ideas.

[ridoo]

However we can open a discussion on the mailing list to further investigate the problem and hear from the community if there are some suitable proposals/ideas.

You mean geonode-devel@lists.osgeo.org? I am subscribed, but it seems it makes not much noise in my inbox. However, I will open a discussion thread there.

edit: mail address .. geonode-devel is the right one -- in fact I only found the geonode-devel-requests address in my inbox

[ridoo]

However, I will open a discussion thread there.

@afabiani my email awaits approval :man_shrugging:

[giohappy]

@ridoo if you agree I would merge the PR

[ridoo]

@giohappy if it is ok for you, I'd take a deeper look later this day, before just saying "ok".

[github-advanced-security[bot]]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.