尧图网页设计 
Flower SuperLink 状态持久化Docker 下通过 --database 与卷挂载让数据跨容器重启保留【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flowerFlower SuperLink 默认把所有运行状态保存在内存中这意味着使用docker run --rm启动的 SuperLink 容器一旦停止连接注册、任务分派等全部状态随之丢失。本文以 Flower 官方文档“Persist the State of the SuperLink”为核心讲解如何通过--database参数加 Docker 卷挂载将 SuperLink 状态落盘到宿主机并结合仓库源码说明--database的默认值、内存态与 SQLite 态的选择逻辑以及 Docker Compose 场景下的等价配置读完即可在 Linux/macOS 宿主机上安全地让 SuperLink 状态跨容器重启保留。为什么需要持久化SuperLink 默认是内存态从 persist-superlink-state.rst 的定义看默认情况下 SuperLink 将其状态保存在内存in-memory中。当使用 Docker 的--rm标志运行容器时容器停止后其文件系统会被删除状态自然无法在两次容器启动之间保留。这一点在源码中可以得到直接印证。SuperLink 的入口命令flower-superlink定义了--database参数其默认值是 FLWR_IN_MEMORY_DB_NAME而该常量的取值是:flwr-in-memory:——一个明确的“不落盘”标记# framework/py/flwr/supercore/constant.py FLWR_IN_MEMORY_DB_NAME :flwr-in-memory:在 flower_superlink.py 中可以看到该参数的定义与帮助说明parser.add_argument( --database, helpA string representing the path to the database file that will be opened. If nothing is provided, Flower will just create a state in memory., defaultFLWR_IN_MEMORY_DB_NAME, )也就是说不传--database时Flower 只在内存中创建状态只有显式提供一个文件路径状态才会被写进数据库文件。源码视角--database 如何决定内存态还是文件态SuperLink 启动时通过 LinkStateFactory 创建状态实例。工厂类根据database参数二选一见 linkstate_factory.py# InMemoryState if self.database FLWR_IN_MEMORY_DB_NAME: self.state_instance InMemoryLinkState( self.federation_manager, object_store ) # SqlLinkState else: state SqlLinkState( self.database, self.federation_manager, object_store ) state.initialize() self.state_instance state从源码结构看逻辑非常清晰当database等于特殊值:flwr-in-memory:时使用InMemoryLinkState只要传入的是其他任何值都会走SqlLinkState分支即以文件路径打开一个 SQLite 数据库并执行state.initialize()。这解释了文档中“指定目录 数据库文件名”这一做法的本质——--database后面跟的实际上是一个 SQLite 文件路径而文件能否持久化取决于该路径是否位于 Docker 挂载卷上。宿主机操作步骤Linux 权限要点根据 persist-superlink-state.rst要在宿主机上持久化 SuperLink 状态只需指定两样东西宿主机上用于保存数据库文件的目录以及数据库文件的名称。这里有一个容易踩坑的权限细节SuperLink 容器默认以名为app、UID 为49999的非 root 用户运行在 superlink/Dockerfile 中镜像基于flwr/baseENTRYPOINT为flower-superlinkapp用户定义在基础镜像中。在 Linux 上使用 Docker 时文档建议先创建目录并把它的所有者改为 UID49999确保挂载目录拥有正确的写权限。完整示例继承自原文档版本以仓库 compose 文件当前默认值1.38.0为例可用latest或其他已发布 tag 替换# 1. 创建宿主机上的状态目录 $ mkdir state # 2. 将目录所有者改为容器内 app 用户的 UID49999 $ sudo chown -R 49999:49999 state # 3. 挂载目录并以 --database 指定数据库文件启动 SuperLink $ docker run --rm \ --volume ./state/:/app/state flwr/superlink:1.38.0 \ --database state/state.db \ additional-args各要素说明--volume ./state/:/app/state把宿主机./state/目录挂载到容器内/app/state使数据库文件落在宿主机磁盘上--database state/state.db相对容器工作目录的数据库文件路径最终落盘为宿主机的./state/state.dbadditional-argsSuperLink 的其余启动参数例如--insecure、--isolation process、--host 0.0.0.0、--port 8000等完整参数定义见 flower_superlink.py。状态的创建、恢复与重置SuperLink 一启动就会在宿主机state目录中创建state.db文件如果文件已存在SuperLink 会尝试从文件中恢复此前的状态——这正是“跨容器重启保留状态”的实现机制。如果想让 SuperLink 以空数据库启动只需在执行docker run之前确认state目录中没有state.db例如rm state.db。事后清理如果之后想删除该目录由于目录当前属于 UID 49999可以直接用sudo chown -R $USER:$(id -gn) state把属主改回当前用户再执行删除。Docker Compose 中的等价配置如果通过 Docker Compose 部署完整的 Flower 部署运行时SuperLink SuperExec SuperNode仓库提供了带状态持久化的示例文件 with-state.yml。其 SuperLink 服务的核心配置是services: superlink: command: - --insecure - --isolation - process - --host - 0.0.0.0 - --port - 8000 - --databasestate/state.db volumes: - ./state/:/app/state/:rw可以看到它与手工docker run的写法完全对应command中追加--databasestate/state.dbvolumes中把宿主机./state/以读写模式挂到/app/state/。该文件还以注释形式给出了开启 TLS 时同样持久化状态的变体在command中改用--ssl-ca-certfile、--ssl-certfile、--ssl-keyfile并保留--databasestate/state.db可作为与 TLS 部署参见 with-tls.yml结合持久化时参考。而默认的 compose.yml 中 SuperLink 并未配置--database属于纯内存态两者对比可以直观看出持久化仅需要这两处改动。版本与适用前提镜像版本仓库中 compose 文件默认使用FLWR_VERSION:-1.38.0SuperLink 镜像支持latest、unstable及逐版本 tag完整 tag 列表见 superlink/README.md支持amd64与arm64v8架构。固定版本 tag 的做法可参考 pin-version.rst权限前提UID49999的 chown 步骤主要针对 Linux 宿主机的 Docker若宿主机目录权限模型不同如 macOS/Windows 上的 Docker Desktop挂载目录的权限通常由 Docker 运行时自动处理可按需省略 chown 步骤数据库文件语义state.db是SqlLinkState打开的 SQLite 数据库文件SuperLink 启动时若文件存在即尝试恢复状态删除文件即得到全新状态这一行为在 persist-superlink-state.rst 与 linkstate_factory.py 的分支逻辑中相互印证。总结让 SuperLink 状态持久化本质上只做一件事——给--database一个落在挂载卷上的文件路径并保证容器内app用户UID 49999对该卷有写权限。其余如 TLS、SuperNode 认证等配置都保持原有文档的用法不变。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Flower SuperLink 状态持久化：Docker 下通过 --database 与卷挂载让数据跨容器重启保留
Flower SuperLink 状态持久化Docker 下通过 --database 与卷挂载让数据跨容器重启保留【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flowerFlower SuperLink 默认把所有运行状态保存在内存中这意味着使用docker run --rm启动的 SuperLink 容器一旦停止连接注册、任务分派等全部状态随之丢失。本文以 Flower 官方文档“Persist the State of the SuperLink”为核心讲解如何通过--database参数加 Docker 卷挂载将 SuperLink 状态落盘到宿主机并结合仓库源码说明--database的默认值、内存态与 SQLite 态的选择逻辑以及 Docker Compose 场景下的等价配置读完即可在 Linux/macOS 宿主机上安全地让 SuperLink 状态跨容器重启保留。为什么需要持久化SuperLink 默认是内存态从 persist-superlink-state.rst 的定义看默认情况下 SuperLink 将其状态保存在内存in-memory中。当使用 Docker 的--rm标志运行容器时容器停止后其文件系统会被删除状态自然无法在两次容器启动之间保留。这一点在源码中可以得到直接印证。SuperLink 的入口命令flower-superlink定义了--database参数其默认值是 FLWR_IN_MEMORY_DB_NAME而该常量的取值是:flwr-in-memory:——一个明确的“不落盘”标记# framework/py/flwr/supercore/constant.py FLWR_IN_MEMORY_DB_NAME :flwr-in-memory:在 flower_superlink.py 中可以看到该参数的定义与帮助说明parser.add_argument( --database, helpA string representing the path to the database file that will be opened. If nothing is provided, Flower will just create a state in memory., defaultFLWR_IN_MEMORY_DB_NAME, )也就是说不传--database时Flower 只在内存中创建状态只有显式提供一个文件路径状态才会被写进数据库文件。源码视角--database 如何决定内存态还是文件态SuperLink 启动时通过 LinkStateFactory 创建状态实例。工厂类根据database参数二选一见 linkstate_factory.py# InMemoryState if self.database FLWR_IN_MEMORY_DB_NAME: self.state_instance InMemoryLinkState( self.federation_manager, object_store ) # SqlLinkState else: state SqlLinkState( self.database, self.federation_manager, object_store ) state.initialize() self.state_instance state从源码结构看逻辑非常清晰当database等于特殊值:flwr-in-memory:时使用InMemoryLinkState只要传入的是其他任何值都会走SqlLinkState分支即以文件路径打开一个 SQLite 数据库并执行state.initialize()。这解释了文档中“指定目录 数据库文件名”这一做法的本质——--database后面跟的实际上是一个 SQLite 文件路径而文件能否持久化取决于该路径是否位于 Docker 挂载卷上。宿主机操作步骤Linux 权限要点根据 persist-superlink-state.rst要在宿主机上持久化 SuperLink 状态只需指定两样东西宿主机上用于保存数据库文件的目录以及数据库文件的名称。这里有一个容易踩坑的权限细节SuperLink 容器默认以名为app、UID 为49999的非 root 用户运行在 superlink/Dockerfile 中镜像基于flwr/baseENTRYPOINT为flower-superlinkapp用户定义在基础镜像中。在 Linux 上使用 Docker 时文档建议先创建目录并把它的所有者改为 UID49999确保挂载目录拥有正确的写权限。完整示例继承自原文档版本以仓库 compose 文件当前默认值1.38.0为例可用latest或其他已发布 tag 替换# 1. 创建宿主机上的状态目录 $ mkdir state # 2. 将目录所有者改为容器内 app 用户的 UID49999 $ sudo chown -R 49999:49999 state # 3. 挂载目录并以 --database 指定数据库文件启动 SuperLink $ docker run --rm \ --volume ./state/:/app/state flwr/superlink:1.38.0 \ --database state/state.db \ additional-args各要素说明--volume ./state/:/app/state把宿主机./state/目录挂载到容器内/app/state使数据库文件落在宿主机磁盘上--database state/state.db相对容器工作目录的数据库文件路径最终落盘为宿主机的./state/state.dbadditional-argsSuperLink 的其余启动参数例如--insecure、--isolation process、--host 0.0.0.0、--port 8000等完整参数定义见 flower_superlink.py。状态的创建、恢复与重置SuperLink 一启动就会在宿主机state目录中创建state.db文件如果文件已存在SuperLink 会尝试从文件中恢复此前的状态——这正是“跨容器重启保留状态”的实现机制。如果想让 SuperLink 以空数据库启动只需在执行docker run之前确认state目录中没有state.db例如rm state.db。事后清理如果之后想删除该目录由于目录当前属于 UID 49999可以直接用sudo chown -R $USER:$(id -gn) state把属主改回当前用户再执行删除。Docker Compose 中的等价配置如果通过 Docker Compose 部署完整的 Flower 部署运行时SuperLink SuperExec SuperNode仓库提供了带状态持久化的示例文件 with-state.yml。其 SuperLink 服务的核心配置是services: superlink: command: - --insecure - --isolation - process - --host - 0.0.0.0 - --port - 8000 - --databasestate/state.db volumes: - ./state/:/app/state/:rw可以看到它与手工docker run的写法完全对应command中追加--databasestate/state.dbvolumes中把宿主机./state/以读写模式挂到/app/state/。该文件还以注释形式给出了开启 TLS 时同样持久化状态的变体在command中改用--ssl-ca-certfile、--ssl-certfile、--ssl-keyfile并保留--databasestate/state.db可作为与 TLS 部署参见 with-tls.yml结合持久化时参考。而默认的 compose.yml 中 SuperLink 并未配置--database属于纯内存态两者对比可以直观看出持久化仅需要这两处改动。版本与适用前提镜像版本仓库中 compose 文件默认使用FLWR_VERSION:-1.38.0SuperLink 镜像支持latest、unstable及逐版本 tag完整 tag 列表见 superlink/README.md支持amd64与arm64v8架构。固定版本 tag 的做法可参考 pin-version.rst权限前提UID49999的 chown 步骤主要针对 Linux 宿主机的 Docker若宿主机目录权限模型不同如 macOS/Windows 上的 Docker Desktop挂载目录的权限通常由 Docker 运行时自动处理可按需省略 chown 步骤数据库文件语义state.db是SqlLinkState打开的 SQLite 数据库文件SuperLink 启动时若文件存在即尝试恢复状态删除文件即得到全新状态这一行为在 persist-superlink-state.rst 与 linkstate_factory.py 的分支逻辑中相互印证。总结让 SuperLink 状态持久化本质上只做一件事——给--database一个落在挂载卷上的文件路径并保证容器内app用户UID 49999对该卷有写权限。其余如 TLS、SuperNode 认证等配置都保持原有文档的用法不变。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考