surevine / openfire-docker-compose

Run multiple Openfire servers & DBs in Docker for local testing

Multiple Openfires in Docker

Quickly create multiple Openfire servers with associated PostgreSQL DBs in Docker containers for local testing.

Data and config snapshots have been taken of each DB and Openfire server so that a known desired state is configured on start. See the "How it's built" section below if you want to understand how this was done or need to add more nodes.

Prerequisites

• Docker - https://docs.docker.com/engine/install/

• Docker Compose - https://docs.docker.com/compose/install/

  docker build -t openfire:latest .

Quick Start

1. Make sure you have docker and docker-compose installed
2. Create a local Openfire docker image, tagged openfire:latest that contains the version of Openfire that you want to run
   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.

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.

openfire-docker-compose's Issues

Rename domain names to provide a 'secure context'

Many (web) clients features depend (or should depend) on being executed in a secure context (eg, accessed over an encrypted connection, or on localhost). See https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts for details.

The domains used by this project do not automatically qualify as a secure context. This can make interacting with it from a webclient troublesome. We should consider renaming the domain names like xmpp1.localhost.example to something that does define as a ‘secure context’, such as xmpp1.example.localhost

See https://igniterealtime.atlassian.net/browse/OF-2574

Adapt or clone for clustering

The content of this repository is very handy for establishing an environment that consists of two distinct XMPP domains, that can be used to test functionality that relates to 'federation'.

It would be helpful to have a similar solution that establishes an Openfire cluster (one XMPP domain, that consists of two distinct servers). I'm not sure if it makes sense to add that functionality to this repository, or simply create a new solution/repo altogether.

Obvious differences between the desired clustering environment and a federation environment:

• In clustering, each host uses the same XMPP Domain name value. The fully qualified hostname for each server can be distinct.
• The network between the hosts ideally allows for multicast traffic between them, on IP Address: 224.2.2.3 UDP Port: 54327
• The Hazelcast plugin is needed on both Openfire nodes. If multicast is available as defined above, I don't think it requires further configuration? If UDP can't be used, TCP can be used. See https://www.igniterealtime.org/projects/openfire/plugins/2.4.2/hazelcast/readme.html#config
• all instances of Openfire share the same database.

File content created that can't be removed

After running an instance (using ./start.sh) an _data folder is created that has content. Some of that content gets file permissions that prevent the user that issued the start from removing it. This causes errors during the setup of subsequent starts, as shown below.

$ ./start.sh 
Starting a federated environment (use -c to start a clustered environment instead).
WARNING: Found orphan containers (openfire-docker-compose_db_1) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Removing openfire-docker-compose_xmpp1_1 ... done
Removing openfire-docker-compose_xmpp2_1 ... done
Removing openfire-docker-compose_db1_1   ... done
Removing openfire-docker-compose_db2_1   ... done
Removing network openfire-docker-compose_openfire-federated-net
Pulling db1   ... done
Pulling db2   ... done
Pulling xmpp1 ... error
Pulling xmpp2 ... error

ERROR: for xmpp1  pull access denied for openfire, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

ERROR: for xmpp2  pull access denied for openfire, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
ERROR: pull access denied for openfire, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
rm: cannot remove '_data/xmpp/federated/2/conf': Permission denied
rm: cannot remove '_data/xmpp/federated/1/conf': Permission denied
mkdir: cannot create directory ‘_data’: File exists
cp: cannot stat '_data/xmpp/federated/1/conf/available-plugins.xml': Permission denied
cp: cannot stat '_data/xmpp/federated/1/conf/crowd.properties': Permission denied
cp: cannot stat '_data/xmpp/federated/1/conf/openfire-demoboot.xml': Permission denied
cp: cannot stat '_data/xmpp/federated/1/conf/openfire.xml': Permission denied
cp: cannot stat '_data/xmpp/federated/1/conf/security.xml': Permission denied
cp: cannot stat '_data/xmpp/federated/1/conf/security': Permission denied
cp: cannot stat '_data/xmpp/federated/1/conf/server-update.xml': Permission denied
cp: cannot stat '_data/xmpp/federated/2/conf/available-plugins.xml': Permission denied
cp: cannot stat '_data/xmpp/federated/2/conf/crowd.properties': Permission denied
cp: cannot stat '_data/xmpp/federated/2/conf/openfire-demoboot.xml': Permission denied
cp: cannot stat '_data/xmpp/federated/2/conf/openfire.xml': Permission denied
cp: cannot stat '_data/xmpp/federated/2/conf/security.xml': Permission denied
cp: cannot stat '_data/xmpp/federated/2/conf/security': Permission denied
cp: cannot stat '_data/xmpp/federated/2/conf/server-update.xml': Permission denied
Creating network "openfire-docker-compose_openfire-federated-net" with driver "bridge"
WARNING: Found orphan containers (openfire-docker-compose_db_1) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating openfire-docker-compose_db2_1   ... done
Creating openfire-docker-compose_db1_1 ... done
Creating openfire-docker-compose_xmpp1_1 ... done
Creating openfire-docker-compose_xmpp2_1 ... done
Attaching to openfire-docker-compose_db1_1, openfire-docker-compose_db2_1, openfire-docker-compose_xmpp1_1, openfire-docker-compose_xmpp2_1
db1_1    | The files belonging to this database system will be owned by user "postgres".
db1_1    | This user must also own the server process.
db1_1    | 
db1_1    | The database cluster will be initialized with locale "en_US.utf8".
db1_1    | The default database encoding has accordingly been set to "UTF8".
db1_1    | The default text search configuration will be set to "english".
...

Help understanding nginx proxy

In nginx proxy setup, https://github.com/surevine/openfire-docker-compose/blob/master/proxy/docker-compose.yml

I cannot proxy xmpp connection from client at port: 55222 through nginx.
Client connection only works directly connecting to port 5222 of openfire.

Please help me understand if only nginx is exposed to internet or both openfire & nginx is open for internet and client connection?
https://github.com/surevine/openfire-docker-compose/blob/master/proxy/README.md

Simple Configuration for testing in TestContainers

I'd like to integrate this into my development workflow. I'm currently building a Spring Boot app that will integrate with an XMPP server. It would be great if there was a simple, in-memory version of this docker-compose that just sets up a few test users.

The goal is to include this in the docker-compose module of TestContainers, so that a XMPP server could be launched with a known state for repeated automated tests.

https://www.testcontainers.org/modules/docker_compose/

I'm happy to work through whatever issues may arise.

Have distinct XMPP domain names

Although each server starts with a different hostname (xmpp1.localhost.example and xmpp1.localhost.example) they're both identifying themselves using the same XMPP domain name value (localhost.example). These should be two different values. We have a couple of options, but making the XMPP domain equal to the hostname is convenient for configuring clients (unless we also want to put DNS SRV records in place).

Add load balancer to cluster

Add HTTP File Upload functionality

Add the HTTP File Upload plugin to all environments.

On the clustered environments, use a shared volume to make sure that data can be accessed on/from all cluster nodes.

This aims to support work on igniterealtime/openfire-httpFileUpload-plugin#36

Unable to restart immediately

About 75% of the time where I want to stop an environment, to redeploy it with another build, the start.sh script fails with:

ERROR: for lb  Cannot start service lb: driver failed programming external connectivity on endpoint openfire-docker-compose_lb_1 (41e778f93e620e6df1b3cf52dd64e1f6e1421ee3fba4c9b9e1b2846474629520): Error starting userland proxy: listen tcp 0.0.0.0:57070: bind: address already in use

Port 57070 is most frequently reported, although I occasionally see another port.

This seems to correspond with a socket that's in TIME_WAIT state, as netstat reports:

tcp        0      0 127.0.0.1:57070         127.0.0.1:1024          TIME_WAIT   - 

Eventually, the problem disappears (after the socket expiry passes).

Hostnames should resolve

The hostsnames of the instances (xmpp1.localhost.example, xmpp2.localhost.example) should resolve to an IP address (but currently do not)

Allow a non-docker host to federate

It would speed up development time if we were able to run one Openfire instance outside of the docker compose based environment, at times. That would allow, for example, to run one Openfire in a debugger, while we're sending FMUC data from the other.

I'm not exactly sure what would be needed, but most if it revolves around having networking / name resolution, I think? Maybe exposing port 5269 (for s2s) combined with some editing of /etc/hosts files suffices.