企业官网建设流程全解析

• 后端
• 数据工程

本文以 Parsr 官方 Docker 文档（docs/docker.md）为主线，结合仓库内 docker-compose.yml、docker-compose-build.yml 及docker/目录下的全套 Dockerfile，完整讲解如何用 Docker Compose 一键拉起 Parsr 的 API 与演示 UI，以及如何从源码自行构建 Parsr 及其依赖镜像。阅读本文后，你将掌握 Parsr 容器的端口、卷、环境变量配置原理，并能独立完成标准镜像的启动与自定义镜像的编译。

Parsr 是一个将 PDF、文档与图片转换为增强结构化数据的开源工具，其服务由"API 后端 + 演示 UI 前端"两部分组成。官方提供了一条最省事的运行路径——在仓库根目录执行一条docker-compose up命令，即可同时启动两个容器；同时也保留了从 Dockerfile 自行构建全部镜像的完整能力。本文依次展开这两条路径，并深入到每个 Dockerfile 与 Compose 配置的细节，帮助你理解容器的组成与可调参数。

1. 一键运行：docker-compose up

在仓库根目录（即包含docker-compose.yml的目录）执行：

docker-compose up

该命令会依据根目录下的 docker-compose.yml 拉取并启动2 个容器：

启动后打开http://localhost:8080即可看到演示界面，界面上传文档后由前端把请求转发给运行在3001端口的 API。若希望以后台方式运行（不占用当前终端），可使用：

docker-compose up -d

1.1 首次启动会创建持久化数据卷

官方文档特别提醒：首次启动时会创建一个 Docker volume，用于在容器重启后保留数据。

对应到 docker-compose.yml 的第 18-20 行，Compose 声明了一个名为pipeline的命名卷：

volumes: pipeline: driver: local

这个卷被挂载到 API 容器的输出目录上：

parsr: ... volumes: - ./pipeline/:/opt/app-root/src/api/server/dist/output

也就是说，Parsr 处理文档后生成的结果文件（按文档写入output/目录）会落在宿主机仓库根目录下的./pipeline/文件夹中。可以从源码佐证该输出目录的用途：API 端点在 api/server/src/api.ts 中将输出目录定义为path.resolve(${__dirname}/output)，并在处理文档时创建以文档名-文档ID命名的子目录（api.ts第 328-343 行），处理结果通过 FileManager.ts 写入其中。挂载后，容器重建甚至镜像升级都不会丢失这些处理产物。

1.2 ABBYY 环境变量（可选）

Compose 文件中parsr服务还暴露了一个环境变量占位：

environment: ABBYY_SERVER_URL:

默认留空，即不使用 ABBYY 外部识别引擎。若你部署了 ABBYY FineReader Server，可在启动前通过.env文件或命令行传入其网络地址：

ABBYY_SERVER_URL=http://your-abbyy-host:port docker-compose up

该变量在服务端源码中用于校验并读取 ABBYY 凭证（见 server/src/input/abbyy/AbbyyTools.ts 与 server/src/types/Config.ts），未配置时 Parsr 会回退到内置的 PDF 提取与 OCR 流水线，功能不受影响。

2. 停止与清理

停止并移除容器：

docker-compose down

注意docker-compose down默认不会删除命名卷，./pipeline/中的数据仍会保留；如需连同数据卷一起删除，可追加-v：

docker-compose down -v

3. 自行构建：docker-compose -f docker-compose-build.yml build

官方文档提供了第二种路径：自己动手构建 Parsr 及其全部依赖镜像。在仓库根目录执行：

docker-compose -f docker-compose-build.yml build

与运行用的docker-compose.yml不同，构建配置文件 docker-compose-build.yml 定义了3 个服务，它们之间存在依赖层级：

构建前请先确认本机已安装 Docker 与 Docker Compose，并拥有网络访问权限（构建过程需要拉取 Debian、UBI8、nginx 等基础镜像及 apt/pip/npm 包）。

3.1 基础镜像 parsr-base：依赖全集

docker/parsr-base/Dockerfile 以debian:10为起点，分三步装配运行环境：

1. Chrome/Chromium 运行库：安装gconf-service、libgtk-3-0、libnss3等一整套系统库，并下载google-chrome-unstable及多语言字体（fonts-ipafont-gothic、fonts-wqy-zenhei、fonts-thai-tlwg等），这是为 Puppeteer 内置 Chromium 提供中、日、阿、希伯来、泰等字符集渲染能力（Dockerfile 第 7-15 行的注释明确说明）。
2. 文档处理工具链：imagemagick（图像处理）、mupdf/mupdf-tools与qpdf（PDF 解析与修复）、pandoc（格式转换）、tesseract-ocr-all（OCR）、nodejs/npm、python-pdfminer与python3-pdfminer（文本提取）、python3-opencv（图像预处理）。
3. Python 识别栈：通过pip3安装ghostscript、camelot-py[cv]（表格提取）、numpy、pillow、scikit-learn==0.23.2（机器学习模块）、tabula-py等，同时以policy.xml覆盖 ImageMagick 的默认安全策略。

末尾设置USER 1001以非 root 用户运行，并默认工作目录为/opt/app-root/src。该镜像将后续所有 Parsr 处理模块（Pdfminer、Tesseract、Camelot 表格检测、ML 标题检测等）所需的运行时一次性打包。

3.2 API 镜像 parsr：编译 TypeScript 并启动服务

docker/parsr/Dockerfile 基于axarev/parsr-base（版本号由BASEIMAGE_VERSION构建参数控制，默认latest）：

ARG BASEIMAGE_VERSION FROM axarev/parsr-base:${BASEIMAGE_VERSION:-latest} ENV NODE_ENV development EXPOSE 3001 COPY --chown=1001:0 . /opt/app-root/src RUN docker/parsr/build.sh CMD docker/parsr/run.sh

构建时通过build.sh编译项目（含api/server与server两个 TypeScript 子项目的依赖安装与编译），运行入口是 docker/parsr/run.sh，其核心动作是切换到api/server目录并执行：

exec node dist/index.js

这正好与 API 包的 package.json 中定义的入口一致，3001端口由 api.ts 的服务器监听逻辑承接。

3.3 前端镜像 parsr-ui：Vue 构建 + Nginx 托管

docker/parsr-ui/Dockerfile 采用两阶段构建：

• 第一阶段基于 Red Hat UBI8 的nodejs-10镜像，通过VUE_APP_API构建参数注入 API 地址（默认http://localhost:3001），执行docker/parsr-ui/build.sh对 demo/vue-viewer 前端项目进行打包，产物输出到demo/vue-viewer/dist；
• 第二阶段以nginx:stable为基础，把构建产物复制到/usr/share/nginx/html，并启用 docker/parsr-ui/nginx.conf 作为站点配置。该配置监听 80 端口，用try_files $uri $uri/ /index.html实现 Vue Router 的 history 模式回退，保证前端路由刷新不 404。

所以容器对外暴露8080:80，Nginx 在容器内监听 80，宿主机通过 8080 访问。

3.4 构建时的关键参数

构建配置中有两个值得注意的参数：

1. DEV_MODE: 'true'（parsr服务）：传给 API Dockerfile 的开发模式标记，可让NODE_ENV=development生效；
2. VUE_APP_API: ${VUE_APP_API:-http://localhost:3001}（parsr-ui服务）：如果 API 没有运行在localhost:3001，必须重新构建 UI 镜像并传入正确的VUE_APP_API——这是 docker-compose-build.yml 第 28 行注释明确指出的要点。例如：

VUE_APP_API=http://192.168.1.10:3001 docker-compose -f docker-compose-build.yml build parsr-ui

4. 两个 Compose 文件的分工与关系

两条路径共享相同的端口、卷与环境变量约定，因此你可以先用docker-compose up快速体验，再根据业务需要（如修改了源码、更换 API 地址）切换到构建流程产出自己的镜像。构建完成后即可用docker-compose -f docker-compose-build.yml up直接以本地镜像启动整条流水线。

5. 常见问题速查

• UI 打不开 / 上传后无响应：先确认 API 容器是否在3001端口监听，再确认 UI 构建时VUE_APP_API是否指向可达的 API 地址（见 3.4）。
• 容器重启后处理结果丢失：确认parsr服务的卷挂载存在；正常配置下处理产物保存在宿主机./pipeline/目录，由 Compose 的命名卷机制保证持久化。
• 想替换识别引擎：在.env中设置ABBYY_SERVER_URL后重新docker-compose up；Parsr 同时支持 ABBYY、Tesseract、Pdfminer、Amazon Textract 等输入提取器，容器内已默认内置 Tesseract 与 Pdfminer（见 server/src/input）。
• 构建很慢：parsr-base需要安装大量系统依赖与 Python 包，属正常现象；该镜像只应在依赖变更时重建，日常开发直接复用已构建的axarev/parsr-base即可（docker-compose-build.yml 第 4-5 行注释即为此意）。

6. 小结

Parsr 的容器化部署遵循"两条路径、一个约定"的设计：docker-compose up面向绝大多数用户，一条命令拉起 API（3001）与 UI（8080），并借由pipeline命名卷实现数据持久化；docker-compose -f docker-compose-build.yml build面向需要自定义的开发者，可依次构建parsr-base、parsr、parsr-ui三个镜像，其中 UI 镜像的 API 地址通过VUE_APP_API构建参数控制，是前后端联调时最需要留意的配置点。理解了这些文件与参数，无论是要快速验证 Parsr 的能力，还是将其整合进自己的服务编排体系，都有了明确的落脚点。更多容器相关的细节（如镜像 tag 规则脚本）可进一步查看 docker/tags.sh 与 docker-compose.yml。

• 后端
• 数据工程