mm on pi4(arm)?

[dolphin-cat]

how do i compile a mattermost-server docker image for linux/arm64

[amyblais]

Hi @dolphin-cat, this previous issue may help answer the question: https://github.com/mattermost/mattermost-server/issues/21979.

Also, feel free to contribute any feature requests on our feature idea forum here.

[dolphin-cat]

i see no clear instructions there, all i see is some outdated code and some non outdated code and a "use them together" without any explanation how to do so

[amyblais]

how do i compile a mattermost-server docker image for linux/arm64

@nab-77 Would you know the answer to this, or is this something we're planning to support?

[mmospanenko]

here you have 'buildx' step (https://github.com/mattermost/mattermost/blob/b20ef95b9124e2eb666c59f28a918952124b626f/.github/workflows/artifacts.yml#L56C18-L56C18), why if you'll add something like

...
      - name: Set up QEMU
        uses: docker/setup-qemu-action@v2
        with:
          platforms: 'amd64,arm64'
...
      - name: Build image and push 
        uses: docker/build-push-action@v3
        with:
          platforms: 'amd64,arm64'    
        ...

[this-is-tobi]

Hi @mmospanenko,

If we take a closer look at this line, we can notice that there is another problem, the binary used is for amd64 and it is hardcoded. My suggestion would be as follows:

• Hamonize the code with the mattermost-operator image but this is a deeper refactor in the docker build system:
  1. Evaluate the target architecture inside the docker file with the TARGETARCH variable (see https://docs.docker.com/engine/reference/builder/#automatic-platform-args-in-the-global-scope).
  2. Download the correct binary using the above variable.
  3. In the .github/workflows/artifacts.yml#66 pipeline, run the docker build command with the --platform="linux/amd64,linux/arm64" flag.

OR

• Use a matrix pipeline with multiple architectures so that a variable inside the pipeline can be used to download the correct binary and set the correct docker target platform.

Note: I detected a similar problem on the mattermost-operator image and opened a PR for it.

I wanted to make a PR to fix this but if we look at this line we can see that this workflow builds an image named mattermostdevelopment/mm-te-test, it's not mattermost/mattermost-team-edition and I can't find where this image is built. @amyblais if you know anyone who can give me information on this, I could probably do a PR.

PS: I don't know if it's mandatory but as @mmospanenko mentioned, I always use docker/setup-qemu-action in my multi arch pipeline because it's an emulator.

[amyblais]

Thank you for your interest in helping with this issue. I've shared this report internally to our team to see if one of our team members is able to help with more information. The DevOps channel on our community server is also one good place to follow-up on this issue.

[remiheens]

Hi, if you want, I maintain a docker image build process for arm arch, since it's no more supported.

https://github.com/remiheens/mattermost-docker-arm

Hope ARM came back into supported arch here.

[hibobmaster]

It's not so hard, here is my working steps for arm64 device.

cd ~/build/mattermost
wget https://raw.githubusercontent.com/mattermost/mattermost/master/server/build/entrypoint.sh

Create a Dockerfile and edit version 9.2.1 to match your need.

FROM ubuntu:jammy

# Setting bash as our shell, and enabling pipefail option
SHELL ["/bin/bash", "-o", "pipefail", "-c"]

# Some ENV variables
ENV PATH="/mattermost/bin:${PATH}"
ARG PUID=2000
ARG PGID=2000
ARG MM_PACKAGE="https://releases.mattermost.com/9.2.1/mattermost-9.2.1-linux-arm64.tar.gz?src=docker"

# # Install needed packages and indirect dependencies
RUN apt-get update \
  && DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends -y \
  ca-certificates \
  curl \
  mime-support \
  unrtf \
  wv \
  poppler-utils \
  tidy \
  tzdata \
  && rm -rf /var/lib/apt/lists/*

# Set mattermost group/user and download Mattermost
RUN mkdir -p /mattermost/data /mattermost/plugins /mattermost/client/plugins \
  && addgroup -gid ${PGID} mattermost \
  && adduser -q --disabled-password --uid ${PUID} --gid ${PGID} --gecos "" --home /mattermost mattermost \
  && if [ -n "$MM_PACKAGE" ]; then curl $MM_PACKAGE | tar -xvz ; \
  else echo "please set the MM_PACKAGE" ; exit 127 ; fi \
  && chown -R mattermost:mattermost /mattermost /mattermost/data /mattermost/plugins /mattermost/client/plugins

# We should refrain from running as privileged user
USER mattermost

#Healthcheck to make sure container is ready
HEALTHCHECK --interval=30s --timeout=10s \
  CMD curl -f http://localhost:8065/api/v4/system/ping || exit 1

# Configure entrypoint and command
COPY --chown=mattermost:mattermost --chmod=765 entrypoint.sh /
ENTRYPOINT ["/entrypoint.sh"]
WORKDIR /mattermost
CMD ["mattermost"]

EXPOSE 8065 8067 8074 8075

# Declare volumes for mount point directories
VOLUME ["/mattermost/data", "/mattermost/logs", "/mattermost/config", "/mattermost/plugins", "/mattermost/client/plugins"]

Build arm64 docker image

docker build . -t mattermost-arm:9.2.1

---

Mattermost working directory setup

cd /opt/mattermost
mkdir -p mattermost/{config,data,logs,plugins,bleve-indexes}
mkdir -p mattermost/client/plugins
chown 2000:2000 -R .

Create a compose.yaml file, edit chat.example.com to your domain name

services:
  postgres:
    container_name: postgres_mattermost
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - ./postgresql/data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=mattermost
      - POSTGRES_PASSWORD=mattermost
      - POSTGRES_DB=mattermost

  mattermost:
    depends_on:
      - postgres
    container_name: mattermost
    image: mattermost-arm:9.2.1
    restart: unless-stopped
    ports:
      - 127.0.0.1:8065:8065
    volumes:
      - ./mattermost/config:/mattermost/config
      - ./mattermost/data:/mattermost/data
      - ./mattermost/logs:/mattermost/logs
      - ./mattermost/plugins:/mattermost/plugins
      - ./mattermost/client/plugins:/mattermost/client/plugins
      - ./mattermost/bleve-indexes:/mattermost/bleve-indexes
    environment:
      # necessary Mattermost options/variables (see env.example)
      - MM_SQLSETTINGS_DRIVERNAME=postgres
      - MM_SQLSETTINGS_DATASOURCE=postgres://mattermost:mattermost@postgres:5432/mattermost?sslmode=disable&connect_timeout=10

      # necessary for bleve
      - MM_BLEVESETTINGS_INDEXDIR=/mattermost/bleve-indexes

      # additional settings
      - MM_SERVICESETTINGS_SITEURL=https://chat.example.com

Spin up container

docker compose up

If it looks okay, Ctrl+C then run the container in detach mode.

docker compose up -d

Edit: https://github.com/hibobmaster/useful-notes/tree/main/mattermost You can use hibobmaster/mattermost-arm if you don't want to build it yourself. Cheers!

[mmospanenko]

thanks, yes, this is not hard, but we should build it on runtime env (have build tooling, etc), maintain it. Will be great to have ARM image in registry

[Givemeurcookies]

This is getting increasingly important, more and more infrastructure providers now support ARM processors due to the cost savings in both purchasing the hardware and saved power usage. It's obvious that the providers that has made the switch want more people to use ARM so they're often 30-60% cheaper than the AMD equivalent.

I work for a handful of companies and I've chosen multi-architecture some of the Kubernetes clusters. I've landed on Mattermost because the operator had ARM support but I am suddenly stopped because the Mattermost deployment itself doesn't support ARM... My fault for not checking, but it's not intuitive what image is being used to deploy with the operator and there's no documentation of it. There should be some documentation or way to define the arch used in the operator, optionally some documentation on how to set up nodeAffinity for AMD processors for the ones that haven't done that before.

Currently getting the error exec format error is just annoying as hell. You spend a few hours of configuring some software for Kubernetes and then you get that error and it turns out that most software developers just didn't add one line to their build process and you have to build it yourself (which you won't in a professional setting, since it requires a lot of maintenance and you want to benefit from auto image updates). I understand from the thread that it's a bit more involved in Mattermost due to some hardcoding, but still, could this be prioritised? This isn't just an issue of people running Mattermost on their RPI's, it's turning away companies that want to use Mattermost as an alternative to Slack (especially due to the longterm cost and new design of Slack).

[agnivade]

I just want to add a bit of context here.

and then you get that error and it turns out that most software developers just didn't add one line to their build process

Because we don't officially support it.

I understand from the thread that it's a bit more involved in Mattermost due to some hardcoding, but still, could this be prioritised?

As you have correctly surmised, officially adding ARM support is a bit more than adding a single line. It means spending more engineering time and bandwidth, both of which are a limited resource at this point. Officially supporting would mean testing for both AMD64 and ARM architectures in CI which means increased costs. It also means developers need to study and understand the performance implications of ARM architectures. While none of these are impossible, it requires a big investment from our side.

[mmospanenko]

ARM is future that already today. We moved our infrastructure to ARM, but have some old-fashion services on old/expensive/slow AMD64 servers. Here you can compare costs (my ref link with some credits to test it).

Anyway, I can't agree with:

for both AMD64 and ARM architectures in CI which means increased costs

We significantly reduced costs (tens of prod, staging, development servers) on infrastructure with moving to ARM, getting a lot of powerful instances and got a lot of free resources for CI. Yes, developers should learn something new, but once again - ARM is the future today. We can't stop progress :)

[this-is-tobi]

Hello,

I understand the issues raised in getting official support for the ARM architecture, I think the community is willing to help implement this feature however one of the problems I see is that the build/release CI for Docker images is not public (at least it doesn't seem to be done on Github Actions within the project and I haven't found any documentation providing any information on this even asking the question on Mattermost's Mattermost).

@agnivade Is there any reason not to use Github Actions as a CI system for Docker image releases ? I don't want to advertise Github, but they offer free runners for open source projects, which could help increase the CI load without increasing costs (see. https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions), maybe it would be possible to use emulation for the arm64 part of the CI if it's a subject. In addition, a public CI would allow external contributors to participate in its improvement (as I did, for example, to build the arm64 image of the Mattermost operator). Perhaps you'd like to keep control of this part of the CI, or perhaps migration would be too costly ?

While waiting for a permanent solution to this problem, I've built an automated system that checks every day whether a new version is available and builds a multi-arch image based on the binaries available on https://releases.mattermost.com (including the arm64 binary, am I to understand that it is not officially supported ?)

In case anyone is interested, my mirror CI is available here: https://github.com/this-is-tobi/multiarch-mirror/blob/main/.github/workflows/mattermost.yml (it still requires maintenance to check that the system isn't broken, but it's less impactful than building mirrors by hand for each new Mattermost release). The image is available here : https://github.com/this-is-tobi/multiarch-mirror/pkgs/container/mirror%2Fmattermost.

# pull command
docker pull ghcr.io/this-is-tobi/mirror/mattermost:latest