Before I installed my first Jitsi server I thought that it must be quite a complicated affair. I searched around a bit and found a simple way to install it via a docker-compose script. The Docker script sets up a couple of Docker containers that encapsulate the different programs required to run the Jitsi-meet server such as the web server, the xmpp server and other stuff. Neat. However, there were two problems that prompted me to search for another solution in a hurry.
Dry-Runs for a Demo
The need for an alternative emerged out of the blue. To give back to the community, I wanted to do a live demo on how to install Jitsi-Meet on a server at the first Divoc conference “Hidden Service”. As lots of things can go wrong in a live demo I really wanted to be prepared so I did a couple of dry-runs. In the last dry run the day before, the installation procedure started to royally fail. I turned out that Jitsi was updated which in turn broke the Docker container setup. And nobody noticed before Easter. That really ruins your day if that happens during a live demo.
A Different Method is Better Than a Fix
But I had a day to find a fix. In the end, my solution was not to use Docker containers at all but to install Jitsi-meet from Jitsi’s own apt repository. Even simpler than using containers! This makes me wonder why there’s a dockerized version of the installation when it is even easier to install it via an apt repository!? Beats me…
Not that I’m against dockerized installations in general. Collabora online office as part of a Nextcloud instance, for example, runs happily in a container. But the decision which way to go is not straight forward. Another interesting thing I’ve learnt in the past couple of weeks.