Deploy and unregister --rm-data silently destroy another instance's ExApp container and volume when two Nextclouds share one Docker daemon
维护者通常 3 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 65/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- docker, kubernetes, php
- 领域
- devops, infrastructure
调研方向
从 DockerActions.php:138 和 :81-88 开始，然后检查 Unregister.php:106 和 :135-139、ExAppsPageController.php:494-500 以及 AppAPIService.php:806/809 中的删除路径。将这些路径与 haproxy_agent.py:2374 中的实例标签处理进行比较。当 Docker 容器和卷带有实例标识，且删除操作拒绝删除属于其他实例的资源，同时保留同一实例的清理行为时，即视为完成。
由索引模型根据 Issue 内容生成。
描述
We lost the data volume of a working ExApp because a second Nextcloud instance on the same host uninstalled its own copy of the same app.
Setup: two Nextcloud instances (a real one and a throwaway test instance), each with its own HaRP, both pointing at the same Docker daemon. Container and volume names are built from the app id alone (nc_app_<appid>, nc_app_<appid>_data), so both instances resolved to the same container and the same volume.
Two things happened, and I think both deserve a look:
- Deploying the app on instance B force-removed the running container of instance A and recreated it with B's
APP_SECRETandNEXTCLOUD_URL(DockerActions.php:138on the HaRP path,:81-88on the classic one). A's app was broken from that moment, without any warning. occ app_api:app:unregister <appid> --rm-dataon B then deleted the shared volume. For us that was a search index over 50,000 files, roughly 19 hours of rebuild. Docker's own "volume is in use" protection could not help because step 1 had already removed the container that held it.
None of the removal paths checks who created the container or volume: the occ command (Unregister.php:106 and :135-139), the admin UI (ExAppsPageController.php:494-500), and removing a deploy daemon (AppAPIService.php:806/809), which deletes volumes without any flag at all.
I know about #523 and this is deliberately not another naming ticket: even with an instance prefix in place, existing volumes stay unprefixed and the removal paths still delete blindly. It is also not the multitenancy request from nextcloud/HaRP#49, rather the opposite: we do not want to share a container between instances, we want two independent deployments to stop destroying each other.
A fix that would have saved us, and that looks backportable: set labels on container and volume at create time (for example nextcloud.appapi.instance_id) and make the removal paths refuse when the label points to a different instance. Right now the Docker path sets no labels at all, while the Kubernetes path already sets app.kubernetes.io/instance from instance_id (haproxy_agent.py:2374), so the pattern exists in the codebase.
Observed with Nextcloud 34.0.3, AppAPI with HaRP 0.4.5, Docker on Ubuntu (arm64). Happy to share the full logs with timestamps.
- 主要语言
- PHP
- 星标
- 198
- 派生
- 26
- 平均合并
- 2 天 6 小时
- 30 天内合并 PR
- 48
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
nextcloud/app_api 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 3 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
nextcloud/app_api#1099 · 1 条评论 ·
维护者通常 3 天内回复
-
deploy discussion enhancement
难度 5/5 一周以上 新手友好度 30/100
维护者通常 3 天内回复
-
难度 4/5 3-5 天 新手友好度 38/100
nextcloud/app_api#1013 · 2 条评论 ·
维护者通常 3 天内回复
-
daemon enhancement
难度 3/5 1-2 天 新手友好度 52/100
维护者通常 3 天内回复
查看 nextcloud/app_api 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
Do not throw `WordPress.Security.EscapeOutput.OutputNotEscaped` on `apply_shortcodes()`可能已有人在做 @tbradsha 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 62/100
landsman/adminer-desktop#120 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
components-web-app/docs#227 ·
-
难度 1/5 1 小时以内 新手友好度 85/100