feat(docker): Expose PostgreSQL configuration files on host for tuning in GeoNode Docker setup

[brynsofz]

Checklist

Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

For all pull requests:

• Confirm you have read the contribution guidelines
• You have sent a Contribution Licence Agreement (CLA) as necessary (not required for small changes, e.g., fixing typos in the documentation)
• Make sure the first PR targets the master branch, eventual backports will be managed later. This can be ignored if the PR is fixing an issue that only happens in a specific branch, but not in newer ones.

The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):

• There is a ticket in https://github.com/GeoNode/geonode/issues describing the issue/improvement/feature (a notable exemption is, changes not visible to end-users)
• The issue connected to the PR must have Labels and Milestone assigned
• PR for bug fixes and small new features are presented as a single commit
• PR title must be in the form "[Fixes #<issue_number>] Title of the PR"
• New unit tests have been added covering the changes, unless there is an explanation on why the tests are not necessary/implemented

Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @brynsofz on file. In order for us to review and merge your code, please contact the project maintainers to get yourself added.

[gemini-code-assist]

Summary of Changes

Hello @brynsofz, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the GeoNode Docker setup by externalizing PostgreSQL configuration files. By mounting postgresql.conf, pg_hba.conf, and a conf.d directory from the host into the database container, it provides greater flexibility for users to customize and tune PostgreSQL settings. This change improves the maintainability and operational control over the database within the Dockerized environment, allowing for easier adjustments to performance and security parameters.

Highlights

• PostgreSQL Configuration Externalization: The docker-compose.yml file has been updated to mount key PostgreSQL configuration files (postgresql.conf, pg_hba.conf) and a conf.d directory from the host into the PostgreSQL container. This allows for easier tuning and management of PostgreSQL settings without modifying the Docker image.
• Custom PostgreSQL Command: The PostgreSQL container's startup command in docker-compose.yml is now explicitly set to use the mounted postgresql.conf file, ensuring that the externalized configuration is applied.
• New pg_hba.conf for Authentication: A new pg_hba.conf file has been introduced, defining detailed host-based authentication rules. It configures scram-sha-256 authentication for GeoNode-related databases (geonode, geonode_data) for connections originating from the Docker network (172.19.0.0/16), enhancing security.
• New postgresql.conf for Core Settings: A new postgresql.conf file has been added, which sets fundamental PostgreSQL parameters such as data_directory, listen_addresses = '*', and explicitly references the custom pg_hba.conf and conf.d directory for additional configuration includes.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request is a great step towards making the PostgreSQL configuration more flexible and tunable in the Docker setup by exposing the configuration files to the host. The use of read-only volumes for configuration is a good security practice.

However, there are a couple of significant issues:

1. Inconsistent Environments: The changes are only applied to docker-compose.yml. The docker-compose-dev.yml and docker-compose-test.yml files are left unchanged, which will lead to different database configurations and behaviors between production, development, and testing environments. It's crucial to apply these changes consistently across all relevant docker-compose files.
2. Breaking Change: The POSTGRESQL_MAX_CONNECTIONS environment variable is no longer used. This is a breaking change that should be documented. While the new conf.d approach is more powerful, users should be guided on how to migrate their settings.

I've also added a suggestion to improve the security of the default pg_hba.conf settings.

[gemini-code-assist]

The POSTGRESQL_MAX_CONNECTIONS environment variable, which was used here to configure max_connections, is no longer effective with the new configuration approach. This is a potentially breaking change for users who were relying on it. It would be helpful to document this change and provide instructions for setting max_connections via the new conf.d directory mechanism.

[gemini-code-assist]

For better security, it's recommended to follow the principle of least privilege by denying all connections by default. The current configuration allows any connection that provides a valid password. Consider changing this catch-all rule to reject to ensure only explicitly authorized connections are permitted. An example of this is already commented out on line 36.

host    all             all             all                     reject

[t-book]

@brynsofz Pull requests need an issue that describe the goal and plan. Further I am not convinced, exposing the postgresql database of geonode worldwide in general. You can still use a SSH Tunnel for getting access (as example for a more secure way)