公共卫生领域的数据分析经常面临一个尴尬局面：一份来自省级疾控中心的分析脚本，到了市级单位就因为R包版本不同或geos库缺失而无法运行。Docker把操作系统、运行时、依赖库和应用代码整体打包，恰好解决了这种跨机构复现难题。它不像虚拟机那样占用大量资源，启动速度接近原生进程，特别适合在基层单位的普通电脑上运行复杂的流行病学分析任务。
构建面向公共卫生分析的基础镜像
公共卫生分析最常用的工具是R语言和Python，同时经常需要处理Shapefile地理文件、连接PostgreSQL数据库或调用Stan进行贝叶斯建模。自己从零开始安装这些依赖非常耗时，而且容易出现系统库与语言包之间的编译错误。一个更可靠的做法是基于官方rocker/r-ver基础镜像进行扩展，这个镜像由R社区维护，已经处理好了很多底层依赖。
下面这个Dockerfile演示了如何构建一个包含tidyverse、sf、rstan和Python基础环境的镜像。注意使用apt-get安装系统级依赖时，要把清理缓存放在同一层以减小镜像体积。
FROM rocker/r-ver:4.3.1
RUN apt-get update && apt-get install -y --no-install-recommends \
libgdal-dev \
libgeos-dev \
libproj-dev \
libudunits2-dev \
libnode-dev \
libfontconfig1-dev \
python3 \
python3-pip \
&& rm -rf /var/lib/apt/lists/*
RUN install2.r --error --skipinstalled \
tidyverse \
sf \
lubridate \
brms \
cmdstanr
RUN pip3 install --no-cache-dir pandas geopandas matplotlib
RUN mkdir -p /home/rstudio/work
WORKDIR /home/rstudio/work
上面的镜像构建完成后，任何一位分析人员只需要执行docker build -t pubhealth-base .，然后再运行docker run --rm -v $(pwd):/home/rstudio/work pubhealth-base Rscript analysis.R，就能在完全一致的环境中执行脚本。这里的数据卷挂载让容器内的计算结果直接写回宿主机当前目录，避免了数据遗留在容器内部造成丢失。
对于需要图形界面查看地图输出的场景，rocker项目还提供了带RStudio Server的镜像，例如rocker/rstudio。团队可以在一台服务器上启动RStudio Server容器，为每个成员分配独立账号，所有人都通过浏览器访问同一个分析环境，从根源上消除了“我电脑上跑得好好的”这类沟通成本。
用Docker Compose编排数据库与分析容器
很多公共卫生监测系统需要实时读取数据库中的病例数据，然后在分析容器中生成统计报表或预警信号。手动启动多个容器并管理网络链接非常繁琐，Docker Compose允许用YAML文件描述整个服务栈，一条命令即可启动或停止所有相关服务。
下面这个docker-compose.yml定义了一个PostgreSQL数据库（带有PostGIS扩展）和一个R分析容器。分析容器通过环境变量获取数据库连接信息，并且依赖数据库服务先启动。这样每次运行R脚本时，数据库都是就绪状态。
version: "3.9"
services:
db:
image: postgis/postgis:15-3.4
environment:
POSTGRES_DB: surveillance
POSTGRES_USER: epiuser
POSTGRES_PASSWORD: secret123
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U epiuser -d surveillance"]
interval: 5s
timeout: 5s
retries: 5
analysis:
build: .
depends_on:
db:
condition: service_healthy
environment:
DB_HOST: db
DB_PORT: 5432
DB_NAME: surveillance
DB_USER: epiuser
DB_PASSWORD: secret123
volumes:
- ./scripts:/home/rstudio/work/scripts
- ./output:/home/rstudio/work/output
command: Rscript scripts/daily_report.R
volumes:
pgdata:
这个编排文件有几个值得注意的细节。healthcheck部分利用PostgreSQL自带的pg_isready命令检查数据库是否真正接受连接，而depends_on中的condition: service_healthy确保分析容器在数据库完全就绪后才启动，而不是仅仅等到容器进程运行。数据卷pgdata将数据库文件持久化到宿主机，即使容器被删除，历史病例数据也不会丢失。
实际执行时，团队只需要在项目根目录运行docker compose up -d，Compose会自动构建分析镜像、拉取PostGIS镜像、创建网络并启动两个容器。分析容器执行完R脚本后退出，但数据库容器仍在后台运行。如果要重新运行当日报表，只需要docker compose run --rm analysis Rscript scripts/daily_report.R即可，不会影响数据库状态。
把流行病学模型封装为API服务
当数据分析结果需要被Web仪表盘、移动端应用或外部合作单位实时调用时，直接把R脚本或Python脚本暴露给调用方并不现实。更优雅的方案是将训练好的模型封装成一个HTTP API服务，前端通过标准接口获取预测结果。Docker让这种API服务的部署变得极其简单，而且可以水平扩展。
以Python的FastAPI框架为例，下面是一个简单的传染病传播风险预测接口。模型事先用joblib序列化保存，API服务加载模型后接收区域特征数据，返回风险等级和概率。Dockerfile使用轻量级的python:3.11-slim作为基础镜像，只安装必要的依赖，最终镜像体积通常不到200MB。
# app.py
from fastapi import FastAPI
from pydantic import BaseModel
import joblib
import numpy as np
app = FastAPI(title="Epi Risk API")
model = joblib.load("/app/model/risk_model.joblib")
class RegionFeatures(BaseModel):
population_density: float
avg_temperature: float
humidity: float
mobility_index: float
vaccination_rate: float
@app.post("/predict")
def predict_risk(features: RegionFeatures):
X = np.array([[
features.population_density,
features.avg_temperature,
features.humidity,
features.mobility_index,
features.vaccination_rate
]])
prob = float(model.predict_proba(X)[0, 1])
risk_level = "low" if prob < 0.3 else ("medium" if prob < 0.7 else "high")
return {"risk_level": risk_level, "probability": round(prob, 4)}
FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . COPY model/risk_model.joblib ./model/ EXPOSE 8000 CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]
部署时运行docker run -d -p 8000:8000 --name risk-api epi-risk-api，外部系统就能通过http://服务器IP:8000/predict获取预测结果。如果访问量增大，可以使用docker compose配合nginx反向代理启动多个API容器副本，实现负载均衡。这种架构让模型更新与前端应用解耦：重新训练模型后只需要重新构建镜像并滚动替换容器，前端代码无需任何改动。
容器化部署还带来了一个额外好处：当卫生部门需要将模型交付给下级单位离线使用时，可以直接导出镜像文件，下级单位导入镜像后即可在局域网内提供服务，完全避免了依赖互联网的安装过程。
数据安全与镜像维护的实用建议
公共卫生数据往往涉及个人隐私和敏感信息，使用Docker时必须严格控制数据流向。核心原则是不要把任何真实数据构建进镜像层，数据永远通过挂载卷或环境变量在运行时注入。如果镜像中残留了测试数据，可以通过docker history查看每一层的历史命令，确认没有复制过敏感文件。同时建议为镜像仓库配置访问控制，只允许经过审核的基础镜像进入内部网络。
镜像的更新维护同样不容忽视。基础操作系统和语言包会不断发布安全补丁，应该定期重新构建镜像并推送到私有仓库。可以在CI/CD流程中加入镜像扫描步骤，使用Trivy或Grype检查已知漏洞。对于长期运行的分析容器，建议设置资源限制，例如docker run --memory=4g --cpus=2，避免单个分析任务耗尽服务器资源影响其他服务。
最后，镜像标签要遵循明确的语义化版本规范。不要使用latest标签作为生产环境的引用，而应该使用像pubhealth-base:4.3.1-2024.01这样的具体版本号。这样当基础镜像更新时，可以通过修改标签逐步升级，而不是让所有下游系统突然面对未知变更。对于关键分析流程，建议在镜像构建时记录依赖的具体版本，甚至使用renv或pip freeze生成锁定文件，确保一年后重新构建时环境仍然一致。
