文档抽取是数据处理流程中非常基础但又容易踩坑的一环。常见的抽取需求包括从PDF中提取文本、从Word文档中读取段落、从扫描图片中识别文字，甚至从混合格式的压缩包里整理出结构化数据。这些任务往往需要不同的解析库：PDF需要pdfplumber、PyMuPDF或Apache PDFBox，Word需要python-docx或Apache POI，OCR则需要Tesseract或PaddleOCR。不同库对底层系统依赖的要求差异很大，例如Tesseract需要安装语言包和图像处理库，而某些PDF工具依赖特定的字体渲染环境。如果直接在一台机器上手工配置，很容易出现版本冲突，或者换一台机器就无法复现结果。Docker能够把这些工具及其运行环境整体打包，让文档抽取服务在不同主机、不同云平台上表现一致。
容器化的另一个显著优势是部署简单。开发人员可以将编写好的抽取逻辑连同依赖一起构建成镜像，测试通过后直接推送到镜像仓库，生产环境拉取镜像即可运行，不需要重新安装任何系统级软件。对于需要频繁迭代的文档抽取算法，这一特性尤其重要。此外，Docker的资源隔离机制可以限制单个抽取任务占用的CPU和内存，避免处理超大PDF时拖垮整个宿主机。接下来本文会从实际项目出发，详细说明如何用Docker构建一个可用的文档抽取环境。
文档抽取工具链的容器化改造
假设我们要实现一个基于Python的PDF文本抽取接口，核心逻辑使用PyMuPDF（fitz）库。如果不使用Docker，通常需要先安装Python、pip，然后安装PyMuPDF，但PyMuPDF依赖的MuPDF底层库可能在Linux发行版上存在兼容问题。容器化之后，我们编写的Dockerfile可以固定基础镜像版本，并在构建阶段一次性安装好所有依赖。
# 使用官方Python 3.11 slim镜像作为基础
FROM python:3.11-slim
# 设置工作目录
WORKDIR /app
# 安装PyMuPDF及必要的系统库
RUN apt-get update && apt-get install -y --no-install-recommends \
libgomp1 \
&& rm -rf /var/lib/apt/lists/*
# 复制依赖文件并安装Python包
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 复制应用代码
COPY extractor.py .
# 启动服务
CMD ["python", "extractor.py"]
上面的Dockerfile里，基础镜像选择了slim版本以减小体积，同时通过apt安装了libgomp1，这是PyMuPDF在部分环境下运行所需的共享库。requirements.txt中只需要写入PyMuPDF一个依赖即可。构建时执行docker build -t pdf-extractor:1.0 .，之后任何安装了Docker的主机都可以运行该镜像。如果后续需要升级PyMuPDF版本，只需修改requirements.txt并重新构建，不会影响宿主机环境。
对于不需要图形界面的纯文本抽取，使用alpine基础镜像可以进一步压缩镜像体积，但要注意alpine使用musl libc，某些编译型Python包可能没有对应的wheel，需要额外安装构建工具。相比之下，slim镜像更加稳妥，适合大多数文档抽取场景。如果抽取任务涉及OCR，还需要在镜像中加入Tesseract及其语言包，同时安装pytesseract包装库。
用Docker Compose编排Tika与OCR服务
单个容器的能力有限，实际文档抽取系统往往需要处理多种文件格式。Apache Tika是一个强大的内容抽取工具，支持上千种文件类型，并内置了元数据解析、语言检测等功能。我们可以将Tika Server单独运行在一个容器中，再通过HTTP接口调用它来完成复杂格式的抽取。与此同时，OCR服务可以独立为一个容器，方便按需扩展。
下面是一段docker-compose.yml示例，定义了两个服务：tika负责通用格式抽取，ocr负责扫描件识别。
version: "3.9"
services:
tika:
image: apache/tika:2.9.1.0-full
ports:
- "9998:9998"
environment:
- TIKA_CHILD_JAVA_OPTS=-Xms256m -Xmx1g
restart: unless-stopped
ocr:
build: ./ocr-service
ports:
- "5000:5000"
environment:
- TESSDATA_PREFIX=/usr/share/tesseract-ocr/5/tessdata
volumes:
- ./tessdata:/usr/share/tesseract-ocr/5/tessdata
restart: unless-stopped
这里的Tika镜像使用了full标签，自带大量解析器和依赖，适合快速验证。如果追求轻量化，可以使用core版镜像，但某些格式（如老旧Office文档）需要额外下载解析器，灵活性稍差。OCR服务则需要自己编写Dockerfile，基础镜像可以选择包含Tesseract的官方镜像，例如tesseractshadow/tesseract4re，也可以基于Ubuntu手动安装。容器内部通过Flask或FastAPI暴露一个简单的HTTP接口，客户端提交图片，返回识别文本。
使用Docker Compose管理这些服务后，本地开发环境与生产环境的差异被降到最低。开发者只需要在项目根目录执行docker compose up -d，即可启动完整的抽取流水线。当需要增加OCR处理能力时，可以通过docker compose up -d --scale ocr=3将OCR服务扩展为三个实例，配合反向代理实现负载均衡。这种弹性伸缩能力是直接在宿主机上部署多个进程难以快速实现的。
生产环境中的优化与避坑建议
镜像体积是容器化文档抽取服务时需要重点关注的指标。一个包含完整Tesseract语言包、PyMuPDF、PaddleOCR的镜像可能轻松超过3GB，过大的镜像会拖慢分发速度，增加存储成本。优化手段包括：使用多阶段构建，在builder阶段编译依赖，在最终镜像中只保留运行时文件；清理apt缓存和pip缓存；按需安装语言包，例如只保留中文和英文；对于OCR模型文件，可以通过挂载卷的方式在容器启动时加载，而不是打包进镜像。
另一类常见问题是权限与资源限制。文档抽取任务处理超大文件时容易占用大量内存，例如用PyMuPDF渲染整个PDF页面为图片再OCR，内存消耗可能瞬间飙升。建议在docker run或compose文件中设置mem_limit和cpus参数，避免单个容器耗尽宿主机资源。同时，容器内默认以root用户运行，存在安全隐患，可以在Dockerfile中创建非root用户并通过USER指令切换。
日志与监控也不容忽视。文档抽取服务在批量处理时可能遇到损坏文件、加密文件或格式异常的情况，这些错误需要被记录下来。可以在应用代码中统一捕获异常并输出结构化日志，再通过Docker的日志驱动收集到集中式日志平台。如果使用Tika Server，可以通过修改JVM参数开启GC日志，便于排查内存溢出问题。合理设置健康检查（healthcheck）能够帮助编排工具及时发现异常容器并自动重启。
最后需要提醒的是，文档抽取往往涉及敏感信息，容器镜像的基础层可能包含已知漏洞。建议定期使用漏洞扫描工具（如Trivy、Clair）检查镜像，并及时更新基础镜像版本。对于临时生成的抽取结果文件，应在容器退出前清理，或者使用tmpfs挂载临时目录，避免数据落盘造成泄露。通过以上这些实践，Docker能够让文档抽取任务从一次性脚本升级为可持续维护、稳定运行的生产级服务。
