SecretFlow 提供了联邦学习、多方安全计算、匿踪查询等一系列隐私计算能力，但它的组件依赖相当复杂，涉及 Python 环境、Ray 集群、通信证书等多个层面。直接在物理机或虚拟机上部署，很容易因为 Python 版本不匹配、依赖库冲突而浪费大量时间。容器化是解决这类问题的标准做法：把运行环境和依赖打包进镜像，部署、迁移、扩容都变得可复制。这篇文章就从镜像准备、单机运行、多节点集群搭建到生产化加固，完整讲一遍 SecretFlow 的容器化部署过程。
一、镜像获取与本地构建
SecretFlow 官方在 Docker Hub 上维护了镜像，最常用的入口镜像是 secretflow/secretflow-anolis8，它基于 Anolis OS 构建，集成了完整的 SecretFlow 运行时。获取镜像只需要一条命令：
docker pull secretflow/secretflow-anolis8:latest
拉取完成后可以先跑一个简单验证，确认容器内 Python 环境和 SecretFlow 版本正常：
docker run --rm secretflow/secretflow-anolis8:latest \ python -c "import secretflow; print(secretflow.__version__)"
如果官方镜像不满足需求，比如需要安装额外的算法包或企业内部依赖，可以基于官方镜像写一个 Dockerfile 进行二次构建。下面是一个典型示例：
FROM secretflow/secretflow-anolis8:latest # 切换镜像源加速安装 RUN pip config set global.index-url https://pypi.mirrors.ustc.edu.cn/simple/ # 安装业务侧额外依赖 RUN pip install --no-cache-dir pandas scikit-learn flask # 拷贝业务代码 COPY ./app /home/admin/app WORKDIR /home/admin/app CMD ["python", "main.py"]
自建镜像时有两点要注意。一是尽量把不常变动的层放在前面，比如依赖安装，把经常改动的业务代码放在后面，这样能充分利用 Docker 的层缓存，加快重复构建速度。二是镜像体积较大，建议配合镜像仓库做内部分发，避免每台机器都从公网拉取。
二、单机模拟多方运行
在真正搭建多节点集群之前，建议先用单机模式把流程跑通。SecretFlow 提供了模拟模式（simulation），可以在一个进程里模拟 Alice、Bob 等多个参与方，非常适合开发调试阶段验证算法逻辑。
import secretflow as sf
# 初始化模拟环境，模拟两个参与方
sf.init(['alice', 'bob'], address='local')
alice = sf.PYU('alice')
bob = sf.PYU('bob')
# 在不同参与方下执行代码
data_alice = alice(lambda: [1, 2, 3])()
data_bob = bob(lambda: [4, 5, 6])()
print(sf.reveal(data_alice), sf.reveal(data_bob))
把这段脚本保存为 test_sim.py，然后通过容器执行：
docker run --rm -v $(pwd):/home/admin/work \ -w /home/admin/work \ secretflow/secretflow-anolis8:latest \ python test_sim.py
这里通过 -v 参数把宿主机当前目录挂载进容器，脚本就能直接使用镜像内的环境运行，不需要每次修改代码都重新构建镜像。如果模拟模式运行正常，说明镜像本身没有问题，后续排查多节点故障时可以排除环境因素。
需要注意的是，SecretFlow 的一些算子依赖 Ray 集群。模拟模式下 Ray 会以本地模式启动，但如果程序中创建了 SPU 或 HEU 设备，对内存的消耗会明显上升，建议给容器分配至少 8GB 内存，否则容易出现 OOM。
三、基于 Docker Compose 搭建多节点集群
生产上 SecretFlow 通常以点对点模式（production mode）部署，每个参与方一个独立节点。用 Docker Compose 可以在一台或多台机器上方便地编排这些节点。先编写 docker-compose.yml：
version: "3.8"
services:
alice:
image: secretflow/secretflow-anolis8:latest
container_name: alice_node
hostname: alice
networks:
- sf_net
volumes:
- ./certs:/home/admin/certs
- ./app:/home/admin/app
command: >
python /home/admin/app/node.py
--party alice
--port 9500
ports:
- "9500:9500"
bob:
image: secretflow/secretflow-anolis8:latest
container_name: bob_node
hostname: bob
networks:
- sf_net
volumes:
- ./certs:/home/admin/certs
- ./app:/home/admin/app
command: >
python /home/admin/app/node.py
--party bob
--port 9501
ports:
- "9501:9501"
networks:
sf_net:
driver: bridge
这个配置文件里有几个关键点。第一，两个服务通过自定义桥接网络 sf_net 通信，容器之间可以直接用服务名解析，比如 alice 节点可以用 bob:9501 访问对方。第二，证书目录以挂载方式注入而不是打进镜像，这样密钥轮换时只需替换宿主机文件并重启容器，不用重建镜像。第三，显式设置 hostname 很重要，SecretFlow 的集群配置里各参与方地址要和这里保持一致。
节点脚本 node.py 中初始化生产模式的写法大致如下：
import secretflow as sf
cluster_def = {
'parties': {
'alice': {'address': 'alice:9500'},
'bob': {'address': 'bob:9501'},
},
'self_party': 'alice',
}
sf.init(address='alice:9500', cluster_config=cluster_def)
启动整个集群只需要一条 docker compose up -d，然后通过 docker compose logs -f 观察各节点日志，确认节点之间握手成功。如果节点分布在多台物理机上，就不能依赖单个 Compose 文件里的桥接网络了，需要改用 host 网络模式或者 overlay 网络，同时保证各机器之间的端口互相放通。
四、生产环境的加固建议
开发环境跑通之后，上生产前还有几件事必须处理。首先是资源限制，SecretFlow 计算密集，不加以限制容易吃光宿主机资源，影响同机的其他服务：
services:
alice:
image: secretflow/secretflow-anolis8:latest
deploy:
resources:
limits:
cpus: "8"
memory: 16G
restart: unless-stopped
logging:
driver: json-file
options:
max-size: "100m"
max-file: "5"
其次是安全加固。镜像内的默认用户是 admin，建议以非 root 用户运行，并在宿主机层面配合防火墙只放通参与方之间的通信端口。证书私钥的挂载目录权限应设为仅容器内用户可读，避免被其他进程读取。如果对合规有要求，还可以在 SecretFlow 之上启用审计日志，把每个任务的参与方、数据集、耗时记录到独立的日志服务中。
最后是可观测性。容器化之后日志都在 stdout，接入统一的日志采集系统（如 Filebeat 或 Fluent Bit 收集到 Elasticsearch）比逐台机器看日志高效得多。同时建议为每个节点暴露健康检查端口，编排系统据此自动重启异常容器，保证长期任务的稳定性。做完这些，SecretFlow 的容器化部署就比较完善了，后续的联邦学习建模任务可以直接在这个集群上开展。
SecretFlow容器化部署Docker隐私计算SecretFlow集群修改时间：2026-09-06 10:54:39