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中需要的全量依赖打包下载后传入内网。

bash 复制代码

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

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

bash 复制代码

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

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

bash 复制代码

FORCE_VERIFYING_SIGNATURE = FALSE

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

一、环境依赖问题

依赖包缺失
- 现象：安装时提示ModuleNotFoundError或dependency resolution failed
- 原因：内网无法访问PyPI/NPM源，离线包未完整导入
- 解决方案 ：
  - 提前在联网环境打包全量依赖：
    bash 复制代码
```
pip download -r requirements.txt --platform manylinux2014_x86_64
```
  - 使用--no-index --find-links=/path/to/packages安装
离线环境Dify ollama插件安装，尝试了离线包安装、本地安装插件打包镜像上传两种方式，均不同程度的失败。

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

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

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

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

二、配置陷阱

网络隔离配置
- 关键点 ：
  - 必须显式关闭外部服务探测（如Sentry/Telemetry）
  - 修改config.py中所有*_URL为内网地址
- 验证命令 ：
  bash 复制代码
```
netstat -tuln | grep -E '5000|3000'  # 确认服务端口监听
```
存储路径权限
- 典型错误 ：
  - 容器内UID/GID与宿主机不一致导致volume写入失败
- 根治方案 ：
  dockerfile 复制代码
```
RUN chown -R 1000:1000 /app/storage  # Dockerfile中预设权限
```

三、容器化部署难点

镜像构建臃肿
- 优化策略 ：
  - 分阶段构建（前端+后端分离）
  - 使用Alpine基础镜像缩减体积
- 示例：
  dockerfile 复制代码
```
FROM node:18-alpine AS frontend
RUN yarn build --prod

FROM python:3.10-slim
COPY --from=frontend /app/dist /static
```
跨容器通信故障
- 调试步骤 ：
  1. 确认Docker网络模式为bridge
  2. 使用docker-compose exec service ping other_service测试连通性
  3. 检查环境变量注入（如REDIS_HOST=redis）

四、数据持久化风险

数据库初始化失败
- 根本原因 ：
  - 首次启动时未自动执行migration
- 应急方案 ：
  bash 复制代码
```
docker-compose run --entrypoint "alembic upgrade head" backend
```
备份机制缺失
- 必做措施 ：
  - 定时导出PostgreSQL：pg_dump -Fc > dify_backup.dump
  - 对象存储同步/minio冷备方案

五、后续维护隐患

版本升级断链
- 推荐流程 ：
  - 建立私有GitLab仓库镜像官方Repo
  - 通过CI/CD管道测试离线升级
- 避坑提示 ：
  - 禁止跳过次要版本（如0.3→0.5需逐步升级）
日志监控盲区
- 部署时需预设 ：
  - ELK栈集成（Filebeat收集容器日志）
  - Prometheus监控端点/metrics暴露

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

依赖包完整性校验（sha256sum对比）

高并发压力测试（模拟200+并发用户）

断电恢复测试（验证数据库事务一致性）

外网获取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. 源码目录结构

插件安装后所在位置

三、插件安装与迁移

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，解压重命名，启动容器，然后本地重新安装插件。

Dify内网离线部署

镜像下载

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

一、环境依赖问题

二、配置陷阱

三、容器化部署难点

四、数据持久化风险

五、后续维护隐患

外网获取Dify的 镜像

加载 Docker 镜像

修改配置文件

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

外网获取Dify的镜像