Flower 框架 Docker 部署：以子进程模式在 SuperLink/SuperNode 容器中运行 ServerApp 与 ClientApp

Flower 框架 Docker 部署以子进程模式在 SuperLink/SuperNode 容器中运行 ServerApp 与 ClientApp【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flowerFlower 框架的 SuperLink服务端组件与 SuperNode客户端组件都支持两种应用隔离模式subprocess子进程模式与process独立进程模式。本文基于 Flower 框架官方文档《Run ServerApp or ClientApp as a Subprocess》完整介绍子进程模式下的镜像构建与容器启动方式并结合框架源码说明两种模式的底层实现差异帮助你在资源受限环境下用更少的容器部署 Flower 应用同时清楚理解其安全隔离边界。两种隔离模式subprocess 与 processSuperLink 和 SuperNode 各自负责启动并托管一类应用SuperLink 负责ServerAppSuperNode 负责ClientApp。二者的隔离模式通过--isolation命令行参数控制可选值为subprocess和process在源码中定义于 constant.py# Isolation modes ISOLATION_MODE_SUBPROCESS subprocess ISOLATION_MODE_PROCESS process两种模式的差异如下Subprocess 模式默认SuperLink / SuperNode 负责在自身进程内部拉起ServerApp/ClientApp的子进程。与process模式使用完全独立的容器不同子进程模式减少了运行中的容器数量对资源受限的环境更友好代价是应用与其父容器不隔离可能带来额外的安全顾虑例如应用代码与 SuperLink/SuperNode 运行时共享同一容器的文件系统与网络命名空间。Process 模式ServerApp和ClientApp运行在完全独立的进程中通常是独立容器SuperLink / SuperNode 不创建、不管理这些进程它们必须由外部如 docker compose启动。该模式的完整部署方式参见 tutorial-quickstart-docker.rst 文档。两种模式可以任意混合以获得灵活性。例如让 SuperLink 运行在subprocess模式、SuperNode 保持process模式或反过来——每个组件独立通过自己的--isolation参数选择。在源码层面该参数在两个 CLI 中的解析位置分别是 flower_superlink.py 与 flower_supernode.py默认值均为subprocess因此使用子进程模式时无需显式设置--isolation标志--isolation Isolation mode when running a ServerApp (subprocess by default, possible values: subprocess, process). Use subprocess to configure SuperLink to run a ServerApp in a subprocess. Use process to indicate that a separate independent process gets created outside of SuperLink.子进程模式的底层实现SuperExec从源码结构看子进程模式的核心是SuperExecflower-superexecSuperLink / SuperNode 启动时会自动 fork 出一个 SuperExec 子进程由它向宿主组件暴露 Runtime HTTP API实际的应用FAB 打包的ServerApp/ClientApp在该子进程内执行。SuperLink 侧的逻辑在 flower_superlink.py 的_start_superexec_if_needed中def _start_superexec_if_needed(self) - None: config self.config if config.isolation ! ISOLATION_MODE_SUBPROCESS: return runtime_host f[{config.host}] if : in config.host else config.host runtime_address resolve_bind_address(f{runtime_host}:{config.port}) command _get_superexec_command(...) self.superexec_process subprocess.Popen(command, **get_popen_detach_kwargs())SuperNode 侧逻辑类似位于 start_client_internal.py# Launch the SuperExec if the isolation mode is subprocess if isolation ISOLATION_MODE_SUBPROCESS: runtime_address resolve_bind_address(runtime_api_address) command [flower-superexec] command get_client_tls_args(...) command [--runtime-api-address, runtime_address] command [--plugin-type, ExecPluginType.CLIENT_APP] command [--parent-pid, str(os.getpid())] subprocess.Popen(command)两个关键细节通过--plugin-type区分插件类型SuperLink 自动拉起 SuperExec 时使用ExecPluginType.SERVER_APP见 _get_superexec_commandSuperNode 使用ExecPluginType.CLIENT_APP。在子进程模式下SuperExec 元数据认证--superexec-auth-secret-file会被自动禁用并打印警告start_client_internal.py因为 SuperExec 运行在受信任的父进程容器中不需要额外的 API 鉴权层。运行 ServerApp 作为子进程SuperLink 侧前置步骤 1扩展 SuperLink 镜像预装 FAB 依赖子进程模式下应用运行在 SuperLink 容器内部因此ServerApp 的 FABFlower App Build依赖必须先安装进镜像。做法是基于官方 SuperLink 镜像扩展出一个新镜像将 ServerApp 的pyproject.toml拷入镜像用sed删除其中的flwr[simulation]行框架本身已由基础镜像提供再执行pip install把应用自身的第三方依赖装进系统环境。Dockerfile 如下superlink.DockerfileFROM flwr/superlink:|stable_flwr_version| WORKDIR /app COPY pyproject.toml . RUN sed -i s/.*flwr\[simulation\].*// pyproject.toml \ python -m pip install -U --no-cache-dir . ENTRYPOINT [flower-superlink]其中|stable_flwr_version|是 Flower 文档的替换变量实际使用时替换为当前稳定版flwr的镜像 tag。注意ENTRYPOINT保持不变容器启动时仍由flower-superlink命令接管附加参数如--insecure会追加在该入口之后。仓库内官方 SuperLink 镜像的构建文件可参考 superlink/Dockerfile。前置步骤 2构建镜像在 Dockerfile 所在目录该目录同时包含 ServerApp 的pyproject.toml执行$ docker build -f superlink.Dockerfile -t flwr_superlink:0.0.1 .启动容器$ docker run --rm \ -p 8000:8000 -p 9092:9092 \ --detach \ flwr_superlink:0.0.1 \ --insecure \ --host 0.0.0.0各参数说明参数说明-p 8000:8000映射 SuperLink Runtime HTTP API 端口源码中SUPERLINK_UVICORN_DEFAULT_PORT 8000见 constant.py-p 9092:9092映射 Fleet APIgRPC-rere 传输层端口SuperNode 通过该端口与 SuperLink 通信--insecure以无 TLS 的 HTTP 启动默认启用 HTTPS仅在本机实验或自明其风险时使用--host 0.0.0.0Runtime HTTP API 绑定地址设为0.0.0.0否则容器内仅监听回环地址外部客户端不可达由于子进程模式是默认模式上述命令未设置--isolation即默认按subprocess运行。运行 ClientApp 作为子进程SuperNode 侧流程与 ServerApp 完全对称区别只是基础镜像换成flwr/supernode、入口换成flower-supernode。前置步骤 1扩展 SuperNode 镜像supernode.DockerfileFROM flwr/supernode:|stable_flwr_version| WORKDIR /app COPY pyproject.toml . RUN sed -i s/.*flwr\[simulation\].*// pyproject.toml \ python -m pip install -U --no-cache-dir . ENTRYPOINT [flower-supernode]前置步骤 2构建镜像$ docker build -f supernode.Dockerfile -t flwr_supernode:0.0.1 .启动容器$ docker run --rm \ --detach \ flwr_supernode:0.0.1 \ --insecure \ --superlink superlink-address:9092其中superlink-address为 SuperLink 容器的可达地址同主机可用localhost跨主机用对应 IP/域名9092是 Fleet API 端口与 SuperLink 容器映射的端口一致。SuperNode 侧无需映射 8000/9092 到宿主因为它只作为客户端向外连接SuperNode 自身 Runtime HTTP API 的默认端口为 9094SUPERNODE_UVICORN_DEFAULT_PORT见 constant.py仅在 SuperExec 等组件访问该 API 时涉及。关键 CLI 参数汇总子进程部署中最常用的参数适用于flower-superlink与flower-supernode参数默认值说明--isolationsubprocess隔离模式可选subprocess/process子进程模式无需显式设置--insecure关闭以 HTTP无 TLS运行默认启用 HTTPS--host127.0.0.1系列默认主机Runtime HTTP API 绑定主机跨容器访问需设为0.0.0.0--portSuperLink 8000 / SuperNode 9094Runtime HTTP API 端口取值范围 1–65535源码中_port_int校验见 flower_supernode.py--superlink[::]:9092SuperNode 连接 SuperLink Fleet API 的地址--max-retries/--max-wait-timeNone无限制与 SuperLink 重连的最大次数 / 最大等待时长模式选择建议资源受限、单机或少量节点优先使用subprocess模式每个 SuperLink / SuperNode 只占一个容器运维简单。前提是接受“应用与组件容器共享环境”这一安全边界适合自研可信应用的场景。多租户、强隔离要求改用process模式让 SuperExec 以独立容器运行官方镜像见 superexec/Dockerfile完整流程参考 tutorial-quickstart-docker.rst。混合部署两个组件各自独立选择模式可依据单侧的资源与安全约束分别决策。相关源码与文档flower_superlink.py--isolation解析、SuperExec 子进程启动与优雅关闭shutdown中会terminate()该子进程flower_supernode.pySuperNode CLI 参数与配置组装start_client_internal.pySuperNode 主循环与 SuperExec 拉起逻辑constant.py隔离模式与传输类型常量supercore/constant.pySuperLink/SuperNode 默认端口定义tutorial-quickstart-docker.rstprocess模式的独立容器部署指南tutorial-quickstart-docker-compose.rstdocker compose 部署方式【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考