This repository holds a helm chart for ejabberd which
[...] is an open-source, robust, scalable and extensible realtime platform built using Erlang/OTP, that includes XMPP Server, MQTT Broker and SIP Service.
The chart configures the environment needed to build and run ejabberd kubernetes
clusters. Additionally, the values.yaml
file allows to include most of the
configuration items, ejabberd offers in their ejabberd.yml
.
The chart and its items can be found here.
The chart is under development, meaning there is room for enhancements and improvements. The issue tracker may be used to define roadmap items.
The chart is functional and needs testing. Please report back if anything does not work as expected.
This repository also contains a CI which tests basic activities, e.g. scaling, XMPP connectivity and traffic with processone's rtb as well as pod failures, kills, etc. with chaos mesh.
Contributors and PRs are also welcome.
The chart uses a custom ejabberd image, which is based on the official
ejabberd container image. Currently only built for x86_64
due to an issue in
QEMU - now resolved, however. So there will be soon an arm64
variant as well.
The image name is: ghcr.io/sando38/ejabberd:23.10-k8s1
This repository contains the patches applied to the official ejabberd releases in the image directory and the respective workflow file.
A short summary:
leases
for pod leaders.ejabberdctl
to use correct naming conventions for
ejabberd clusters in kubernetes.ejabberd_auth_http
and mod_ecaptcha
.mod_s3_upload
are installed in the image
already.The patches are defined per release, hence a container image tag always bears
the ejabberd release, e.g.: 23.10
.
Furthermore, a suffix -k8s1
is used in case the image needs an update. The
first release image has a suffix -k8s1
.
The image may be used with docker compose
using the following definitions:
version: '3'
services:
ejabberd:
image: ghcr.io/sando38/ejabberd:23.10-k8s3
command: >
sh -c "ejabberdctl foreground"
environment:
- ERLANG_NODE_ARG=ejabberd@localhost
Note: command
and environment
arguments are required to simulate the
official image behhavior.
Yes, that is considered and actually also desired (link to discussion).