Research the possibilities of including a standard Postgres database in the docker-zulip stack

[janhalen]

In the docker-zulip compose file image: "zulip/zulip-postgresql:14"is used and in the helm-chart values file its the same:

  # We need to override the Postgresql image to get all the plugins Zulip needs
  image:
    repository: zulip/zulip-postgresql

It would greatly reduce the operational load if this image could be a standardized postgresql image.

Why are the zulip-docker stack using a custom image?

[janhalen]

Starting points for postgresql usage in zulip:

Overview: https://zulip.readthedocs.io/en/latest/overview/architecture-overview.html#postgresql

Config: https://zulip.readthedocs.io/en/latest/production/system-configuration.html#postgresql

[janhalen]

@orehoj: Good news! 🎉

Digging into the configuration options for the database described in the "Zulip in Production" section of the docs, it seems perfectly possible to use a standard Postgres installation!

Zulip needs to be installed with the install argument --puppet-classes=zulip::profile::standalone_nodb

The description is clearly designed with native installations and not containers in mind, but finding a way to make inject the install argument in the container build via an external config file, should be attainable.

[janhalen]

Further reading of the docs reval that the "Remote Postgres Database" solution is actually recommended for production setups.

Dedicated database.
For installations with hundreds of daily active users, we recommend using a remote PostgreSQL database, but it’s not required.

https://zulip.readthedocs.io/en/stable/production/requirements.html#scalability

My conclusion is that the custom zulip image in the docker-compose file is meant for just quick demos, development or test setups, and this makes sense as docker-compose is a way to deploy these kinds of setups, not a production setup.

Why it is stil referenced in the k8s charts are a bit more difficult to understand, but i guess a test/demo setup in k8s could be the target for these files?

Anyway, It seems from these preliminary findings that we can cross the custom Postgres image of the list as a requirement. Would you agree @orehoj?

[orehoj]

@janhalen, if we want to use a "shared postgres cluster" for the solution. Then we should properly follow "cloud service" instructions:
zulip postgres.
It sounds like there is some free text search that does not entirely work. But maybe that's ok?
Alternatively, something must be installed on the Postgres server. Then it would be best if a dedicated postgres installation is made for Zulip and it is maintained independently.

[janhalen]

@orehoj that is true.

For an initial low-user-count situation I would not be worried about running without FTS. The way it is presented to the users are naturally paramount. A simple SLA that indicates that "This is not to be used as a persistant data or document storage system, ...." should suffice for a version 1.0 of the service.

That being said (and considering my somewhat limited understanding of helm charts) enabling FTS would NOT require building og runinng a custom container image, the FTS could be configured in the values.yml of the helm chart right?

As i read other charts it could be as simple as utilizing an init container and add something like this to the chart:

  # Enable extensions for full-text search
  initdbScripts:
    init-fts.sql: |
      CREATE EXTENSION IF NOT EXISTS pg_trgm;
      CREATE EXTENSION IF NOT EXISTS unaccent;

  # Configure additional settings if needed
  postgresqlExtendedConf:
    shared_preload_libraries: "pg_trgm, unaccent"
    work_mem: "16MB"

But that could be considered for a later more user-demanding version of the service.. not the initial 1.0

[mikkeschiren]

After investigation - when using the Helm chart, the custom postgres image is needed by the installer of Zulip (or using, like you say @janhalen - an init container to install the same things that are in the custom image). So installer breaks with the addons.

[mikkeschiren]

With that said - I will try to override and add --puppet-classes=zulip::profile::standalone_nodb to the helm setup.