【免费下载链接】cloud-in-a-bottleDeploy, use, and share web apps on a server you control. Your apps, data, and infrastructure stay yours.项目地址https://gitcode.com/gh_mirrors/cl/cloud-in-a-bottle点击查看免费下载Cloud in a Bottle 是一款让你在自己的服务器上部署、使用和分享 Web 应用的开源平台。它的核心设计之一就是把每个应用的存储拆成永久、临时、归档三层数据模型并用 JuiceFS S3 让归档层可以弹性扩展到对象存储。本文带你完整拆解这套存储架构的动机、实现细节与备份策略。为什么要分三层一个目录不够吗 很多自建平台给每个容器挂一个大目录就完事了。问题出在数据性格完全不同SQLite 数据库需要本地磁盘的真实fsync和严格 POSIX 语义绝不能放到网络文件系统上缩略图、构建产物随时可重建丢了不心疼照片、视频、附件体积巨大会撑爆本地磁盘却恰恰是你最不想丢的数据。Cloud in a Bottle 的做法每层一个独立目录默认只给永久层另外两层由应用在 manifest 里显式申请。这样权限最小化也方便备份策略分层处理。三层数据模型速览层级容器内路径底层存储是否进备份典型用途永久层(Permanent)/data/app_data/app本地磁盘✅ 包含SQLite 数据库、笔记、配置临时层(Temporary)/data/app_temp_data/app本地磁盘✅ 包含缩略图、转码缓存、构建产物归档层(Archive)/data/app_archive/appJuiceFS本地或 S3❌ 排除照片、视频、大附件、模型权重三个要点值得注意路径结构恒定应用无论被授予哪些权限看到的目录布局都一样只是没权限的目录不会被挂载。应用应读取环境变量BOTTLE_APP_DATA_DIR、BOTTLE_APP_TEMP_DIR、BOTTLE_APP_ARCHIVE_DIR而不是硬编码路径。临时层 ≠ 易失它只在容器重启或实例重启之间保留删除应用时会清掉但设计上要求可重建。特权通道文件浏览器、备份工具可申请access_all_app_data以读写方式挂载所有应用的三层目录。目录创建与环境变量注入的逻辑集中在 make_data_dirs_and_env_vars其中app_data默认开启app_temp_data和app_archive需显式申请。归档层设计为什么总是 JuiceFS这是整套架构里最精妙的一处。源码注释说得直白归档层永远是一个 JuiceFS 卷变化的只是 JuiceFS 底下的对象存储见 archive_backend.py 模块注释后端对象存储位置特点Local默认实例本地磁盘--storage file零配置开箱即用但机器坏了数据就没了S3你自己提供的 S3/S3 兼容桶数据落到实例之外未缓存首读有几十到几百毫秒延迟这样设计带来的直接好处应用无感容器永远 bind-mount 同一个 JuiceFS 挂载点应用生命周期完全不需要知道背后是本地盘还是 S3随处可装申请归档层的应用在任何实例上都能跑因为挂载点形态永远一致元数据独立JuiceFS 把文件名 → 对象的映射放在本地 SQLite 元数据库meta.db并定期把元数据转储到对象存储。⚠️ 注意仅恢复 S3 对象无法重建归档文件系统还需要可用的元数据转储 手动juicefs load。JuiceFS 挂载由 systemd 服务openhost-juicefs托管unit 模板见 openhost-juicefs.service.j2Restartalways保证 FUSE 进程被 OOM 杀掉后自动恢复。从 Local 切换到 S3数据如何无损搬家担心本地盘不持久可以在面板里把归档后端切到 S3整个过程是 JuiceFS 原生迁移列出受影响应用切换前面板会显示哪些应用的归档数据会被迁移由 local_archive_apps_with_data 扫描挂载点得出确认保护存在本地归档数据时必须显式勾选确认API 层面用 409 confirm_migrate_local守卫防止误操作复制 校验用juicefs sync --check-all把每个对象复制到新桶并逐一比对捕获短读/损坏重指向同一卷juicefs config --storage/--bucket只改数据后端元数据库原封不动——所有文件、权限、属主完整保留Fail-open 语义切换提交前出任何问题卷继续从原存储读取绝不出现数据搬了一半、两边都读不到的中间态。同一个机制还支持 S3 → S3换桶、换供应商如 AWS → MinIO。数据在磁盘上的落位所有东西都在实例数据目录config.toml中的data_root_dir通常是~/.openhost/local_compute_space/下路径内容persistent_data/app_data/app/各应用永久数据persistent_data/app_archive_local_objects/JuiceFS 原始对象仅 local 后端persistent_data/openhost/路由数据库、TLS 证书、密钥、JuiceFS 状态persistent_data/openhost/juicefs/state/meta.dbJuiceFS 文件名→对象映射temporary_data/app_temp_data/app/临时数据 构建/容器日志app_archive/JuiceFS 挂载点完整说明见 docs/src/how_it_works/data.md。备份视角哪些层会被快照内置备份应用基于 restic✅永久层 临时层被快照排除备份应用自己的永久数据目录❌归档层两种后端都排除——本地后端本来就没有机外副本S3 后端对象虽在实例外但恢复还需 JuiceFS 元数据属于独立的恢复流程❌实例状态router.db、证书、JuiceFS 元数据标准挂载不会暴露给任何应用需要时得走 SSH 或面板终端自己复制。另外提醒备份读的是活文件不会停应用或做数据库一致性转储所以含数据库文件的快照不保证应用级一致。磁盘守卫别让实例把盘写满 在一台存着自己数据的主机上把磁盘跑满比提前停服更糟。因此实例预留了安全水位可用空间低于storage_min_free_mb默认500 MB时存储守卫会停止正在运行的应用直到腾出空间阈值可在config.toml修改设为0关闭守卫改完重启生效。给应用开发者的三条实践建议默认只依赖永久层数据库、配置放BOTTLE_APP_DATA_DIR别自己发明路径缓存类产物声明app_temp_data true接受删除即清除的语义大文件才申请app_archive true索引留在永久层、字节放归档层是官方文档推荐的标准组合见 manifest 规范 [data] 段落 与 应用数据存储说明。总结Cloud in a Bottle 的三层数据模型本质是一套按数据价值与体积分级的存储策略永久层保正确性本地盘 严格 POSIX临时层换性能可重建的缓存随便写归档层换容量与持久性JuiceFS 卷Local/S3 后端可平滑迁移。三层各司其职、互不越界备份策略也随之分层清晰——这正是应用、数据和基础设施都归你自己这句话在存储层面的落地。赞分享【免费下载链接】cloud-in-a-bottleDeploy, use, and share web apps on a server you control. Your apps, data, and infrastructure stay yours.项目地址https://gitcode.com/gh_mirrors/cl/cloud-in-a-bottle点击查看免费下载相关推荐终极入门mirai-api-http插件安装与配置教程从零基础到成功运行终极入门mirai api http插件安装与配置教程从零基础到成功运行 mirai api http是一款功能强大的QQ机器人接口插件它能帮助开发者轻松Meshery 数据持久层架构Bitcask、SQLite 与内存存储的设计解析Meshery 数据持久层架构Bitcask、SQLite 与内存存储的设计解析 本文围绕 Meshery 官方架构文档《Database》展开系统讲解 M云原生微服务运维DevOpsFathom Lite数据归档存储S3兼容方案全解析Fathom Lite数据归档存储S3兼容方案全解析 数据备份痛点与解决方案 你是否还在为网站分析数据的安全存储发愁随着用户量增长Fathom Lite收数据分析后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考