# deploy-test — 测试服务器部署脚本集 > **适用场景**:部署在**有公网 IP 的测试服务器**上。所有服务(后端、前端、Docker 基础设施、LiveKit)均在本机运行。 > > 如果你在本机 Mac 开发,请使用 `deploy-local/` 目录。 --- ## 两套环境对比 | 项目 | deploy-test(本目录)| deploy-local/ | |------|---------------------|----------------| | 适用机器 | 测试服务器(有公网 IP) | 本机 Mac(无公网 IP) | | 配置文件 | `.env.deploy-test` | `.env.deploy-local` | | 运行时目录 | `.deploy-test/` | `.deploy-local/` | | LiveKit | 本机 Docker 启动,使用公网 IP | 指向本目录服务器的 LiveKit | | Redis/Kafka/Etcd/MinIO | 本机 Docker | 本机 Docker | | 后端服务 | 本机进程 | 本机进程 | | 前端服务 | 本机进程(可选) | 本机进程 | --- ## GitHub:优先配置 SSH 密钥 克隆仓库、`yarn` / `npm` 安装依赖时,部分包会通过 **SSH**(`git@github.com`)访问 GitHub。**请优先在本机或服务器上配置 GitHub SSH 公钥**,再执行 `setup.sh` 或安装前端依赖;这比仅依赖下文的「HTTPS 重写」更符合日常习惯,也少踩坑。 ### 1. 生成密钥(若还没有) ```bash ssh-keygen -t ed25519 -C "your_email@example.com" # 默认路径 ~/.ssh/id_ed25519,可直接回车;passphrase 可选 ``` ### 2. 将公钥添加到 GitHub ```bash cat ~/.ssh/id_ed25519.pub ``` 复制输出 → GitHub 网页:**Settings** → **SSH and GPG keys** → **New SSH key** → 粘贴保存。 ### 3. 验证连通 ```bash ssh -T git@github.com ``` 首次会提示是否信任主机,输入 `yes`;成功会出现 `Hi ! ...`。 ### 4. 无法使用 SSH 时(备选) 在无 SSH、CI、或不能改 `~/.ssh` 的环境,再使用 **`./deploy-test/00-init-tools.sh`** 里的 Git 配置,把 GitHub 的 SSH 地址重写为 HTTPS(见下文「步骤 0」与「pc 前端 yarn install 失败」)。 --- ## 目录结构 ``` deploy-test/ ├── dt.sh # 总控快捷入口:pull/build/start/stop/restart/status ├── 00-init-tools.sh # 步骤0(可选):Linux 服务器安装 Go / Node / Docker、GOPROXY、GitHub HTTPS 重写 ├── common.sh # 公共函数库(路径、日志函数) ├── 01-init-env.sh # 步骤1:写入 .env.deploy-test(已存在则覆盖,旧文件带时间戳备份) ├── 02-patch-config.sh # 步骤2:将 .env.deploy-test 写入各服务 YAML ├── 03-start-infra.sh # 步骤3:启动 Docker 容器(Redis/Kafka/Etcd/MinIO/LiveKit) ├── 04-build.sh # 步骤4:编译所有后端 Go 服务 ├── 05-start.sh # 步骤5:启动所有后端服务 ├── 06-install-frontend.sh # 步骤6:安装前端依赖(可选) ├── 07-start-frontend.sh # 步骤7:启动前端开发服务器(可选) ├── stop.sh # 停止后端服务 ├── stop-infra.sh # 停止 Docker 容器(含 LiveKit) ├── stop-frontend.sh # 停止前端服务 ├── remove-infra.sh # 删除 Docker 容器及数据(危险!) ├── restart.sh # 重启指定服务(支持 --build) ├── status.sh # 查看所有服务状态 ├── logs.sh # 查看日志(统一入口) ├── check-conn.sh # 验证 MongoDB / MinIO(及 build-server 的 S3)连接 └── setup.sh # 一键完整部署(首次使用) ``` 运行时目录(`.deploy-test/`,已加入 `.gitignore`): ``` .deploy-test/ ├── bin/ # Go 编译产物 ├── pids/ # PID 文件 ├── logs/ # 后端/前端服务日志 ├── docker-data/ # Docker 数据卷 ├── docker-logs/ # Docker 容器日志(按日期滚动) └── script-logs/ # 脚本执行日志(带时间戳) ``` --- ## 快捷入口:`dt.sh` `dt.sh` 是 `deploy-test` 的总控脚本,放在 `deploy-test/` 目录内,但会扫描 **deploy-test 上级目录** 下的所有 Git 工程。 ```bash ./deploy-test/dt.sh pull # 拉取所有工程最新代码(fetch + pull --ff-only) ./deploy-test/dt.sh build # 编译后端服务 ./deploy-test/dt.sh start # 启动 deploy-test 后端服务 ./deploy-test/dt.sh stop # 停止 deploy-test 后端服务 ./deploy-test/dt.sh restart # 重启 deploy-test 后端服务 ./deploy-test/dt.sh status # 查看服务状态 ./deploy-test/dt.sh fe-start pc # 启动 pc 前端 ./deploy-test/dt.sh fe-stop pc # 停止 pc 前端 ./deploy-test/dt.sh up # pull + build + restart ./deploy-test/dt.sh deploy # pull + build + restart + status ``` `pull` 是安全更新:只执行 `git fetch --all --prune` 和 `git pull --ff-only`。如果某工程有本地未提交改动,脚本只会 `fetch` 并提示,不会 `reset` 或覆盖本地修改。 --- ## 步骤 0:`00-init-tools.sh`(裸机 / 新服务器) 在**尚未安装 Go、Node、Docker** 的 Linux 测试服务器上,先执行本脚本再跑 `01-init-env.sh` 及后续步骤。`setup.sh` **不会**自动调用它,需手动执行。 **GitHub 访问**:请先完成上文 **「GitHub:优先配置 SSH 密钥」**;本脚本的 **HTTPS 重写** 是在**不能配 SSH** 时的备选,不是首选。 | 项目 | 说明 | |------|------| | **作用** | 安装 Go(默认 1.22.5,可用 `GO_VERSION` 覆盖)、配置 GOPROXY(测速选节点)、安装 Node.js LTS、全局安装 pnpm/yarn、安装 Docker;**备选**:将 GitHub SSH 克隆地址重写为 HTTPS(当环境无法使用 SSH 时,减轻 `pc` 等项目 `yarn install` 失败) | | **环境变量** | `GO_VERSION`(如 `1.22.5`)、`GO_ARCH`(`amd64` / `arm64`)、`NODE_VERSION`(Node 大版本,默认 `20`) | | **权限** | 需要 **root** 或 **sudo**(写入 `/usr/local/go`、`/etc/profile.d/deploy-env.sh` 等) | | **系统** | 面向 Ubuntu/Debian(`apt-get`);脚本内注释说明前置条件 | ```bash # 安装全部(Go + GOPROXY + Node + Docker) sudo ./deploy-test/00-init-tools.sh # 或只执行其中一项 sudo ./deploy-test/00-init-tools.sh go # Go + GOPROXY sudo ./deploy-test/00-init-tools.sh goproxy # 仅重配 GOPROXY sudo ./deploy-test/00-init-tools.sh node # 仅 Node / npm / pnpm / yarn sudo ./deploy-test/00-init-tools.sh docker # 仅 Docker ``` 执行结束后脚本会提示:新开终端需 `source /etc/profile.d/deploy-env.sh` 或重新登录 SSH,再执行 `./deploy-test/01-init-env.sh`。 --- ## 快速开始 ### 首次使用 ```bash # 裸机请先装工具(可选,见上文「步骤 0」) # sudo ./deploy-test/00-init-tools.sh # 一键执行(推荐,不含 00-init-tools) ./deploy-test/setup.sh ``` ### 分步执行 ```bash # 0. (可选)裸机安装 Go / Node / Docker,见上文「步骤 0」 # sudo ./deploy-test/00-init-tools.sh # 1. 写入配置模板(若 .env.deploy-test 已存在会先备份为 .bak.<时间戳> 再覆盖) ./deploy-test/01-init-env.sh # 2. 修改配置(重要:确认 DEPLOY_TEST_IP 等信息正确) vim .env.deploy-test # 3. 将配置写入各服务 YAML(包括 livekit/livekit.yaml) ./deploy-test/02-patch-config.sh # 4. 启动 Docker 基础设施(Redis / Kafka / Etcd / MinIO / LiveKit) ./deploy-test/03-start-infra.sh # 5. 编译后端服务 ./deploy-test/04-build.sh # 6. 启动后端服务 ./deploy-test/05-start.sh # 7. 安装前端依赖(可选) ./deploy-test/06-install-frontend.sh # 8. 启动前端开发服务器(可选) ./deploy-test/07-start-frontend.sh ``` > **pc(Electron)依赖安装**:**优先**按上文配置 **GitHub SSH 密钥**;裸机还需 **`00-init-tools.sh`**(见「步骤 0」)。若仍无法用 SSH,再依赖脚本内的 GitHub **HTTPS 重写**。详见「pc 前端 yarn install 失败」。`pc` 建议仅用 **Yarn**;可删除 `package-lock.json` 消除混用锁文件警告。 > **`07-start-frontend.sh`**:启动前会读取 `.env.deploy-test`(若存在),文末「访问地址」等处使用 `DEPLOY_TEST_IP`;未设置时默认为 `127.0.0.1`,避免脚本在 `set -u` 下因未定义变量退出。 --- ## 配置文件(`.env.deploy-test`) ```bash # ══ 测试服务器公网 IP ═══════════════════════════════════════════ DEPLOY_TEST_IP=54.116.29.247 # 本机公网 IP(LiveKit WebRTC 必需) # ══ MongoDB ════════════════════════════════════════════════════ MONGO_HOST=47.237.103.4 MONGO_PORT=27017 MONGO_USERNAME=minio_pC5wMB MONGO_PASSWORD=rI57PJsJhnz_qlRkfnTa0RPT MONGO_AUTHSOURCE=admin # 认证库(常见 admin);须与 MongoDB 用户实际创建所在库一致 MONGO_DATABASE=openim_v3 # 业务数据所在库 BUILD_MONGO_DATABASE=build # ══ MinIO(open-im-server,Docker 容器 dev-minio)═════════════════ MINIO_ROOT_USER=minioadmin MINIO_ROOT_PASSWORD=xxx MINIO_BUCKET=openim MINIO_API_PORT=9000 MINIO_CONSOLE_PORT=9001 MINIO_INTERNAL_ADDRESS=127.0.0.1:9000 # 外网访问地址(与 DEPLOY_TEST_IP 一致),须安全组放行 TCP MINIO_API_PORT MINIO_EXTERNAL_ADDRESS=http://54.116.29.247:9000 MINIO_PUBLIC_READ=true # ══ Amazon S3(build-server APK 存储,仍用云端)═════════════════ BUILD_AWS_REGION=ap-east-1 BUILD_AWS_BUCKET=im-hk-apk BUILD_AWS_ACCESS_KEY=xxx BUILD_AWS_SECRET_KEY=xxx # ══ Docker Redis / Kafka / Etcd / MinIO ═════════════════════════ REDIS_PORT=6379 REDIS_PASSWORD=openIM123 KAFKA_PORT=9092 KAFKA_EXTERNAL_PORT=9094 # 外网访问 Kafka bootstrap:DEPLOY_TEST_IP:KAFKA_EXTERNAL_PORT(须安全组放行) ETCD_PORT=2379 # ══ LiveKit(本机 Docker,使用公网 IP)════════════════════════ LIVEKIT_NODE_IP=54.116.29.247 # 与 DEPLOY_TEST_IP 保持一致 LIVEKIT_URL=ws://127.0.0.1:7880 LIVEKIT_API_KEY=API8462dba2 LIVEKIT_API_SECRET=xxx # ══ Cloudflare Stream(livestream)/ 腾讯云 RTC ═══════════════ # 02-patch-config.sh 写入 livestream/config.yaml → cloudflare(无 enabled 字段;API Token 需 Stream:Edit) CF_ACCOUNT_ID=your_cloudflare_account_id CF_API_TOKEN=your_api_token CF_EMAIL= CF_API_KEY= CF_CUSTOMER_CODE=your_stream_customer_code TENCENT_SDK_APP_ID=xxx TENCENT_SDK_SECRET_KEY=xxx ``` --- ## 服务地址 ### 后端服务 | 服务 | 端口 / 说明 | |------|-------------| | openim-server | :10002(HTTP API)、:10001(MsgGateway WebSocket)— **同一进程上两个监听端口**,不是两个独立后端 | | chat-rpc | 对内 RPC(注册到 Etcd,无单独对外 HTTP 端口) | | admin-rpc | 同上 | | chat-api | :10008 | | admin-api | :10009 | | meetingmsg | :8000 (WS) | | livecloud | :8080 | | livestream | :8888(Hertz 默认) | | build-server | :8281 | > **进程数量**:`05-start.sh` 会拉起 **9 个独立操作系统进程**(上表 9 行)。其中 `openim-server` 是 **一个** OpenIM 单二进制,内部包含用户/群组/消息等 RPC 与 API、网关等模块;官方文档或 K8s 部署里常把其中一部分拆成多个 Pod,看起来像「十几个服务」,在本仓库的**单机单进程**模式下合并进同一个 `openim-server`,因此只看到 **1 个 PID**、**2 个对客户端暴露的端口**(10002 + 10001)。 ### 架构说明:`openim-server` 内部 RPC 与 `chat` 四进程 #### `openim-server`:单进程里模块之间怎么调 RPC? - 单二进制在 `main` 里依次启动多个子模块(如 auth、user、group、msg、API、MsgGateway 等)。模块之间**仍然是 gRPC**:各模块在本机 **TCP** 上起 gRPC Server(端口可在配置里固定或由 `autoSetPorts` 分配),客户端通过 **`GetConn(服务名)`** 去连。 - 服务发现使用 **`discovery/standalone`**(`config.SetStandalone()`):在**当前进程内**维护「服务名 → 地址」的注册表,**不经过**本机 Docker 里的 **Etcd**。部署里的 **Etcd** 主要给 **chat** 与其它独立进程做发现;与 `openim-server` **内部** RPC 是两套机制。 #### `chat` 为何是 `chat-rpc` / `admin-rpc` / `chat-api` / `admin-api` 四个进程? - **源码即四个独立 `main` 包**(`chat/cmd/rpc/...`、`chat/cmd/api/...`),与上游 OpenIM Chat 一致,编译为四个二进制,由 `04-build.sh` / `05-start.sh` 分别拉起。 - **职责拆分**:**RPC**(给其它服务 gRPC 调用)与 **HTTP API**(对外 REST)分开;**业务侧(chat)** 与 **管理侧(admin)** 分开,便于鉴权、独立重启、按负载分别扩容,生产环境也可分机器部署。 - **能否合并成一个进程(像 `openim-server` 那样)?** **理论上可以**:新增统一入口、在同一进程内启动四套逻辑并处理端口与 Etcd 注册即可。但本仓库 **当前未提供**该单进程模式,需要额外开发与测试;**默认与推荐**仍是 **4 进程** 部署。 ### 前端开发服务器(可选) | 项目 | 端口 | 说明 | |------|------|------| | pc (Electron) | :7777 | Electron 桌面客户端 | | meetingh5 | :5188 | 直播观看 H5(弹幕+视频) | | h5 | :3003 | 移动端 H5 | | cms | :8001 | 后台管理 | | build-cms | :8002 | 构建管理后台 | | build-down | :8003 | 下载页 | > **meetingh5 访问方式** > > `02-patch-config.sh` 会自动生成 `meetingh5/.env.local`,设置默认后端地址: > > ``` > # 直接访问(使用 .env.local 中的默认后端) > http://:5188 > > # 或显式传入 URL 参数(优先级最高) > http://:5188?ws=ws://:8000&liveApi=http://:8888 > ``` > > - `ws` → meetingmsg 弹幕 WebSocket `:8000` > - `liveApi` → livestream 直播间 API `:8888` ### Nginx 反代(域名 HTTPS 入口,供 PC / 浏览器访问后端) 在**测试服务器**上部署 Nginx,本机 Nginx 仅监听 HTTP `:80`,统一反代 PC Vite dev server、OpenIM API、chat-api 与 MsgGateway WebSocket。外部访问仍使用 `https://cms-jack.imharry.work`,HTTPS 由外层 LB/CDN/其它网关终止后转发到本机 `:80`。 | 路径前缀 | 后端 | |----------|------| | `/api/im/` | `127.0.0.1:10002` | | `/api/user/`、`/api/chat/` | `127.0.0.1:10008` | | `/msg_gateway` | `127.0.0.1:10001`(WebSocket) | | `/openIM.wasm`、`/sql-wasm.wasm`、`/wasm_exec.js`、`/node_modules/@openim/wasm-client-sdk/lib/worker*.js` | `/var/www/openim-pc-sdk`(OpenIM WASM SDK 静态资源) | | `/` | `127.0.0.1:5173`(PC Vite dev server) | 1. 服务器上已执行 `05-start.sh` 等,保证 `10001/10002/10008` 在监听。 2. 域名 `cms-jack.imharry.work` 已解析到测试服务器公网 IP。 3. 仓库根目录执行:`sudo ./deploy-test/00-init-tools.sh nginx`(会安装 `nginx`,并写入配置 `deploy-test/nginx/openim-pc-proxy.conf`;亦已包含在 `00-init-tools.sh` 无参的 **all** 流程末尾,需 root)。 4. 测试服务器本机/安全组放行 **TCP 80**;外层 LB/CDN/网关对公网提供 HTTPS `443` 并转发到本机 `80`。 5. `.env.deploy-test` 中设置 **`PC_BACKEND_ORIGIN=https://cms-jack.imharry.work`**(无末尾 `/`);再 `./deploy-test/07-start-frontend.sh pc` 启动 PC 时即注入 `VITE_*`。 6. 浏览器打开 **`https://cms-jack.imharry.work/`**。 **域名访问**:本配置中 `openim-pc-proxy` 使用 `server_name cms-jack.imharry.work`,只监听本机 `80`;推荐外部 `GET /` 走 `https://cms-jack.imharry.work/`,由外层 HTTPS 入口转发到本机 `80` 后代理 PC Vite。`00-init-tools.sh nginx` 会禁用 `sites-enabled/default`,并尝试去掉 `sites-available/default` 里的 `default_server`,避免默认站点抢占 `:80`。若机上还有其它站点也写了 `default_server`,`nginx -t` 会报错,需在该站点配置中删除 `default_server`(保留 `listen 80;` 即可)。 **PC WASM SDK 资源**:`00-init-tools.sh nginx` 会把 `pc/node_modules/@openim/wasm-client-sdk/lib/worker.js`、`worker-legacy.js` 以及 `openIM.wasm`、`sql-wasm.wasm`、`wasm_exec.js` 复制到 `/var/www/openim-pc-sdk`,并由 Nginx 直接返回这些文件。这样可以绕开 PC Vite dev server 里用于规避 MIME 报错的 `worker.js` placeholder,避免浏览器端 OpenIM SDK 卡在 worker 初始化阶段,导致不发起 `/api/im` 和 `/msg_gateway` 请求。更新 `pc` 依赖或 SDK 后,请重新执行 `sudo ./deploy-test/00-init-tools.sh nginx` 同步静态资源。 ### Docker 基础设施 | 服务 | 端口 | |------|------| | Redis | :6379 | | Kafka | 本机服务:`127.0.0.1:9092`(INTERNAL);外网客户端:`DEPLOY_TEST_IP:9094`(EXTERNAL,PLAINTEXT,默认 `KAFKA_EXTERNAL_PORT=9094`) | | Etcd | :2379 | | MinIO | API `:9000`(映射 `MINIO_API_PORT`);Console `:9001`;外网客户端使用 `MINIO_EXTERNAL_ADDRESS`(须安全组放行 TCP) | | LiveKit | :7880 (API) / :7882 (TCP) / :50000-51000/udp (WebRTC) | > **Kafka 外网**:`03-start-infra.sh` 使用双 listener。云主机安全组需放行 **TCP `KAFKA_EXTERNAL_PORT`**(默认 9094)。仅本机跑后端时仍连 `127.0.0.1:9092` 即可。**若曾用旧脚本建过 `dev-kafka` 单 listener,需** `docker rm -f dev-kafka` **并删除** `.deploy-test/docker-data/kafka` **后重新执行** `03-start-infra.sh`(或 `remove-infra.sh`)以应用新配置。公网 PLAINTEXT 无加密,生产请配合 VPN 或 SASL。 --- ## LiveKit 说明 本测试服务器运行本地 LiveKit 容器,WebRTC 媒体流通过公网 IP 对外暴露。 ``` 测试服务器(DEPLOY_TEST_IP: 54.116.29.247) │ ├── dev-redis :6379 ←── dev-livekit 通过 host.docker.internal 访问 ├── dev-minio :9000(API):9001(Console)←── 公网访问 DEPLOY_TEST_IP:9000 └── dev-livekit :7880 → HTTP API(后端连接) :7882/tcp+udp → WebRTC fallback :50000-51000/udp → WebRTC 媒体流(客户端直连公网 IP) ``` **防火墙必须开放**:7880/tcp、7882/tcp+udp、50000-51000/udp 本机 Mac(deploy-local)的 LiveKit 连接地址为 `ws://54.116.29.247:7880`,与此保持一致。 --- ## 日志体系 ``` .deploy-test/ ├── script-logs/ ← 每次脚本执行的完整输出(带时间戳,自动去除颜色码) ├── logs/ ← 后端/前端服务进程 stdout+stderr └── docker-logs/ ← Docker 容器日志(每日一文件) ├── redis/ ├── kafka/ ├── etcd/ ├── minio/ └── livekit/ ``` ```bash # 查看所有日志概览 ./deploy-test/logs.sh # 实时跟踪某个服务 ./deploy-test/logs.sh openim-server ./deploy-test/logs.sh livekit ./deploy-test/logs.sh cms # 查看脚本执行历史 ./deploy-test/logs.sh scripts ./deploy-test/logs.sh scripts --last # 最新一次完整输出 ``` --- ## 日常操作 ```bash # 早上开机 ./deploy-test/03-start-infra.sh # Docker 容器(含 LiveKit) ./deploy-test/05-start.sh # 后端服务 # 查看状态 ./deploy-test/status.sh # 重启单个后端服务 ./deploy-test/restart.sh chat-api ./deploy-test/restart.sh chat-api --build # 重编译 + 重启 # 下班关机 ./deploy-test/stop.sh # 后端进程 ./deploy-test/stop-infra.sh # Docker 容器(含 LiveKit,数据保留) ``` --- ## 故障排查 ### pc 前端 `yarn install` 失败(Git SSH / Host key verification failed) 现象示例:`git ls-remote ... ssh://git@github.com/electron/node-gyp.git` → `Host key verification failed` 或 `Could not read from remote repository`。 | 说明 | 处理 | |------|------| | **优先** | 按上文 **「GitHub:优先配置 SSH 密钥」** 完成 `ssh-keygen`、公钥添加到 GitHub、`ssh -T git@github.com` 验证通过后再装依赖。 | | **锁文件** | 仓库中 `pc/yarn.lock`、`pc/package-lock.json` 已将 `@electron/node-gyp` 的 `resolved` 固定为 **`git+https://github.com/electron/node-gyp.git#...`**(无需 SSH)。请拉取最新代码后再执行 `yarn install`。 | | **备选(无 SSH 环境)** | 首次部署请执行 `./deploy-test/00-init-tools.sh`,脚本内会通过 `git config url.*.insteadOf` 将 `git+ssh://`、`ssh://git@github.com/`、`git@github.com:` 重写为 `https://github.com/`。 | | **仍失败** | 手动执行(与 `00-init-tools.sh` 一致):
`git config --global url."https://github.com/".insteadOf "git+ssh://git@github.com/"`
`git config --global url."https://github.com/".insteadOf "ssh://git@github.com/"`
`git config --global url."https://github.com/".insteadOf "git@github.com:"` | | **包管理器** | `pc` 使用 **Yarn**。若同时存在 `package-lock.json`,Yarn 会警告混用锁文件;可删除 `pc/package-lock.json`,仅保留 `yarn.lock`(与团队约定一致即可)。 | ```bash cd pc && rm -rf node_modules && yarn install ``` ### `check-conn.sh`(MongoDB / MinIO / S3) 按 `.env.deploy-test` 检查远程 MongoDB、本机 **MinIO**(`--endpoint-url http://127.0.0.1:MINIO_API_PORT`)与 build-server 的 **S3** Bucket。 | 项目 | 说明 | |------|------| | **完整校验** | **mongosh** 可测 MongoDB;MinIO/S3 用 **`aws s3api head-bucket`** 判断访问,成功后再 `s3 ls` 仅作预览(避免旧版 `ls \| head` 因管道 SIGPIPE 误判失败)。 | | **未安装工具时** | MongoDB 可用 **nc** 仅测端口连通;MinIO/S3 会跳过并打印手动验证命令。 | | **安装提示** | 脚本按系统给出命令(macOS 为 `brew`;Amazon/RHEL 为 `dnf`/`yum`),不会在 Linux 上误导为 `brew`。 | | **Ubuntu/Debian 与 mongosh** | 默认 apt **没有** `mongodb-mongosh` 包(`Unable to locate package` 属正常)。需 [MongoDB 官方文档](https://www.mongodb.com/docs/mongodb-shell/install/) 添加 apt 源后再安装,或使用 `snap install mongosh`。 | | **可选自动安装** | **root** 且 `CHECK_CONN_AUTO_INSTALL=1`:**mongosh** 依次默认 apt、snap、MongoDB 8.0 源。**aws** 先 `apt install awscli` / `dnf`/`yum` 装 `aws-cli`;若无包或失败再下载 **AWS CLI v2 官方 zip** 安装(需 `curl`/`unzip` 与联网)。 | | **默认值** | `01-init-env.sh` 生成的 `.env.deploy-test` 已写入 `CHECK_CONN_AUTO_INSTALL=1`;`check-conn.sh` 通过 `load_env` 读取。关闭则改为 `0` 或删行。 | ```bash ./deploy-test/check-conn.sh # 已含上述变量时无需再前缀 env CHECK_CONN_AUTO_INSTALL=1 ./deploy-test/check-conn.sh # 临时覆盖(等同默认) ./deploy-test/check-conn.sh mongo ./deploy-test/check-conn.sh s3 ``` ### 其他 ```bash # 查看 LiveKit 日志(WebRTC 不通时) ./deploy-test/logs.sh livekit --last # 重置 Docker 环境(删除所有数据) ./deploy-test/remove-infra.sh ./deploy-test/02-patch-config.sh ./deploy-test/03-start-infra.sh ```