SkyJourneyandClaude Sonnet 5
c4df499680
新增能力：桌面端新增 macOS 打包支持，electron-builder 增加独立 mac 配置块， 产出 dmg，按 arm64、x64 分别单独构建、不产出 universal 包；Pandoc 运行时清单 新增 darwin/arm64、darwin/x64 两个官方发行项（含独立许可证文件来源），桌面 Pandoc 候选路径与 prepare-pandoc-runtime.mjs 均已泛化为按 --platform/--arch 参数选取目标，不再只认 Windows x64。AGENTS.md 不再硬编码 Windows 绝对路径与 强制 PowerShell 语法，改为按当前 Shell 与仓库实际位置自适应。 问题修复：修复解压内置 Pandoc 时未保留 Unix 可执行权限位的问题（unzipSync 不保留压缩包内权限，已补 chmod 0o755）；修复根 package.json 中 build:web-runtime/dev/desktop:dev 三个脚本的构建顺序错误 （@md-to-pdf/application 被排在其依赖的 @md-to-pdf/preview-engine 之前，在 没有历史 dist 残留的全新环境中会导致类型解析失败）；修正 packages/docx-engine/tests/pandoc-runtime.test.ts 与 apps/desktop/tests/markdown-file.test.ts 中依赖宿主 OS 或路径分隔符的测试 断言，避免这些用例只能在特定平台上通过。 验证结果：docx-engine 包 93 项测试、desktop 包 62 项测试（61 通过 + 1 项 Windows 专属用例按预期跳过）均通过；全项目类型检查、生产构建通过， git diff --check 无空白错误。跳过依赖 Git 忽略的真实客户文档语料（tmp/）的 test:docx-real-world-corpus 与 test:docx-release-gate-suites 后，其余全部 工作区测试均通过；这两步需要接入真实语料的机器上单独执行。本机 macOS （Apple Silicon）实测 npm run package:mac:arm64 全链路成功，内置 Pandoc 3.9.0.2 完成下载、哈希校验与真实 DOCX 冒烟转换；实际截图确认窗口、macOS 原生菜单栏、编辑器工具栏、中文字体与实时预览渲染正常。 兼容与部署：版本统一为 0.6.4。本版本仅完成开发基础设施与验证，未构建正式 发行文件：没有产出真实签名的 dmg、没有重新构建 Windows 安装包，也没有重新 构建 Docker 镜像；正式 macOS 发行产物与 Windows/Docker 同步验证留待 DOCX 发布门禁阶段完成后一并发布。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K5N6pcbjV4jVfXrcH3NcLP
138 lines
4.9 KiB
Markdown
138 lines
4.9 KiB
Markdown
# AIO 容器部署
|
||
|
||
本目录提供单容器部署：Nginx 在 `8080` 端口提供前端，并将
|
||
`/api/` 代理到同容器内的 Fastify；Fastify 复用固定版本
|
||
Playwright Chromium 生成 PDF，并使用固定 Pandoc `3.9.0.2` 生成
|
||
可编辑 DOCX。发行镜像固定内置受校验字体包，不依赖宿主机字体挂载。
|
||
|
||
## 启动
|
||
|
||
要求已经安装并启动 Docker Desktop。
|
||
|
||
```powershell
|
||
docker compose -f deploy\compose.yaml up --build -d
|
||
docker compose -f deploy\compose.yaml ps
|
||
```
|
||
|
||
打开：
|
||
|
||
```text
|
||
http://localhost:8080
|
||
```
|
||
|
||
健康检查：
|
||
|
||
```powershell
|
||
Invoke-RestMethod -Uri 'http://localhost:8080/api/health'
|
||
```
|
||
|
||
查看日志和停止：
|
||
|
||
```powershell
|
||
docker compose -f deploy\compose.yaml logs -f
|
||
docker compose -f deploy\compose.yaml down
|
||
```
|
||
|
||
## 构建发布标签
|
||
|
||
可以直接指定版本化镜像名称构建：
|
||
|
||
```powershell
|
||
$env:MD_TO_PDF_IMAGE = 'yixiong/md-to-pdf:v0.6.4'
|
||
docker compose -f deploy\compose.yaml build
|
||
```
|
||
|
||
该命令只生成本地镜像，不会自动推送到镜像仓库。
|
||
|
||
默认构建会安装项目锁定版本的 Playwright Chromium 及系统依赖。如果本机
|
||
已经保留同版本系列的已验证镜像，可在内网或软件源较慢时复用其运行层：
|
||
|
||
```powershell
|
||
$env:MD_TO_PDF_IMAGE = 'yixiong/md-to-pdf:v0.6.4'
|
||
$env:MD_TO_PDF_RUNTIME_BASE_IMAGE = 'yixiong/md-to-pdf:v0.6.0'
|
||
$env:MD_TO_PDF_REUSE_PLAYWRIGHT_RUNTIME = '1'
|
||
docker compose -f deploy\compose.yaml build
|
||
```
|
||
|
||
复用模式会校验基础镜像中存在 Chromium，再覆盖 v0.6.4 应用代码和生产
|
||
依赖。正式跨机器构建仍建议使用默认完整路径。
|
||
|
||
## 主题挂载
|
||
|
||
Compose 默认将项目的 `.local/themes` 只读挂载到容器中的
|
||
`/app/.local/themes`。可以通过环境变量指定其他目录：
|
||
|
||
```powershell
|
||
$env:MD_TO_PDF_THEME_DIR = 'D:\md-to-pdf-themes'
|
||
docker compose -f deploy\compose.yaml up -d
|
||
```
|
||
|
||
目录下每套主题都应包含 `theme.json`。主题规范详见
|
||
[`docs/THEMES.md`](../docs/THEMES.md)。
|
||
|
||
当前内置 4 套 Typora 风格主题、4 套红头主题、3 套正式文档主题和
|
||
3 套标书主题；挂载目录只用于额外的本机扩展主题，无需重复
|
||
放置内置主题。内置主题与挂载主题 ID 重复时以内置版本为准。
|
||
|
||
## 内置字体包
|
||
|
||
v0.6.4 的发行镜像固定将受校验字体包内置到
|
||
`/app/.local/font-packs`。Compose 不挂载宿主机字体目录，因此部署端
|
||
无需额外复制字体，Preview、PDF 和 DOCX 可以离线使用同一套原生资产。
|
||
|
||
字体包使用固定目录结构：
|
||
|
||
```text
|
||
<字体包根目录>/
|
||
├── mdtp-serif-sc/1.0.0/
|
||
├── mdtp-sans-sc/1.0.0/
|
||
└── mdtp-mono/1.0.0/
|
||
```
|
||
|
||
从源码构建镜像前，先从仓库外冻结源生成字体包，再构建镜像：
|
||
|
||
```powershell
|
||
npm run build:font-pack
|
||
docker compose -f deploy\compose.yaml up -d
|
||
```
|
||
|
||
字体二进制通过 Git LFS 固定在仓库中。Docker 构建上下文只放行构建所需
|
||
源码与本次生成的 `output/font-packs/root`，镜像构建会在缺少清单时立即失败。运行时注册器
|
||
仍会复核许可证、文件类型、路径边界、容量和 SHA-256。更换字体包内容时
|
||
必须提升字体包 SemVer 并重新构建镜像，不能覆盖同一个版本。
|
||
|
||
发布前执行真实内置字体门禁：
|
||
|
||
```powershell
|
||
$env:MD_TO_PDF_IMAGE = 'yixiong/md-to-pdf:v0.6.4'
|
||
npm run verify:docker-font-pack
|
||
```
|
||
|
||
该命令要求本机 Docker 引擎已经启动，并且冻结字体源可供
|
||
`npm run build:font-pack` 生成。验收会重建指定镜像，核对镜像内清单哈希、
|
||
确认不存在字体运行时挂载，并检查健康状态、Pandoc capability、WOFF2
|
||
资源和 DOCX 字体部件；所有临时容器、网络和目录会在结束时清理。
|
||
|
||
## 运行参数
|
||
|
||
| 环境变量 | 默认值 | 说明 |
|
||
| --- | ---: | --- |
|
||
| `MD_TO_PDF_IMAGE` | `md-to-pdf:local` | 构建和运行的镜像标签 |
|
||
| `MD_TO_PDF_RUNTIME_BASE_IMAGE` | `node:22-bookworm-slim` | 可选运行时基础镜像 |
|
||
| `MD_TO_PDF_REUSE_PLAYWRIGHT_RUNTIME` | `0` | 是否复用基础镜像中的 Chromium |
|
||
| `MD_TO_PDF_PORT` | `8080` | 宿主机监听端口 |
|
||
| `MD_TO_PDF_THEME_DIR` | `../.local/themes` | 宿主机主题目录 |
|
||
| `MD_TO_PDF_APP_VERSION` | `0.6.4` | 字体包兼容性判断使用的应用版本 |
|
||
| `PDF_CONCURRENCY` | `1` | 同时执行的 PDF 任务数 |
|
||
| `PDF_MAX_QUEUE` | `4` | 等待队列上限 |
|
||
| `PDF_TIMEOUT_MS` | `120000` | 单次 PDF 生成超时 |
|
||
|
||
增加 PDF 并发会显著增加 Chromium 内存占用。单机部署建议先保持默认值，
|
||
再根据文档复杂度和可用内存调整。
|
||
|
||
容器为 Chromium 提供 1 GiB 共享内存，并以非 root `pwuser` 运行。
|
||
构建阶段使用项目锁定的 Playwright `1.62.0` 安装精确匹配的 Chromium
|
||
及系统依赖，不依赖版本可能滞后的预制浏览器镜像标签。DOCX 运行时仅
|
||
支持 Linux amd64，Pandoc 二进制、许可证和版权文件均在构建阶段执行
|
||
固定版本与 SHA-256 校验。
|