简介：docker-jitsi-meet 的完整源代码压缩包，面向需要快速搭建开源视频会议系统的开发与运维人员。Jitsi-Meet 基于 Docker 容器化部署，支持多人视频、屏幕共享、录制与聊天，适用于远程办公和在线教育等场景。包内包含 128 个文件，主要有 docker-compose.yml、env.example、各类 yml 编排文件、sh 配置脚本、dockerfile 镜像定义以及 conf、lua、properties 等组件配置，zip 包仅 386KB，便于本地部署与二次开发。资源已吸引 206 人学习浏览。通过阅读源码可深入理解容器化视频会议系统的模块划分、安全配置（如密码生成与加密认证）及扩展方式，方便根据业务场景定制组件或开发插件；对希望掌握 Docker 编排与 WebRTC 会议服务集成的学习者而言，是一份紧凑而实用的参考资料。 第一次点进 jitsi/docker-jitsi-meet 仓库的人，十有八九会愣一下：搜“docker-jitsi-meet的源代码”，本以为是 Jitsi Meet 的 React 前端实现，结果仓库里躺着的全是 Dockerfile、rootfs、cfg.lua 这类东西。这个仓库的真实身份是官方 Docker 化部署工程，它不写音视频业务逻辑，却决定了你的视频会议系统如何被构建、配置、启动和扩展。如果你想自建一套 Jitsi 服务、做前端定制、排查“为什么改了配置不起作用”这类问题，读这份源代码反而比直接去看业务源码更当紧。下面我把这份仓库从目录结构到配置注入机制拆开讲透，并补上我在实际维护中踩过的坑。
1. 先搞清楚一件事：这份“源代码”到底指什么
1.1 根目录文件清单：哪些值得逐个读
先按我自己的阅读习惯，把仓库根目录拉出来看一遍：
docker-jitsi-meet/ ├── .env.example # 环境变量模板，部署入口配置 ├── docker-compose.yml # 编排所有服务的主文件 ├── docker-compose.override.yml ├── Makefile # 封装常见操作命令 ├── gen-passwords.sh # 自动生成密码并写入 .env ├── web/ │ └── rootfs/ # web 容器文件系统快照 ├── prosody/ │ └── rootfs/conf.d/ # XMPP 服务器配置模板 ├── jicofo/ │ └── rootfs/ ├── jvb/ │ └── rootfs/ ├── etherpad/ │ └── rootfs/ └── base/ # 各容器共享的基础镜像构建逻辑很多人 clone 下来第一件事就是打开 docker-compose.yml，但我建议先看.env.example。这个文件虽然叫 example，实际是整个部署系统的参数词典，里面每个变量基本都能在 docker-compose.yml 里找到引用位。你可以把它当作“配置索引”来读，然后再去 docker-compose.yml 里查某个变量最终用在哪里。
这里有个新手必踩的坑：.env.example不是.env。官方文档让你cp env.example .env，是因为 docker-compose 加载环境变量的顺序里，.env文件优先于系统环境变量。如果你只在 shell 里 export 了一些变量，没有创建.env，容器里起到的配置可能就是一堆默认值，改了等于没改。
1.2 每个容器目录背后的职责边界
仓库里几乎每个子目录对应对应 docker-compose 里的一个服务，我整理了一张职责表：
| 目录 | 对应容器 | 核心职责 | 需要留意的关键文件 |
|---|---|---|---|
| web/ | web | Nginx 静态资源 + 前端页面 + 配置注入 | rootfs/default.json、rootfs/interface_config.js |
| prosody/ | prosody | XMPP 服务器，处理域名、认证、聊天室 | rootfs/conf.d/ 下的 cfg.lua 模板 |
| jicofo/ | jicofo | 会议焦点，管理会议生命周期与参与者 | rootfs/etc/jicofo 下的配置 |
| jvb/ | jvb | SFU 媒体路由器，处理 WebRTC 音视频流转发 | rootfs/defaults/sip-communicator.properties |
| etherpad/ | etherpad | 可选的协作白板 | rootfs/ 下 Node 应用配置 |
| base/ | base | 基础镜像，供其他容器多阶段构建 | 各 Dockerfile |
要特别解释一下rootfs/的含义。它相当于容器文件系统的“快照模板”，镜像构建时会把 rootfs 下的内容拷进容器对应路径。但注意，这些文件不一定是最终生效的文件，很多只是模板。容器启动时通过 entrypoint 脚本读取环境变量，动态生成真正的配置文件。所以你在 rootfs 里看到的 default.json 是“原材料”，容器内的 /usr/share/jitsi-meet/config.js 才是“成品”。
如果你想把会议中单人带宽限制改掉，应该在.env里找JVB_开头的变量，而不是直接去改 rootfs 里的 sip-communicator.properties。后者会在容器重建时被覆盖，改了半天等于白改。
2. 源码里真正藏着的三个关键机制
2.1 环境变量到容器配置文件的完整链路
docker-jitsi-meet 的核心设计就是“配置即环境变量”。整个链条大概是这样的：
- 容器启动，entrypoint 脚本开始执行
- 脚本读取当前容器的全部环境变量
- 通过模板渲染或字符串替换，生成 Nginx、Prosody、Jicofo、JVB 各自需要的配置文件
- 如果存在
/init.d/下的自定义脚本，再按顺序执行，用于最后覆盖
以 web 容器为例，入口脚本会生成/etc/nginx/conf.d/meet.conf以及前端的config.js、interface_config.js等运行时配置。JITSI_HOST决定 Nginx 的 server_name，ENABLE_AUTH、ENABLE_GUESTS控制是否开启鉴权与访客入会，XMPP_DOMAIN决定 Prosody 的域。
这里推荐一个调试命令，能让你把编排“摊开”来看：
docker-compose config它会读取 docker-compose.yml、.env、override 文件，把环境变量展开后的最终编排结果打印出来。我第一次发现这个命令的时候，很多“为什么容器里配置是这个值”的疑问直接解决了。
2.2 服务依赖与健康检查的设计逻辑
docker-compose.yml 里定义了严格的依赖链：web 依赖 prosody，jicofo 依赖 prosody，jvb 依赖 prosody。这是由 Jitsi 的架构决定的，Prosody 是所有信令的中枢，如果 XMPP 域没准备好，Jicofo 和 JVB 起来也是连着报错。
编排里用了depends_on加condition: service_healthy的写法，容器启动时先做健康检查再启动下游。这个设计在我自己写服务编排时很值得借鉴：
healthcheck: test: ["CMD", "python3", "/usr/local/bin/healthcheck.py"] interval: 30s timeout: 10s retries: 3用健康检查而不是简单地sleep 10，是因为 Prosody 就绪时间在不同机器上差异很大。固定 sleep 容易在配置高一点的服务器上浪费几十秒，在慢机器上又可能不够，健康检查则能自适应。
2.3 gen-passwords.sh：防止配置遗漏的兜底设计
gen-passwords.sh 是很多人容易忽略的小脚本，但它挺能代表这个仓库的工程风格。它会检查.env里是否已有JICOFO_AUTH_PASS、JVB_AUTH_PASS等密码变量，没有则生成一段随机密码追加进去。
这个设计的价值在于：Jicofo、JVB、Prosody 之间的认证密码必须一致，任何一处漏配都会导致服务之间无法认证，但又很难从日志里一眼看出是密码问题。用脚本统一生成和维护，就把这类人为失误降到最低。
我自己的习惯是，.env里的密码一旦生成就不要在多个实例间复制，尤其别把.env提交到 Git。仓库里给的是.env.example就是提醒你：模板可以公开，真实密钥需要保密。
3. 源码落地：三种定制路线和对应改动点
3.1 只改 .env 能解决九成需求
我在维护线上会议实例的过程中发现，大部分需求真的不用改业务代码，改环境变量就行。下面这些配置是我用得非常频繁的：
| 需求 | 环境变量 | 说明 |
|---|---|---|
| 修改访问域名 | JITSI_HOST | 对应 Nginx server_name |
| 开启登录鉴权 | ENABLE_AUTH=1 | 要求用户登录才能入会 |
| 设置默认会议室主题 | THEME_COLOR | 前端 UI 主色调 |
| 开启协作白板 | ENABLE_ETHERPAD=1 | 拉起 etherpad 容器 |
| 限制会议人数上限 | MAX_PARTICIPANTS | Jicofo 侧读取 |
| 调整媒体端口范围 | JVB_TCP_PORT / JVB_UDP_PORT | 务必与 docker-compose 端口映射一致 |
例如开启鉴权，最简单的方式是在.env里配置：
ENABLE_AUTH=1 ENABLE_GUESTS=0 JICOFO_AUTH_USER=focus然后重启容器。这套方式的本质是让源码里已有的代码去处理复杂逻辑，你只是用环境变量告诉它“走哪条分支”。
3.2 挂载覆盖前端配置文件
如果需求涉及前端界面的定制，比如换 Logo、改默认语言、隐藏某个按钮，我一般用 volume 挂载覆盖，而不是直接改镜像里的文件。推荐把自定义内容放在custom-config.js里，因为这个文件本身就是 Jitsi Meet 预留的扩展点。
docker-compose.override.yml 里加一段：
services: web: volumes: - ./custom-config.js:/usr/share/jitsi-meet/custom-config.js:rocustom-config.js里可以写类似这样的逻辑：
window.onload = () => { // 动态修改 config 对象 config.defaultLanguage = 'zh'; interfaceConfig.APP_NAME = '我的会议室'; };为什么不建议直接挂载覆盖interface_config.js？因为 web 容器启动时会重新生成这个文件，你的覆盖可能被冲掉。而custom-config.js是设计给外部扩展使用的加载点，生命周期更稳定，也更不容易被版本升级影响。
3.3 fork 源码后构建私有镜像
当前面两种路线都满足不了需求时，才需要考虑 fork 后自建镜像。比如你想改 Prosody 的 LDAP 对接逻辑，或者修改 JVB 的某些底层网络策略，那就要动 rootfs 里的模板或代码。
构建命令并不复杂：
docker-compose build --no-cache web docker-compose up -d web真正麻烦的是构建时间和镜像体积。web 镜像构建过程中会 npm install 前端依赖，第一次构建可能超过 10 分钟，所以我建议先在本地跑前端开发模式调好逻辑，再走完整构建。另外，自定义镜像要用自己的 Dockerfile 时，尽量基于官方镜像做增量定制，把自定义脚本 COPY 进去就可以，避免从零构建带来的依赖版本不一致问题。
4. 绕不开的部署排错：按源码线索逐层排查
4.1 音视频不通，先查 UDP 端口映射
自建 Jitsi 最常遇到的现象是：会议能创建、其他人能看到画面，但声音断断续续甚至完全没有。这大概率不是 Jitsi 源码 bug，而是 JVB 的 UDP 端口没映射好。
JVB 默认用 UDP 10000 开始的端口范围传输媒体流，docker-compose.yml 里 jvb 服务的端口定义至少要长这样：
ports: - '4443:4443' - '10000:10000/udp'然后宿主机防火墙、路由器都要放行对应 UDP 端口范围。如果你想验证端口到底通不通，可以这样查：
docker-compose ps docker-compose port jvb 10000/udp netstat -ulnp | grep 10000如果docker-compose port输出为空，说明容器里的端口没有正确映射到宿主机，媒体流自然出不去。
4.2 配置改了没生效：四层链路排查法
改完.env重启容器后发现界面还是老样子，这是我最常被问到的问题。大多数人第一反应是“浏览器缓存”，其实大多数情况是配置链路某个环节断了。我总结了一个四层排查链路：
- 容器内环境变量是否真的更新了：
docker-compose exec web env | grep JITSI - 容器内最终生成的配置文件是什么内容：
docker-compose exec web cat /usr/share/jitsi-meet/interface_config.js - 启动日志里有没有配置相关的报错：
docker-compose logs -f web - 挂载卷有没有覆盖目标路径，导致默认生成逻辑被跳过
只要按这个链路走一遍，九成“配置没生效”都能定位到具体原因。核心思想是：环境变量、模板渲染、挂载覆盖、容器内成品文件这四层，每一层都可能出问题，不能改完.env就默认它一定会传导到最终文件。
4.3 三容器日志定位法：什么现象看哪个日志
Jitsi 的问题往往横跨多个组件，看日志也要按“症状”选“容器”：
| 症状 | 优先看 | 再配合 |
|---|---|---|
| 页面打不开、白屏 | web 容器 | Nginx 访问日志 |
| 登录失败、域名解析异常 | prosody 容器 | 认证相关日志 |
| 会议创建失败、人数受限 | jicofo 容器 | 会议调度日志 |
| 通话卡顿、断流、无声音 | jvb 容器 | 媒体路由日志 |
实际操作时我用得最多的是这个命令：
docker-compose logs -f --tail=100 jvb | grep -i "udp\|port\|failed"这样只过滤关键信息，而不是被一堆无关日志淹没。尤其在自建镜像后第一次启动时，建议先单独起 jicofo 确认它能连上 prosody，再起其他容器，让问题边界更清晰。
5. 从这份源码里学到的架构思路
5.1 配置模板与镜像分离的好处
读这份源码最大的收获是：它把“镜像”和“配置”彻底解耦。镜像里只放模板和代码，所有环境相关的差异全部通过环境变量注入。这样同一个镜像可以部署在 dev、staging、prod 不同环境里，不用为每个环境单独重新构建镜像。
这个思路放在个人项目里也适用：与其在代码里写死各种域名、密钥、端口，不如提供一个配置模板，启动时由脚本完成渲染，代码仓库只保留一份模板和一版默认值。
5.2 健康检查是编排可靠性的关键
我之前做服务编排时习惯用“启动顺序 + 固定等待”来处理依赖，时间久了发现很脆弱。docker-jitsi-meet 用健康检查配合 depends_on 方案更稳健。它不是在猜测服务多久就绪，而是主动探测信号，这样在性能不同的服务器上都能拿到最短且安全的启动时机。
5.3 维护自己的 fork 分支
我自己长期维护着一个 fork 分支，用于部署定制版 Jitsi。官方仓库更新节奏不慢，安全修复和 WebRTC 能力改进经常出现，长期停在旧版本风险不小。我现在的习惯是定期拉取最新 tag，在测试环境验证没问题后再切生产：
git fetch upstream git checkout -b upgrade-<version> upstream/main先对比一下自己 fork 的改动点有没有冲突，然后执行docker-compose up -d，重点验证会议创建、参会、共享屏幕、录制等核心链路。这个流程帮我避免过至少两次线上事故，也让我明白了源码阅读的终点不是看懂代码，而是能安全、稳定地把它跑起来并持续迭代。
本文还有配套的精品资源，点击获取
