From 15eb9b18e3218c276054dfc4b395a4010187fc0a Mon Sep 17 00:00:00 2001 From: Matthew Vivian Date: Thu, 4 Dec 2025 11:33:36 +0000 Subject: [PATCH] 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. --- README.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/README.md b/README.md index c68fc99..7286d38 100644 --- a/README.md +++ b/README.md @@ -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 () 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.