Docker
In this short guide we will set up MongooseIM using Docker and run it as part of a cluster.
Running MongooseIM¶
The container can be created and started with the following command:
1 | |
In order to run image built for PR 1006, the command will look like the following:
1 | |
You can check that docker logs mongooseim-1 shows something similar to:
1 2 3 4 5 6 7 8 9 10 | |
We can health-check the MongooseIM node with telnet.
To do that, you need to provide the IP of the container (usually 127.0.0.1) and the published TCP port which translates to container’s port 5222.
In order to find the port you can use the following docker command:
1 2 | |
In the example above you can see that port 5222 inside the container was published on port 32771 on the docker host machine. It can be used to check if the server is really listening on that port:
1 2 3 | |
Success! MongooseIM is accepting XMPP connections.
Adding some users¶
1 | |
Where:
* $USER - a username
* $XMPP_HOST - the XMPP host served by MongooseIM - by default it's localhost
* $PASSWORD - password used for authentication
Example¶
1 2 3 4 5 6 7 8 9 10 11 | |
Customising the configuration¶
You can override the default configuration files by providing them using docker volumes. Let's assume on the local machine there is directory mongooseim-1 with the following content:
1 2 3 4 5 | |
Now we can run the container:
1 | |
The server will use the customised configuration files.
There is also a vm.dist.args file which can be overwritten in the same way.
Database setup¶
MongooseIM can be integrated with various databases and other external services. For example, let's run a PostgreSQL container:
1 2 3 4 | |
${PATH_TO_MONGOOSEIM_PGSQL_FILE} is an absolute path to priv/pgsql.sql, which can be found in the MongooseIM repo.
Don't forget to configure the outgoing connection pools in mongooseim.toml to connect with the services you set up!
Persisting Mnesia files¶
Mnesia files are kept in /var/lib/mongooseim directory inside the container. In some cases it is desired to keep them while updating the image.
In this case the /var/lib/mongooseim dir should be mounted to a host directory.
Using CETS¶
You can use CETS, which is the recommended backend for transient data, instead of Mnesia - see the tutorial for more details.
Setting up a cluster¶
There are two methods of clustering: CETS (recommended) and Mnesia, which can be automatic (default) or manual, giving move control over the cluster formation.
CETS¶
Ensure that outgoing pools are configured with an RDBMS so that CETS can retrieve a list of MongooseIM nodes using the same relational database and cluster them together.
Create a user-defined bridge network and start two nodes connected to it:
1 2 3 | |
The nodes should already form a cluster. Let's check it:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | |
File-based discovery¶
It is possible to read a list of nodes to cluster from a file. See CETS with the file discovery backend.
Mnesia¶
To use the automatic clustering method, your containers need both container names (--name option) and host names (-h option) with the -n suffix,
where n are consecutive integers starting with 1 (configurable with MASTER_ORDINAL env variable), e.g. mongooseim-1, mongooseim-2 and so on.
Make sure you have started a node with -${MASTER_ORDINAL} suffix first (e.g. -h mongooseim-1 and --name mongooseim-1), as all the other nodes will connect to it when joining the cluster.
Few things are important here:
-
The following parameters must be set to the same value if used in docker/docker-compose. The second and all the subsequent containers have the same requirement.
-hoption setsHOSTNAMEenvironment variable for the container which in turn sets long hostname of the machine. The start.sh script uses it to generate the Erlang node name ifNODE_TYPE=name. IfNODE_TYPE=sname(default), short hostname will be used instead. If the value provided to-hoption is already a short hostname, it will be used as is, otherwise it will be shortened (longest part that doesn't contain '.' character). If you need to make the host part of the node name different fromHOSTNAME(or use an IP address instead), you can do it with theNODE_HOSTenvironment variable, e.g.-e NODE_HOST=192.168.1.1.--nameis required to provide automatic DNS resolution between the containers. See Docker network documentation page for more details.
-
Format of the host name:
- Host name of the first container must be in the
${NODE_NAME}-${MASTER_ORDINAL}format. That allows start.sh to identify the primary node of the cluster. - All the subsequent containers must follow the
${NODE_NAME}-Nhost name format, whereN>${MASTER_ORDINAL}.
- Host name of the first container must be in the
Example¶
Create a user-defined bridge network and start two nodes connected to it:
1 2 3 | |
The nodes should already form a cluster. Let's check it:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | |
Kubernetes notes¶
Default clustering may work as part of Kubernetes StatefulSet deployment with only two changes:
MASTER_ORDINALhas to be set to0asStatefulSetstarts counting instances from 0NODE_TYPEhas to be set toname(use of long names) as Kubernetes uses FQDN within internal DNS to resolvepod'sIP address. Please note that forpoddomain to work you have to have headless service running that matches yourStatefulSet(see https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)
Manual clustering¶
With the manual clustering method, you need to explicitly specify the name of the node to join the cluster with via the CLUSTER_WITH environment variable.
Examples¶
Let's try providing a name of the node to join the cluster with manually:
1 2 | |
The first command starts a node which, by default, does not to try to join any clusters (since JOIN_CLUSTER is set to false by default).
We then tell the second node to join the cluster with the first node.
You can now check that the nodes have formed the cluster:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | |