1.前言

​ dify 1.x版本以后插件功能丰富了很多，推出的插件市场上有各式各样的插件，比如 连接数据库、连接大模型、搜索和 mcp服务等。其中，有一个比较大的改动，模型供应商不再内置，而是通过插件的形式提供。因此，如果是内网离线部署，则必须提前准备好插件的安装包。

接下来，本文将从部署的角度对 dify的插件体系进行分析，总结项目落地时的经验。

环境信息：

​ Dify-1.1.3, Dokcer-26, CentOS-7.9

2.插件原理分析

2.1 插件运行环境

联网安装插件十分简单，打开插件市场，点击安装即可。

通过对比，发现 1.1.3版本的 dify比 0.8.3版本多了一个容器：docker-plugin_daemon。

在线安装插件时，查看 docker-plugin_daemon容器的日志发现会去下载很多依赖文件，因此插件的运行环境就是由这个容器提供和进行管理。

2.2 插件安装文件

观察到/app/storage/cwd/目录存放着插件安装后生成的文件，按提供厂商进行组织。

进入 docker-plugin_daemon-1容器的 /app/storage/cwd/langgenius/openai_api_compatible..目录，可以看到下面的内容：

total 44
drwxrwxrwx 7 root root 4096 Apr 8 07:35 ./
drwxrwxrwx 15 root root 4096 Aug 12 09:04 …/
drwxrwxrwx 6 root root 4096 Apr 8 07:35 .venv/
-rwxrwxrwx 1 root root 574 Apr 8 07:31 README.md*
drwxrwxrwx 2 root root 4096 Apr 8 07:35 pycache/
drwxrwxrwx 2 root root 4096 Apr 8 07:31 _assets/
-rwxrwxrwx 1 root root 125 Apr 8 07:31 main.py*
-rwxrwxrwx 1 root root 664 Apr 8 07:31 manifest.yaml*
drwxrwxrwx 8 root root 4096 Apr 8 07:35 models/
drwxrwxrwx 3 root root 4096 Apr 8 07:35 provider/
-rwxrwxrwx 1 root root 37 Apr 8 07:31 requirements.txt*

上面内容来自插件：openai_api_compatible，这里面有两个内容需要关注：

• venv

  这个目录存放的是运行该插件需要的 python虚拟环境，依赖的第三方包会在安装插件下载到该虚拟环境。

  这样设计使得每个插件都拥有单独的依赖环境，能够有效避免依赖包冲突。

• requirements.txt

  这里面记录了依赖的 python第三方包清单。

​ 通过观察插件安装完成后生成的文件，可以知道插件的运行需要 python环境，在安装时会为每个插件生成一个虚拟 python环境，各个插件依赖环境独立，互不影响。

3.制作插件安装包

3.1 官方途径

​ 通过官方插件市场下载的插件安装包为 difypkg格式，是一个二进制文件，通常只有几百kb。经过实测，在离线环境下安装依然会联网下载 python相关依赖，故此种方式无法实现真正的离线安装插件。

​ 这个包比较小，并不是完整的安装包，猜测应该是只有插件的依赖信息，比如 requirements.txt里包含的内容，在安装插件时才会去下载依赖的第三方包。

3.2 第三方

官网途径暂时走不通，发现有一个开源项目可以制作完整的插件安装包，名字叫做：dify-plugin-repackaging。

下面是实操后，总结的步骤：

1. 准备打包环境

   一台能联网、有 docker的 centos7.x服务器（虚拟机）。

2. 下载项目源码

   上传源码到打包环境并解压

3. 编译打包项目为 docker镜像

   进到解压后的目录执行下面的命令：

   docker build -t dify-plugin-repackaging .
   

4. 获取待制作插件的名称、公司名和版本号

   打开 dify插件市场，搜索要制作的插件，按下面的方式获取相关信息：

   

5. 制作插件完整安装包

   这里以 JSON 处理插件为例，使用下面的命令制作插件：

   docker run -v $(pwd):/app dify-plugin-repackaging ./plugin_repackaging.sh -p manylinux_2_17_x86_64 market langgenius json_process 0.0.2
   

   上面的命令中 langgenius是公司名，json_process是插件英文名，0.0.2是版本号。

   制作成功后，会出现下面1个目录和2个文件：

   

   其中这个 17M的文件 langgenius-json_process_0.0.2-offline.difypkg就是完整的插件安装包。

4.离线安装插件

经过第3步制作完成的安装包无法直接安装，需要调整 dify配置，并重启对应服务。

具体步骤如下：

1. 修改 env中的配置

   cd dify-1.1.3/docker
   cp .env.example .env
   vim .env
   
   # 修改下面的参数
   FORCE_VERIFYING_SIGNATURE=false
   PLUGIN_MAX_PACKAGE_SIZE=524288000
   NGINX_CLIENT_MAX_BODY_SIZE=1024M
   

   这里主要目的是放宽 nginx对于上传安装包的大小限制，否则会出现下面的 nginx报错：

   413 Request Entity Too Large

2. 重启 dify服务

   docker compose down
   docker compose up -d
   

3. 使用本地插件功能离线安装插件

   如下，按照提示上传刚刚制作好的插件包即可：

   

5.总结

​ 本文主要从部署的角度分析了 1.1.3版本的 dify插件安装包制作、文件组织方式和运行环境，这里有一个良好的设计值得我们借鉴：为每个插件单独准备一个 python虚拟环境，各个插件之间互不影响。同时，也得吐槽下官方下载的插件包无法直接离线部署。