Flower 1.11.0 版本深度解析FAB 动态代码分发、ClientApp 隔离执行与企业级 Docker 部署【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flowerFlowerA Friendly Federated AI Framework在 1.11.0 版本2024-08-30中完成了联邦学习系统向永久基础设施 动态代码分发模式的演进flwr run现在能把应用打包为 Flower App BundleFAB动态分发到正在运行的 SuperLink 与 SuperNodeSuperNode 引入三种--isolation隔离模式Docker 镜像族新增 Alpine 变体与flwr/clientapp专用镜像并配套了 All-in-One Compose。本文基于 v1.11.0 版本说明 与 framework/py 源码逐项解析这些特性的工作原理、CLI 用法、破坏性变更与迁移路径帮助读者把 1.11 的核心能力落地到自己的联邦学习工程中。一、核心特性FAB 动态代码分发1.1 从静态 App到可热更新的 App Bundle1.11 之前ClientApp与ServerApp通常需要预先部署到节点上更新代码意味着重新部署节点进程。1.11 引入的 FABFlower App Bundle机制彻底改变了这一点flwr run会把整个 Flower App 打包成一个独立的 FAB 文件然后经由SuperExec分发给 SuperLink 以及需要它的 SuperNodes。SuperExec、SuperLink、SuperNodes 从此可以作为永久运行的基础设施常驻而代码更新甚至全新项目都可以动态ship上去。flwr run是实现这一切的唯一入口其调用链可从源码中得到印证framework/py/flwr/cli/run/run.py 中run()先解析本地或远端 App 路径随后_run_with_control_api()调用build_fab_from_disk(app)把本地 App 目录打包成 FAB 字节流并计算fab_hash hashlib.sha256(fab_bytes).hexdigest()作为内容寻址标识最后封装成StartRunRequest携带fabfab_to_proto(fab)与override_config通过 Control API 提交给 SuperLink。SuperNode 侧则通过 Fleet API 的GetFab拉取与 run 关联的 FABframework/py/flwr/server/superlink/fleet/grpc_rere/fleet_servicer.py 中的GetFab方法按fab_hash从状态存储中取出 FAB 返回给请求节点。在 framework/py/flwr/supernode/start_client_internal.py 中SuperNode 收到消息后会调用get_fab(run_info.fab_hash, run_id)拉取并缓存 FAB随后用get_fused_config_from_fab(fab.content, run_info)融合 FAB 内配置与 run 配置构造运行所需的Context。1.2 FAB 的构建与格式FAB 本质上是带有固定元数据的一个 zip 归档命名规范为publisher.name.version.hash前缀8位.fab见 build.py 中的get_fab_filename。构建细节从源码可以确认固定时间戳write_to_zip使用FAB_DATE2024-10-01 00:00:00写入 zip 条目保证同一源码构建出的 FAB 字节级可复现进而保证fab_hashSHA-256稳定大小上限FAB_MAX_SIZE 10 * 1024 * 102410 MB见 framework/py/flwr/common/constant.py包含/排除规则支持fab-include/fab-exclude键与内置默认模式默认排除原始pyproject.toml改为注入带打包信息的配置版本点号替换文件名中的版本号将.替换为-如1.0.0→1-0-0避免与文件名分隔符混淆。手动构建可用flwr build不带参数打包当前目录或flwr build --app ./apps/flower-hello-world指定路径。但日常开发直接使用flwr run即可它会自动完成打包与分发。1.3 运行配置的传递flwr run通过--run-config传入运行时配置在 run.py 中这些键值对被parse_config_args解析后经user_config_to_proto序列化进StartRunRequest.override_config与 FAB 内配置融合get_fused_config_from_fab后供ClientApp/ServerApp的Context.run_config读取。二、ClientApp 隔离执行三种 isolation 模式2.1 为什么需要隔离在企业部署中ClientApp是来自不同团队、甚至第三方的代码需要对其行为施加严格限制。1.11 让 SuperNode 可以完全隔离地运行ClientApp并为此提供三种模式默认行为与旧版本一致同一进程内运行。模式命令运行方式适用场景未设置默认不带--isolation与 SuperNode 同进程开发调试、快速验证subprocess--isolationsubprocessSuperNode 启动子进程运行ClientApp需要进程级隔离、资源限制的通用部署process--isolationprocess外部独立进程运行ClientAppSuperNode 不管理其生命周期需预先启动、手动终止企业级 Docker 部署配合flwr/clientapp镜像从 CLI 定义可以确认flower-supernode的--isolation参数只接受subprocess与process两个取值且subprocess是当前默认值见 framework/py/flwr/supernode/cli/flower_supernode.py 与常量定义 framework/py/flwr/common/constant.py。2.2 隔离模式的工作原理在subprocess模式下SuperNode 启动时会在start_client_internal内通过subprocess.Popen([flower-superexec, ...])拉起一个SuperExec子进程--plugin-type CLIENT_APP、--parent-pid SuperNode PIDClientApp运行在该子进程中通过 SuperNode 暴露的 Runtime HTTP API 通信若启用运行时依赖安装还会追加--allow-runtime-dependency-installation参数。相关逻辑见 framework/py/flwr/supernode/start_client_internal.py。process模式则不在 SuperNode 侧启动任何子进程上述subprocess.Popen分支仅在ISOLATION_MODE_SUBPROCESS时执行SuperNode 只提供 Runtime HTTP API等待外部进程中的ClientApp接入这也是期望外部管理进程这一语义的源码依据。SuperNode 与 SuperLink 之间的消息循环在 start_client_internal.py不断_pull_and_store_message拉取消息含 FAB 拉取、校验、Context 构建再_push_messages把ClientApp的回复推回 SuperLink实现拉取-处理-推送的闭环。2.3 隔离模式与 SuperExec 认证源码中还有一个值得注意的约束subprocess模式下若同时提供了 SuperExec 认证 secretSuperNode 会记录 WARN 日志并忽略该 secretSuperExec auth is disabled for the Runtime API in subprocess isolation mode因为子进程场景的 Runtime API 认证语义与外部进程场景不同而process模式才真正使用--superexec-auth-secret-file加载的认证密钥。这在 flower_supernode.py 与 start_client_internal.py 中有完整实现。三、企业级 Docker 部署改进3.1 新增镜像与推荐架构1.11 的 Docker 改进围绕企业部署展开flwr/supernode新增 Alpine 镜像更小的镜像体积适合作为常驻基础设施的轻量载体新增flwr/clientapp镜像专用于--isolationprocess模式。此时 SuperNode 与ClientApp运行在两个不同的容器中flwr/supernode推荐 Alpine 版本以--isolationprocess长期运行flwr/clientapp容器运行ClientApp。这是官方推荐的企业级部署方式——SuperNode 只负责调度与通信用户代码被完全隔离在独立容器内All-in-One Docker Compose可在单机上一条命令启动完整的 Flower Deployment EngineSuperLink SuperExec SuperNode。相关镜像与编排文件可在仓库的 framework/docker 目录找到supernode/、superlink/、superexec/各有独立镜像目录与 READMEcomplete/目录下提供compose.ymlAll-in-One、with-tls.yml启用 TLS与with-state.yml持久化状态等编排模板distributed/目录则提供 client/server 分离部署的 Compose 模板。3.2 隔离、TLS 与认证的配合企业部署通常需要将隔离模式、TLS 与节点认证组合使用。flower-supernode的完整参数集见 flower_supernode.py包括--superlinkSuperLink Fleet API 地址IPv4/IPv6/域名--insecure关闭 HTTPS默认启用 HTTPS仅理解风险时使用--root-certificatesPEM 根 CA 证书路径用于校验 SuperLink 的 TLS 证书--auth-supernode-private-keySuperNode 私钥路径启用节点认证公钥自动从私钥推导--auth-supernode-public-key已废弃--node-config空格分隔的键值对节点配置如--node-config partition-id0 num-partitions100--max-retries/--max-wait-time连接 SuperLink 失败时的重试上限与总等待时长默认 None 表示不限--trusted-entities指向 YAML 文件的路径映射公钥 ID 到公钥只有被这些实体签名的 FAB 才能在该 SuperNode 上运行--isolation前文所述隔离模式--grpc-rere/--grpc-adapter传输层选择grpc-rere为默认。值得注意节点认证仅支持grpc-rere传输且不安全的--insecure连接与节点认证互斥——若提供了私钥却未启用 TLSSuperNode 会直接退出并提示SuperNode authentication requires a secure TLS connection。这一约束的源码实现见 start_client_internal.py。--trusted-entities对应的 FAB 签名校验在 start_client_internal.py 的_verify_fabSuperNode 用信任实体表中的 Ed25519 公钥对 FAB 内容的 SHA-256 摘要 signed_at时间戳构成的待签名消息做签名验证任一信任实体验证通过即可运行校验失败或 SuperLink 不支持验签时会生成INVALID_FAB错误消息回传给 SuperLink。四、Simulation Engine 与 RecordSet 改进1.11 同时改进了单机仿真与消息数据模型Simulation Engine支持更完善的 run config、更详细的 verbose 日志并可通过flwr run直接配置仿真后端backend 类型、client_resources的 CPU/GPU 配额等。当前仓库中仿真相关实现集中在 framework/py/flwr/simulation其中run_simulation.py与app.py承载后端装配逻辑RecordSet 改进RecordSet是ClientApp与ServerApp之间交换模型参数、配置值和指标的核心对象。1.11 对其及相关的ParametersRecord、ConfigsRecord、MetricsRecord等*Record类型做了若干小改进提升状态交换的健壮性与可读性。ClientApp侧可通过context.state一个RecordDict在轮次间读写这些记录见 start_client_internal.py 中 Context 的构建。五、破坏性变更与迁移指南1.11 引入了三处必须注意的不兼容变更升级前请逐条核对5.1 CLI 改为接收 App 目录flower-supernode与flower-server-app的参数从ClientApp/ServerApp的引用改为app 目录。一个 app 目录指任何包含pyproject.toml且配置了相应 Flower 字段的目录。生成兼容项目结构的最简方式是flwr new——所有flwr new模板在 1.11 中均已更新展示最新推荐的 API 用法。5.2flower-client-app被禁用flower-client-appCLI 命令已禁用请改用flower-supernode。这与此前SuperNode 取代独立 client的演进方向一致。5.3 配置参数分隔符逗号改为空格向 Flower 传递 run config / node config 时键值对之间必须使用空格分隔# ✅ 正确空格分隔 flwr run . --run-config learning-rate0.01 num_rounds10 # ❌ 错误逗号分隔1.11 起不再支持 flwr run . --run-config learning-rate0.01,num_rounds10从源码看--node-config的 CLI help 也明确要求a space separated list of key/value pairs (separated by)见 flower_supernode.py与 1.11 的空格约定保持一致。5.4flwr example被移除实验性的flwr example命令已删除。替代路径先用flwr new生成项目骨架再用flwr run运行。六、弃用项Client.context由于client_fn与server_fn现在都会收到Context对象通过Client.context访问Context的方式已弃用未来版本将移除。若在Client实现中需要访问Context请在client_fn中创建实例时手动传入def client_fn(context: Context) - Client: return FlowerClient(context).to_client()七、版本演进与升级建议1.11 的架构重心在于把联邦基础设施与应用代码解耦。从当前仓库版本框架核心位于 framework/py/flwrDeployment Engine 组件分布在supernode/、superlink/、supercore/等子包Docker 编排见 framework/docker可以观察到这一方向的持续深化。针对 1.11 的升级路径建议先跑通flwr newflwr run基线用最新模板生成项目确认打包-分发-执行全链路正常企业部署优先选择--isolationprocessflwr/clientapp容器把ClientApp与 SuperNode 彻底分离配合--trusted-entities的 FAB 签名校验形成代码可动态分发、运行可严格隔离、来源可验证的完整安全边界检查脚本中的配置分隔符将所有逗号分隔的--run-config/--node-config改为空格分隔避免升级后静默失效尽早替换Client.context与flower-client-app/flwr example这些属于短期内的移除项应在下一次迭代中完成迁移。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考