@dubit0 docker-jitsi-meet

@dubit0: apologies if I am posting to the wrong place. My comment concerns @dubit0 docker hub arm64 variant of docker-jitsi-meet. First thankyou for posting this code. I think that there are some typo errors in the Base/Dockerfile section e.g. /usr//bin/frep and frep 1.3.8 instead of 1.3.11. These were easily corrected. The java recompilation is also missing - is it required?
My stumbling point is that once the Docker image/container is loaded (Docker-compose up) I get the error that indicates that the jvb, web, jicofo etc. parts are for amd64 and not arm64, For a normal, non docker, upload the same instructions do not give an error. As has been identified the jitsi-meet s/w on github loads without error on arm infrastructure, just needs the java tweak to work.
I am working with the Ubuntu 21.04 arm 64 OS rather than Debian. Any ideas what I am doing wrong?
Cheers, Martin

Adding log reports:
Digest: sha256:ddd9ffbb098b756679568b1b1b01e819d73538950028166910e8041ee92e03f3
Status: Downloaded newer image for jitsi/jvb:latest
Creating docker-jitsi-meet-arm64_web_1 … done
Creating docker-jitsi-meet-arm64_prosody_1 … done
Creating docker-jitsi-meet-arm64_jicofo_1 … done
Creating docker-jitsi-meet-arm64_jvb_1 … done
Attaching to docker-jitsi-meet-arm64_prosody_1, docker-jitsi-meet-arm64_web_1, docker-jitsi-meet-arm64_jicofo_1, docker-jitsi-meet-arm64_jvb_1
jicofo_1 | standard_init_linux.go:228: exec user process caused: exec format error
jvb_1 | standard_init_linux.go:228: exec user process caused: exec format error
prosody_1 | standard_init_linux.go:228: exec user process caused: exec format error
web_1 | standard_init_linux.go:228: exec user process caused: exec format error
docker-jitsi-meet-arm64_web_1 exited with code 1
docker-jitsi-meet-arm64_prosody_1 exited with code 1
docker-jitsi-meet-arm64_jicofo_1 exited with code 1
docker-jitsi-meet-arm64_jvb_1 exited with code 1

sudo docker ps
f501a68d0482 jitsi/jvb:latest “/init” 2 minutes ago Restarting (1) 28 seconds ago docker-jitsi-meet-arm64_jvb_1
8e1173897bb7 jitsi/jicofo:latest “/init” 2 minutes ago Restarting (1) 35 seconds ago docker-jitsi-meet-arm64_jicofo_1
db05dadbc468 jitsi/prosody:latest “/init” 2 minutes ago Restarting (1) 38 seconds ago docker-jitsi-meet-arm64_prosody_1
cea372815c73 jitsi/web:latest “/init” 2 minutes ago Restarting (1) 31 seconds ago docker-jitsi-meet-arm64_web_1

sudo docker run jitsi/web:latest
WARNING: The requested image’s platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
standard_init_linux.go:228: exec user process caused: exec format error

This update describes my trials and tribulations from my first failures after cloning and applying docker-“compose up” to the the docker0 docker-jitsi-meet code on github. I progressed to building each image with the Makefile provided and then pushing/uploading the new images to a new dockehub depository I created. Finally I deleted everything on my hardware - Raspberry Pi4, modified the provided .yml file to point to the new repository and applied “docker-compose up” again to have a working jitsi-meet videoconference system. Details follow.

Apologies to @dubit0 first:

  1. /usr//bin//frep (dubit0 dockerfile base) is correct. It does not throw up an error and is interpreted as /usr/bin/frep, according to linux documentation.
  2. The line referring to ARG=FREP_VERSION1.3.8 (dubit0 dockerfile base) is probably not relevant as the line referring to this ARG has been deleted since June 2021.

The errors I was getting complaining about the incorrect architecture - ARM64, are because the .yml file points to images on the jitsi docker depository and these are compiled for AMD64 - zimples!

So how to build images compiled for ARM64? I used the provided Makefile to build/compile the images on my Raspberry Pi4. This was successful but took a long time.

Using the build method is very memory intensive as containers/ images of Golang Alpine , Debian Buster slim, Frep and S6, are pulled/compiled as part of the jitsi component image image build, but not necessary thereafter. So I decided to upload the new jitsi component images on my Pi to a personal docker hub depository (nitramneerg).

I used the Docker TAG and PUSH commands to upload the 6 relevant images. It took me a while to work out that “tag” has a double meaning. There is the Docker TAG command that adds the new depository/name to each image. For example from jitsi/web to nitramneerg/jitsi-web. Follow this with the Docker PUSH command to upload each image to the new depository. The second is the tag or version to identify the image e.g. default.

I fell into the trap of not issuing the docker LOGIN command before I started. That one will ask for your docker password (when you set up a docker depository you provide this password). Being logged in on the browser is not enough! You continue being logged in until you issue the docker LOGOUT command

I deleted (docker system prune -a - note it will destroy all images and containers) all containers and images on my Pi. I modified the .yml file to point all images to my depository with their new names and issued the docker-compose up command. Success! The new images pulled and run without error and I have a working videoconference suite again on my PI4.

As an aside I had to issue the docker-compose commands with sudo (not necessary on my AMD64 and may have something to do with my original docker/ docker-compose software downloads (APT or SNAP).

I was able start stable conferences on my network using the websocket option (on my UBUNTU AMD machine I have not been able to successfully use websockets - but that is another story).

The docker-jitsi-meet quick start document instructs to put the config directory structure into your “home” directory but were not populated upon a “sudo docker-compose up” instruction. The config directory structure must go into the “root” directory if the sudo prefix is used… That one took a while to work out and I hope it is useful to someone.

Please note that Jibri and Jigasi were out of scope for this project.

To conclude, many thanks to @dubit for the modfied dockerfiles for arm64. A docker build (or “make” using the Makefile) will build images for the correct ARM architecture, after which you are good to go