Dify内网离线部署

1、dify-1.3.0源码、及 核心镜像包

docker-compose.yaml配置文件中，查看需要的镜像，前几个必要、后几个按需加载

• langgenius/dify-api：核心 API 服务，处理所有外部请求（如模型调用、应用管理、知识库操作）

• langgenius/dify-web：可视化前端界面，提供用户操作入口（如应用创建、知识库管理、工作流编排）。基于 React 的 Web 界面，支持拖拽式工作流设计。

• langgenius/dify-plugin-daemon：插件运行环境，管理第三方插件的加载和执行

• langgenius/dify-sandbox：代码执行沙箱，用于运行自定义工具或脚本。隔离执行环境，防止代码注入攻击；提供文件系统和网络访问控制；与 SSRF 代理联动，限制外部请求范围。

• langgenius/dify-worker：异步任务处理引擎，处理文档解析、知识库更新、模型缓存等耗时任务；支持任务优先级和失败重试策略。

• langgenius/dify-worker-beat：定时调度。

• postgres：关系型数据库，存储系统元数据（用户、应用配置、任务日志等）

• redis：内存数据库，用于缓存模型调用结果、会话状态和任务队列。提升高频访问场景下的响应速度。

• nginx：反向代理服务器，处理 HTTP 请求路由和负载均衡。转发流量至 dify-api 和 dify-web；实现速率限制。

• minio：对象存储服务，存储上传的文档、音频、视频等文件。兼容 S3 协议，支持分布式存储

• squid：SSRF（服务器端请求伪造）代理，过滤外部请求，拦截未经授权的 HTTP/HTTPS 请求；限制沙箱和插件的网络访问范围；防止恶意代码通过 API 发起攻击。

• weaviate：向量数据库，用于存储文档嵌入向量（替代默认的 SQLite-Vector）。支持高效的语义搜索和多模态检索。

• opensearch：全文搜索引擎，用于关键词检索和日志分析。补充向量检索的召回率，支持混合检索模式；提供可视化的日志查询界面。

  镜像下载

  docker pull --platform linux/amd64 <xxx镜像名称>

  本地保存镜像，内网上传后使用

  docker save --platform linux/amd64 -o <xxx.tar> <xxx镜像名称>

2、docker安装包、docker-compose安装、镜像安装

3、.env环境变量配置

4、docker-compose.yaml容器配置文件

集群模式需要修改涉及的中间件配置。

5、容器启动

在dify1.3.0/docker 目录下执行启动命令：

# 停止容器
docker-compose -f docker-compose.yaml down

# 启动容器
docker-compose -f docker-compose.yaml up -d

# 查看容器列表及状态
docker ps -a

6、插件安装

常用插件：OpenAI-API-compatible、Ollama、rookie_text2data、ECharts图表生成、MinerU文档解析、文档转换、OCR解析、MCP服务 等工具插件。

内网依赖无法满足，因此在外网将插件requirements.txt中需要的全量依赖打包下载后传入内网。

pip download -r requirements.txt --dest ./wheels --platform manylinux_2_17_x86_64

内网修改requirements.txt，增加该依赖引用。

--no-index --find-links=./wheels/

安装插件时可能显示校验不通过，我们需要修改配置文件.env，允许安装所有未在marketplace上架的插件。

FORCE_VERIFYING_SIGNATURE = FALSE

在Dify内网离线部署过程中，以下是最常遇到的典型问题及解决方案：

---

一、环境依赖问题

1. 依赖包缺失

   • 现象 ：安装时提示ModuleNotFoundError或dependency resolution failed
   • 原因：内网无法访问PyPI/NPM源，离线包未完整导入
   • 解决方案 ：

     • 提前在联网环境打包全量依赖：

       pip download -r requirements.txt --platform manylinux2014_x86_64

     • 使用--no-index --find-links=/path/to/packages安装

2. 离线环境Dify ollama插件安装，尝试了离线包安装、本地安装插件打包镜像上传两种方式，均不同程度的失败。

插件、下载difypkg文件，安装。

添加模型时，模型名称不能随便填，ollama list命令查看模型名称。

Dify默认配置限制：.env文件中修改

1. CODE_MAX_STRING_ARRAY_LENGTH

• 问题：代码执行组件中，return的字符串数组长度超过30就报错
• 报错：The length of output variable 'result' must be less than 30 elements.
• 解决方法：提高该配置项的值

• MAX_SUBMIT_COUNT

• • 问题：迭代组件设置为并行时，当"输入数组长度×设置的并行数>100"时报错
  • 报错：Max submit count 100 of workflow thread pool reached.
  • 解决方法：增加工作流最大并发线程数限制

• WORKFLOW_MAX_EXECUTION_STEPS

• • 问题：画布中所有工作流执行总次数达到500时触发限制
  • 报错：Max steps 500 reached.
  • 解决方法：调高工作流执行总次数限制

• WORKFLOW_CALL_MAX_DEPTH

• • 问题：工作流调用嵌套过深时报错
  • 报错：Max workflow call depth 5 reached.
  • 解决方法：增加工作流调用深度限制

• CODE_MAX_STRING_LENGTH

• • 问题：代码执行器中返回的字符串长度超过80000会报错
  • 报错：The length of output variable 'result' must be less than 80000 characters
  • 解决方法：增加最大字符串返回长度限制

• SERVER_WORKER_AMOUNT

• • 问题：一个工作流正在执行且耗时较长时，另一个工作流界面无法打开
  • 报错：无报错，页面一直等待
  • 解决方法：增加工作进程数，最大值=CPU核心数×2+1

• UPLOAD_FILE_SIZE_LIMIT

• • 问题：上传文件大小超过15M报错
  • 报错：上传document不能超过15M
  • 解决方法：增加允许的最大文件大小

  修改完成后执行docker-compose down && docker-compose up -d命令重启dify

---

二、配置陷阱

1. 网络隔离配置

   • 关键点 ：

     • 必须显式关闭外部服务探测（如Sentry/Telemetry）
     • 修改config.py中所有*_URL为内网地址

   • 验证命令 ：

     netstat -tuln | grep -E '5000|3000'  # 确认服务端口监听

2. 存储路径权限

   • 典型错误 ：

     • 容器内UID/GID与宿主机不一致导致volume写入失败

   • 根治方案 ：

     RUN chown -R 1000:1000 /app/storage  # Dockerfile中预设权限

---

三、容器化部署难点

1. 镜像构建臃肿

   • 优化策略 ：

     • 分阶段构建（前端+后端分离）
     • 使用Alpine基础镜像缩减体积

   • 示例 ：

     FROM node:18-alpine AS frontend
     RUN yarn build --prod
     
     FROM python:3.10-slim
     COPY --from=frontend /app/dist /static

2. 跨容器通信故障

   • 调试步骤 ：
     1. 确认Docker网络模式为bridge
     2. 使用docker-compose exec service ping other_service测试连通性
     3. 检查环境变量注入（如REDIS_HOST=redis）

---

四、数据持久化风险

1. 数据库初始化失败

   • 根本原因 ：

     • 首次启动时未自动执行migration

   • 应急方案 ：

     docker-compose run --entrypoint "alembic upgrade head" backend

2. 备份机制缺失

   • 必做措施 ：
     • 定时导出PostgreSQL：pg_dump -Fc > dify_backup.dump
     • 对象存储同步/minio冷备方案

---

五、后续维护隐患

1. 版本升级断链

   • 推荐流程 ：
     • 建立私有GitLab仓库镜像官方Repo
     • 通过CI/CD管道测试离线升级
   • 避坑提示 ：
     • 禁止跳过次要版本（如0.3→0.5需逐步升级）

2. 日志监控盲区

   • 部署时需预设 ：
     • ELK栈集成（Filebeat收集容器日志）
     • Prometheus监控端点/metrics暴露

终极建议：在预生产环境完整模拟离线部署流程，重点验证：

1. 依赖包完整性校验（sha256sum对比）
2. 高并发压力测试（模拟200+并发用户）
3. 断电恢复测试（验证数据库事务一致性）

外网获取Dify的 镜像

# 镜像下载
docker pull --platform linux/amd64 <镜像名称>
 
# 本地保存镜像为 .tar 文件
docker save --platform linux/amd64 -o dify-images.tar <你下载的镜像名称>

加载 Docker 镜像

# 加载tar包下所有镜像
docker load -i dify-images.tar

# 查看加载的镜像列表
docker images

修改配置文件

编辑 .env 文件：

• 确保 OPENAI_API_KEY 等依赖互联网的配置为空或替换为离线模型（如本地部署的 LLM）。

• 关闭无法离线使用的功能（如邮箱服务）。

六、Dify运行后文件对比分析

1. 源码目录结构

2. 运行后目录结构

3. 插件安装后所在位置

三、插件安装与迁移

1.插件安装

首先在联网的设备中安装插件，将需要的插件一次性装完。

2.更新插件镜像包

从运行的容器中更新镜像包，作用是将插件所用的依赖加入到镜像，避免使用下面命令后重新联网。

docker compose down

创建新的镜像：docker compose up -ddocker commit docker-plugin_daemon-1 langgenius/dify-plugin-daemon:0.0.6-local-24

docker compose down

删除原来的 langgenius/dify-plugin-daemon:0.0.6-local镜像：

docker tag langgenius/dify-plugin-daemon:0.0.6-local-24 langgenius/dify-plugin-daemon:0.0.6-local

docker compose up -d

3.导出镜像

docker save -o dify-plugin-24plugin.tar langgenius/dify-plugin-daemon:0.0.6-local......

4.打包用于启动Dify的源码目录

5.迁移至内网

- 导入镜像

docker load -i dify-plugin.tar

- 展开源码

- 启动服务

docker compose up -d

按上述操作，可能遇到如下问题：

源码目录下插件打包不了，提示无法访问此文件。解决办法：进入docker-plugin_daemon-1的容器，把storage目录打包，然后用docker cp拷出来。然后移动到内网的存储卷的目录dify/docker/volumes，解压重命名，启动容器，然后本地重新安装插件。