docs: document deployment options and SQL naming convention

The root README lacked an overview of what each deployment directory
provides, making it harder for new users to choose the right setup
for their testing scenario.

Adds a "Deployment Options" table summarising simple, federation,
cluster, cluster_with_federation, and proxy configurations.
pull/83/head
Matthew Vivian 2025-12-04 11:33:36 +00:00 committed by Matthew Vivian
parent 005e0edb4a
commit 15eb9b18e3
1 changed files with 14 additions and 0 deletions

View File

@ -19,6 +19,20 @@ See the "How it's built" section below if you want to understand how this was do
1. run `docker build --tag openfire:latest .` in the root of the Openfire repository (<https://github.com/igniterealtime/Openfire>)
3. Launch the environment using the `start.sh` in the directory of your choice.
## Deployment Options
Each directory contains a different deployment configuration. Choose the one that matches your testing scenario:
| Directory | Description |
|-----------|-------------|
| `simple/` | Single Openfire server with PostgreSQL database. The simplest configuration for basic testing and development. |
| `federation/` | Two independent Openfire servers on separate domains (`xmpp1.localhost.example` and `xmpp2.localhost.example`), each with their own database. Use this to test server-to-server (S2S) federation between XMPP domains. |
| `cluster/` | Three Openfire servers sharing a single database, with an nginx load balancer. Tests Openfire's clustering capabilities using the Hazelcast plugin. |
| `cluster_with_federation/` | A 3-node Openfire cluster plus an additional standalone Openfire server on a different domain (`otherxmpp.localhost.example`). Use this to test clustering and federation simultaneously. |
| `proxy/` | Single Openfire server with an nginx reverse proxy in front. Use this to test proxy configurations and header handling. |
All configurations support optional IPv6 networking via the `-6` flag to `start.sh`. See the README in each directory for detailed information about ports, users, and network configuration.
## How it's built
To recreate the known good state for the system we first create base Openfire and relevant database containers. We then perform the manual setup and any other configuration that we require, such as adding users and MUC rooms. Once the setup is complete we dump the database from the container to the Docker host and copy the Openfire config files from the container to the Docker host. These are then used with Docker volumes for creating the same state in subsequent Openfire and database containers.