Offer an image that run on other OSs

[karimhm]

ejabberd Community Server Official Docker Image is based on the alpine distribution. Some people might prefer other distributions such as Debian, CentOS, Ubuntu ... this might force them to create their own Docker image from scratch which might lead to instabilities and issues.

Is it possible to add support for the other distributions?.

Many thanks.

[badlop]

It seems I don't understand it.

Are you asking somebody else to invest the time and effort to create images for every existing distribution, for every ejabberd release, just because maybe somebody else prefers to not use Alpine? Which distributions? Why those distributions, and not others?

[karimhm]

It seems I don't understand it.

Are you asking somebody else to invest the time and effort to create images for every existing distribution, for every ejabberd release, just because maybe somebody else prefers to not use Alpine? Which distributions? Why those distributions, and not others?

I was asking to offer an ejabberd Docker image that is based on Ubuntu or Debian or other distribution. Alpine uses the musl libc which can cause performance issues.

[badlop]

That already exists: https://github.com/rroemhild/docker-ejabberd

[badlop]

I've load-tested ejabberd on my Debian and on this Docker image, using the old jab_simul, and it shows similar CPU usage on both systems.

Alpine uses the musl libc which can cause performance issues.

Searching over Internet, I couldn't find any reference to such issues. Where did you read it? Or in what circumstances did you experience it?

[karimhm]

I've load-tested ejabberd on my Debian and on this Docker image, using the old jab_simul, and it shows similar CPU usage on both systems.

Alpine uses the musl libc which can cause performance issues.

Searching over Internet, I couldn't find any reference to such issues. Where did you read it? Or in what circumstances did you experience it?

@badlop Here is a list of a few posts that mention the issues of Alpine Linux.

• Moving away from Alpine
• Alpine vs. Debian Container Images for Java / JVM Builds
• Using Alpine can make Python Docker builds 50× slower
• python3.5 on docker alpine is slower than docker ubuntu
• Performance of Node.js is quite bad compared to other images
• Why is the Alpine Docker image over 50% slower than the Ubuntu image?

I do know that this need to be measured rather than blindly assume things based on random posts

[badlop]

I wrote this quick and dirty Dockerfile that uses erlang slim image, based in Debian Buster:

FROM erlang:23.3.1-slim

RUN apt-get -qq update && apt-get -qq install \
    autoconf \
    automake \
    g++ \
    gcc \
    git \
    libexpat1-dev \
    libgd-dev \
    libpam0g-dev \
    libsqlite3-dev \
    libssl-dev \
    libwebp-dev \
    libyaml-dev \
    make

WORKDIR /ejabberd
COPY ejabberd-21.04.tgz .
RUN tar -xzvf ejabberd-21.04.tgz

WORKDIR /ejabberd/ejabberd-21.04
RUN ./autogen.sh \
    && ./configure \
    && make update \
    && make

ENTRYPOINT ["bash"]

In that container I run a subset of ejabberd's common test suite (excluding mysql and postgresql tests, that could interfere with the results):

cd ejabberd/
export CT_BACKENDS=mnesia
time -p make test >raw-alt.log 2>final.log

I repeat this three times, and obtain as "real time" seconds in this erlang-slim, based in Debian buster image: 500, 471, 467

Then I run those tests three times in a container using ejabberd/mix, based in Alpine 3.11 image: 476, 495, 469

Finally, I run those tests a pair of times in my Debian real machine, outside of Docker: 480, 473.

After this brief testing, I don't see any specific benefit or drawback when using one or other image.

---

Now let's review the experiences that other people had using Alpine images:

• Moving away from Alpine

Unrelated to performance. It talks about: missing package, losing version when a package is not available, syslog limit

• Alpine vs. Debian Container Images for Java / JVM Builds

we saw an increase in the time it took to run our tests and builds when using Alpine as a base for our Gradle builds.

That is not the case for ejabberd's tests.

• Using Alpine can make Python Docker builds 50× slower

Says:

Standard PyPI wheels don’t work on Alpine

That library problem is irrelevant for ejabberd

Alpine Linux can cause unexpected runtime bugs

Don’t use Alpine Linux for Python images

Ok.

• python3.5 on docker alpine is slower than docker ubuntu

That simple Python benchmark is irrelevant here.

• Performance of Node.js is quite bad compared to other images

Umm, ok.

• Why is the Alpine Docker image over 50% slower than the Ubuntu image?

Again a simple Python benchmark that is irrelevant here.

---

My conclusion is that, right now, with the available evidences, using Alpine for ejabberd is perfectly correct.

On the other hand, it's important to remember that other people had varied problems when running other programs in Alpine: if we find any weird behaviour or performance when using ejabberd in Alpine, the first thing to investigate is wether using other image solves it.

Thanks for pointing to that possibility!

[karimhm]

I wrote this quick and dirty Dockerfile that uses erlang slim image, based in Debian Buster:

FROM erlang:23.3.1-slim

RUN apt-get -qq update && apt-get -qq install \
    autoconf \
    automake \
    g++ \
    gcc \
    git \
    libexpat1-dev \
    libgd-dev \
    libpam0g-dev \
    libsqlite3-dev \
    libssl-dev \
    libwebp-dev \
    libyaml-dev \
    make

WORKDIR /ejabberd
COPY ejabberd-21.04.tgz .
RUN tar -xzvf ejabberd-21.04.tgz

WORKDIR /ejabberd/ejabberd-21.04
RUN ./autogen.sh \
    && ./configure \
    && make update \
    && make

ENTRYPOINT ["bash"]

In that container I run a subset of ejabberd's common test suite (excluding mysql and postgresql tests, that could interfere with the results):

cd ejabberd/
export CT_BACKENDS=mnesia
time -p make test >raw-alt.log 2>final.log

I repeat this three times, and obtain as "real time" seconds in this erlang-slim, based in Debian buster image: 500, 471, 467

Then I run those tests three times in a container using ejabberd/mix, based in Alpine 3.11 image: 476, 495, 469

Finally, I run those tests a pair of times in my Debian real machine, outside of Docker: 480, 473.

After this brief testing, I don't see any specific benefit or drawback when using one or other image.

Now let's review the experiences that other people had using Alpine images:

• Moving away from Alpine

Unrelated to performance. It talks about: missing package, losing version when a package is not available, syslog limit

• Alpine vs. Debian Container Images for Java / JVM Builds

we saw an increase in the time it took to run our tests and builds when using Alpine as a base for our Gradle builds.

That is not the case for ejabberd's tests.

• Using Alpine can make Python Docker builds 50× slower

Says:

Standard PyPI wheels don’t work on Alpine

That library problem is irrelevant for ejabberd

Alpine Linux can cause unexpected runtime bugs

Don’t use Alpine Linux for Python images

Ok.

• python3.5 on docker alpine is slower than docker ubuntu

That simple Python benchmark is irrelevant here.

• Performance of Node.js is quite bad compared to other images

Umm, ok.

• Why is the Alpine Docker image over 50% slower than the Ubuntu image?

Again a simple Python benchmark that is irrelevant here.

My conclusion is that, right now, with the available evidences, using Alpine for ejabberd is perfectly correct.

On the other hand, it's important to remember that other people had varied problems when running other programs in Alpine: if we find any weird behaviour or performance when using ejabberd in Alpine, the first thing to investigate is wether using other image solves it.

Thanks for pointing to that possibility!

Thanks for taking the time to do those measures.