Docker项目修改（ddcc优化字幕）

记录一下 docker 项目修改的经历。 vps 远程开发

#tech / dev #type / howto #status / evergreen

[!info] related notes

BodySense 项目 MOC

Development Environment MOC

Go 高级运行时与抽象 MOC

Go 并发 MOC

Go 语言基础 MOC

Docker项目修改

概览

docker-project-ddcc-subtitle-optimization
为了保证代码可控，使用了之前建立的 3.0 的仓库（http://10.248.18.6:9000/boc-live/boc-live.git），并将代码重新应用到该仓库中。
- 修改分支为feature/apply-new-changes
现在需要在测试服务器上部署这个仓库的 bbb，测试添加代码后能否使用
- 与运维人员沟通
  - 测试服务器上的 bbb 是 docker 3.0.4 版本的，白板功能好像有缺失。
  - 现在需要 docker 3.0.8 的源码（基准版本）来自建仓库，方便代码管理和修改
在该测试服务器上进行开发（字幕样式优化）和测试

为了帮助 AI（无论是生成代码的 AI 还是辅助设计的 AI）精准理解这张图中的需求，我将图片中的视觉信息和文字标注转化为了结构化的需求描述提示词（Prompt）。

你可以直接复制下面的内容发送给 AI。

22服务器（环境）bbb域名

📷 图像需求转化为文字描述

1. 核心目标

调整 Web 会议/直播界面的 UI 布局，将原本悬浮或独立的“实时语音转文字（Smart Caption）”模块，整合进页面左侧的侧边栏（Sidebar）中。

2. 具体 UI/UX 更改细节

新增一级导航分类：
- 位置： 在页面最左侧的竖向图标导航栏（现有的“消息”、“笔记”、“用户”下方）。
- 名称： 新增一个名为 “翻译” (Translation) 的分类。
- 样式： 保持与现有侧边栏图标风格一致。
新增二级功能入口：
- 层级： 在“翻译”分类下。
- 功能名称： Smart Caption。
- 交互： 用户点击左侧导航栏的“翻译”后，应显示“Smart Caption”选项（或者直接默认展开该面板）。
面板显示区域：
- 布局： 当选中“Smart Caption”时，实时语音转写的字幕内容应显示在左侧的面板区域（即原本显示“公共聊天”或“共享笔记”的区域）。
- 视觉参照： 这里的显示样式和布局逻辑，应完全参考“公共聊天 (Public Chat)” 的样式——即一条条的消息流形式，包含发言人名字和对应的文字内容。

3. 逻辑流程

原状态： Smart Caption 是一个悬浮的弹窗（如图中箭头起始处）。 新状态： Smart Caption 变为左侧侧边栏的一个固定功能模块（如图中箭头指向处及红字标注）。

🤖 推荐使用的 AI 提示词 (Prompt)

如果你需要让 AI 写代码或生成设计文档，可以使用以下这段更专业的描述：

角色设定： 前端 UI/UX 工程师

任务： 根据提供的设计草图，修改 Web 会议室界面的左侧导航栏布局。

具体需求：

左侧导航栏 (Sidebar) 更新： 在现有的 Messages, Notes, Users 列表下方，追加一个新的导航项 Translation (中文：翻译)。

功能模块集成： 将 Smart Caption (智能字幕) 功能移动到 Translation 模块下。

面板布局 (Panel Layout)：

废弃原有的 Smart Caption 悬浮弹窗模式。

将字幕内容渲染在左侧的抽屉面板（Drawer/Panel）中。

面板的 UI 结构复用 Public Chat (公共聊天) 的组件样式：包括头部标题、消息列表容器、以及发言人 ID 和文本内容的排列方式。

预期结果： 用户点击左侧“翻译”图标时，左侧面板切换为 Smart Caption 界面，实时显示会议语音转写内容。

概念

部署也是按照源码启动的，是放在一起的。

源码编译完打到容器里后，就不会用了，挪走也是没事的。但是如果改了源码，就需要重新使用Dockerfile编译，重建容器源码编译的命令是docker compose up -d —build —force-recreate —build 是编译，—force-recreate 是重建容器然后看日志 docker compose logs -f —tail=500 bbb-web 容器重启命令：docker compose restart 你改的基本是web ，容器（nginx、web、transcription-controller）可能要频繁编译和重建容器，重启，其他的服务是否重启要看情况了涉及到24个容器

你的理解完全正确，但有几个关键点需要注意，特别是关于效率和 配置修正。

我已经帮你修改了 docker-compose.yml，现在 bbb-transcription-controller 也能支持源码编译了。

1. 你的理解确认

编译并重建：docker compose up -d --build --force-recreate
- ✅ 正确。这是“核弹级”命令，会强制重新构建所有镜像并重建所有容器。
- ⚠️ 缺点：24 个容器全部重跑非常慢。
查看日志：docker compose logs -f --tail=500 <服务名>
- ✅ 正确。
重启容器：docker compose restart <服务名>
- ✅ 正确。仅适用于修改了配置文件（挂载的 volume），不适用于修改了代码（因为代码通常是在 build 阶段打入镜像的）。

2. 关键修正与优化建议

你提到主要修改 nginx (HTML5), web, transcription-controller。为了提高效率，建议只重构你修改的服务：

A. 修改了 HTML5 前端代码 (`bigbluebutton-html5`)

在这个 Docker 架构中，HTML5 客户端是在 nginx 容器构建阶段被编译进去的（通过 additional_contexts 引入）。

命令：
```
docker compose up -d --build --force-recreate nginx
```
(注意：这会触发 HTML5 的完整编译，可能需要几分钟)

B. 修改了 BBB Web 后端代码 (`bigbluebutton-web`)

命令：

docker compose up -d --build --force-recreate bbb-web

C. 修改了 Transcription Controller 代码

重要：原 docker-compose.yml 中该服务直接使用线上镜像，不会读取你的本地源码。 我已经帮你修改了配置，添加了 build: ../bbb-transcription-controller。

命令：

docker compose up -d --build --force-recreate bbb-transcription-controller

总结：开发常用命令速查

场景	命令	备注
修改了 HTML5 代码	`docker compose up -d --build nginx`	HTML5 编译较慢，请耐心等待
修改了 Web 代码	`docker compose up -d --build bbb-web`	较快
修改了字幕服务代码	`docker compose up -d --build bbb-transcription-controller`	极快 (Node.js)
修改了配置文件	`docker compose restart <服务名>`	例如改了 `default.yml`
查看日志	`docker compose logs -f --tail=200 <服务名>`	推荐加上服务名，否则日志太乱

现在你可以尝试去修改代码，然后用上面的针对性命令来更新容器了。

Made changes.

是吧，然后你在自己创建的dev目录，重新编译启动不过去，应该是容器冲突，不能同时启动两个而且编译的时候，容器的名称好像跟目录名称也是有关系的就是编译打包的时候，跟代码目录名称也有关系 bbb有他自己的编译打包规则。。

问题

docker 缓存问题

报错：

failed to solve: bigbluebutton/bbb-build:v3.0.x-release--2025-03-28-180244: failed to resolve source metadata for docker.io/bigbluebutton/bbb-build:v3.0.x-release--2025-03-28-180244: unexpected status from HEAD request to [https://joi8b47k.mirror.aliyuncs.com/v2/bigbluebutton/bbb-build/manifests/v3.0.x-release--2025-03-28-180244?ns=docker.io:](https://joi8b47k.mirror.aliyuncs.com/v2/bigbluebutton/bbb-build/manifests/v3.0.x-release--2025-03-28-180244?ns=docker.io:) 403 Forbidden

分析：单独拉取两个镜像都显示已存在。两个镜像都已存在并且可以拉取，那么构建失败的原因极有可能是 Docker Buildx（或新的 Compose 构建引擎）在尝试解析多阶段构建 (Multi-Stage Build) 缓存或元数据时，仍在尝试使用之前失败的、依赖于阿里云镜像的旧构建配置。

# 1. 清理所有悬挂的或未使用的构建缓存
docker builder prune -f

# 清理出来 91G，执行了半年，我还以为卡住了
n7a5mwdq041kju1gi0ylpnscy                       true    0B                Less than a second ago
Total:  91.07GB

解决：使用 docker builder prune -f 重新构建就不会报错了

让我先了解一下BBB默认演示文稿的生成机制和配置： 

Searched for regex `whiteboard-welcome|default.*presentation|defaultUploadedPresentation`, 20 results

Searched for regex `disableDefaultPresentation|skipDefaultPresentationWhenCustom`, no results

Read [](file:///home/boc-live/bbb-docker-3.0.8-release/mod/bbb-web/bbb-web.properties)

Using "Fetch Web Page"

Fetched https://docs.bigbluebutton.org/development/api/#create

根据我的研究，我发现了一个非常重要的 API 参数：`preUploadedPresentationOverrideDefault`。让我进一步查看相关配置： 

Read [](file:///home/boc-live/bbb-docker-3.0.8-release/sample.env#1-1), lines 1 to 60

Read [](file:///home/boc-live/bbb-docker-3.0.8-release/sample.env#80-80), lines 80 to 158

Read [](file:///home/boc-live/bbb-docker-3.0.8-release/mod/nginx/bigbluebutton#30-30), lines 30 to 50

现在我明白了整个情况。让我总结一下问题和解决方案：

## 问题分析

你使用 `whiteboard-welcome.pdf` 作为默认白板文件，但当用户通过 create API 预上传了演示文稿时，BBB 默认行为是 **不发送默认演示文稿** (`preUploadedPresentationOverrideDefault=true` 是默认值)。

## 解决方案

有三个可行的解决方案，按推荐顺序：

### 方案 1: 修改前端逻辑 (推荐 ✅)

最简单的方案是修改你的 `TogglePresentationButton` 组件，让它始终可用：

- **不依赖** `whiteboard-welcome.pdf` 是否存在
- 改为检测是否有 **任意** 演示文稿可以切换
- 或者让按钮变成"打开白板面板"的功能

### 方案 2: 在 create API 调用时设置参数

在创建会议时添加参数 `preUploadedPresentationOverrideDefault=false`，这样即使预上传了文档，BBB 也会同时加载默认的 `whiteboard-welcome.pdf`。

**位置**：在你调用 BBB create API 的地方（通常在后端集成代码中）

### 方案 3: 通过 insertDocument API 动态插入白板

在前端检测到没有 `whiteboard-welcome.pdf` 时，通过 BBB 的 `insertDocument` API 动态插入该文件。

---

**你想采用哪个方案？**

- **方案 1** 需要修改前端 React 组件
- **方案 2** 需要修改后端 API 调用（Greenlight 或其他集成）
- **方案 3** 需要前端调用 API 插入文档

如果你告诉我你的集成方式（使用 Greenlight 还是自定义后端），我可以帮你具体实现。