Dev Workflow Question: How to build a custom docker image of jitsi-meet (web) for use in our dockerized setup?

First of all, thanks for developing this great product!

After successfully setting up both local and public deployments of jitsi using Docker, and setting up a local development workflow for jitsi-meet (using VSCode and WSL on Windows), we’ve hit a bit of a roadblock.

My original plan was:

  1. build custom docker image of jitsi-meet and upload it to our company’s private docker registry
  2. in our deployment (based on docker-jitsi-meet), login to both the docker registry where the jitsi stack is hosted, as well as into our private registry, and modify the docker-compose.yml file so that web.image points to our custom image

One uncertainty I had was that the naming confused me a little. The jitsi/jitsi-meet repository seems to represent the “web/frontend” part, but jitsi/docker-jitsi-meet seems to represent docker configuration for all components of the stack. Is this correct?

I have to preface this by saying that I don’t have a lot of experience with developing/building docker images; I’ve only been on the consuming end so far.

Documentation didn’t get me too far I’m afraid. My main questions are:

  1. I have connected our fork of jitsi-meet to a private repository on dockerhub. What infrastructure do I need to add to the fork so the image can be built on dockerhub? Should I copy over the Dockerfile and Makefile from docker-jitsi-meet/web into the fork’s root directory? My goal is to have dockerhub generate a clean, isolated image of just the jitsi-meet web frontend that I can then pull in through a dockercompose file.
  2. When step 1 is working, would it be enough to just point the docker-jitsi-meet/docker-compose.yml's web.image entry to our own image? Or would we need to configure anything else?

Please do let me know if you have any follow-up questions or if anything’s unclear and I’ll try my best to provide more details. Thanks for your time!

Quick update on what we’ve tried so far, hoping to get our custom jitsi-meet fork built into a docker image for usage in our jitsi kubernetes setup.

Our basic plan:

  1. fork jitsi-meet (done)
  2. modify it locally (done)
  3. run make to build it (done)
  4. run docker build someargs to create a docker image from it
  5. run docker push to push the image to our repository on dockerhub

We’re currently stuck on step 4.

Things we’ve tried:

I found the official Dockerfile for jitsi-meet-web. The main issue here is that the Dockerfile pulls in an existing jitsi-meet-web package through apt-get:

apt-dpkg-wrap apt-get install -y cron nginx-extras jitsi-meet-web && \

This means that a 1:1 replacement would require us to publish our own image to an apt repository (and we’d need to find out how this package needs to be structured). Optimally, though, I would like to just build our image from the artifacts of running make inside jitsi-meet through the Dockerfile.

I searched for other solutions, and found this thread:

The workaround (custom Dockerfile) was acknowledged by @saghul , so this looks like a viable path. However, I’m not entirely sure about the exact setup to get this Dockerfile working. I tried adding it to the root of the jitsi-meet repository and invoking it there, but I get stuck at:

Step 4/10 : COPY /config /config
COPY failed: stat /var/lib/docker/tmp/docker-builder069766215/config: no such file or directory

I checked, and neither jitsi-meet nor docker-jitsi-meet has a root-level /config directory. I’m not sure what the intention there is, or if this Dockerfile is for an outdated version, or if I’m supposed to use it with a different (official? non-official?) jitsi-meet repository.

To summarize: we’re still looking for a way to get our customized jitsi-meet (name of the repository we forked; the part we’re really interested in is web - we want to modify the css, basically) into our kubernetes cluster.

Any help is appreciated, thanks!

1 Like

This is how I’m using it.

ARG JITSI_REPO=jitsi
FROM ${JITSI_REPO}/base

ADD https://dl.eff.org/certbot-auto /usr/local/bin/

RUN \
	apt-dpkg-wrap apt-get clean && rm -rf /var/lib/apt/lists/* && \
	apt-dpkg-wrap apt-get update --fix-missing && \
	apt-dpkg-wrap apt-get install -y cron nginx-extras jitsi-meet-web && \
	apt-dpkg-wrap apt-get -d install -y jitsi-meet-web-config && \
    dpkg -x /var/cache/apt/archives/jitsi-meet-web-config*.deb /tmp/pkg && \
    mv /tmp/pkg/usr/share/jitsi-meet-web-config/config.js /defaults && \
	mv /usr/share/jitsi-meet/interface_config.js /defaults && \
	apt-cleanup && \
	rm -f /etc/nginx/conf.d/default.conf && \
	rm -rf /tmp/pkg /var/cache/apt

RUN \
	chmod a+x /usr/local/bin/certbot-auto && \
	certbot-auto --noninteractive --install-only

COPY rootfs/ / 

COPY DynamicChanges/ /usr/share/jitsi-meet
COPY DynamicChanges/interface_config.js /defaults/interface_config.js

EXPOSE 80 443

VOLUME ["/config", "/etc/letsencrypt", "/usr/share/jitsi-meet/transcripts"]

Thanks! @metadata one thing I can’t read from your solution is the outside context in which you run this Dockerfile. You copy rootfs/ and DynamicChanges/ - where do these come from?

We managed to solve this last night with a different approach, though. Instead of building our own jitsi/web image from jitsi/base, we simply take jitsi/web as a template and use COPY to overwrite specific elements.

In case this helps anyone else, here’s how:

  1. fork https://github.com/jitsi/jitsi-meet and set up local dev environment so you can make the project
  2. add this Dockerfile to the repo root:
FROM jitsi/web:stable-4548-1
USER root
COPY ./css/all.css /usr/share/jitsi-meet/css/
# we only needed the css so far; add further COPY instructions for other build artefacts if needed
  1. If you want to build it on DockerHub, link the repo, set up autobuild and add the following hooks/pre_build file:
#!/bin/bash
curl -sL https://deb.nodesource.com/setup_12.x -o nodesource_setup.sh
bash nodesource_setup.sh
apt-get install -y nodejs
apt-get install -y npm
hash -d npm
npm install
make

This allowed us to continously build and deploy our custom image. We were then able to use that image in our kubernetes setup in place of the official one.

Problem solved! Though it took us around 4 days to arrive at this solution - mentioning this as a possible way somewhere in the documentation could save others time, I think.

@RobinB rootfs is web/rootfs and DynamicChanges is the directory that I use to configure the web UI like changing the background with a wallpaper, redirecting to different website once the meeting is closed.

1 Like

This discussion was really helpful to me as I worked through doing a Docker development deployment myself. I wrote an extended blog post on my experiences here. This post describes how I set up my development environment, including live-reloading of the front-end using webpack and rapid Docker container rebuilds of the back-end. Hopefully that will be of some use to people looking for examples of Docker deployments. Thanks again!