Dify 安全优雅升级到新版本指南
因为前段时间的 react 的漏洞,导致前面部署的 dify 版本都没有逃过,官方最新版本才解决,要解决的话可以选择自己修改自己部署的版本依赖然后重新打包镜像,或者是升级升级到官方修复 bug 的最新版本,众所周知 dify 的更新频率是非常快的,你几周不更新就发现跨越了多个大版本,好歹官方提供了完整的 docker 方案,并且能够轻松的一键保留数据并升级到最新版本,官方虽然有写如何升级,但是只是简单的教你备份然后拉取最新代码,如果我们有一些定制化代码的话,那么这个过程并不是那么容易和简单,并且合并最新代码会导致一堆冲突什么的,本文就将指导你如何优雅安全的升级生产最新版本,这个方案可以适用基于开源项目私有化定制和同时需要追踪开源最新代码的最佳实践。
在升级的第一要做的就是备份!!!切记,数据无价,我们为了做到更加安全的操作,我们要保证随时能够升级失败回滚的方案。
下面我们先看下官方说的升级方案,然后再说最佳实践。
官方升级教程
Back up your customized docker-compose YAML file (optional)
cd docker cp docker-compose.yaml docker-compose.yaml.$(date +%s).bakGet the latest code from the main branch
git checkout main git pull origin mainStop the service. Please execute in the docker directory
docker compose downBack up data
tar -cvf volumes-$(date +%s).tgz volumesUpgrade services
docker compose up -d
最佳实践
1、首先备份部署目录下的 dify/docker 下的所有文件。如果你还不知道我说的什么,可以先看我前面的部署教程《开源 LLM 应用开发平台 Dify 部署教程》
cd dify-1.7.1
tar -cvf dify.1.7.1 ./docker
# 再单独备份一下 volume 挂载目录
cd dify/docker
tar -cvf volumes-1.7.1.tgz volumes2、然后新创建一个仓库git仓库,仓库的作用就是用来对比当前部署版本和要升级的最新版本的部署文件的变动,用来精确的识别到需要调整的配置。
3、git仓库创建2个分支,分别是当前部署的代码分支代码和最新代码分支代码。
4、当前部署分支代码需要将当前部署的配置文件 .env 和 docker-compose.yaml 文件进行替换然后进行提交(因为这一步我们基于当时的最新版本改了一些自己的配置,比如域名,镜像地址,端口,数据库等等)
5、将最新代码分支的代码合并到当前部署分支的代码上,根据自己定制化的参数和修改自定义的参数选择解决冲突,最终生成我们要升级到目标版本的配置。
6、新创建一个最新版本的目录,直接拉取我们合并最新代码后的所有文件。
# 创建一个新目录不污染原目录导致不能回退
mkdir dify-1.11.2
# 克隆自己合并最新代码后的分支
git clone http://www.51it.wang/lcry/dify-deploy.git
# 切换到合并完的分支上
git switch -c mydify origin/mydify
# 然后拷贝 volumes 的文件到部署目录下
mv dify-1.7.1/docker/volumes-1.7.1.tgz .
tar -xvf volumes-1.7.1.tgz
# 注意我们这里的.env.example也是本地部署文件然后追踪了最新分支的,也就是说.env和.env.example两个配置文件每次部署理论是一样的
cp .env.example .env
# 启动
docker-compose up -d7、查看启动日志没报错,然后正常登录系统,检查数据、插件、配置等信息是否正确保留了
8、升级完成
总结
本文介绍了面对开源项目dify的高频升级,在基于开源项目做了定制化的操作上面如何安全优雅的做到升级,主要通过git仓库解决冲突,复制docker中的持久化目录到最新代码中即可保留数据进行升级,其中数据库部分是由dify的每个版本的升级sql自动操作无需人为干预,这一套最佳实践能够面对一切基于开源项目定开并且还需要持续追踪开源项目的代码的情况,但是通常建议我们在一周或者二周的一个周期内定时去合并上游代码,而不是很长时间不合并,这样会大大增加对比解决冲突的工作量,希望本文能给大家一些参考帮助。
商业转载请联系作者获得授权,非商业转载请注明本文出处及文章链接
