1Panel 用着让人太郁闷了,不吐不快

  • 问题 1:1Panel 商店安装的 Umami v2 不能直接升级 v3。
    • 情况:
      • 先前就是使用 pg 的用户,手动更新镜像正常可用。
      • v2 和 v3 “重大变更”的 compose 文件就更新了个镜像地址和 healthchecklink
      • v2.20.0 修复最新满分 CVE 的版本,两天过去了商店里还没更新(提醒后已解决)
    • 开发人员提供的解决方案:
      • 即使实际更新了,你也没法让 1Panel 知道你真的更新了。
      • 建议用户自己重新部署 v3,然后把 v2 pg 数据迁到 v3 pg 数据。link
      • EDIT:楼主研究后,不需要迁移数据库,按照我提供的方案即可顺利更新 link
  • 问题 2:最新版本 2.0.15 更新后,子节点直接更新失败导致断连。 link
    • 开发人员提供的临时解决方案无法解决问题。
    • EDIT:我实际的解决方案是回退主节点版本,然后重新同步信息到子节点。link
5 个赞

一直都是宝塔 宝塔YYDS

4 个赞

一直用宝塔,中间换着用了两次 1panel,最后还是换回宝塔了

2 个赞

姜还是老的辣 而且宝塔这边出现问题 客服态度也非常积极配合解决
(不是水军 真实评价)

3 个赞

我用宝塔好像还没动过找客服的念头?

1 个赞

那别用了呗。个人小站的话,命令行用着用着就会了,就抛弃面板了。

2 个赞

我在个人建站的时候,用过1panel和宝塔。感觉1panel只是UI好看一点…

3 个赞

免费面板那么多,还是不上1panel了

2 个赞

对小白来说,1panel的docker管理还是方便些

1 个赞

我感觉都还好,可能我使用场景不多 :distorted_face:

项目不太多,都是自用的,直接docker-compose了,而且小鸡的内存也不太大:tieba_087:

v2和v3在docker配置上发生变化只是针对于重新部署而言,docker配置变化不代表软件整体架构的改变,否则latest意味着软件永远不变。通常软件发生变化major数据库结构同样会发生改变,设计良好的可能会直接迁移,设计不好的直接挂机失败,也就是破坏性更新。

1panel有一些镜像确实更新比较慢,不过也属于正常现象,毕竟没有那么多精力关注新版本。

上面提及到的更多是用户自己的责任,数据库内容迁移备份生产环境当中就是需要谨慎操作的。

事实上,Umami 对于 pg 用户, v2 → v3 就是可直接无缝升级。 :wink:

没法让用户自己指定实际版本,非得重装,这个设计就比较尴尬 :thinking:

补充:楼主是 1Panel 专业永久版用户。 :smiling_face_with_three_hearts: 总体上我还是觉得 1p 是好使的,但今天真郁闷到了。

3 个赞

1panel占内存

给使用 pg 数据库用户,在 1panel 从 Umami v2 升级 Umami v3 的操作方案:

  • 首先前往已安装的 Umami,记录以下信息
    • 数据库名
    • 数据库用户
    • 数据库用户密码
    • HTTP 端口
    • 哈希盐 (随机字符串)
    • 展开高级设置,记录先前设定(建议截图方便对照)
  • 删除已安装的 Umami,删除时选项不要删除关联的数据库
  • 重新安装新版 v3 Umami,按之前记录的信息填写。
  • 即可完成升级。

以前用过,我记得是可以自己自定义compose文件然后指定版本的吧,网页图形界面的配置会在文件当中体现,

现在 1p 更节约内存 https://m.bilibili.com/video/BV1B62aBMEsj

摘自视频评论区

实测显示,宝塔初始安装占 67M,比 1Panel 的 94M 低 27M;
但登录面板后,宝塔涨至 120.8M(增幅 80.3%),反超 1Panel 的 116.5M;
部署网站后,宝塔再升至 127.1M,1Panel 却降至 87M。
可见宝塔仅在安装完成时占优,后续内存持续升高,1Panel 后期更稳定且占用更低。
1 个赞

no,我从 v1 用到 v2,修改 compose 文件只是修改 compose 文件,不影响它记录的版本。

比如它商店只有 v2.19.0,我更新文件变成 v2.20.0,但记录依然是 v2.19.0,GUI 显示也是 v2.19.0,它检测更新也是以它记录的 v2.19.0 来检测。

1P的性能和高级功能一直不如宝塔,但它相对开放,UI也更现代化。对于刚接触服务器这一块的用户,1P的确是入门的好选择。