1
Mithril 2023-03-04 16:03:12 +08:00
定期备份,随缘更新。
有安全更新的话就去看看 release note ,如果自己的场景里可能被利用,那就立刻更新。 如果只是普通更新,或者不是什么特别严重的安全更新,那就差不多每个月备份完了更新一下。 反正都是 Docker ,备份更新四条命令的事。 |
2
edis0n0 OP 更新不现实,麻烦不说,更新炸了还影响别人开发
|
3
springz 2023-03-04 16:07:32 +08:00
一路从一个 5 年前的版本升上来的,按照 GitLab 官方提供的升级规则,一个版本一个版本往上升。前提是 Docker 部署的,自己部署的当我没说。
|
4
a33291 2023-03-04 16:08:18 +08:00
目前都是下班后直接从包管理器升级,暂未遇到任何升级故障.
比如前段时间,15.x 就有好几个漏洞报告,官方推荐升级 |
5
springz 2023-03-04 16:08:57 +08:00
公司用,云服务的话搞个磁盘快照再升,自己我是 ZFS + VM ,ZFS 打个快照再升级,炸了大不了滚回去。
|
6
perfectlife 2023-03-04 16:13:11 +08:00 via Android
我只能说这种基础服务用容器部署完全没啥优势,我是 yum 安装,维护最方便,每次更新按官方升级路线直接 update ,没啥问题。不想更新要么坦然接受安全问题,毕竟哪个软件没漏洞,要么就放到内网里
|
7
shelken 2023-03-04 18:36:47 +08:00 via iPhone
公司测试环境,因为一个漏洞被植入挖矿了,后来大佬一个版本一个版本往上升级。也没什么大坑吧
|
8
kongkx 2023-03-04 18:54:20 +08:00 via iPhone
|
9
cnhongwei 2023-03-05 10:51:31 +08:00
使用 docker 安装,看到有版本升级的时候就,刚好自己有点时间的时候升级,升级也就几分钟。没有出过问题,只是有一次升级的 gitlab 有 bug ,不过官方有解决办法,修改了配置参数就搞定了。我现在就发现,这种常升级一般很少出问题,有问题也容易回滚。等个 1 到 2 年,升几个大版本才麻烦,而且容易出问题。
|
10
leeg810312 2023-03-05 14:20:19 +08:00 via Android
搭个升级预演环境,测试一遍升级,可以把绝大多数坑都踩到,做好升级失败回滚预案,然后升级生产环境。几年不升级,跨几个大版本升级很可能会遇到数据迁移和必须大版本逐个升级的情况,反而更麻烦
|